Le début de scandale qui éclabousse le FBI suite aux révélations (cf lien en fin d’article) de Gregory Perry, ancien directeur technique de NetSec (devenu Verizon Business Security) soulève un point crucial que chacun (DSI ou citoyen lambda) doit garder en permanence à l’esprit : quelle confiance accorder aux logiciels et applications locaux et web ? En effet, nous confions de plus en plus de données personnelles et professionnelles à des systèmes informatiques dont nous ne maîtrisons ni le fonctionnement interne ni même l’origine. Et pourtant, les portes dérobées sont une véritable menace pour l’intégrité et la préservation de la confidentialité de nos données.
Une porte dérobée (back door pour les initiés) équivaut à la porte de derrière, celle dont la clef est dans le pot de fleur ou sous le paillasson. Une porte dérobée échappe (par définition) aux règles de contrôle interne. De ce point de vue, les portes dérobées forment une menace fantôme pour reprendre le titre d’un film bien connu : malgré les règles de contrôle interne, la politique d’habilitation et le paramétrage des pare-feux, le système (et ses données) est à la merci de tiers plus ou moins malveillants qui pourront consulter, modifier voire supprimer les données les plus stratégiques d’une entreprise ou d’une organisation, et ce, à son insu.
Pour détecter ces portes dérobées, il n’y a pas beaucoup de solutions :
– Soit analyser (avec un sniffeur IP) les flux réseaux générés par l’application vers l’extérieur (internet), ce qui au demeurant ne sera efficace que si le tiers accède au système pendant les opérations de surveillance réseau.
– Soit analyser le fonctionnement interne des logiciels. Pour ce faire, il est nécessaire de lire le code source ce qui requiert des connaissances pointues en programmation informatique. En réalité le code source n’est rendu public que pour les logiciels libres (open source) ; pour les autres logiciels, dits « propriétaires », l’analyse sera précédée d’une phase de rétro-ingénierie (reverse engineering), c’est-à-dire de la décompilation permettant d’obtenir un code source reconstitué, cette pratique est non seulement complexe (le code obtenu étant non documenté) mais de plus contrevient aux dispositions contractuelles des licences utilisateurs (CLUF).
Vous noterez que pour les applications en mode web, Saas, ASP (messageries en webmail, suites bureautiques Google ou Microsoft, réseaux sociaux, partage de fichiers et données…), aucune de ces opérations de contrôle n’est possible. Par ailleurs, ces logiciels et les données confiées sont la plupart du temps hébergés sur des serveurs situés à l’étranger (aux Etats-Unis entre autres), pays n’offrant pas les mêmes garanties de protection. L’externalisation de la fonction informatique et de ses applicatifs a un prix, celui de la dépendance.
Il serait exagéré de s’inquiéter outre mesure mais la prudence dans le choix de ses applications est de mise.
Lien externe : http://www.zdnet.fr/actualites/le-fbi-soupconne-d-avoir-integre-des-backdoors-dans-openbsd-39756913.htm
Derniers articles parBenoît RIVIERE (voir tous)
- VBA/SQL vs Power Query : deux solutions complémentaires - mercredi 2 octobre 2024
- L’IA dans les cabinets comptables : cas concrets - jeudi 26 septembre 2024
- EXCEL : insérer une image ou un logo dans une cellule - lundi 16 septembre 2024
- Lancer l’exécution d’un script Python à partir d’une macro VBA - lundi 9 septembre 2024
- Open Data : quoi de neuf ? - lundi 2 septembre 2024