inetdoc.net

La connaissance de son système est probablement la chose la plus importante lorsque l'on essaie de le défendre. Peu importe qu'il s'agisse d'un château ou d'un serveur Linux ; si vous ne connaissez pas réellement les entrées et les sorties de ce que vous défendez, vous avez peu de chances de succès.

La connaissance exacte des logiciels exécutés sur vos systèmes est un bon exemple dans le monde de la sécurité de l'information. Quels sont les démons actifs ? Quel genre d'exposition engendrent-ils ? Un bon auto-test pour quelqu'un travaillant dans un environnement de taille moyenne serait de choisir aléatoirement une adresse IP dans la liste des systèmes et de voir si il connaît la liste exacte des ports qui sont ouverts sur les machines.

Un bon administrateur système devrait être capable de dire, par exemple, «c'est un serveur Web, donc il fonctionne seulement avec les ports 80, 443 et 22 pour l'administration à distance ; voilà.» ; et ainsi de suite pour chaque type de serveur dans l'environnement. Il ne devrait pas y avoir de surprises en examinant les résultats des scans de ports.

Ce que l'on ne veut pas entendre dans ce genre de test c'est : «Waouh, qu'est-ce que c'est que ce port ?». Avoir à se poser la question est un signe que l'administrateur n'est pas entièrement au courant de tout ce qui fonctionne sur la machine en question et c'est précisément la situation que l'on doit éviter.

Le concept suivant super important est celui du moindre privilège. Il indique simplement que les utilisateurs et les éléments du système d'information devraient pouvoir accéder seulement à ce dont ils ont besoin pour effectuer leurs tâches, et rien d'autre. La raison pour laquelle j'inclus les «éléments» c'est que les administrateurs configurent souvent des tâches automatisées qui ont besoin de pouvoir faire certaines choses : des sauvegardes par exemple. Et bien, ce qui se produit souvent c'est que les administrateurs se contentent de placer l'utilisateur qui effectue les opérations de sauvegarde dans le groupe d'administration du domaine ; même si ils pourraient faire fonctionner le service d'une autre manière. Pourquoi ? Parce que c'est plus facile.

Finalement c'est un principe conçu pour entrer directement en conflit avec la nature humaine, c'est-à-dire la paresse. Il est toujours plus difficile de donner un accès granulaire qui permet seulement d'effectuer des tâches spécifiques que de donner accès à un échelon plus élevé qui inclut les besoins à satisfaire.

Cette règle du moindre privilège nous rappelle simplement de ne pas céder à la tentation et d'agir de cette façon. Il ne faut jamais céder et prendre le temps de rendre tout accès granulaire, au niveau le plus bas possible.

La défense en profondeur est peut-être le concept le moins bien compris des quatre. Beaucoup pensent qu'il s'agit d'empiler trois pare-feux au lieu d'un, ou d'employer deux programmes d'antivirus plutôt qu'un. Techniquement c'est réalisable, mais ça ne correspond pas à la vraie nature de la défense en profondeur.

La véritable idée est d'empiler des couches de protection multiples entre un attaquant et des biens. Et ces couches n'ont pas besoin d'être des produits ; elles peuvent être l'application d'autres concepts, tel que le moindre privilège.

Prenons l'exemple d'un attaquant sur l'Internet qui essaie de compromettre un serveur web dans la DMZ. Ce pourrait être relativement facile en présence d'une vulnérabilité importante dans le système. Mais, avec une infrastructure construite en utilisant la défense en profondeur, ça peut être beaucoup plus difficile.

Qu'il s'agisse du durcissement des routeurs et des pare-feux, de l'introduction d'IPS/IDS, du durcissement du serveur cible, de la présence d'un IPS hôte sur le serveur, de l'antivirus sur le serveur, etc. ; une seule de ces étapes peut suffire à empêcher le succès complet d'une attaque.

L'idée, c'est que nous devrions penser à l'envers ; plutôt que de penser à ce qui doit être mis en place pour arrêter une attaque, il faut justement penser à tout ce qui doit se passer pour qu'elle soit réussie. Il faut donc envisager qu'une attaque doive passer par le routeur externe, le pare-feu, le commutateur, accéder au serveur, exécuter ceci, établir une connexion sortante vers un hôte extérieur, télécharger du contenu, exécuter cela, etc., etc.

Et si l'une de ces étapes échouait ? C'est la clef à la défense en profondeur ; placer des barrières sur autant de points que possible. Verrouiller les listes de contrôle d'accès (ACLs) du réseau. Verrouiller les accès aux fichiers. Utiliser la prévention d'intrusion réseau, utiliser la détection d'intrusion, rendre l'exécution de code hostile plus difficile sur les systèmes, s'assurer que les démons sont exécutés avec les moindres privilèges utilisateur, etc., etc.

Le bénéfice de cette démarche est simple à comprendre : vous avez plus de chances d'empêcher qu'une attaque soit couronnée de succès. Il est possible que quelqu'un parvienne à passer, à accéder à la machine en question, et soit arrêté par le fait que le code malveillant en question ne soit pas exécutable sur le serveur. Et même si ce code malveillant a été corrigé de sorte qu'il fonctionne, il sera alors bloqué par un IPS mis à jour ou un contrôle d'accès (ACL) plus restrictif sur un pare-feu. L'idée est de verrouiller tout ce que l'on peut à chaque niveau. Pas simplement un élément, l'ensemble : les permissions sur les systèmes de fichiers, les protections d'accès sur les piles mémoire des systèmes, les ACLs, l'IPS hôte, la limitation des accès d'administration, l'exécution avec des droits limités. La liste continue indéfiniment.

Le concept fondamental est simple : ne pas compter sur des solutions uniques pour défendre les biens à protéger. Traiter chaque élément de défense comme si c'était la seule couche disponible. Lorsque l'on adopte cette approche on est plus à même de bloquer les attaques avant qu'elles n'atteignent leur but.

Le concept final est plutôt simple à énoncer mais extrêmement important. L'idée est que même s'il vaut mieux qu'une attaque soit stoppée avant qu'elle ait atteint son but, il est absolument crucial de savoir au moins ce qui s'est produit. À titre d'exemple, ont peut avoir des protections en place qui essaient d'empêcher l'exécution de code malveillant sur le système, mais si un code de ce type est exécuté et que quelque chose est fait, il est indispensable d'être alerté et de pouvoir réagir rapidement.

La différence entre apprendre qu'une attaque est réussie dans un délai de 5 ou 10 minutes et le découvrir des semaines est plus tard est astronomique. Souvent, avoir connaissance assez tôt d'une attaque peut entraîner son échec. Même si des attaquants obtiennent un accès sur la machine et ajoutent un compte utilisateur, il doit être possible de placer rapidement cette machine hors-ligne avant qu'ils ne puissent faire n'importe quoi avec.

Quel que soit le contexte, la détection est un devoir absolu parce que les démarches préventives n'ont aucune garantie de succès à 100%.

La protection de la confidentialité consiste à préserver des informations secrètes. Ces informations peuvent aller de la propriété intellectuelle d'une société à la collection photo personnelle d'un utilisateur. Tout ce qui attaque la capacité de chacun à préserver ce qu'il veut garder secret est une attaque contre la confidentialité.

L'intégrité consiste à s'assurer que les informations n'ont pas été modifiées relativement à leur forme authentique. Les attaques contre l'intégrité sont celles qui essaient de modifier une information en vue d'une utilisation ultérieure. Des modifications de prix dans une base de données commerciale ou la modification du niveau de paie de quelqu'un sur une feuille de calcul de tableur sont des exemples de ce type d'attaque.

La disponibilité est un élément tout à fait critique du puzzle CIA. Comme on peut s'y attendre, les attaques contre la disponibilité sont celles qui font que la victime ne peut plus accéder à une ressource particulière. L'exemple le plus célèbre de ce type d'attaque est le déni de service (Denial of Service ou DoS). Le principe, c'est qu'avec ce type d'attaque rien n'est volé ni modifié. L'attaquant vous empêche d'accéder à tous les services visés. Les ressources attaquées peuvent être un serveur isolé ou bien même un réseau entier dans le cas des attaques basées sur la bande passante (Distributed Denial of Service ou DDoS).

Une vulnérabilité est une faiblesse dans un système. C'est assez simple à comprendre parce que l'on emploie généralement ce terme exact dans les avis (advisories) et même dans les médias. Comme exemple, on trouve l'avis LSASS CVE-2004-0894 qui permet à un attaquant de prendre le contrôle des systèmes à distance. Quand on applique un correctif (patch) à un système, on le fait pour supprimer une vulnérabilité.

Une menace est un événement, naturel ou artificiel, qui peut endommager un système. Les types de menaces comprennent les gens qui essaient de pénétrer dans un réseau pour voler des informations, les feux, les tornades, les inondations, l'ingénierie sociale, les salariés malveillants, etc. Tout ce qui peut endommager les systèmes est essentiellement une menace pour ces systèmes. Souvenons nous aussi qu'une menace est habituellement évaluée comme une probabilité, ou une chance, que cet événement puisse survenir. Comme exemple, on pourrait prendre la menace d'utilisation de code malveillant contre une vulnérabilité particulière. S'il n'existe aucun code malveillant connu dans la nature le niveau de cette menace est assez bas. Mais si un nouveau code malveillant apparaît en force dans les listes de diffusion majeures, le niveau de la menace augmente significativement.

Le risque est peut-être la plus importante de toutes ces définitions puisque la mission principale des responsables de la sécurité de l'information est de gérer ce risque. L'explication la plus simple que j'ai entendue est que le risque est la chance de quelque chose de mauvais arrive. C'est un peu trop simpliste et je pense que la meilleure façon d'expliquer ce terme est d'utiliser deux ou trois formules :

La multiplication est utilisée ici pour une raison très spécifique. Dès que l'un des deux termes vaut zéro, le résultat devient nul. Autrement dit, il n'y a aucun risque s'il n'y a pas de menace ou de vulnérabilité.

À titre d'exemple, si notre serveur Linux est totalement vulnérable selon la publication de l'avis CVE-XYZ mais qu'il n'existe aucun moyen d'exploiter la vulnérabilité, alors le risque devient nul. De même, s'il existe quantité de façons d'exploiter une vulnérabilité et que nous avons déjà appliqué le correctif (nous ne sommes donc plus vulnérable), nous n'encourrons de nouveau aucun risque.

Une formule plus élaborée inclut l'impact, ou le coût, à l'équation (littéralement) :

Ce facteur permet à un décideur d'affecter une valeur quantitative au problème. Ce n'est pas toujours une science exacte, mais si nous savons qu'un vol de propriété intellectuelle vitale pour votre société nous coûterait 4 milliards de $, alors c'est une bonne information à considérer pour traiter le risque.

Cette dernière partie est importante. L'objectif global de l'affectation d'une valeur au risque est que les responsables puissent prendre les décisions sur ce qui doit être traité ou pas. S'il existe un risque associé à l'hébergement de certaines données sur un serveur FTP public, mais que ce risque n'est pas assez sérieux pour dépasser les bénéfices attendus, alors c'est une bonne affaire de continuer à héberger ces données.

C'est tout l'enjeu. Les responsables chargés de la sécurité de l'information doivent en savoir assez sur les menaces et les vulnérabilités pour être capables de prendre des décisions pertinentes sur la façon de développer l'infrastructure informatique. La gestion des risques justifie pleinement le travail sur la sécurité de l'information.

Une politique de sécurité est une prise de position affirmée de la direction établissant ce qui est permis dans l'entreprise et ce qui ne l'est pas. Une politique de sécurité dira, par exemple, que vous pouvez lire votre courrier électronique personnel au travail mais que vous ne pouvez pas consulter votre banque en ligne, etc. Une politique devrait être assez large pour englober l'entreprise entière et devrait avoir l'aval de ses instances.