Alliance - Fotolia
Sept questions à poser avant d’acquérir un SIEM
L’experte Karen Scarfone se penche sur les critères importants pour l’évaluation d’un système de gestion des informations et des événements de sécurité.
Les produits et services de système de gestion des informations et des événements de sécurité (SIEM) collectent et analysent des données de log d’un grand nombre d’équipements de sécurité d’entreprise, de systèmes d’exploitation d’hôtes, d’applications d’entreprise, et d’autres logiciels utilisés par une organisation. Certains SIEM ont également la capacité de tenter de bloquer des attaques en cours dès leur détection, pour potentiellement prévenir la compromission de systèmes, ou au moins limiter les dégâts induits par une compromission réussie.
De nombreux SIEM sont aujourd’hui disponibles, dont des produit « light » conçus pour les organisations qui ne peuvent s’offrir ou ne ressentent pas le besoin d’un SIEM avancé. Il peut être difficile de choisir quels produits évaluer, et encore plus de choisir celui qui répond le mieux aux besoins de son organisation, ou de l’une de ses divisions. Le processus d’évaluation d’un SIEM devrait notamment impliquer la création d’une liste de critères utilisés pour mettre en évidence les caractéristiques les plus importantes à prendre en compte.
Cet article propose plusieurs critères, présentés sous la forme de questions, qu’il peut être pertinent d’intégrer à son évaluation d’un SIEM.
Quel support natif pour les sources de log importantes
La valeur d’un SIEM est réduite s’il n’est pas capable de recevoir et comprendre des données de logs provenant de toutes les sources de logs importantes au sein de l’organisation. Les sources les plus évidentes sont notamment les pare-feu, les VPN, les IPS/IDS, les passerelles de sécurité Web et e-mail, et les outils de protection contre les logiciels malveillants. Il est raisonnable d’attendre d’un SIEM qu’il comprenne nativement les fichiers de logs générés par des produits avec une bonne position sur le marché, ou des services Cloud de renom.
En outre, un SIEM devrait supporter nativement les fichiers de log des principaux systèmes d’exploitation utilisés par l’organisation. A l’exception des OS mobiles qui, souvent, ne proposent pas de génération de logs. Mais le support natif de logs devrait également recouvrir ceux des principaux SGBD, ainsi que les applications d’entreprises permettant aux utilisateurs d’interagir avec des données sensibles.
Un support natif de sources de logs plus étendu est appréciable, mais pas indispensable. Et si une source n’est pas supportée nativement, il est généralement possible de développer un module logiciel complémentaire.
Le SIEM peut-il compléter des capacités existantes de génération de logs ?
Certaines applications peuvent ne pas offrir de capacités robustes de génération de logs. Certains SIEM peuvent compenser cette lacune en assurant la supervision de ces applications, via un agent résident. Le SIEM dépasse alors son rôle de collecter et d’analyse de logs en assurant la production de données de logs brutes, à la place de certains hôtes.
Le SIEM peut-il mettre à profit des renseignements sur les menaces ?
La plupart des SIEM sont capables d’ingérer des flux de renseignements sur les menaces. Ces flux, souvent acquis sous la forme d’un service à l’abonnement séparé, contiennent des informations actualisées sur les activités malveillantes observées à travers le monde, y compris les adresses IP des hôtes utilisés pour lancer ou soutenir des attaques, ainsi que les caractéristiques de ces opérations. Ces flux permettent au SIEM d’identifier les attaques plus précisément et de prendre des décisions plus éclairées, souvent de manière automatique, pour stopper les attaques le plus efficacement possible.
Bien sûr, la qualité des renseignements sur les menaces varie d’un fournisseur à l’autre. Mais l’évaluation de ces flux est un autre sujet.
Quelles capacités d’investigation ?
Traditionnellement, les SIEM ne collectaient que les données fournies par des sources de logs. Mais récemment, certains produits se sont enrichis de capacités d’investigation capables de collecter leurs propres de données sur des activités suspectes. Par exemple, certains sont capables de capturer les paquets de données complets sur une connexion réseau associée à une activité suspecte. Si ces paquets ne sont pas chiffrés, un analyste de sécurité peut consulter leurs contenus plus attentivement afin de mieux comprendre la nature de l’activité en question. Un autre aspect de l’investigation est l’enregistrement des traces d’activités des hôtes. Un tel enregistrement peut être effectué en continu, ou simplement déclenché dès le début de l’observation d’une activité suspecte.
Quelles fonctions pour aider à l’analyse des données ?
Les produits de SIEM utilisés pour la détection et/ou la gestion d’incidents devraient offrir des fonctions aidant les utilisateurs à examiner et analyser les données de logs eux-mêmes, ainsi que les alertes remontées par le SIEM. De fait, même un SIEM hautement précis est susceptible d’interpréter, de temps à autre, des événements de manière erronée : l’intervention humaine est nécessaire pour valider les résultats du SIEM. En outre, les personnes enquêtant sur des incidents ont besoin d’interfaces conçues pour faciliter leurs investigations. Et cela recouvre notamment des fonctions avancées de recherche et de visualisation de données.
A quel point les capacités de réaction automatique du SIEM sont-elles rapides, sûres et efficaces ?
L’évaluation des capacités de réaction automatique d’un SIEM se fait nécessairement dans le contexte spécifique de l’entreprise, car elles dépendent largement de l’architecture spécifique de son réseau et de ses contrôles de sécurité réseau, notamment. Par exemple, un SIEM donné peut ne pas avoir la capacité de piloter le pare-feu de l’entreprise afin de bloquer une connexion suspecte. Mais outre ces capacités d’interopérabilité, il est important de prendre en compte les caractéristiques suivantes : le délai de réaction du SIEM, entre détection et activation des contrôles de sécurité appropriés ; la protection des communications entre SIEM et contrôles de sécurité de l’infrastructure contre les écoutes, interceptions et altération ; l’efficacité du SIEM pour effectivement stopper des attaques avant que des dégâts ne soient commis.
Quelles réglementations sont supportées nativement ?
La plupart des SIEM proposent des capacités de reporting hautement personnalisables. Nombre de ces produits offrent également un support natif des rapports exigés par différentes réglementations et initiatives de sécurité. Chaque organisation devrait identifier les initiatives qui lui sont applicables et s’assurer que le produit de SIEM en supporte autant que possible. Et pour chaque initiative non supportée nativement, il est important de vérifier que la personnalisation permet de générer les rapports nécessaires.
Au travail !
Les SIEM sont des produits complexes qui nécessitent une intégration poussée avec les contrôles de sécurité de l’entreprise et les nombreux hôtes de son infrastructure. Pour identifier le SIEM le plus adapté à son organisation, il est important de définir des critères d’évaluation de base.
Il n’y a pas un SIEM qui soit le meilleur pour toutes les organisations ; chaque environnement présente sa propre combinaison de caractéristiques IT et de besoins de sécurité qui doivent être pris en compte. Même la principal raison d’adoption d’un SIEM varie largement d’une organisation à l’autre.
Il n’en est donc que plus important de procéder à sa propre évaluation de produits et services SIEM avant d’en retenir un.
Adapté de l’anglais.
