sécurité : SIEM ou pas SIEM ?

C’est sans doute la question que j’entends le plus fréquemment en ce moment.

Mais avant d’y répondre, il convient d’apporter quelques éléments importants au moulin du débat. (Rappel : SIEM : "Security information management system")

la gestion des logs et la supervision de la sécurité

Le premier de ces points est le fait qu’il faut bien distinguer deux besoins : la gestion des logs et la supervision de la sécurité.

La gestion des logs, plus souvent appelée « Log Management », consiste en la mise en place d’une ou plusieurs solutions permettant à une entreprise de collecter, stocker, sécuriser et archiver les journaux d’information provenant des différents équipements de sécurité, d’authentification, d’accès à Internet...

Ce besoin fait très souvent suite à des contraintes légales de conservation des « informations de connexion », mais permet également aux équipes IT de faire des recherches a posteriori, et souvent laborieuses, en cas de problème.

Cette ou ces solutions peuvent être commerciales, « Open Source » ou « faites maison ». Le seul critère obligatoire qu’il faudra prendre en compte est le fait qu’il devra y avoir un mécanisme assurant le stockage intègre de l’information collectée afin d’en conserver la valeur probante en cas d’enquête judiciaire.

La supervision de la sécurité, quant à elle, reflète une réflexion plus avancée sur les besoins de vérifier que « tout va pour le mieux » dans le Système d’Information. En effet, au-delà d’être en capacité de fournir une « information à valeur probante » à la justice, les entreprises qui font le choix de la mise en place d’une solution de supervision de la sécurité expriment un réel besoin de suivre en temps réel l’activité de leur SI, de corréler tous les évènements qui s’y passent et d’être alertés en cas de problème de sécurité.

SIEM : mobilisation générale !

L’implémentation d’un SIEM, puisque c’est de ce type de solution dont on parle lorsque l’on évoque la supervision de la sécurité, implique une organisation et une mobilisation d’un grand nombre d’acteurs si l’on souhaite que le projet réussisse.

Du CISO aux équipes IT, en passant par les RSSI et DSI, chaque métier doit être consulté afin que tous les besoins et toutes les contraintes soient respectés, que la PSSI soit implémentée dans la solution et que le SI n’ait pas à pâtir de la mise en place du SIEM.

Mais un SIEM impliquera également la création d’une équipe dédiée, capable d’assurer plusieurs niveaux de services autour de l’outil. En effet, il faudra être en capacité de lire, d’analyser, de vérifier, de valider les alertes de sécurité remontées par la solution. Il faudra être en capacité de mobiliser les bons interlocuteurs, d’appliquer les process d’escalade, etc… Bref, il faudra créer un SOC.

Vient alors la question du « Heures ouvrées ou 24/7 » ? Très rapidement suivie par « On le fait nous-même ou on le confie à un MSSP ? ».

« supervision de la sécurité : 24h/24, 7j/7 »

La supervision de la sécurité n’a de sens que si elle est assurée 24h/24, 7j/7. En effet, les incidents les plus graves ne se produiront pas tous pendant les heures de travail de la majorité des équipes.

C’est sans doute même l’inverse ! Et puis les périodes un peu plus creuses sont plus propices à la détection de signaux faibles, d’anomalies etc… non pas par la solution, qui doit être en capacité de les détecter quel que soit le moment, mais par les équipes qui seront bien trop souvent mobilisées sur des problématiques grossières (virus, DDoS, Phishing…) pendant les heures normales de travail.

Ce qui nous amène à ébaucher un début de réponse à la question « On le fait nous-même ? ». C’est toujours très intéressant de créer son propre SOC. Qui mieux que celui qui l’a créé peut comprendre un SI ? Peut le modifier pour lui faire retrouver le bon chemin ?

Mais tout ceci a un prix et l’organisation d’un SOC interne ne se fait pas d’un simple claquement de doigts. Je reviendrai, dans un autre article, sur ce qu’implique la création d’un Security Operations Center.

donc, SIEM ou pas SIEM ?

Aujourd’hui, mon avis est que la question doit être posée autrement : « Est-ce que mon SI doit être surveillé comme le lait sur le feu ? »

Dès lors que l’on expose un certain nombre d’actifs sensibles (données personnelles, données clients, brevets, etc…), que ce soit sur Internet ou en interne, il est une nécessité absolue de surveiller ce qui se passe. Les revenus des « pirates » informatiques sont essentiellement liés à la revente de telles informations. Le choix qui sera fait devra à minima prendre en compte le coût de la perte d’au moins l’une de ces données. Le SIEM devient donc la solution à adopter.

Dans le cas contraire, une solution de gestion des logs sera suffisante, d’autant qu’il ne sera pas trop tard pour implémenter un SIEM puisque certains produits proposent les 2 modes et sont capables d’activer la couche « intelligente » par simple ajout de licence.

Le SIEM, n’est plus une simple mode. Il doit désormais être inclus dans les solutions de sécurité mises en place au sein d’un SI, au même titre qu’un firewall ou qu’un WAF. Il doit faire partie des investissements à prévoir ou à continuer.

Le SIEM sera les yeux des équipes de sécurité IT et permettra aux RSSI d’être plus sereins quant à leur capacité à connaître l’information au bon moment, et autrement que par les médias sociaux ou les journaux télévisés.

Antonin

Crédit photo : © Maksim Kabakou - Fotolia.com

Antonin Hily

Directeur Technique du département SIEM & Threat Management chez Atheos-Orange CyberDefense, j'interviens auprès de grands groupes pour les accompagner dans la mise en place des outils nécessaires à la surveillance de leurs SI. Ancien RSSI adjoint et responsable du SOC d'une grande SSII internationale, je suis intervenu sur de multiples problématiques de sécurité IT.

Passionné et opiniâtre, j'aime aller au bout de tout ce que j'entreprends et mon passé d'enseignant me pousse systématiquement vers la vulgarisation de tout ce qui peut l'être. Le savoir ne vaut que s'il est partagé par tous. Défenseur du monde "Libre" et de "l'OpenSource", j'oeuvre auprès d'associations comme l'APRIL ou la FSF depuis de nombreuses années.