Vigilance sécuritéLes 10 lois immuables de la sécurité revisitées, 1ère partie
Jesper M. Johansson
En 2000, Scott Culp a publié un article intitulé « Les 10 lois immuables de la sécurité ». C'est l'un des meilleurs articles sur la sécurité que j'aie jamais lu. Les informations qui y étaient présentées restent fondamentales pour tout travail en rapport avec la sécurité informatique et je vous recommande d'y jeter un coup d'œil (et même de l'imprimer) si ce n'est déjà fait. Il est disponible sur microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
Cet article a engendré diverses réactions. Certaines personnes ont fait remarquer sarcastiquement qu'il s'agissait pour Microsoft d'une façon d'éviter de corriger ce qui était perçu comme des problèmes sérieux. D'autres l'ont considéré comme LE document fondateur sur la sécurité et l'ont plagié sans vergogne du fait de son importance. Toutefois, certaines de mes réactions préférées sont celles où les personnes ont été inspirées et ont créé leurs propres listes, comme celle disponible sur edgeblog.net/2006/10-new-immutable-laws-of-it-security.
Au cours des huit années écoulées depuis la publication de cet article, il s'est passé beaucoup de choses dans le domaine de la sécurité. Pratiquement tous les vers un tant soit peu importants ont été mis en circulation. Nous sommes entrés dans un état de guerre de l'information (avec son crime organisé, ses entités politiques, etc.). De nouveaux mots et expressions font désormais partie du vocabulaire courant, notamment phishing (hameçonnage), pharming (détournement de site), botnet (réseau de zombies), logiciel espion et contrefaçon de requête intersite. Nous disposons désormais de certains des rootkits les plus sophistiqués jamais créés sur Windows. Nous avons de nouvelles versions de système d'exploitation dédiées, en grande partie, à la sécurité et d'autres systèmes d'exploitation qui ignorent toujours la sécurité.
L'ingénierie sociale s'est transformée en menace majeure. Les violations de données, comme lorsqu'un grand magasin a divulgué les numéros de 94 millions de cartes de crédit, font régulièrement la une des journaux (et pourtant les gens continuent à faire leurs courses dans ces magasins). Les gouvernements des États-Unis et du Royaume-Uni ont, collectivement, réussi à égarer les informations personnelles d'un pourcentage considérable des habitants du monde occidental (et pourtant les gens continuent à communiquer des informations personnelles à ces gouvernements). Et une énorme dose de comédie sécuritaire s'est immiscée dans nos vies, et dans nos aéroports.
Je pense qu'il est temps de jeter un nouveau coup d'œil à ces lois. Étant donné toutes les modifications survenues dans la première partie de ce siècle, pouvons-nous toujours prétendre que ces lois sont immuables ? Si elles le sont, si elles ont survécu aux 8 dernières années, on peut se risquer à dire qu'elles survivront aux 10 prochaines.
Dans cette série en trois parties, j'examinerai de façon critique chacune des 10 lois. Ce mois-ci, je traite des lois 1 à 3. Le mois prochain, je m'intéresserai aux lois 4 à 7. Et je consacrerai la dernière partie aux lois 8 à 10, en ajoutant quelques réflexions et commentaires qui semblent raisonnables au vu de ce qui s'est passé depuis que les lois ont été écrites en 2000.
Loi 1 : Si une personne malintentionnée peut vous persuader d'exécuter son programme sur votre ordinateur, ce n'est plus votre ordinateur.
Cette loi indique clairement que tout logiciel que vous exécutez sur un ordinateur peut prendre le contrôle de cet ordinateur. Lorsque les lois immuables ont été rédigées, les systèmes d'exploitation proposés par Microsoft étaient Windows 98, Windows Me et Windows NT 4.0. Aujourd'hui nous avons Windows Vista et Windows Server 2008.
Sur Windows 98 et Windows Me, tout logiciel que vous exécutiez disposait du contrôle total de l'ordinateur. Windows NT 4.0 bénéficiait d'un modèle de sécurité sous-jacent très solide, mais si vous l'exécutiez en tant qu'Administrateur, vous réduisiez son modèle d'isolation à celui de Windows 98 et Windows Me. Il était possible d'exécuter Windows NT 4.0 en tant que non-administrateur, mais cela était assez pénible et très peu d'organisations le faisaient (vous pourriez probablement compter le nombre total d'organisations à l'avoir fait sur les dix doigts de vos mains).
Imaginons que vous exécutiez véritablement Windows NT 4.0 en tant que non-administrateur. La loi 1 était-elle vraie lorsqu'elle a été écrite ? La réponse est oui. Tout d'abord, Windows NT 4.0 recelait un grand nombre de failles importantes. Par exemple, certaines autorisations auraient pu être plus strictes, notamment sur les objets de noyau et dans le Registre. De plus, de nombreux types d'attaques n'avaient pas encore été découverts, mais les experts s'attendaient à leur arrivée. Par exemple, en 1999 les gens ne s'étaient pas rendu compte que l'exécution des processus en tant qu'utilisateur bénéficiant d'un accès élevé sur le bureau interactif pouvait compromettre l'ordinateur. Ce n'est qu'en 2002, lorsque Chris Paget a publié son livre blanc sur les attaques destructrices, « Exploiting the Win32 API », que ce fait a été couramment admis (seclists.org/bugtraq/2002/Aug/0102.html).
Microsoft avait-il prévu les attaques destructrices lorsque la Loi 1 a été rédigée ? Non, pas vraiment. Microsoft a simplement reconnu un fait : il n'existe que très peu de vraies limites de sécurité pouvant empêcher une application exécutée sur un ordinateur de prendre le contrôle de cet ordinateur.
Windows Vista et Windows Server 2008 sont distantes de Windows NT 4.0 de deux générations. Ont-ils invalidé la Loi 1 ? Est-ce le cas d'autres systèmes d'exploitation ? Ça dépend. Il existe certainement des limites de sécurité plus solides dans les nouveaux systèmes d'exploitation et il existait des systèmes d'exploitation expérimentaux en 2000 qui avaient des limites de sécurité appropriées. Cependant, ces limites sont toujours rares. Par exemple, la sécurité d'accès au code dans Microsoft .NET Framework est une limite de sécurité. Elle est spécifiquement conçue pour empêcher le code exécuté dans le bac à sable d'affecter le système d'exploitation sous-jacent.
Les Iframes d'Internet Explorer fournissent une autre limite de sécurité. Mais les Iframes n'affectent pas l'accès au système d'exploitation lui-même, uniquement l'accès entre les éléments de contenu sur une page Web. Le mode protégé d'Internet Explorer, illustré à la figure 1, est une limite de sécurité au niveau système d'exploitation. Son but est d'empêcher le code exécuté dans un navigateur d'affecter le système d'exploitation sous-jacent, sans action de l'utilisateur. Il en existe quelques autres, telles que les comptes d'utilisateur standard, qui sont censés empêcher un compte utilisateur d'affecter le système d'exploitation sous-jacent ou un autre utilisateur.
Figure 1 Internet Explorer 7 utilise une limite de sécurité nommée Mode protégé (cliquez sur l'image pour l'agrandir)
Il est extrêmement important de comprendre ce que signifie l'expression « limite de sécurité ». Cela ne signifie pas qu'un mur inviolable garantit une isolation imperméable et indéfinie. L'expression signifie que le fournisseur du logiciel, Microsoft par exemple, est s'engage à remédier à toute violation de cette limite au moyen d'un correctif de sécurité. Les logiciels comporteront toujours des bogues et nous continuerons sans aucun doute à découvrir de nouvelles violations que les fournisseurs de logiciels continueront à corriger. Au fil du temps, ils devraient améliorer leurs logiciels pour empêcher ces vulnérabilités d'apparaître. Cela peut être considéré comme la confirmation que la Loi 1 est toujours valable.
Cependant, je dois aborder un dernier point crucial. Vous avez peut-être remarqué la phrase « sans action de l'utilisateur » utilisée ci-dessus. La Loi 1 ne concerne pas vraiment les défauts ou les vulnérabilités des logiciels. En réalité, elle concerne plutôt les vulnérabilités des personnes ! L'expression clé est « vous persuader ». Si une personne malintentionnée peut vous persuader d'exécuter son programme, elle peut probablement vous persuader de le faire dans un contexte qui, à dessein, donne au programme des privilèges élevés.
Même si vous n'avez pas de privilèges d'administrateur, ce n'est pas important. En tant qu'utilisateur standard, vous avez toujours accès à de nombreuses informations croustillantes : vos fichiers bancaires, lettres d'amour, photos, vidéos et données professionnelles confidentielles. Toutes ces données sont potentiellement intéressantes pour un attaquant et elles peuvent toutes être lues sans privilège élevé. Du point de vue des informations que vous gérez sur votre ordinateur, l'exécution d'un programme malveillant transmet tout ce que vous faites à l'attaquant. Donc, si vous définissez « votre ordinateur » comme « les données que vous gérez sur votre ordinateur », vous pouvez ignorer toute discussion sur les privilèges et simplement conclure que la Loi 1 reste valable.
Même sans couper les cheveux en quatre à propos de la définition de votre ordinateur, la Loi 1 semble avoir résisté à l'épreuve du temps. La Loi 1 vise à établir le fait que vous, en tant qu'opérateur d'un ordinateur, devez assumer la responsabilité des logiciels que vous exécutez sur cet ordinateur. Si vous installez un pilote malveillant ou un codec vidéo diabolique, vous avez transmis le contrôle intégral de cet ordinateur à un criminel !
Bien que les fournisseurs de logiciels puissent faire beaucoup pour empêcher les violations accidentelles, ce qui est l'objet des limites de sécurité, l'exécution intentionnelle d'un logiciel malveillant déjoue généralement toutes ces mesures de protection. C'est pourquoi parallèlement aux procédés qui garantissant que les utilisateurs n'ont pas l'autorisation d'exécuter des tâches administratives, l'éducation des utilisateurs est primordiale. On peut par conséquent dire sans risque que la Loi 1 reste vraie aujourd'hui, mais probablement avec une légère modification de la définition de votre ordinateur.
Loi 2 : Si une personne malintentionnée peut modifier le système d'exploitation de votre ordinateur, ce n'est plus votre ordinateur.
À première vue, cette loi semble assez simple. Il va de soi que si la personne malintentionnée peut modifier le système d'exploitation sur votre ordinateur, vous ne pouvez plus faire confiance à l'ordinateur. Mais le concept de système d'exploitation a changé au fil de l'évolution des besoins informatiques. Il y a de nombreuses années, j'ai rédigé la définition de l'expression « système d'exploitation » pour The Blackwell Encyclopedia of Management (managementencyclopedia.com). Cette définition parlait d'un système d'exploitation gérant l'accès aux périphériques d'entrée et de sortie, l'accès au matériel et ainsi de suite. Je n'ai jamais reçu d'exemplaire de cette encyclopédie et ma contribution originale n'est pas entrée dans l'histoire, mais je suis certain de ne pas avoir mentionné qu'un système d'exploitation inclut un jeu de solitaire, un système d'entrée pour Tablet et des transcodeurs vidéo.
Comme l'informatique est devenue de plus en plus complexe, les systèmes d'exploitation se sont développés pour prendre en charge bien plus de fonctionnalités. Pour compliquer le problème, les OEM incluent souvent leur propre assortiment de logiciels complémentaires, qui vont généralement d'outils vaguement utiles à des outils franchement nuisibles. En outre, certains de ces logiciels supplémentaires dupliquent des fonctionnalités déjà intégrées au système d'exploitation central.
Par exemple, une installation par défaut de Windows Server 2008 Édition Entreprise occupe plus de 5 gigaoctets. Windows Vista Édition Intégrale comprend plus de 58 000 fichiers, représentant plus de 10 gigaoctets. Et le système d'exploitation n'est pas constitué que de fichiers. Il y a les paramètres de configuration, des milliers d'entre eux ; et il y a des démons ou services.
Tout cela fait partie du système d'exploitation. Il s'agit d'un terme collectif qui inclut tous les fichiers, tous les paramètres de configuration et tous les services, ainsi que tous les objets d'exécution (sémaphores, canaux nommés, points de terminaison RPC) créés par les fichiers et paramètres de configuration. Même des constructions aussi abstraites que l'heure du système et certains types de données, comme les contenus de journaux d'événements, doivent être considérées comme éléments à part entière du système d'exploitation.
Étant donné la façon dont le système d'exploitation s'est développé et a évolué, est-il vrai que la modification de l'un de ces fichiers rend l'ordinateur non fiable ? La réponse directe est non. Par exemple, Windows Vista est équipé d'edlin.exe, l'ancien éditeur de ligne de MS-DOS. Je n'en ai pas la preuve, mais je parierais un triple moka qu'edlin.exe n'a été invoqué que deux fois sur toutes les copies installées de Windows Vista depuis la sortie de ce système d'exploitation. Et les deux fois, c'était il y a environ trois minutes, lorsque j'essayais de me rappeler la syntaxe. Si quelqu'un modifie edlin.exe ou un autre fichier que personne n'utilise jamais, cela signifie-t-il vraiment que votre ordinateur n'est plus votre ordinateur ?
Edlin.exe fait indiscutablement partie du système d'exploitation, mais si personne n'exécute jamais le fichier, comment sa modification peut-il compromettre votre ordinateur ? La réponse est, bien sûr, qu'elle ne le peut pas. La modification d'un élément du système d'exploitation qui n'est jamais utilisé ne compromet pas votre ordinateur. Et de nombreux éléments du système d'exploitation ne sont jamais utilisés.
Toutefois, la réponse indirecte est néanmoins oui. Il ne suffit pas de savoir si quelqu'un exécute un fichier pour voir si sa modification peut compromettre votre ordinateur. Le problème est plus subtil que cela. Jetons un coup d'œil à la liste de contrôle d'accès (ACL) pour edlin.exe, illustrée à la figure 2.
Figure 2 L'ACL pour edlin.exe est très restrictive (cliquez sur l'image pour l'agrandir)
L'ACL pour edlin.exe est très restrictive. Seul le service TrustedInstaller a le droit de modifier cet exécutable. C'est très important : cela signifie qu'il y a un effet indirect pour une personne malintentionnée modifiant ce fichier sur votre ordinateur. La modification d'edlin.exe signifie que ce n'est plus votre ordinateur. En l'occurrence, c'est le fait que l'utilisateur malintentionné a la possibilité de modifier edlin.exe qui est primordial. Si la personne malintentionnée peut modifier ce fichier, elle peut modifier n'importe quel fichier, ce qui signifie que vous ne pouvez plus faire confiance à votre ordinateur.
Le système d'exploitation se protège lui-même. Les services sont protégés contre les modifications non autorisées. Les paramètres de configuration sont protégés contre les modifications non autorisées. Les fichiers sur le disque sont protégés contre les modifications non autorisées. Même les sémaphores et les points de terminaison RPC utilisés par le système d'exploitation sont protégés contre les modifications non autorisées. Si un attaquant peut modifier l'un de ces objets protégés, il peut tous les modifier et, très probablement, l'a déjà fait.
Il s'agit là d'un point critique. Avec plusieurs des lois immuables, ce n'est pas l'acte de faire quelque chose qui signifie que votre ordinateur est compromis. La seule chose qui compte, c'est que quelqu'un a la possibilité de faire quelque chose. C'est là un point qui ne doit pas être négligé. Pour chaque aspect de la sécurité informatique, vous devez toujours vous rappeler que la capacité est souvent bien plus importante que l'action réellement effectuée.
Si un ordinateur est grand ouvert sur Internet et n'est pas protégé pendant des mois, est-il toujours digne de confiance ? Non. Cet ordinateur doit être considéré comme compromis. Vous ne pouvez faire confiance à aucun élément d'un système pouvant avoir été compromis. (Je disais déjà la même chose il y a cinq ans dans mon article « Au secours ! Je me suis fait pirater. Que faire ? » disponible à l'adresse technet.microsoft.com/library/cc512587.) Si vous avez affaire à un adversaire compétent, un système compromis peut même ne pas présenter de signes de sa compromission. Le système peut paraître parfaitement normal.
Sans aucun doute, la Loi 2 reste valable. Si un attaquant a la possibilité de modifier un objet protégé sur votre ordinateur, ce n'est plus votre ordinateur. N'oubliez pas, c'est la possibilité de modifier ces objets qui compte, pas le fait qu'ils l'ont été ou non.
Loi 3 : Si une personne malintentionnée dispose d'un accès physique non restreint à votre ordinateur, ce n'est plus votre ordinateur.
Cette loi était critique en 2000. De nombreuses personnes ne comprenaient pas vraiment ce que vous pouviez faire en disposant de l'accès physique à un système. En fait, même certaines administrations publiques qui auraient dû être bien informées n'ont pas saisi l'importance de ce point. À cette époque, les directives de sécurité recommandaient de désactiver l'option Autoriser l'arrêt sans connexion. Lorsque cette option est désactivée, le bouton Arrêter... à l'écran d'ouverture de session est grisé. La théorie était que pour arrêter l'ordinateur, l'utilisateur doit d'abord ouvrir une session. En conséquence, un enregistrement d'audit indiquerait qui arrête le système.
C'est un mauvais raisonnement digne d'une étude de cas. Pour avoir accès au bouton Arrêter... à l'écran d'ouverture de session, vous devez vous trouver devant la console. Et si vous vous trouvez devant la console et que vous voulez vraiment arrêter l'ordinateur, vous pouvez utiliser le gros bouton rond à l'avant de l'ordinateur, voire le cordon d'alimentation. Système arrêté. Aucun suivi d'audit.
Windows 2000 comporte un paramètre de sécurité appelé Autoriser le retrait sans ouverture de session préalable, et cette option est toujours disponible dans Windows Vista, comme illustré à la figure 3. Le principe était le même. Pour retirer un portable de sa station d'accueil, il est nécessaire d'ouvrir au préalable une session sur le système.
Figure 3 Pourquoi ne pas voler l'ordinateur et la station d'accueil ? (cliquez sur l'image pour l'agrandir)
La valeur réelle de ce paramètre en termes de sécurité est extrêmement douteuse. Je pense que la théorie était que si quelqu'un pouvait accéder au portable et le détacher, cette personne pouvait aussi bien voler l'ordinateur. Je ne volerais jamais un portable, mais si je devais le faire, cette mesure préventive ne me dissuaderait pas. Je m'emparerais probablement du portable et de la station d'accueil. Et puis tant qu'à faire, je volerais également le câble réseau et le cordon d'alimentation. Vous parlez d'une mesure de sécurité inutile !
La question de l'accès physique a été réellement reconnue lorsque Petter Nordahl-Hagen a créé son Offline NT Password & Registry Editor. Sa création n'était qu'un disque de démarrage Linux avec un pilote de système de fichiers NTFS expérimental qui permettait l'accès en lecture et en écriture à un volume NTFS. Le logiciel sur le disque de démarrage était conçu pour monter le Registre sur l'ordinateur local et écrire un nouveau mot de passe pour le compte d'administrateur dans la ruche du SAM (software asset management). Il vous suffisait de disposer d'un accès physique au système pendant une à deux minutes.
C'est exactement pour des outils comme cela que la Loi 3 a été écrite. En fait, l'outil de Nordahl-Hagen a été utilisé dans de nombreuses démonstrations. Malheureusement, le grand public n'en a pas eu connaissance. J'ai personnellement utilisé cet outil dans certaines démonstrations, mais j'ai arrêté parce que je me suis lassé que l'on me demande « Comment nous assurer qu'aucun de nos utilisateurs ne connaît un tel outil ? » et « Que fait Microsoft pour résoudre ce problème ? ». Une grande partie de l'industrie informatique ne voulait simplement pas accepter ou comprendre que l'accès physique prendrait le dessus sur tout le reste.
Dans cet environnement, la Loi 3 était très importante. Pourtant les critiques l'ont assaillie sans pitié. Elle a été ridiculisée et présentée comme une tentative par Microsoft d'éviter de corriger tout problème pouvant être lié, même de loin, à l'accès physique. En fait, la Loi 3 a été utilisée à plusieurs reprises pour ignorer les rapports de vulnérabilité, y compris le piratage avec Offline NT Password & Registry Editor. Cependant, il n'est possible de bloquer les attaquants qui ont un accès physique au système que d'une seule façon : en s'assurant qu'ils ne peuvent accéder à rien.
C'est là que se trouve le défaut de la cuirasse de la Loi 3. Depuis que les lois ont été écrites, la technologie de chiffrement de disque complet est devenue une solution viable. Avec le chiffrement complet du disque dur, plus justement dénommé chiffrement de volume complet, un volume entier (ce qui est appelé partition dans d'autres systèmes d'exploitation) peut être chiffré. Donc, si le volume de démarrage entier (en d'autres termes, le volume sur lequel réside le système d'exploitation) est chiffré, la question que nous devons nous poser est la Loi 3 reste-t-elle valable ?
La réponse est oui, très probablement. Tout d'abord, les clés de déchiffrement doivent être stockées quelque part. Le lieu le plus simple où mettre les clés, et l'option par défaut dans BitLocker, est dans une puce de module de plateforme sécurisée dans l'ordinateur. Ainsi, l'ordinateur démarre sans assistance. Une fois l'ordinateur démarré, un attaquant ingénieux et bien subventionné, disposant du contrôle physique permanent sur l'ordinateur, peut l'attaquer de plusieurs façons. Comme l'ordinateur peut maintenant être connecté à un réseau arbitraire, il est possible d'attaquer le système par le réseau.
L'attaquant peut, par exemple, lire ou écrire la mémoire au moyen d'un dispositif d'accès direct à la mémoire (DMA), tel qu'un lecteur flash USB. Lorsque l'ordinateur est en cours d'exécution, tous les paris s'annulent s'il s'agit d'un attaquant avec accès physique à cet ordinateur.
Si les clés ne sont pas stockées sur l'ordinateur lui-même, l'attaque dépend du fait que l'attaquant peut obtenir ou deviner les clés. Si un code PIN est utilisé pour démarrer l'ordinateur, l'attaquant peut probablement deviner le code avec relativement peu d'effort. Si les clés sont stockées dans ou dérivées d'un périphérique matériel séparé, comme un lecteur flash USB ou un mot de passe à utilisation unique, l'attaquant doit avoir accès à ce périphérique séparé. Il existe certainement des moyens d'obtenir ces clés ou de rendre la vie très difficile pour la personne qui y a accès, bien que l'effort requis soit probablement plus important.
Vous pouvez également interpréter la Loi 3 d'une façon légèrement différente : « Si l'attaquant dispose d'un accès physique à votre ordinateur, c'est probablement que l'ordinateur a été volé et, donc, il est peu probable que vous le retrouviez ». De ce point de vue, ce n'est vraiment plus votre ordinateur. Et de ce point de vue, l'attaquant peut ne même pas se soucier de pouvoir ou non accéder aux données situées sur votre ordinateur. Cependant, ce n'est vraiment pas l'esprit de la Loi 3. En effet, elle signifiait que l'attaquant avait accès aux données sur votre ordinateur et pas juste à l'ordinateur.
Tout bien considéré, la Loi 3 s'applique toujours. Il est vrai que certaines technologies disponibles aujourd'hui sont parviennent à arrêter de nombreux attaquants avec accès physique et ainsi à réduire le nombre d'attaquants capables d'accéder aux données d'un ordinateur protégé par une mesure de sécurité. Cela dit, les capacités de l'attaquant définissent toujours ce que l'attaquant peut faire, et de nouvelles technologies répondent à plusieurs des 10 lois immuables, dans une certaine mesure. Mais l'accès physique offre toujours des façons, bien qu'elles soient plus complexes, de pénétrer dans un système.
Jusqu'à présent, les lois immuables de la sécurité s'avèrent très résilientes, à la fois face aux avances technologiques et au temps. Parmi les 3 premières, la Loi 3 est sur le terrain le plus instable, mais elle reste néanmoins valable dans certains cas. C'est, toutefois, celle qui a les atténuations les plus facilement disponibles et robustes en place. Je reviendrai dans les deux prochains numéros de TechNet Magazine pour continuer cette discussion et déterminer si les Lois 4 à 10 sont toujours immuables.
Jesper M. Johansson est architecte de logiciels, chargé des problèmes de sécurité logicielle et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.