En deux ateliers distincts, La Poste et un autre grand établissement bancaire ont révélés leur mise en oeuvre d’une solution SIEM lors des dernières Rencontres de l’Identity & Access Management organisées par Atheos. Deux projets, deux produits différents (dont celui de Loglogic pour La Poste) mais des facteurs de succès communs.

« Nous avons d’abord demandé aux métiers ce qui est important pour eux, ce qu’ils veulent conserver. On peut voir cette démarche comme une analyse de risque métiers. D’ailleurs les réponses sont en termes purement métiers : qui a passé un ordre, était-il du bon montant, cet opérateur était-il autorisé à le faire ? Et ce n’est qu’ensuite que nous avons remonté le fil afin de déterminer quelles sources, quels journaux, étaient nécessaires pour arriver à ce résultat », explique le responsable de la sécurité logique d’un grand groupe bancaire français.

Même approche chez La Poste : « Il ne faut surtout pas considérer le SIEM comme un projet technique. Il faut partir des risques et savoir ce que l’on veut couvrir », confirme Philippe Steuer, responsable de l’Observatoire de la Sécurité des SI au Groupe La Poste. Seule différence : plutôt que d’aller interroger les métiers, le Groupe La Poste s’est appuyé sur sa politique de sécurité, censée avoir déjà identifié les risques. « Pour démarrer, nous avons pris notre politique de sécurité et regardé tout ce qui est interdit. A partir de là, nous avons cherché à traduire ces interdictions en comportements, puis en traces à collecter et règles de corrélations », ajoute Philippe Steuer.

En outre, s’appuyer sur une analyse afin de déterminer les risques à couvrir permet de progresser par lot. En intégrant au périmètre du SIEM uniquement les ressources correspondantes aux risques individuels en cours de couverture on évite le fameux effet tunnel qui guette les projets trop ambitieux.

Autre priorité : pouvoir compter sur une excellente architecture de stockage. « Ca a été pour nous un aspect critique de l’avant-projet : nous avions déjà en place un excellent système d’archivage et une vision claire de ce qui doit être conservé », se souvient le responsable sécurité. Quels journaux conserver ? Combien de temps ? En intégralité (afin de fournir une preuve si nécessaire) ou sous forme normalisée ? Autant de questions qui doivent être posées et répondues avant le début du projet.

Les deux projets ont en revanche adopté deux approches différentes en matière de traitement des alertes. Mais ils ont en commun d’avoir su trancher la question d’emblée.

Pour le premier groupe bancaire, la priorité a été donnée à l’analyse forensics : « Le SIEM est pour nous un outil d’analyse différée. Nous préférons agréger plus d’information et procéder à une corrélation plus poussée, mais générer ainsi des alertes de niveau deux, concernant notamment la conformité », justifie son responsable sécurité. Bien entendu, le groupe ne fait pas pour autant l’impasse sur les alertes en temps réel, mais celles-ci sont considérées comme une « commodité » et externalisées à un SOC infogéré. C’est donc une boîte noire qui produit des alertes de niveau 1 en temps réel basées sur des sources qui peuvent ne pas être les mêmes que celles du SIEM exploité en interne pour la conformité.

A La Poste en revanche, le focus est sur le temps réel. « Je ne voulais pas mettre en place un simple outil de reporting. Je veux aussi être en mesure de faire de l’alerting : nous sommes en temps quasi-réel, à 20 minutes, et nous avons mis en place à côté de ça une architecture post-mortem pour répondre aux requêtes légales », détaille Philippe Steuer.

Cela paraît évident mais ça va mieux en le disant : un SIEM doit être capable d’accompagner les changements de l’entreprise. « Nous avons voulu un système complètement vivant : il faut être en mesure d’intégrer de nouveaux journaux ou de nouvelles applications, de récupérer des logs plus détaillés si besoin ou d’étendre le périmètre à tout moment », prévient Philippe Steuer. Et les impératifs sont les mêmes pour le second témoin : une architecture souple et évolutive avant tout. « Il faut pouvoir intégrer les évolutions réglementaires, les nouveaux besoins métiers, ou encore refléter d’éventuels changements dans l’organisation, par exemple » confirme son responsable sécurité.

La réflexion doit donc prendre en compte que les sources (les journaux) ou les règles (la réglementation) peuvent changer à tout moment. La solution sélectionnée doit être en mesure de refléter ces changements rapidement, simplement et avec un impact faible sur l’équipe technique et nul sur l’organisation.

Avoir des alertes, c’est bien. Etre en mesure d’y répondre, c’est mieux. Inutile de déployer un SIEM si aucune procédure n’est prévue pour prendre en charge les messages générés par l’outil. « L’une des valeurs ajoutée de notre projet est d’avoir mis en place un Wiki pour nos équipes du SOC : ils y trouvent des plans de réaction, des procédures techniques, etc… » explique Philippe Steuer.

Les plans de réaction sont essentiels : qui contacter face à telle ou telle alerte, quand escalader, et où ? Sans de tels plans, autant éteindre la console du SIEM !

« Les règles de corrélation sont vraiment trop dépendantes de l’entreprise et de son Système d’Information. Nous n’avons donc pas utilisé les règles par défaut fournies par l’éditeur, que nous avons jugées inutiles. Nous avons rédigé nos propres règles qui collent à nos propres scénarios de menaces », prévient Frédéric Le Bastard, expert sécurité à La Poste. Au final, c’est une cinquantaine de scénarios de menace personnalisés, traduits en 130 règles de corrélation maison qui animent le SIEM de La Poste.

L’efficacité d’un SIEM se mesure généralement au rapport entre le nombre d’événements entrés dans le systèmes et le nombre d’alertes qualifiées traitées par les équipes de sécurité. Sur ce terrain, le premier groupe bancaire parle d’un passage « de millions à des dizaines », tandis que La Poste est plus précise : sur 220 millions de lignes de log ingurgitées chaque jours, le système produit 100 alertes, dont deux donnent véritablement lieu à une intervention humaine.

Mais le gain est aussi en terme de visibilité : « Nous avions vendu le projet comme nous permettant de voir passer les attaques des pirates chinois, et nous finissons en réalité par traiter essentiellement des alertes internes ! Et c’est là que ça devient compliqué : il faut gérer les sensibilité, le process RH, etc », nous confie l’un des responsables de ces projets.

Le point le plus complexe d’un projet SIEM serait-il en définitive de préparer l’entreprise à accepter ce qu’elle va découvrir en scrutant son Système d’Information ?