Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Dominique Jouniot, Thylenea S.I. : Organisation autour d’une faille ou une approche ISO 27001 du bug DNS

juillet 2008 par Dominique Jouniot, Thylenea SI

Depuis maintenant plusieurs semaines, on assiste, sur Internet, a une suite d’échanges techniques sur la faille DNS découverte par Dan Kaminsky, qui doivent laisser perplexe plus d’un Responsable Sécurité de l’Information. Dominique Jouniot, Fondateur de Thylenea SI propose une approche organisationnelle au regard de l’ISO 27001 de cette fameuse vulnérabilité.

Cette annonce, qui a fait l’effet d’une bombe parmi les experts d’Internet, s’est très vite transformée en un débat technique, mettant en évidence des notions très complexes… normal ! le protocole DNS est l’un des plus compliqué du Net.

Les experts techniques ont juste oublié un petit détail, il existe assez peu de gens au fait des informations ultra techniques relatives à ce protocole. Le résultat de ces discours peut entraîner des réactions désastreuses : d’une part alarmer les opérationnels, et de fait entraîner des réactions désordonnées ("patcher" sans contrôle, coupure de services inutiles, etc.), d’autre part exaspérer les managers, et entraîner une réaction de passivité, c’est-à-dire « on ignore et/ou on attend que ça se calme ».

Au regard de cette faille et des risques encourus, il est évident que ces deux sortes de réactions sont néfastes. Il s’agit pour tout Responsable Sécurité de l’Information en place, de prendre les dispositions nécessaires, mais cette fois de manière structurée. Nous allons tenter de suivre une démarche en accord avec la norme de sécurité ISO 27001.

C’est un cas d’école typique, que l’on appelle communément une « détection d’incident de sécurité ». La gravité de l’incident n’est pas formellement défini (certains vont sans doute « hurler » devant cette remarque), mais aujourd’hui, les débats sur les suites à donner restent encore très contradictoires. De plus, le sujet fait rage sur le Net depuis maintenant 3 semaines, les communications et DNS du Net semblent toujours fonctionner correctement. Donc, un RSI prudent et non expert technique, peut-être en droit de se poser certaines questions.

Ceci dit, la bonne pratique sur cette étape, est quand même d’ouvrir la gestion de l’incident et d’assurer un suivi. Les « entrées » formalisées de cette gestion d’incident (ainsi que l’événement déclencheur) sont les avis d’experts, dont le premier Dan Kaminsky. Dans le cadre d’une approche normalisée, nous couvrons l’exigence référencée A.6.1.7 de la norme ISO 27001.

Il est clair que dans ce domaine, et pour cet incident en particulier, il faut également suivre les avis des organismes de référence. Pour la France, il est important de se rapprocher de la Direction Central de la Sécurité des Systèmes d’Information (DCSSI - instance gouvernementale) et de ses publications (le Centre d’Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques - CERTA). Cette action couvre l’exigence référencée A.6.1.6 de la norme ISO 27001.

L’enregistrement de l’incident, au regard du mouvement et de l’agitation sur Internet, doit inciter le RSI à déclencher une cellule de crise (couverture des exigences référencée A.13 de la norme ISO 27001). Cette cellule sera composée des acteurs impliqués de la Direction des Systèmes d’information (le DSI lui-même, les experts réseaux, les experts systèmes, les responsables de la production), ainsi que les Maîtrises d’Ouvrage Applicatives.

Pourquoi les Maîtrises d’Ouvrage Applicatives ? Il est important, pour le RSI, de bien comprendre le point de vue de l’entreprise, vis-à-vis de ce genre de problème. Le monde technique dit : "patchez !". Mais attention, pas n’importe comment. Certes la faille DNS peut entraîner du "phishing" et des "dénis de service", mais "patcher" un système de façon automatique et incontrôlée peut provoquer les mêmes natures d’incident. Le rôle de la cellule de crise est de prévenir et empêcher ce type comportement. C’est également son rôle de surveiller et de prendre les mesures nécessaires, durant la période où le système est considéré comme vulnérable (c’est-à-dire non encore "patché" et/ou non "patchable" ; si, si c’est possible !).

Le Responsable Sécurité de l’Information, en tant que coordinateur de la cellule de crise, doit s’assurer du bon déroulement des étapes suivantes :
• Première étape : « PLAN » analyser les risques.
• Deuxième étape : « DO » application des corrections.
• Troisième étape : « CHECK » s’assurer de la réalisation, contrôler.
• Quatrième étape : « ACT » suivre les évolutions, les failles et assurer la mise à jour des évolutions.

L’analyse des risques impose au RSI et aux acteurs des Maîtrise d’Ouvrage Applicatives de se poser, entre autres, les questions :
• Sommes-nous concerné par cette menace ? si oui, quel est l’impact ?
• Avons-nous, en interne, des DNS vulnérables ?
• Notre activité utilise-t-elle des DNS externes vulnérables ?

Même si le « patch » du « resolveur de nom » sur les postes bureautiques est, probablement, sans risque, la question doit être envisagée, posée et, dans l’absolu, doit justifier une méthodologie de mise en œuvre.

PLAN

Le RSI, en collaboration avec l’équipe de la cellule de crise, doit donc planifier l’action (PLAN) : les "patchs" ne doivent pas se faire n’importe comment. Nous sommes dans des cas de production, une mise à jour corrective mal appliquée peut générer une régression de l’application et entraîner un "déni de service".

C’est la raison pour laquelle, les Maîtrises d’Ouvrage Applicatives doivent être consultées. Ces acteurs doivent être prêts en cas de problème à passer en plan de continuité d’activité dégradée.

Concernant le "PLAN" :
• Récupérer les "patchs" pour les systèmes concernés, valider la source !
• Planifier les tests de non régression des applications, bien sûr sur une plate forme sécurisée (exigence référencée A.12.4.1 de la norme ISO 27001).
• Distribuer les rôles et responsabilités.
• Planifier le déploiement.

DO

Pour la réalisation, c’est un travail qui incombe en grande partie à la D.S.I. et à la MAO. L’équipe du RSI doit juste prendre en charge le contrôle d’intégrité des sources des différents "patchs". Il faut quand même se souvenir que c’est une faille DNS, il serait comique que le résolveur DNS qui donne accès aux "patchs" officiels se soit fait attaquer et rende une adresse en "phishing" sur un faux site de mise à jour, contenant pour le coup un excellent rootkit ! Cette action doit être parfaitement maîtrisée et formalisée par le RSI.

Le RSI et son équipe doivent, dans la mesure du possible, éviter d’intervenir dans la partie "DO" de l’opération. Il y a là un risque de "juge et partie" important, vis-à-vis de la suite des actions. Les étapes de surveillance et de suivi de ces opérations doivent être déléguées aux équipes de contrôle interne, voir à la qualité.

Il nous reste encore deux étapes à développer.

CHECK

Le "CHECK", et oui ! L’équipe d’audit interne sécurité doit impérativement vérifier la réalisation du travail. Cela ne doit pas se borner simplement à voir si les "patchs" sont appliqués… trop simple ! Il faut s’assurer que la méthodologie a été suivie et que toutes les actions ont été correctement enregistrées et archivées (cela couvre tous les points méthodologiques des exigences référencées A.4.3 de la norme ISO 27001).

A l’issue de cette étape de contrôle, on peut considérer que l’on a répondu à l’injonction des experts : "Patchez !".

Ceci dit, et malheureusement pour le RSI, le travail n’est pas encore terminé. Il reste le "ACT".

ACT

L’histoire de cette faille est loin d’être clôturée et il semble que d’autres rebondissements sont à prévoir dans les semaines, voir les mois à venir. Il est clair que l’incident ne peut pas être clos. Il est donc impératif de l’inclure dans le Système de Management de la Sécurité de l’Information (SMSI) et de lui affecter un technicien assurant un suivi permanent.

Mettre en place la politique de surveillance

Il faut mettre en place une politique de surveillance particulière des incidents pouvant découler de cette faille (par exemple, assurer un contrôle des requêtes avec des IDS, analyser les logs des systèmes concernés, etc.). Bien que ce soit déjà le rôle au quotidien de l’équipe Sécurité de l’Information et en partie de l’équipe de la DSI, il devra y avoir, et ce pendant toute la durée de cette faille, une attention particulière des équipes sur ce sujet.

Cette faille est grave. Le battage médiatique qui a été fait autour, malheureusement nuit à sa correcte compréhension. De plus, la période des vacances d’été n’arrange rien car les équipes techniques fonctionnent à effectif réduit.

Cependant, une bonne maîtrise du SMSI, en appliquant les bonnes pratiques et les exigences de la norme de sécurité (ISO 27001), peuvent permettre de suivre ce problème de manière formalisé et structuré et d’assurer une minimisation des risques induits.

Assurer la continuité et l’intégrité des informations

Le vrai travail du RSI se situe là, et non dans les débats d’expert. Il doit s’assurer de la continuité et de l’intégrité des informations de son entreprise, il doit réagir à l’incident de manière formalisée, et savoir le gérer. Il doit aussi contrôler que les autres acteurs de l’entreprise, en particulier dans ce cas, la DSI., ont appliqué correctement et de manière méthodologique les consignes de la politique de sécurité.

Communiquer

Le RSI conclura son travail par une action de communication intègre mais rassurante (image de marque oblige !) auprès des entités internes et externes de l’entreprise :
• En interne, afin d’expliquer les actions et d’éviter la diffusion d’information erronée (par exemple, on retrouve dans un journal à scandale des infos telles que : « les systèmes de la société ne sont pas mis à jour, ne sont pas sécurisés, etc. »). On risque une perte d’image de marque.

• En externe, auprès des fournisseurs, pour s’assurer qu’ils ont également réagi positivement à cette alerte.
• En externe, auprès des clients, afin d’éviter une panique ou une polémique autour de la qualité des produits ou des services de l’entreprise (par exemple, dans le cadre du commerce électronique)

Pour conclure cet article, j’ai le sentiment que les vacances des RSSI, cette année, ne vont pas être de tout repos. Allez l’arrière saison sera peut-être plus clémente. Mais avec la sécurité de l’information, on n’est jamais à l’abri d’un orage soudain !


Articles connexes:


Voir les articles précédents

    

Voir les articles suivants