Comprendre les raisons de l'échec des SIEM et SIM

Récemment lors d’un tour de table avec une quinzaine de RSSI, il n’en restait qu'un pour défendre son Systèmes de management de la sécurité de l'information. Cette débâcle était prévisible, avec ces solutions l’on a cherché à répondre en une fois à trois besoins totalement distincts : archivage, corrélation et tableaux de bord.

Il y a déjà quelque temps que j'ai arrêté de compter les personnes qui m'annonçaient avoir remisé leur SIEM (Security Information and Event Management) ou SIM (Systèmes de Management de la Sécurité de l'Information), recyclé les serveurs et discrètement jeté le projet aux oubliettes. Récemment lors d'un tour de table avec une quinzaine de RSSI, il n'en restait qu'un pour défendre son SIEM - tout en admettant que celui-ci répondait à 5% des exigences après avoir coûté plusieurs centaines de milliers d'euros - et un aventureux qui osait affronter la morsure d'un tel projet. 


Cette débâcle était prévisible, avec les SIEM et SIM l'on a cherché à répondre en une fois à trois besoins totalement distincts. Ces besoins, complexes, répondent à des enjeux précis et de fait ils nécessitent une approche spécifique. Pour comprendre les causes de ces échecs en série, il est nécessaire de clairement expliciter ces trois besoins.

Le premier besoin est celui de l'archivage des traces, journaux et autres données circonstancielles. Il procède dans sa légitimité de contraintes légales et juridiques. L'archivage est un beau projet en soit. En effet, il faut d'une part déterminer les contraintes légales, réglementaires (etc.), qui imposent l'obligation d'archiver. Souvent ces contraintes n'indiquent même pas clairement la durée de rétention ! Cette première tâche s'avère souvent complexe et son résultat impact directement la responsabilité de l'organisation et de ses dirigeants. 


La deuxième tache est d'identifier précisément, et de façon quasi exhaustive, les éléments à archiver. Un inventaire qui couvrira le plus facile, les journaux, et le plus complexe comme les bases de données, parfois intégrées, de progiciels sécurité et autres. Il faudra aussi mettre en place le processus de gestion de l'évolution de l'archivage pour prendre compte de nouveaux éléments à archiver introduit par exemple par les évolutions du SI. Une sinécure. 


Une fois ces deux taches accomplies, il reste à prendre en compte les notions de gestion documentaire, à calculer le volume de stockage nécessaire, puis faire appel aux experts de l'archivage pour mettre en œuvre une solution qui répondent aux besoins notamment de non-répudiation, relecture, indexation, etc.


La faute des SIEM ou SIM est de prétendre qu'un outil généraliste de sécurité peut adresser ce besoin un tant soit peu. Les capacités ridicules des appliances et solutions explosent en quelques jours ou semaines. Les éléments qui ne sont pas des journaux ne sont pas pris en compte. La gestion documentaire est totalement absente. Les opérationnels réduisent arbitrairement ce qui est archivé pour tenter de sauver le navire SIEM qui coule sous le poids de l'inefficacité. Il est largement temps d'arrêter ce fiasco et de lancer un vrai projet d'archivage, cette fois, peut-être, sous la houlette de la direction juridique, avec des acteurs de la GED et du stockage.

Le deuxième besoin, la corrélation, est avant tout une vanité. La vanité, "caractère de ce qui est vain, vide et sans solidité" nous dit le Littré. En effet, il s'agit bien plus souvent d'un fantasme des ingénieurs de la sécurité que d'un besoin réel pour l'organisation qu'ils protègent. L'objectif est de trouver dans la masse des événements le signe distinctif d'une attaque, une vraie ! Le fantasme de l'ingénieur sécurité qui se voit en Zorro de l'entreprise, et rêve d'un outil qui, enfin, lui apporterait cette reconnaissance tant recherchée.

La frustration matinée de fantasme est un sentiment puissant que savent exploiter les bonimenteurs.
 À l'origine le besoin militaire, pressentir d'où viendra l'attaque, la détecter, et être capable de projeter en avance une force de réaction pour ainsi dénier l'effet de surprise.

Le piège est le lapin afghan, le faux faux positif. Les troupes de l'empire britannique, puis soviétique et maintenant américaine en ont une expérience douloureuse. Son principe est simple, faire déclencher volontairement les alarmes en lançant des lapins sur et par-dessus les mesures de défenses. Les défenseurs de lassitude finissent par désensibiliser et adapter leurs défenses, et la véritable attaque a lieu alors. Utiliser le faux faux positif comme arme est un raffinement. La contre mesure du lapin afghan est le retour aux fondamentaux que sont la défense en profondeur et la réactivité.

Conceptuellement, il faut comprendre que le type de corrélation recherché par ces messieurs de la sécurité du XXI siècle est strictement le même que celui de la prédiction de panne. C'est un sujet sur lequel des chercheurs s'évertuent  depuis le milieu du XX siècle pour les précurseurs - HP ou IBM par exemple - avec pour résultat une approche par la robustesse et la haute-disponibilité. Les travaux sur les probabilités et la corrélation ont été et sont nombreux. Il n'y a pas encore d'algorithme magique et le meilleur vient aujourd'hui de l'application des découvertes de Bayes, un mathématicien anglais du XVIII siècle ! Chacun peut vouloir croire les propos des bonimenteurs de foire qui, comme chez Lucky Luke, vantent les mérites d'une eau de jouvence de sécurité. Préparez le goudron et les plumes pour le fournisseur avant que vos fantasmes ne vous en fassent faire les frais.

Il existe de très bons moteurs de corrélation et de réseaux bayesiens (ie. Bayes), et des SIEM de bonne facture. Il est tout à fait possible de les utiliser mais ce sont des éléments complexes qui requièrent une haute expertise et une équipe adaptée. À la base du moteur se trouve un ou des systèmes de règles et de réseaux de calculs. Ce moteur sophistiqué et fragile nécessite pour fonctionner correctement des ajustements constant et permanent. Il faut donc prévoir, ad minima, une personne dédiée. De la qualité des ajustements du moteur dépend l'ensemble. Le concessionnaire du coin n'est pas la scuderia Ferrari et courir avec ce type d'engin n'est pas pour tout le monde.


Ce moteur va donc permettre de calculer des alertes ou événements sur la base de la foultitude d'informations dont on le nourrit en flot continu. Admettons des ajustements experts et, de fait, simplement une centaine d'alertes par jour en sortie. Un miracle déjà. Il faut des yeux pour lire et agir sur ces alertes, donc au moins un pilote d'exploitation ou ingénieur à plein-temps. Admettons que celui-ci soit des plus efficaces, il traite 70% des tickets en direct, n'en laisse en désuétude que 10% et n'envoie en niveau 2, vers les experts, que 20%. Le niveau 2 reçoit donc 20 tickets/incidents préqualifié par jour.

Là encore, selon l'approche d'une équipe minimaliste, un seul solide ingénieur sécurité, doué, vif et qui ne compte pas ses heures. Mais voilà les journées ne font que 24 heures et il ne peut réalistement traiter que 5 à 6 incidents par jour et certains vont l'occuper sur plusieurs jours ! De tous ces incidents pour les plus sévères, 2 à 3 par semaine, il faudra un manager pour les gérer et traiter pendant plusieurs semaines chacun. Nous y voilà, un strict minimum de 4 personnes à plein-temps, déjà débordé, et dédié à faire fonctionner et opérer le SIEM. Malheureusement ce n'était pas prévu dans le projet !


Il ne suffit pas de pouvoir se payer une formule 1, un jouet, il faut avoir les moyens et la capacité de s'en occuper. Il est donc facile pour des commerciaux d'user de l'appât de l'envie du jouet, de la promesse de l'ivresse de la vitesse. Il ne faudra pas se plaindre des conséquences si au final le bolide après deux tours et des sorties de route finit remisé au paddock pour toujours. A défaut, il faut donc savoir faire appel à de véritables professionnels de l'outsourcing et du service qui savent gérer et offrir ce type de service.

Le troisième besoin est celui des tableaux de bord. Mais oui, bien sûr, c'est évident. L'omniscient SIEM avec ses archives babylonesque et sa prescience tautologique vous fera devenir le Zeus de la sécurité et des risques! Signez là en bas. Oh, Les phrases en tout petit, en bas, ce n'est rien. Purgatoire dites-vous ? Mais, non voyons, juste en enfer directement c'est plus simple car tous les voyants y sont au rouge ! Les tableaux de bord procèdent d'un besoin totalement distinct de la corrélation et de l'archivage. Certes la solution d'archivage aura ses consoles d'administration et le reporting associé. L'outil de corrélation aura aussi ses consoles et rapports mais ceux-ci ne sont ni plus ni moins pertinents sur les alertes que ceux de la gestion des identités ne le sont sur les identités. Ils ne font que répondre à une fonction de gestion sur un domaine donné.

Ah, vous vouliez une vision globale et des "Key Risk Indicators" ?!  
Le pilotage est global et indépendant des moyens de terrain. Depuis le tréfonds de l'humanité la sémantique de la sécurité et des risques est stable. De la barrière de bois au firewall ce n'est qu'une évolution technologique, la sémantique est la protection de la frontière entre l'intérieur et l'extérieur. L'humanité reste tragiquement invariable, seule sa sophistication technologique progresse.

Le besoin en gouvernance, hier pilotage ou commandement, est naturel et perpétuel pour qui est en charge. Il faut prendre ce besoin non pas sous l'angle des sources et moyens mais bien sous celui de la sémantique et des problèmes de décision de haut niveau. Pour ce faire, il faut constituer des métriques, puis indicateurs puis KRI qui certes se fondent dans leurs calculs sur les données issues du SI mais sont totalement indépendants et invariants des solutions technologiques de tous ordres. Il en va de même que pour le contrôle de gestion qui n'est pas fait par la comptabilité ni par le progiciel comptable.

Ainsi les éléments de pilotage ne peuvent provenir que d'une source indépendante de la production et exploitation informatique et sécurité. En effet, celle-ci doit pouvoir fournir une vision consolidée (infogérants multiples, filiales, sites multiples) et des métriques, indicateurs, KRI sur les trois horizons: court terme (jour, semaine, mois, trimestre), moyen terme (trimestre, semestre, année), long terme (années, décennies).

Un tableau de bord est un outil au service d'une stratégie. Le point de départ est donc de croiser une approche montante: quelles métriques de bases peuvent être consolidées, et une approche descendante: déclinaison de la stratégie en tableaux de bord de suivi. Si les deux approches se rencontrent alors on a un potentiel pour monter une solution. À défaut, il faudra se pencher sur le problème de management que pose l'absence de métriques de bases vis-à-vis de la stratégie de l'organisation.
Une fois cette première phase complétée, l'on pourra mettre en oeuvre une solution de consolidation de métriques et calculs d'indicateurs puis constitution de KRI.

Restera à faire évoluer ces tableaux, les animer et les analyser en créant une fonction de Contrôleur de la gestion de la sécurité ! Tout un travail qui nécessite du recul, la compréhension des hommes et de l'entreprise et bien d'autres aspects très éloignés des salles machines et encore plus d'alertes de sécurité issues d'un "ciéme" Monsieur le Directeur ! Oui, je sais vous n'y comprenez rien et cela ne vous sert à rien, je vais, à l'instar du DAF et de ce que font ses équipes de contrôle de gestion, vous fournir un vrai tableau de bord sous peu.

Voilà, quant à confondre le SMSI décrit par l'ISO 27001 et SIEM, cela relève d'une corrélation des plus hasardeuse, mais il faut bien pour certain trouver un nouveau boniment marketing. Le SMSI est un Système et non outil. Le Littré définit système comme "proprement, un composé de parties coordonnées entre elles".

Le SMSI est l'incarnation d'une stratégie et organisation de la sécurité, de ce fait il nécessite des tableaux de bord consolidés, sémantique, stable pour le gouverner mais pas l'inverse. Le SMSI est une version appliquée du dilemme de Pascale de la Sécurité, "Je ne peux pas comprendre le tout si je ne connais pas les parties, et je ne peux pas comprendre les parties si je ne connais pas le tout".

Autour du même sujet