Bradford Nelson travaille pour « une importante agence fédérale américaine » et l’on n’en saura pas plus. Mais peu importe : l’homme de l’ombre est surtout venu livrer un retour d’expérience : celui de presque six ans de vie commune avec son SIEM dans le cadre d’un déploiement à grande échelle.

Avec le recul, Bradford Nelson identifie trois étapes essentielles dans la croissance d’un projet SIEM :

L’enfance, d’abord. A ce stade l’effort est mis sur la partie SIM de la chose (captation et corrélation des journaux, mais pas d’analyse en temps réel), et cela avant tout dans une optique de conformité. C’est ici que l’équipe du projet dresse l’inventaire de ses sources et des connecteurs disponibles, et qu’elle découvre au passage les affres de la récupération des journaux.

Une fois que tout fonctionne à peu près, Bradford Nelson conseille de rester à ce stade au moins six mois afin de roder la solution et les équipes. Mais attention à ne pas trop s’y attarder non plus : selon lui 80% des SIEM déployés aujourd’hui restent bloqués à ce stade.

La croissance ensuite. Le focus se déplace désormais sur la partie SEM du projet (surveillance en temps réel). Maintenant qu’elles sont rodées les équipes peuvent à ce stade chercher à intégrer des sources qui ne sont pas supportées nativement par les connecteurs standards, en faisant réaliser par exemple des connecteurs spécifiques.

Mais la partie la plus complexe du projet reste encore à venir : ajouter du contexte aux événements capturés. « C’est une étape cruciale ! Mettez tous les systèmes dans un tableur Excel et tenez-le à jour : à quoi correspondent les systèmes que vous voyez, qui les gère ?« , explique Bradford Nelson. Cette étape est indispensable afin de rendre les informations issues du SIEM immédiatement actionnables par les équipes des systèmes concernés.

Enfin, c’est également à ce stade que la surveillance du SIEM lui-même peut être abordée (en intégrant le SIEM comme source d’incidents).

La maturité enfin. C’est ici que les choses sérieuses commencent ! Tout d’abord en ajoutant un contexte métier aux informations existantes (quels systèmes servent quels métiers, et quel est leur importance pour ces derniers). Mais aussi en affinant grandement la corrélation (plus agressive), en y ajoutant des règles d’analyse comportementale, en cherchant à déceler des attaques « lentes » ou encore en traquant les anomalies noyées dans la masse.

Toujours du côté de la technique, le projet est désormais mûr pour intégrer des sources tierces d’information complémentaires sur les menaces (Dshield, divers pots de miel divers, le projet ZeuS Tracker, la Malware Domain List, etc…). L’objectif ici est d’ajouter un a priori aux adresses IP sources d’incidents.

Toutefois à cette étape le gros du travail réside dans l’organisation plutôt que la technique : il faut notamment mettre en place une capacité de prioritisation des alertes en fonction des besoins et des risques métiers ainsi qu’une cellule de réponse 24/7. Enfin, une véritable gouvernance du projet SIEM peut-être envisagée à ce stade : au delà de l’équipe IT une entité supérieure, plus transversale, doit elle aussi « surveiller le gardien« .

On le voit, le chemin est donc long avant d’utiliser son SIEM au maximum de ses capacités. Restez un peu trop longtemps à l’étape de l’enfance, par exemple, et le projet a toutes les chances d’être sous-utilisé à jamais (à cause de la diminution progressive des ressources qui lui sont allouées ou de l’évaporation du support de la direction). Mais passez-y trop peu de temps et le SIEM sera bâti sur du sable, ce qui ne vaut guère mieux. Ce sont là autant de considérations qui illustrent  parfaitement combien un SIEM est un projet de longue haleine qu’il sera difficile de mener seul.

Finalement, l’externalisation n’est peut-être pas si mal !

Les autres conseils de Bradford

Au delà des trois phases critiques du projet, Bradford Nelson offre quelques conseils annexes particulièrement intéressants. Les voici, en vrac :

• Ne pas se laisser influencer par les success stories mentionnées par les vendeurs : ils ne choisissent que des projets ayant bénéficiés d’une équipe dédiée. 95% d’un SIEM est inutile « out of the box« .
• Mettre en place une excellente relation entre l’équipe du SIEM, la IT et les métiers. Car une simple mise à jour d’une application surveillée par le SIEM peut en effet casser le connecteur ou polluer les données du SIEM si elle n’est pas anticipée. Un projet de gestion du changement est un must ici !
• Il faut décourager la journalisation à base d’agent spécifiques tiers et préférer la journalisation native partout où cela est possible (et de préférence avec SyslogNG plutôt que syslog).
• Les connecteurs sont particulièrement gourmands en terme de ressources (RAM, notamment). Mieux vaut être généreux.
• N’utilisez que du matériel très standard (Bradford Nelson a reconnu un an de retard dans son projet parce qu’il utilisait des processeurs SPARC, dont un bug sournois perturbait le fonctionnement de la solution)
• Ne pas hésiter à « socialiser » le projet en fournissant régulièrement des tendances, des chiffres faciles à consulter, des graphiques simples.
• Surveiller attentivement le volume de données récupérées, et le comparer en permanence avec ce qui est attendu. « Il n’est pas rare que quelqu’un ait désactivé la journalisation sur un système ou renvoyé le syslog ailleurs, et que le SIEM ne reçoive pas toutes les données attendues. Il faut pouvoir donner l’alerte dans ces cas là« , prévient Bradford Nelson.

Explosion de données

A titre d’exemple, Bradford Nelson a communiqué le volume des données récoltées par son SIEM depuis 2004. L’on constate une explosion du volume collecté, notamment depuis que son entreprise intègre les applications web au périmètre du SIEM (les arguments passés aux URLs sont pléthore !) et les captures de trafic brut.

Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Participez!

 Comments (2)