beeboys - Fotolia
Réponse à incident : le choix difficile de l’outillage
Le choix des outils pour la constitution de l’arsenal des équipes de réponse à incident n’est pas trivial. Mathias Fuchs, formateur en criminalistique numérique avancée au sein de l’institut SANS, apporte son éclairage.
A quoi ressemble la trousse à outils requise pour enquêter sur un incident de sécurité informatique ? Mathias Fuchs, formateur de l’institut SANS, affiche une longue expérience en criminalistique numérique. Il a accepté de la partager avec la rédaction.
Pour lui, « la première décision à prendre consiste à savoir si l’on veut acheter quelque chose auprès d’un éditeur réputé, ou si l’on préfère construire quelque chose soi-même ». Mais pour cela, il faut commencer par définir ce dont on a besoin : « quelles fonctionnalités, quels flux de communication, à quelle échelle – parce que l’échelle est essentielle ». C’est d’autant plus vrai que « certains outils ne fonctionnent pas à grande échelle ».
« Pour autant, il est important de disposer d’outils capables de fonctionner pour 10 hôtes autant que pour 100 000. Personnellement, la plus vaste investigation que j’ai pu traiter avec de bons outils portait sur 170 000 hôtes. Nous l'avons fait avec quatre personnes, en trois mois. Réussir cela a été une question de personnes autant que de technologie ».
Se reposer autant que possible sur les hôtes étudiés
Cette question d’échelle touche en tout premier lieu à la collecte de données. « En la matière, il n’y a pas moyen d’échapper aux solutions reposant sur des agents. Ce qui laisse toutefois bon nombre d’options. Mais ces solutions doivent impérativement proposer certaines fonctionnalités ».
En particulier, pour Mathias Fuchs, les solutions envisagées « doivent déporter sur le poste client tout ce qu’elles font, parce que sinon, il est impossible de travailler à grande échelle. Car, on ne peut pas installer un gros serveur musclé très cher sur site pour l’enquête ».
Mais ce n’est pas tout : pas question de miser sur un outil qui se repose sur les API de Windows. Pour une simple raison : « sur une machine compromise, cela ne permet pas, avec certitude, de tout voir ; on risque de ne voir que ce que l’attaquant veut bien laisser entrevoir. Cela réduit l’éventail de produits envisageables ».
Un système d’accès aux données musclé
Les enquêteurs doivent pouvoir examiner, filtrer, trier ces données collectées en masse avec rapidité. Et le défi peut être d’autant plus grand que l’approche est exigeante. « Au SANS, nous nous appuyons systématiquement sur des chronologies, basées sur les systèmes de fichiers, les marqueurs de temps, etc. Les super-chronologies intègrent des journaux d’activité, des artéfacts de mémoire vive, des changements dans le registre… tout ce que l’on peut extraire. Et il faut replacer tout cela dans le contexte, non seulement de l’hôte étudié, mais de l’ensemble de l’incident ».
Il s’agit donc de gérer de vastes volumes de données et d’être capable de traiter des recherches et des filtres rapidement« tout en offrant beaucoup de fonctionnalités collaboratives, pour commenter, marquer les événements comme bon ou mauvais ».
Mais il ne faut pas s’attendre à des miracles. « Pour être honnête, l’outil idéal n’est pas vraiment disponible », avoue Mathias Fuchs. Ce qui implique, dès lors, « de construire quelque chose soi-même ».
Bonne nouvelle : « les composants de base sont là. Il y a quelques outils disponibles qui sont dotés de plusieurs de ces caractéristiques ».
En Open Source et gratuit, le formateur de l’institut SANS identifie en particulier « Google Rapid Response (GRR), que Google utilise lui-même en interne », et son successeur, Rekall. Mais, seule la partie acquisition des données est couverte ; pas celle de la visualisation.
Une multitude d’outils gratuits
Heureusement, GRR présente une architecture extensible, et de nombreux plug-ins sont immédiatement disponibles. Pour la visualisation et l’analyse chronologique, Mathias Fuchs pointe Timesktech, un projet ouvert, hébergé sur le compte Github de Google, et construit sur le projet Open Source Kibana (un plug-in à ElasticSearch). « Avec lui, lorsque vous découvrez un logiciel malveillant sur un hôte, vous regardez quand il a été installé, cinq minutes avant cet instant, puis cinq minutes après. De quoi obtenir des indications supplémentaires sur ce qui s’est passé sur le système. »
Mais lorsque l’on trouve un échantillon suspect, il faut pouvoir l’analyser, et cela passe par des bacs à sable (sandbox). Là, Mathias Fuchs mise sur une combinaison de projets Open Source et de produits commerciaux. A commencer par le bien connu Cuckoo qui « offre d’importantes possibilités de configuration ; ce qui rend plus difficile, pour l’attaquant, de tester dessus sont logiciel malveillant ». Cuckoo gagne néanmoins à être combiné à d’autres produits, comme Joe’s Sandbox.
