C’est un petit secret honteux de l’industrie qui commence à se fissurer : le SIEM ne fait pas tout.

Le SIEM (Security Information and Event Management) a d’abord été vendu comme la solution ultime capable d’agréger des événements de sécurité et de les corréler afin d’en faire émerger la substantifique moelle, le fameux 0,001% d’attaques qui méritent vraiment l’attention de l’expert sécurité. Dans cette vision idéale la machine doit faire le sale travail et l’humain n’a plus qu’à s’occuper de l’exceptionnel tout en sirotant un mojito le reste du temps.

Le principe est bon mais force est de constater que nous n’y sommes malheureusement pas encore vraiment, et que l’on déguste rarement de bon mojito dans les SOC. Et c’est probablement pour cette raison que le SIEM a déçu. Car si l’outil est évidemment loin d’être inutile, il n’est en réalité que la première pierre d’une stratégie qui comprend de nombreuses autres étapes, des traitements et des de processus auxquels le SIEM ne peut espérer apporter une solution à lui seul. C’est d’ailleurs la théorie développée récemment par Ericka Chickowski dans une publication sur le site Dark Reading : selon elle le SIEM est le pré-requis à une bonne analyse, mais seulement son pré-requis…

Il s’agit là en partie d’une incompréhension liée au fait que le contexte des attaques a largement évolué : les SIEM, en ne sachant pour l’essentiel que réduire le volume d’information à traiter par l’opérateur, ne donnent aucune indication sur le contexte de l’évènement et ne permettent pas non plus d’identifier des anomalies pour lesquelles il n’existe pas de règles pré-écrites.

Et là encore c’est probablement une simplification à outrance de la part des vendeurs qui est à l’origine de cette méprise : vendus comme étant en mesure d’identifier des « attaques », les SIEM isolent en réalité seulement des évènements. Or un événement n’est évidemment pas forcément une attaque. Il peut certes être éventuellement corrélé avec d’autres selon des règles pré-définies basées sur l’analyse d’attaques passées (ce qu’un SIEM sait faire), mais ça ne sera malgré tout qu’une vision partielle des menaces. Car une attaque ne se découvre pas toujours à travers une simple suite d’événements, notamment parce qu’elle peut très bien ne générer aucun événement de sécurité immédiatement exploitable. C’est par exemple le cas lorsqu’elle ne laisse que des traces parfaitement légitimes (à l’image de celles que pourraient générer un utilisateur autorisé réalisant des actions qui ne peuvent être interdites individuellement). Ainsi au delà de l’évènement c’est surtout le contexte et l’historique qui permettra le plus souvent d’identifier le comportement anormal et donc probablement l’attaque. Et ça, le SIEM n’est pas en mesure de le faire tout seul.

Dernière confusion, enfin : le SIEM a souvent été vendu comme une solution en temps réel. Or dans ce domaine le temps réel est une chimère. Ainsi les analyses forensiques réalisées après des intrusions s’appuient très souvent sur des traces récupérées dans les journaux de divers équipements ou d’applications, dont la plupart peuvent être (ou sont déjà) intégrés au SIEM.
Et pourtant l’on constate que ce dernier n’a rien vu sur le moment alors que les enquêteurs sont parfaitement en mesure de reconstruire le déroulement de l’attaque a posteriori en utilisant exactement les mêmes traces. Pourquoi cela ? Simplement parce que les techniciens disposent du recul nécessaire pour reconstruire le contexte de l’attaque et l’appréhender dans la durée, ce qu’il est évidement impossible de faire en temps strictement réel.

Ainsi bien que de nombreux SIEM soient déployés dans les entreprises, ils ne sont désormais bien souvent là plus que pour répondre à une exigence réglementaire. Et lorsque l’on interroge les analystes au sein des équipes sécurité, ils reconnaissent que leur travail demeure encore très largement manuel : tel analyste compile ainsi plusieurs fois par jour une liste d’URLs accédées via la passerelle web et tente d’y trouver des motifs inhabituels qui éveilleraient sa curiosité, ou tel autre génère des graphiques d’utilisation de certaines ressources par utilisateur et dans le temps, là aussi afin d’y trouver manuellement des incohérences. Ironiquement, alors que de coûteuses licences pour des solutions SIEM performantes trônent à quelques mètres de là, c’est encore le bon vieil Excel qui reste le plus utilisé au quotidien…

Le point commun de ces pratiques manuelles est l’intuition : l’analyste cherche à identifier des motifs, à rapprocher certaines informations d’apparence anodines à d’autres, plus lointaines, qui partagent cependant avec elles un lien qu’une machine aurait du mal à établir automatiquement. Il exploite ainsi pleinement la force du cerveau humain, naturellement doué pour procéder à de tels rapprochements.

Et les start-ups qui travaillent aujourd’hui sur la question l’ont parfaitement compris. Les visionnaires de l’ère post-SIEM se donnent désormais comme objectif d’accompagner l’humain plutôt que de l’assister, et de créer pour cela un contexte propice à faire émerger son intuition. Ces nouvelles approches opèrent par exemple une première passe afin d’identifier des comportements ou des motifs suspicieux qui ne répondent pas des menaces déjà connues, et ensuite tentent de présenter à l’opérateur une vaste quantité d’information sous la meilleure forme possible afin que le cerveau humain puisse jouer son rôle dans les meilleures conditions.

Leur approche est ainsi très différente de celle d’un SIEM (qu’elles utilisent toutefois comme une entrée parmi d’autres). Leur but n’est plus d’évacuer un maximum d’information afin de ne présenter à l’opérateur que le produit limité d’un choix automatique forcément arbitraire, mais plutôt de lui présenter à l’inverse un maximum d’information sous une forme adaptée afin qu’il puisse en tirer lui-même des conclusions. Et qu’il soit ensuite capable de « creuser » à volonté, aussi profond que nécessaire, pour suivre une piste…
Les armes de ces startups sont donc avant tout mathématiques, que ce soit dans le calcul (modélisation, analyse des comportements, profilage, échantillonnage, calcul d’entropie et de distribution…) ou dans la présentation de l’information (visualisation de séries temporelles, de clustering, etc…).

Des éditeurs tels Splunk ou Picviz Labs (qui travaille en particulier sur la visualisation) se sont déjà positionnés sur ce créneau. Et de nombreux autres y travaillent avec l’ambition d’aller plus loin encore dans le data-mining et la modélisation.

Bien entendu toutes les technologies associées au Big Data sont des outils précieux pour ces nouveaux projets. Mais leur force réside avant tout dans le choix fondamental de leur design. Celui de considérer l’humain – l’analyste – au coeur du dispositif plutôt que d’essayer de le remplacer d’abord et de le consulter ensuite. C’est un travail d’équilibriste, un numéro d’artiste de l’interface graphique tout autant que génie des mathématiques.

Et l’on réalise alors à quel point la route est longue après avoir simplement déployé un SIEM…