Réponse à incident : le choix difficile de l’outillage

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.