Sur la perception

Ayant quitté mon équipe IR depuis plus de trois mois, je me prends à philosopher par manque de cas croustillants à me mettre sous la dent (une des raisons pour lesquelles je délaisse ce blog, sans aucun doute). La vieillesse me gagne peut-être ou serait-ce l'ennui ??

Devant rapidement trouver un nouveau job pour nourrir ma petite famille, j'ai dû réviser mes classiques INFOSEC, afin de ne pas sécher bêtement devant une question basique. En effet, après une vingtaine d'entretiens, je n'ai eu aucune question relative au live forensique ou à la réponse aux incidents ! Il faut dire que ces sujets semblent d'avantage faire partie de la recherche expérimentale que des bonnes pratiques ITIL ou autre standard à la mode... Toujours est-il qu'en révisant ces fameux classiques, j'ai eu soudain un doute vertigineux vis à vis des fondements même de l'INFOSEC tels qu'on me les a enseignés voilà plus de dix ans.

Lorsque j'étais encore étudiant en mathématiques appliquées (voila deux éternités...) j'ai subi la torture mentale infligée par un spécialiste de la logique formelle. Outre de violentes migraines, je me souviens essentiellement du théorème de Gödel, qui démontre l'assertion géniale suivante : "Au sein même d'un système, il est impossible de démontrer logiquement les points de départ."

Pour l'INFOSEC, cela peut signifier que les définitions de base (la sécurité, l'équation du risque, les menaces...) sont uniquement de simples perceptions et des valeurs arbitraires !

Or, lorsque l'on connait la part non négligeable qu'ont pris les spécialistes de l'assurance financière dans la genèse de l'actuelle doctrine INFOSEC, notamment dans la gestion des risques, il y a lieu de s'inquiéter. Pour s'en convaincre, il suffit de passer en revue les méthodologies d'analyse de risque à notre disposition. En France, EBIOS et Mehari sont des exemples flagrants de systèmes pseudo-scientifiques - si courants dans l'analyse financière - qui sont bâtis sur du vent et dont le résultat ne repose que sur l'expérience et le pragmatisme de celui qui les met en oeuvre. Ce qui requiert une compétence très poussée en programmation neuro-linguistique. ;-)

Je connais une bonne dizaine de définitions du concept de sécurité appliqué à l'INFOSEC. Cependant, celle que je préfère n'est préconisée ni par les instances de standardisation, ni par notre très haute autorité française : la DCSSI. Il s'agit tout bêtement d'une définition utilisée depuis une trentaine d'années dans le monde du renseignement qui, contrairement au monde de l'assurance financière, possède un encrage évident dans la réalité. Cette définition est la suivante :

La sécurité est le processus du maintien du risque perçu à un niveau acceptable.

Rien de bien nouveau me direz-vous, il fait simplement de l'esbroufe, sachant qu'il n'a plus grand chose à dire sur le sujet du live forensique. Peut-être, bien que je garde encore quelques cartes dans ma manche... Mais, il y a une notion qui peut paraître anodine au premier abord dans cette définition, mais qui change pourtant toute la donne. Il s'agit de la perception.

Pour un esprit français, baigné depuis sa plus tendre enfance dans la logique carthésienne, la dialectique et le raisonnement, la perception reste un élément secondaire de la réflexion. La pensée critique reste le nec plus ultra en Occident, et surtout dans notre beau pays. Il suffit pour cela d'écouter, même d'une oreille très discrète, les derniers discours de la présidentielle...

La perception est pourtant une clé, et même la clé, pour comprendre le concept de sécurité. Pour un analyste INFOSEC, la perception est la partie la plus importante de sa réflexion. En fait, toutes les erreurs que j'ai rencontrées avec mon équipe IR provenaient d'erreurs de perception, dues très souvent au stress, au manque de sommeil et surtout à une trop grande précipitation. En pratique, les erreurs de logique sont rares dans l'analyse INFOSEC. Malgré tout, nous avons appris en tant que fiers enfants de Descartes que réfléchir consiste uniquement à éviter les erreurs de logique.

Ainsi, si l'on s'attache à la perception du risque et non simplement au risque dans un système absolu, on peut alors se concentrer sur les menaces et non plus uniquement sur les vulnérabilités. Lorsque l'on observe les listes de diffusion INFOSEC que cela soit dans notre pays ou encore dans les pays anglosaxons, on voit que la majorité de notre attention est focalisée sur les vulnérabilités découvertes par les chercheurs INFOSEC.

Pour ne pas ajouter un troll à mon actif (et surtout pour ne pas blesser la susceptibilité d'un de mes uniques lecteurs), je tiens simplement à dire qu'il est vain de courir après toutes les vulnérabilités que l'on nous sert chaque semaine. Il faut en fait se concentrer sur les menaces qui nous concernent, comme le font les professionnels du renseignement depuis des années.

Mon expérience en la matière est que l'étude des groupes possédant la capacité et l'intention de nuire à une organisation est bien plus importante (et bien plus utile) que d'essayer de patcher toutes les vulnérabilités qui apparaissent. Il suffit pour s'en convaincre, de faire une pause en reconsidérant les dernières vulnérabilités zéro-days qui viennent d'être publiées à la veille de nombreuses mises à jour de produits de sécurité et des conférences INFOSEC printanières (Oups, j'ai encore trollé :-).

L'étude de tels groupes reste très confidentielle. J'ai relevé dernièrement un post assez proche de cette thématique ici. Si vous en connaissez d'autres, je suis preneur.

De l'initiative dans la résolution d'une crise

Chaque individu possède une dose de créativité, fonction de sa personnalité (inné) et de son adaptation au terrain (acquis). Cette créativité s'exprime dans les initiatives de chacun et forme, selon mon expérience, la source de la performance de toute équipe.

Or, j'ai trop souvent observé des chefs d'équipe - généralement aguerris - tuer dans l'oeuf une initiative au nom de la sacro-sainte urgence de la crise. Il est vrai que les initiatives doivent être régulées pour ne pas mettre en péril une mission. Mais, il convient de ne pas confondre crise et urgence !

Ce qui caractérise une crise, c'est justement le fait que les solutions "classiques" ne fonctionnent pas et qu'il est vital d'être créatif pour pouvoir s'en sortir. Pour ma part, je pense qu'il faut toujours encourager une initiative relevant d'une tâche individuelle (ou relevant du binôme IR). Elle atteste généralement de la qualité de son auteur, et doit être relevée pour le debriefing de fin de crise.

Par contre, je pense qu'une initiative relative à la procédure générale de l'équipe IR ne doit généralement pas être tentée directement au cours d'une crise. Mais, elle mérite également d'être notée et surtout de faire l'objet d'une évaluation approfondie lors du debriefing. Si elle s'avère pertinente, elle devra être mise à l'actif de son auteur, faisant la preuve que chacun peut améliorer le fonctionnement de l'équipe. Dans le cas contraire, le debriefing devra démontrer les difficultés de sa mise en oeuvre.

J'entends ici par debriefing, ou retour d'expérience, l'analyse d'un évènement dans lequel l'équipe IR a été impliquée ou non. L'objectif est de décortiquer l'évènement, généralement complexe, pour en comprendre toutes les facettes. Le debriefing fait partie des bonnes pratiques à mettre en place, et pas uniquement dans les équipes IR. Cette mise en place ne doit cependant pas s'accompagner de la fin du cycle des examens de situation, qui doivent intervenir très régulièrement au cours de la résolution d'une crise.

Tout l'art du coordinateur IR revient à savoir assoir son autorité sur le partage de l'information et faire déboucher son équipe sur une solution qui recueille l'assentiment général, tout en étant la mieux adaptée aux circonstances. Or, il n'est pas rare en cas de crise - lorsque les informations se multiplient et le doute s'installe - de voir disparaitre le dialogue constructif au profit d'un autoritarisme des plus primitifs !

Là encore, le coordinateur IR expérimenté saura simplement mettre en oeuvre son autorité pour entendre les arguments de ses collaborateurs, identifier les arbitrage à prononcer et surtout obtenir l'adhésion de tous autour de la décision prise.

A titre de conclusion, j'affirme que rien n'est pire que l'absence de décision en cas de crise ! La prise de décision est la justification de la qualité du coordinateur, l'expression ultime de sa compétence. Mais, encore faut-il ne jamais oublier que prendre une décision ne signifie pas imposer sa propre vision du problème.

L'éthique kantienne contre la fascination du côté obscure

Toujours dans le thème du social, nous allons traiter ce soir des problèmes éthiques auxquels une équipe IR peut être un jour confrontée.

Si l'aphorisme du XVIIe siècle : savoir, c'est pouvoir est aujourd'hui évident pour notre société de l'information, l'adage du XIXe siècle : le pouvoir corrompt est une constatation quotidienne des équipes IR.

Quelle équipe IR n'a jamais traité une compromission liée à un problème de moralité ?

Bien entendu, ceci ne signifie pas que le pouvoir est un synonyme de corruption, mais simplement que tout individu investi d'une autorité ou d'une responsabilité peut être tenté de l'utiliser afin d'en tirer un quelconque avantage personnel.

Une déduction immédiate peut être tirée de ces deux affirmations :

Si savoir, c'est pouvoir et si le pouvoir corrompt, alors le savoir corrompt !

Ainsi, la connaissance accroit le risque de corruption. Et c'est là le noeud du problème.

Un membre d'une équipe IR possède les connaissances et le savoir-faire pour devenir un agent extrêmement dangereux, en particulier pour l'organisation qu'il est sensé protéger ! Sa reconversion en blackhat semble très facile :

la même connaissance des vulnérabilités des systèmes d'exploitations et de la plupart des applications, la même utilisation quoditienne d'outils d'analyse et de débogage, et enfin le suivi quotidien des mêmes pages relatives aux derniers rootkits et autres malwares.

En fait, il n'en est rien. Le passage à l'acte est souvent lié chez un individu à une absence de connaissance sur les moyens à la disposition des enquêteurs. Or, peu de personnes sont plus au fait des dernières techniques de forensique numérique qu'un membre d'une équipe IR. Il est également connu que le crime parfait ne résiste jamais à l'amélioration des techniques d'investigation...

Les sommes folles offertes actuellement pour une simple vulnérabilité dans Vista étaient ce matin dans tous les esprits de mon équipe. De tels montants, comparés aux salaires de techniciens, font rêver. Je ne sais plus qui d'entre nous a lancé l'idée d'unir nos efforts afin de rechercher une telle vulnérabilité, puis de monter une société écran dans un quelconque paradis fiscal, afin d'en faire profit...

La conversation a gentiment dérapé vers toutes les actions que l'équipe pourrait entreprendre à son propre profit : détournement de centres de calcul entiers afin de réaliser des rainbow tables, collecte d'informations personnels pour la revente à des spammers ou des list-brokers, renseignement économique... Bref, l'arsenal complet du parfait criminel en col blanc.

Au delà de cette simple conversation, une équipe IR - dont la mission est essentiellement défensive - utilise les mêmes outils que ses adversaires. Ajouté à cela le côté sulfureux de la sécurité informatique, il est alors inévitable que la plupart des responsables soient méfiants vis à vis de toute initiative entreprise par son équipe IR ou son staff chargé de la sécurité informatique. Toujours est-il que notre profession souffre suffisamment de l'ignorance ambiante, pour que nous puissions nous permettre d'avoir une attitude équivoque vis à vis de notre moralité.

En fait, j'ai souvent des pics de violence lorsque j'entends l'un de ces pseudo-hackers/professionnel-INFOSEC laisser supposer qu'il pratique toujours la compromission système à distance, comme un simple passe-temps.

Pour revenir à notre sujet principal, mon autre question d'ordre éthique est la suivante :

Jusqu'où peut-on aller pour stopper ou coincer un assaillant ?

Un coordinateur IR doit constamment s'interroger sur le bien-fondé moral des contre-mesures qu'il fait mettre en place par son équipe : sniffer, pot de goudron, pot de miel (j'adore les termes français pour ces deux là), keylogger... Sur quoi un tel jugement peut-il reposer ?

L'approche la plus simpliste consiste à se convaincre que tout ce qui tient du mensonge, du chantage ou de la tromperie est immoral. Au delà des considérations religieuses (qui ne sont pas ma tasse de thé en cette période de politiquement-correct), je préfère, pour ma part, pratiquer la règle de Kant qui stipule qu'un acte est moral s'il est universel. En d'autres termes, il est légitime de tromper l'assaillant dans des situations où nous admettons que quiconque à notre place serait en droit de le tromper.

Ainsi, l'acte moral s'apprécie en fonction des intentions qui le sous-tendent. Etant donné le caractère confidentielle des affaires qu'elle traite habituellement, une équipe IR ne peut pas s'appuyer sur un quelconque débat public pour justifier du bien fondé d'une de ces actions. Mon expérience fait que je me tiens à la règle suivante : ne déployer que le strict nécessaire de moyens pour stopper ou découvrir les acteurs d'une compromission. Tout en respectant la législation des pays concernés, cela va de soi...

C'est promis, le prochain article sera technique. ;-)

La sociologie des équipes IR ou la libre société

Bon, j'ai cinq articles sur le forensique en préparation, et toujours rien de suffisamment abouti pour être présentable en l'état (perfectionniste, me direz-vous ?). Il faut savoir que c'est très long de faire des copies d'écran d'expériences réalisées à la vas-vite...

Faisons donc un peu de social, cela peut se faire sans aucune préparation :

Les méthodologies pratiquées par les équipes IR reposent toutes sur des hypothèses visant à expliquer les informations et les données recueillies. Or, il est souvent possible d'émettre plusieurs hypothèses à partir d'un recueil donné. La première question est la suivante :

Faut-il toujours choisir le scénario le plus simple ?

Un ancien précepte philosophique, connu sous le nom de rasoir d'Ockham, du nom d'un philosophe anglais du Moyen Âge stipule que : Parmi toutes les hypothèses, choisissez la plus restreinte. S'il est possible de ne retenir qu'un élément pour expliquer tel ou tel évènement, écartez le second.

Mais, la pratique de l'IR montre que, fréquemment, le scénario le plus évident n'est pas toujours le plus proche de la réalité. Un bon binôme IR doit donc savoir abandonner ce qu'il avait présumé au préalable et être capable de prendre du recul par rapport au scénario qu'il privilégie. Toute l'expérience du responsable de l'équipe IR (appelé par la suite coordinateur IR) réside dans la décision de se détacher d'un scénario qui ne colle pas aux données recueillies.

Quelle doit donc être l'état d'esprit de l'équipe IR lorsqu'un de ses binômes présente un scénario ?

Après plusieurs tâtonnements, j'en suis venu à considérer que la meilleure attitude consistait à écouter la ou les hypothèses, puis à chercher à les démolir à l'aide de toute les objections possibles et imaginables. Le coordinateur IR et le reste de l'équipe IR se doivent donc de critiquer le scénario construit par le binôme IR. Ceci va à l'encontre de toute règle sociale et peut mettre en danger la cohésion d'une équipe IR non entrainée à cette pratique !

Le processus de réfutation doit pour cela être facilité par le binôme IR qui doit faire en sorte de présenter son scénario de manière à permettre justement son démenti. Ceci demande beaucoup d'entrainement et ressemble, pour une oreille non avertie, à de la langue de bois !

Mais cela ne suffit pas. Mon opinion est la suivante :

La formulation d'une critique n'est possible que dans une équipe IR ouverte, dans laquelle l'information circule librement.

L'un des meilleurs moyens que je connaisse consiste à faire tourner le rôle de coordinateur IR, facilitant à la longue une libre expression, là où une hiérarchie trop stricte ne ferait que la museler.

On est là à des années lumières de l'image convenue de la cellule de crise : le sombre capitaine, seul maitre à bord au milieu de la tempête, qui dicte ses ordres à une équipe disciplinée, au fil de son intuition... Les plus gros désastres, que j'ai d'ailleurs pu observer au cours de ma carrière, provenaient souvent de ce genre de configuration, si prisée dans les films d'actions. Mais, je m'égare encore...

Personne n'aime faire l'objet de critique, surtout après une vingtaine d'heures de travail acharné. Enfin, notre éducation fait que l'on hésite toujours à critiquer la travail d'un proche. Le rôle du coordinateur IR est donc d'encourager ce genre d'aptitude. Le plus dur à vaincre reste la peur du ridicule devant ses pairs, si une réfutation parait complètement farfelue.

Finalement, les meilleures équipes IR que j'ai pu rencontrer ressemblaient d'avantage à un cercle de joueurs de poker, plutôt qu'à une section d'infanterie de la Grande Armée ! Quant à l'image que peut avoir une telle équipe au sein d'une organisation, ceci est une autre histoire. :-)

Livraison en cinquante minutes chrono...

Un petit texte d'ambiance, pour nous changer de la technique pure...

Bien que le combat en milieu urbain l'ai mis au rencard au profit du trinôme, mon opinion est que le binôme constitue la structure de base la plus efficace pour une équipe IR :
- un opérateur IR aux manettes : interlocuteur unique de l'administrateur distant en première ligne (souvent, le premier intervenant sur l'incident)
- un opérateur IR : tenant le cahier de bord et veillant au respect de la procédure

Ce binôme IR est composé, de préférence, du grand classique Mentor/Scarabé. Cette configuration permet d'éviter les éternels conflits de générations (ou de diviser pour régner selon les points de vue) et surtout de former en un rien de temps les nouveaux venus.

Voila pour la mise en situation...

L'objectif de toute investigation IR sur un évènement suspect consiste à déterminer si un incident sécurité informatique est survenu et - dans l'affirmative - comment il s'est produit. Un binôme d'opérateurs IR a cinquante minutes pour bâtir une hypothèse plausible et dix minutes pour la présenter au coordinateur de l'équipe IR. Ce dernier devra alors l'expliquer, en termes non-techniques, au responsable du système suspect (cas classique) ou au responsable de la cellule conduite (crise ou incident majeur).

Cinquante minutes peuvent être terriblement courtes, surtout avec un administrateur qui en passe quinze à trouver les clés de la baie technique... Le meilleur allié de l'équipe IR reste un simple cédérom d'investigation. Ce dernier peut contenir la distribution HELIX ou une petite compilation d'outils maison. Il doit bien sûr être détenu par l'administrateur du système suspecté ; sinon, nous avons encore perdu de précieuses minutes pour monter une autre manip' ! (vive la planification)

La quasi-majorité des systèmes d'extrémité actuels (serveurs et stations de travail) possèdent un lecteur de cédérom ou compatible. Ce qui n'est d'ailleurs plus le cas du lecteur de disquette. Parce qu'un cédérom ne peut pas être réécrit une fois gravé, il est théoriquement invulnérable à la corruption des codes malveillants (certains diront que les drivers ne le sont pas...).

Il reste au binôme IR à récupérer les données collectées : le réseau - via ce vieux netcat ou son petit frère cryptcat - reste le meilleur moyen, mais d'autres options doivent être planifiées.

Un fois le dispositif en place, le binôme IR doit s'assurer de collecter ou faire collecter assez d'informations pour déterminer si l'évènement rapporté est un incident sécurité informatique (et non une simple panne ou un bogue logiciel). Il doit collecter autant d'informations volatiles que possible sur le système suspect, en s'efforçant de ne pas piétiner l'éventuelle scène du crime. Le choix des outils d'investigation est alors primordial.

En comptant une moyenne de vingt minutes pour les préparatifs et un minimum de vingt minutes pour l'analyse, cela laisse moins de dix minutes pour réaliser la collecte ! Selon les informations déjà à disposition, l'OS et surtout la fonction du système suspecté, plusieurs options techniques s'offrent au binôme IR (de la plus lente à la plus rapide) :
- dialogue interactif avec l'administrateur qui exécute un certain nombre d'outils de recueil dont les résultats sont analysés à la volée par le binôme IR (choix préféré des opérateurs confirmés)
- récupération de la totalité de la mémoire physique du système
- lancement d'un script de recueil regroupant le résultat de plusieurs outils de collecte

Outre le temps qui reste au binôme pour fournir son diagnostique, l'autre facteur à prendre en compte est le principe d'échange d'Edmond Locard Ce principe fondateur des sciences forensiques stipule (de mémoire) : "lorsque deux objets viennent en contact, un transfert matériel a lieu entre eux." Ce principe peut également s'appliquer au monde numérique : "Lorsqu'un système se connecte à un autre via le réseau, il s'opère un échange d'informations entre eux".

Les rootkits et les intrus expérimentés s'évertuent toujours à effacer ce type d'informations. L'expérience d'un intrus tient d'ailleurs d'avantage à cet effacement qu'au choix de la méthode d'intrusion utilisée (on voit toujours les mêmes choses, mais ceci est une autre histoire...). Quant aux rootkits noyau, il faut développer pour chacun d'entre eux une méthode de détection spécifique, bien que je pense tester bientôt les outils de Joanna Rutkowska.

L'objectif de la collecte consiste à recueillir ce qui reste de ces informations à l'aide d'un large panel d'outils. Dans ce domaine, si un simple netstat est comparable à la vérification du registre d'un hôtel borgne, l'analyse de la mémoire physique peut, quant à elle, être comparée à l'analyse ADN de l'ensemble des fragments organiques trouvés sur la scène du crime.

Et voila, je suis revenu à la technique pure...

Le cauchemard du svchost.exe résolu par l'exécutable tlist du débogueur !

Lorsqu'un administrateur système appelle notre équipe IR pour rendre compte du comportement suspect d'une machine MS Windows, nous réalisons avec lui l'étape Réponse Initiale de notre procédure de réponse aux incidents.

En quelques mots, cette étape consiste à faire recueillir par l'administrateur les premiers éléments de preuve sur la machine suspecte toujours en fonctionnement. Lors de ce recueil, les administrateurs nous ont souvent fait part de leur inquiétude vis à vis des processus visibles dans le Gestionnaire des Tâches Windows, notamment, sur le nombre inquiétant d'instances du processus svchost.exe.

En effet, plusieurs codes malveillants - dont les chevaux de Troie toujours actifs : Agobot et Backdoor.XTS - adorent se camoufler sous ce nom de fichier. Le fait est que les systèmes MS Windows possèdent toujours un certain nombre de ces processus. J'en ai compté deux sur un système WIN2K, six dans un WINXP et même sept dans un WIN2K3 !

En parcourant la prose de Microsoft rapidement, on peut lire que svchost peut être considéré comme un super processus générique qui lance des services à partir de librairies liées de manière dynamique (DLL). Chaque instance de svchost fait donc tourner un ou plusieurs services. Il nous reste à pouvoir examiner ces services !

Lorsqu'il est lancé, svchost lit la clé de registre suivante pour lancer les groupes de services qu'il doit lancer (une ligne par groupe):
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost

Sur un système vivant (c'est le cas dans l'étape Réponse Initiale), on peut afficher ces services à l'aide de la commande :
- tlist -s
Il ne s'agit pas de l'exécutable tlist.exe fourni avec les Ressources Kits, mais de celui fourni avec les débogueurs Noyau Microsoft. Nous avons tout d'abord rajouté cet exécutable dans un répertoire nommé add On à la racine du cédérom HELIX. Les fichiers contenus dans un tel répertoire sont alors visibles par les deux parties d'HELIX (Linux et Windows).

Par la suite, les exécutables intéressants du débogueur Noyau Microsoft, dont tlist, ont été intégrés nativement dans HELIX (de mémoire, dans le répertoire /IR/windbg/). Ce cédérom est à la base de notre procédure de Réponse Initiale...

Pour détecter rapidement les instances suspectes de svchost, nous utilisons le même exécutable tlist.exe du débogueur Microsoft. Normalement, svchost.exe doit être lancé par le processus services.exe. Pour afficher l'arbre d'affiliation des processus en cours, on utilise le drapeau -t de tlist comme dans l'exemple suivant :
Une instance suspecte de svchost.exe aura généralement pour père le processus cmd.exe.

Le plus sympa avec tlist.exe est que son drapeau -c permet d'afficher la ligne de commande qui a lancé chacun des processus en cours :
Si, comme ici, notre administrateur trouve un svchost.exe lancé par une ligne du type : C:\svchost.exe -L -p 21 -e cmd.exe, nous avons soulevé un nouveau lièvre !

Equipe forensique, équipe IR, quelle différence ?

Le forensique est souvent confondu avec la réponse aux incidents (abrégé dans la suite par IR pour Incidents Response). Mais, leurs objectifs sont fondamentalement différents.

Toute entreprise doit pouvoir mettre sur pied une équipe IR, lorsqu'un évènement suspect survient ou lorsqu'il faut stopper une activité malveillante. Monter une équipe forensique répond à d'autres besoins :

Une équipe forensique doit bien sûr posséder des connaissances techniques poussées, mais également un background légal conséquent. La différence fondamentale avec une équipe IR classique est la suivante :

L'équipe forensique doit maitriser la manipulation et la préservation de preuves numériques et doit savoir les présenter à un tribunal.

Ses membres doivent bien sûr être choisis parmi les techniciens systèmes et réseaux. Mais il faut également des spécialistes dans les domaines des ressources humaines, des affaires juridiques et même, parfois, des relations publiques...

Après avoir rédiger des procédures détaillées pour :
- identifier les systèmes critiques et la manière de les inspecter en cas d'incident (par exemple, certains systèmes ne pourront pas être mis hors tension, car trop critiques pour la conduite des opérations...)
- définir une certification d'authenticité (chain-of-custody pour les anglo-saxons) pour la collecte des preuves
- rédiger les modèles des documents forensiques
Il faut encore munir l'équipe forensique d'une trousse à outils conséquente.

Monter une équipe forensique est loin d'être à la porter de toute les entreprises. L'une des meilleures solutions consiste à fournir un bagage forensique à une équipe IR, en l'associant à un consultant forensique spécialisé, si on décide qu'un incident nécessite une poursuite judiciaire.

L'équipe forensique mène alors l'enquête, collecte et analyse les preuves. Le consultant vérifie que l'enquête est menée dans les règles de l'art et s'assure surtout que les preuves sont admissibles par un tribunal.

Quelques leçons apprises sur la réponse aux incidents

Dans le traitement de n'importe quelle crise, l'expérience montre que seuls deux facteurs sont réellement fondamentaux : l'expérience et la préparation.

Après de long mois passés à résoudre (ou tenter de résoudre...) des incidents sécurité informatique, j'en suis venu à la conclusion que la réussite ou l'échec d'une équipe IR ne provenaient pas du nombre d'IDS, IPS, pare-feu, antivirus, proxy et même honeypots qu'elle pouvait aligner, mais tout simplement de son organisation et des rapports humains qu'elle avait su tisser avec ses partenaires.

En fait, savoir répondre à un incident sécurité informatique se résume à respecter les trois principes suivants :
- la perception de l'incident
- la mobilisation des acteurs
- l'organisation de la réponse

Et oui, cela ne demande a priori aucune connaissance technique ! Il suffit pour s'en convaincre d'aligner cinq ou six hackers de haut vol dans une salle de crise... De plus, il faut avoir conscience que, contrairement à l'idée reçue, la gestion d'un incident majeur ne constitue pas une épreuve de vérité, mais un réel savoir-faire qui se construit essentiellement avec l'expérience.

La gravité d'un incident est une notion éminemment relative. Il faut pour cela se préserver de tous les éditeurs de logiciels de sécurité (les éditeurs d'antivirus en tête) qui rivalisent de sensationnalisme. Parfois même, les CERTs les plus sérieux se laissent prendre au piège...

La perception d'un incident sécurité informatique s'affine avec l'expérience et l'on doit toujours s'efforcer d'éviter de nommer crise ce qui n'est qu'une simple urgence, sous peine de perdre une crédibilité si difficile à acquérir.

Le principe de mobilisation consiste à éviter de passer soudain du calme quotidien à l'alerte de mobilisation générale. Il s'agit donc d'accompagner graduellement les indices d'un incident potentiel. Mais, dans la sécurité informatique, tout peut aller très vite...

La règle est la suivante : lorsqu'un faisceau suffisant de présomptions est réuni, il faut placer son équipe en état de veille renforcée. L'objectif est d'accompagner le développement de la situation afin de pouvoir déclencher le dispositif de la résolution d'incident au bon moment. Là encore, l'expérience est reine.

Enfin, il faut pouvoir proposer au client-victime un dispositif organisationnel approprié pour répondre à l'incident. Un tel dispositif fait partie des savoir-faire que l'on ne dévoile pas facilement (et je ne dérogerai pas à cette règle, du moins pour l'instant !).

Toutefois, il faut savoir que la mise en place du dispositif dépend de la nature et de la dynamique de l'incident : on ne gère pas de la même manière un incident court et un incident de longue durée. Et c'est toujours l'expérience qui permet de deviner la durée d'un incident, bien qu'on la sous-estime la plupart du temps !

Un des petits trucs que j'ai appris auprès des spécialistes de l'urgence est l'importance des repères visuels en état de stress. Dans de telles situations, on risque rapidement de perdre ses repères, d'oublier son rôle ou tout simplement de conserver sa propre carte mentale de la situation avant l'incident. De plus, lorsque enfin arrive la relève de l'équipe IR, un compte-rendu oral décousu, sous le coup de la fatigue, n'apporte en général rien de bon, si ce n'est cet habituel : bon courage !

Un tableau blanc avec un organigramme à jour au format géant, un ou plusieurs cahiers de bord (en bon papier), forment encore ce que l'on fait de mieux pour ne pas perdre pied dans un incident majeur regroupant une bonne cinquantaine de sites. Les logiciels de type Trouble Tickets, même les plus sophistiqués, ne les remplaceront jamais...

Ce tableau blanc doit évidemment être placé de manière à permettre au "visiteur" - du type haut responsable - de jeter un oeil derrière l'une des vitres de la salle de crise, sans vous déranger pour vous demander un point de situation et en profiter pour vous raconter sa jeunesse, lorsqu'il était un opérationnel...

Faut-il débrancher ou pas ?

L'usage des techniques forensiques est en plein évolution. Pourtant, lorsqu'un expert forensique est mandaté pour un délit ou un crime, la procédure reste immuable :
- éteindre la machine suspecte en "arrachant" son cordon d'alimentation
- convoquer le suspect et le plaignant pour la saisie des preuves
- acquérir les données du disque dur
- prendre une image forensique (bit par bit) à l'aide de "dd" ou de EnCase
- analyser les données
- rédiger un rapport

Il y a encore quelques années, un employé ne disposait que d'un unique PC, doté d'un petit disque. Les réseaux étaient rudimentaires, voire inexistants. Les protections par mot de passe étaient simplistes et le chiffrement fort des données était interdit par la loi dans notre beau pays ! Un enquêteur forensique était sûr de ses outils et de ses résultats et se présentait sereinement devant n'importe quel tribunal.

Avec l'avènement de l'hyperconnexion des réseaux d'entreprise, suite aux diverses fusions, acquisitions et autres partenariats faisant vivre les heureux détenteurs d'un MBA ;-), les données d'un employé sont réparties sur toute la planète et sont de plus en plus chiffrés avec de bons algorithmes. Bien entendu, l'employé doit pouvoir les consulter et les modifier de partout et tout le temps, surtout lorsqu'il s'agit d'un membre du directoire. La conséquence est que les experts forensics se montrent de plus en plus impuissants face aux crimes des cols blancs.

Mon approche des techniques forensiques provient de la réponse aux incidents (abréviation courante : IR, pour Incident Response). Dans ce domaine particulier, si nous avons toujours en tête que toutes les preuves recueillies sont susceptibles d'être présentées un jour devant un tribunal, l'objectif prioritaire reste de découvrir le plus rapidement possible les artefacts clés de l'incident. C'est à partir de ces artefacts que seront établis une ou plusieurs hypothèses de travail.

La procédure forensique "classique" est inadaptée aux besoins d'une équipe IR, surtout lorsque l'on connaît les délais et la logistique qu'elle implique ! C'est pourquoi elle reste toujours une option exceptionnelle de l'IR. On y pense parfois pour bétonner la rédaction d'un compte-rendu de retour d'expérience...

Après cette longue introduction, voici la question du jour :

Faut-il encore recommander à l'administrateur système de mettre hors tension un système suspecté de contenir des preuves d'un incident sécurité informatique ?

L'enquêteur forensics expérimenté répondra par l'habituelle :

cela dépend de la situation, du système, des applications qui tournent (SGBD)...

Quoi qu'il en soit, une chose est sûre :

la mémoire volatile et l'état du système sont perdu lors de la mise hors tension.

En fait, quelles sont les informations potentiellement utiles pour l'IR qui sont localisées dans la mémoire physique d'un système suspect :
- mots de passe en cache (chiffrement, messagerie...)
- codes malveillants résidant uniquement en mémoire physique (SQLSlammer)
- processus en mode noyau camouflés des backdoors
- données en clair de disques chiffrés (PGP Disk Encryption, SafeBoot, Vista TPM...)
- données de navigation Web persistantes en mémoire, alors que le cache du navigateur et toutes les traces ont été nettoyés

Pour une équipe IR, la collecte de la mémoire physique d'un système suspect permet :
- de confirmer des alertes ou événements remontés par des IDS
- de collecter (et préserver) certains fichiers si le système doit continuer à fonctionner

Par contre, cette collecte est relativement intrusive et peut entacher une éventuelle poursuite judiciaire ultérieure (vice de forme...).

Le dernier argument de poids pour débuter l'investigation avant que le système soit mis hors tension est l'augmentation du chiffrement de données, qu'il soit réalisé au niveau du noyau, du système de fichiers ou bien d'une simple librairie d'application.

Installation de SIRIOS : serveur de tickets d'incident sécurité informatique Open Source

Description de SIRIOS

SIRIOS est un logiciel Open Source destiné à répondre aux besoins d'un CERT ou d'une équipe de réponses aux incidents. Le CERT-Bund (Le CERT de l'office fédéral de la sécurité informatique allemand) a commandé ce projet à la société OTRS fin 2003.

SIRIOS est basé sur le système de gestion de tickets d'incident OTRS (écrit en Perl), qui permet de réaliser et d'enregistrer toute la correspondance de la résolution d'un incident (e-mail, téléphone, note interne...).

SIRIOS est constitué d'une série de modules pour OTRS :
* module Incident : permet de gérer des incidents à base du format XML IODEF
* module Advisory : permet de générer des recommandations sous le format XML EISPP/DAF
* module Vulnerability : une base de données de vulnérabilités pouvant être enrichies par des bases existantes
* module Artefact : permet de sauver (valeur de hachage) et de gérer les artefacts (exploits, logs...) à analyser
* module WebWatcher : surveillance de site Web.

Installation de SIRIOS sur un serveur Debian.

La documentation de SIRIOS est essentiellement en langue allemande. Mais son installation est relativement simple.

La première étape consiste à installer un serveur LAMP traditionnel. Nous avons choisi ici un système d'exploitation Debian Linux.

Une fois ce dernier paramétré, nous allons télécharger l'avant dernière version stable du gestionnaire de tickets OTRS, disponible sur le site Internet : www.otrs.org. Pour ce message, il s'agit de la version otrs-2.0.4-01.tar.gz. SIRIOS possède actuellement un problème de compatibilité avec les versions 2.1.X d'OTRS.

Installation du logiciel OTRS

Nous allons copier cette archive et la décompresser dans le répertoire /opt à l'aide de la commande suivante :
# tar -xzvf otrs-2.0.4-01.tar.gz
OTRS nécessite un certain nombre de modules Perl. Nous allons les installer à l'aide de la commande suivante :
# apt-get install libapache2-mod-perl2 libapache2-request-perl libCGI-perl libapache-dbi-perl libgd-gd2-perl libmd5-perl libgd-graph-perl libgd-text-perl libnet-dns-perl libxml-parser-perl libdbd-mysql-perl libauthen-sasl-perl libpdf-api2-perl libcompress-zlib-perl
Pour vérifier que tous les modules perl nécessaires à OTRS sont présents, nous utilisons la commande suivante :
# ./otrs.checkModules
CGI ... ok
Date::Pcalc ... ok
Date::Format ... ok
DBI ... ok
DBD::mysql ... ok
Digest::MD5 ... ok
Crypt::PasswdMD5 ... ok
LWP::UserAgent ... ok
IO::Scalar ... ok
IO::Wrap ... ok
MIME::Base64 ... ok
MIME::Tools ... ok
Mail::Internet ... ok
Net::DNS ... ok
Net::POP3 ... ok
Net::LDAP ... not installed! (for directory authentication - not required)
Net::SMTP ... ok
Authen::SASL ... ok
GD ... ok
GD::Text ... ok
GD::Graph ... ok
GD::Graph::lines ... ok
GD::Text::Align ... ok
XML::Parser ... ok
PDF::API2 ... ok
Compress::Zlib ... ok

Une fois ces modules installés, nous allons créer l'utilisateur sirios et son groupe d'utilisateur (également nommé sirios) :
# groupadd sirios
# useradd ­-g sirios ­-d /opt/otrs/ ­sirios

Nous allons désormais mettre en place les fichiers de configuration de otrs en les tirant des fichiers-exemples (*.dist) :
# cd /opt/otrs/
# cp Kernel/Config.pm.dist Kernel/Config.pm
# cd Kernel/Config/
# for foo in *.dist; do cp $foo `basename $foo .dist`; done

L'étape suivante consiste à mettre en place les permissions nécessaires à l'utilisateur sirios et à l'utilisateur www-data (utilisateur du serveur Apache) :
# /opt/otrs/bin/SetPermissions.sh /opt/otrs sirios www-data www-data www-data

Les deux scripts Perl suivants permettent de vérifier que l'ensemble des pré-requis nécessaires aux pages de connexions des utilisateurs de SIRIOS sont vérifiés :
# perl ­-cw /opt/otrs/bin/cgi­bin/index.pl
/opt/otrs/bin/cgi­bin/index.pl syntax OK
# perl ­-cw /opt/otrs/bin/PostMaster.pl
/opt/otrs/bin/PostMaster.pl syntax OK

Reste à modifier le fichier de configuration du fichier /etc/apache2/sites-available/default. Pour cela nous allons l'éditer avec notre éditeur de texte préféré (ici nano) :
# nano /etc/apache2/sites-available/default

Nous allons rajouter les éléments suivants dans les répertoires virtuels :
Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
ScriptAlias /sirios/ "/opt/otrs/bin/cgi-bin/"

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

Il faut désormais relancer le serveur Apache, à l'aide de la commande suivante :
# /etc/init.d/apache2 reload

Installation graphique de la base de données

Pour cela, il suffit de lancer son navigateur favori avec l'adresse : http://localhost/sirios/installer.pl
A l'invit. de connexion, utilisez les éléments suivant :
- nom de connexion : root@localhost
- mot de passe : root(qu'il faudra changé dès que possible)
La première étape concerne la licence d'utilisation d'OTRS :
La deuxième étape consiste à rentrer les informations nécessaires à la création de la base.

Les informations clés sont les suivantes :
- administrateur de la base Mysql : root
- son mot de passe
- hôte : locahost
- type : Mysql
- nouvel utilisateur de la base : sirios
- son mot de passe : mot-de-passe-super-costaud (existe un script dans otrs pour le chiffrer)
- l'hôte de la base : localhost
- nom de la base de données : sirios
- action : créer

La dernière étape importante consiste à rentrer les derniers paramètres :
- le nom complet (FQND) du système : incident.société.com
- l'adresse de messagerie de son administrateur : admin@société.com
- le nom de l'organisation : CELLULE REPONSE INCIDENTS
- les paramètres des fichiers d'audit (log) doivent être laissés comme tels
- caractères par défaut : iso-8859-15
- langue par défaut : français
- CheckMXRecord : No

Paramètrage des tâches cron du serveur OTRS

Le serveur OTRS nécessite un certain nombre de tâches cron pour fonctionner correctement. Ces tâches doivent être lancé sous l'utilisateur sirios. Tous les scripts contenant ces tâches sont contenus dans le répertoire : /opt/otrs/var/cron.
# cd /opt/otrs/var/cron
# ls
aaa_base.dist pending_jobs.dist session.dist
fetchmail.dist postmaster.dist unlock.dist
generic_agent-database.dist postmaster_pop3.dist
generic_agent.dist rebuild_ticket_index.dist

Tous ces scripts possèdent un nom se terminant par .dist. Vous devez les copier dans des fichiers sans ce préfixe :
# for foo in *.dist; do cp $foo `basename $foo .dist`; done
Il faut désormais les intégrer dans les tâches de l'utilisateur sirios :
# cd /opt/otrs/bin/
# su sirios
$ ./Cron.sh start
Cron.sh - start/stop OTRS cronjobs - <$Revision: 1.4 $>
Copyright (c) 2002 Martin Edenhofer
(using /opt/otrs) done
$ exit
exit

La commande crontab -l -u sirios exécutée en tant que root permet de vérifier que ces tâches sont bien attribuées à l'utilsateur sirios :
# crontab -l -u sirios
...

Installation des modules SIRIOS

Les modules de SIRIOS à ajouter au serveur OTRS doivent être téléchargés à partir du site : www.sirios.org
Un fois ces modules copiés sur votre poste de travail, lancer une session du serveur otrs (via votre navigateur préféré) en tant qu'administrateur et, dans le menu, cliquez sur le lien : Package Manager :

Si cela ne fonctionne pas, il s'agit certainement d'un problème de permissions. Relancez alors l'utilitaire qui fixe les permissions du serveur otrs :

# /opt/otrs/bin/SetPermissions.sh /opt/otrs sirios www-data www-data www-data
...