La Théorie et la Réalité du ROI des SIEM

Beaucoup de choses sont écrites sur le SIEM, mais mon expérience personnelle avec ces merveilleux outils a commencé en 2007. Aujourd’hui, la technologie elle-même a plus de 18 ans et le SIEM est à tous égards un marché mature. Avec des clients, une équipe et des partenaires, j’ai eu le privilège de participer activement à plus d’une centaine de projets SIEM dans le monde entier. Ensemble, nous avons construit un SOC à partir de zéro, mis en œuvre des sources de journaux critiques SOX pour se conformer aux délais d’audit serrés, ressuscité une installation SIEM abandonnée en une demi-journée pour localiser des indices médico-légaux et affiné les règles de corrélation anti-fraude… et simplement pris une quantité appropriée de bière avec des entreprises de toutes les industries et de toutes les régions du monde en discutant de l’histoire des victoires et des défaites des projets SIEM. On sait que plus de 40 000 organisations dans le monde ont des systèmes SIEM, ce qui constitue donc une communauté assez grande et bien sûr un marché. Ce qui est certain, c’est que l’histoire est loin d’être terminée, car le concept même de SIEM continue d’évoluer. La plupart des organisations qui ne sont pas indifférentes à la cybersécurité ont déjà un SIEM sous une forme ou une autre. Les limites entre les technologies SIEM sont floues : il existe des premières, deuxièmes et troisièmes générations de la plateforme, bien que dire que IBM QRadar ou Micro Focus ArcSight sont des technologies de la première génération et que LogRhythm est de la deuxième n’est pas tout à fait correct, car les technologies évoluent constamment. De plus, les affirmations selon lesquelles Splunk et Elastic ne sont pas un SIEM sont incorrectes car ils ont de nombreuses propriétés et fonctionnalités SIEM.

Alors comment le SIEM et le ROI se rejoignent-ils ? Si nous examinons le ROI du point de vue de toute entreprise, cela signifierait soit un profit supplémentaire, soit une réduction des coûts. On peut donner de nombreux exemples de retour sur investissement en matière de sécurité de l’information suffisants pour rédiger un article distinct, alors pour l’instant, concentrons-nous sur le SIEM. Il est difficile de croire que quiconque investit dans ces systèmes pour gagner de l’argent, alors il nous reste le facteur de réduction des coûts. Essayons de le comprendre.

Comment le SIEM apparaît-il dans nos vies ?
5 moteurs de ROI de base

1. Conformité
2. Référentiel central de logs
3. Investigations Forensiques
4. Centre des Opérations de Sécurité (SOC)
5. Héritage

SIEM pour la conformité PCI, SOX et HIPAA

Très souvent, les SIEM sont achetés par des institutions financières et des banques car différentes réglementations de conformité exigent la collecte et le traitement des données de journal. Le PCI DSS exige de collecter centralement les données de journal, de les stocker et de les conserver dans une forme non modifiée, de fournir une piste d’audit de leur intégrité (une exigence très importante que tous les SIEM ne peuvent toujours pas satisfaire même à ce jour) et bien sûr de surveiller les événements au quotidien. Si nous devons nous conformer à SOX, il est nécessaire de suivre et de gérer les incidents de tous les systèmes critiques SOX et en fonction de cela, les auditeurs font ou non confiance aux données de l’entreprise dans les systèmes traités. Si les incidents ne sont pas traités, l’audit devient beaucoup plus coûteux. Un autre exemple est la conformité HIPAA avec l’exigence de maintenir une trace d’audit sur l’accès aux données des patients pendant jusqu’à 5 ans. Cela affecte principalement l’architecture du traitement des données SIEM : la flexibilité des capacités d’intégration des systèmes tiers, l’efficacité et la stabilité de l’agrégation, les algorithmes de compression des données ainsi que le contrôle de l’intégrité.

Alors, quel type de ROI le SIEM peut-il générer pour la conformité ? Le plus clair est l’absence d’amendes et de pénalités dues non seulement au respect mais au dépassement des exigences des réglementations. Cela représente un excellent retour sur investissement du SIEM puisque l’investissement dans le projet sera probablement au moins 10 fois inférieur à la pénalité pour violation de conformité. Il est conseillé de créer un modèle TCO sur 5 ans incluant toutes les dépenses telles que le support technique, le matériel, le coût des logiciels, le coût de l’équipe, la formation et le programme de rétention. Ensuite, faites correspondre le TCO avec les économies possibles sur les violations de conformité en fonction des risques auxquels vous faites face. Cela permettrait de prouver le ROI non seulement sur papier et d’éviter les erreurs de calcul.

Référentiel central de logs

La meilleure façon de calculer le ROI de l’utilisation du SIEM en tant que référentiel central de logs est assez simple : déterminer quelles données de log nous devons collecter et stocker, combien d’espace elles prendront, les spécifications matérielles et la charge de travail pour cette tâche. Il est nécessaire de tenir compte de tous les paramètres, de l’espace disque dur au coût d’un cœur CPU (en particulier pour les déploiements basés sur le cloud et sur la virtualisation). Tous les systèmes de gestion de logs et SIEM sont très efficaces pour compresser les données de log avec une efficacité de 2X à plus de 10X ce qui entraîne des économies directes sur le stockage, même si l’enrichissement et la normalisation des données sont effectués. La capacité d’un SIEM particulier à affiner granulomètre agrégation et filtrage des données de log améliorera directement l’efficacité du stockage et le ROI. L’agrégation est présente dans toute plateforme SIEM mature, pratiquement tous les systèmes que vous voyez dans Gartner ont une certaine forme d’agrégation. Les capacités varient d’un fournisseur à l’autre : très souvent, c’est juste un bouton on/off, tandis que dans d’autres technologies, nous avons plus de 9000 paramètres qui peuvent être configurés pour s’adapter à n’importe quelle infrastructure.

Les SIEMs sont conçus pour supporter la recherche rapide et la fourniture en temps opportun d’informations. De plus, nous utilisons la technologie pour simplifier la sauvegarde et la gestion des données de log. Étonnamment, il est beaucoup plus facile de gérer un système de stockage de logs centralisé plutôt que de s’occuper de chaque source de log individuellement. Les archives créées par le SIEM ont très souvent un contrôle d’intégrité intégré et sont difficiles à falsifier : elles sont soit cryptées, soit créées comme un seul conteneur où le bris de l’intégrité du conteneur ne passera pas inaperçu. Tous les SIEMs matures contrôlent l’intégrité de tels conteneurs et la conservation des logs.

Nous voyons souvent comment les projets SIEM se manifestent à la fois comme des initiatives informatiques et de sécurité, principalement en raison des économies de stockage des données de logs. C’est particulièrement vrai pour les plateformes Splunk et Elasticsearch, car elles sont toutes deux les plus adaptées pour cette tâche. Un scénario typique ici est lorsque le département informatique obtient le soutien et le financement de la direction pour le projet, acquiert la plateforme et l’équipe de sécurité obtient une licence supplémentaire en tant que mise à niveau, car l’intégration de technologies du même fournisseur réduit le TCO et simplifie le support.

ROI sur les opérations de Forensics Proactive

Avoir un stockage centralisé sécurisé de toutes les données de logs ouvre la voie à un ROI en Forensics : les logs sont stockés dans un format non modifié à l’épreuve de la falsification, permettent une recherche rapide, un pivotement et tout cela réalisable en un temps raisonnable si nous avons bien mis en œuvre notre SIEM. Ainsi, notre enquête sur les incidents peut être menée plus rapidement et l’obtention de preuves devient plus simple. Quand en avons-nous vraiment besoin ? Eh bien, si notre expérience en cybersécurité nous a appris quelque chose, c’est que lorsque qu’un incident se produit, la plupart des organisations n’ont pas d’experts à temps plein pour mener une enquête et cette responsabilité incombe d’une manière ou d’une autre au département de la sécurité (ou cyber) de l’information. Seules les grandes entreprises et organisations du secteur public peuvent se permettre de consacrer un employé à ces fins. Et aux yeux de l’entreprise, la médecine légale est un coût important pour l’entreprise qui ne peut être évité. Si le SIEM dispose de toutes les données nécessaires, un spécialiste CHFI mènera une enquête beaucoup plus rapidement et se concentrera sur l’objectif principal – trouver les adversaires et les preuves. Il est beaucoup plus facile de mener une enquête lorsque les données de logs sont disponibles dans un format original, des rapports prédéfinis et des exportations existent réellement et ne prennent pas des jours à récupérer, les captures de trafic (PCAP) sont disponibles et nous pouvons même avoir des événements de sécurité suspects alias statistiques d’incidents pour mieux construire une image complète. Dans la situation inverse, le spécialiste de la médecine légale devra creuser profondément et probablement se rendre sur place pour collecter personnellement les données nécessaires depuis les serveurs bit à bit. Dans cette situation, le temps nécessaire pour mener une enquête proprement augmente ce qui augmente directement les coûts médico-légaux ou diminue la qualité à un point où le résultat final peut être décevant. Si l’incident ne s’est jamais produit, il est presque impossible de calculer le ROI sur la forensique proactive. Cependant, si nous examinons la tendance croissante des violations de données, des attaques d’APT et des statistiques d’incidents cyber et que nous embrassons la réalité, nous réalisons que tôt ou tard, toute organisation subit une attaque. Et une violation conduit inévitablement à traiter directement ou indirectement avec une enquête médico-légale pour tout DSI.

SIEM et Forensics dans la vie réelle

Il y a quelque temps, nous avons travaillé en étroite collaboration avec notre partenaire sur une enquête concernant une possible attaque interne. Lorsque nous sommes arrivés sur site, il n’y avait pas de SIEM ni même de gestion centrale des logs déployée et, comme dans les classiques, quelqu’un avait supprimé les logs là où il avait une chance, les sauvegardes n’ont pas été effectuées, les ACL n’étaient pas là, aucun fichier PCAP n’était disponible. Nous avons analysé les images cibles, envoyé des données au laboratoire pour récupération, effectué quelques surfs sur le darknet et fouilles.. En conséquence, la direction du client a payé pour 5 jours de forensique + le temps pour le rapport et la présentation, qui ont prouvé les traces et dommages de l’attaque interne, mais comme l’entreprise n’avait aucune gestion de logs ni SIEM, il était impossible d’attribuer cette attaque à une personne spécifique, donc l’attribution était le meilleur moyen de finaliser l’enquête. L’entreprise aurait pu investir plus de ressources dans la récupération des données, mais l’estimation était encore de 30 jours supplémentaires, ce qui est en tout point une entreprise plutôt coûteuse, donc nous n’avons pas vraiment conseillé cela. Le client était-il satisfait du résultat considérant qu’en fait nous n’avons rien trouvé ? Oui, ils ont obtenu les résultats de l’enquête officielle utilisable au tribunal. Bien que IMHO, c’est une raison très coûteuse de vérifier si un système SIEM est nécessaire dans l’entreprise.

Il y a aussi un petit exemple de l’histoire réussie du ROI du SIEM dans l’enquête sur l’attaque APT en 2015-2016, lorsque nous avons agi en tant que consultants dans l’enquête sur les incidents qui semblaient faire partie de l’attaque BlackEnergy APT. L’entreprise cible APT menait une implémentation PoC de SIEM (dans ce cas, c’était arcsight) qui a essentiellement aidé à trouver les codes de log d’événements Microsoft qui ont montré la séquence de l’installation de nouveaux services et nous avons découvert comment les pilotes malveillants ont été injectés dans le système. Étant donné que tous les journaux d’audit ont été supprimés sur les systèmes attaqués (BlackEnergy et KillDisk), le SIEM fonctionnait sur Unix et dans le segment isolé, donc BlackEnergy ne l’a pas atteint (KillDisk pour Unix n’existait pas / n’existe pas). Ainsi, dans ce cas, le SIEM a aidé à préserver les traces de l’attaque et était le premier indice pour commencer l’enquête médico-légale complète.

Mesurer le ROI du SOC

Le moteur le plus courant pour l’implémentation du SIEM est de construire un centre de surveillance proactive des incidents de sécurité afin de les identifier en temps voulu et de réduire préventivement les risques. Cependant, construire un SOC est une raison courante d’acheter un SIEM. La tâche principale du système SIEM dans un SOC est de réaliser toutes sortes de corrélations d’événements et de trouver ce qu’un humain ne peut physiquement pas faire en raison du volume de données à analyser. De nos jours, les SIEM sont capables de traiter des milliards d’événements par jour, des centaines de milliers ou même plus d’un million d’EPS et de fournir des informations sous une forme appropriée pour une analyse rapide et avec tous les outils d’enquête nécessaires. Répondre à ces exigences réunit la Conformité, le Forensics et le Référentiel central de logs autour du SOC et les élève à un tout nouveau niveau.

Déterminer le ROI du SOC est un grand sujet, mais dans ses bases, il est nécessaire de surveiller et de compter tous les incidents détectés et de modéliser les dommages évités à un stade précoce. Il est nécessaire de construire et de maintenir en permanence un modèle d’actifs et de réseau de l’entreprise, le coût et la valeur des actifs informatiques, les risques applicables, idéalement de construire également un modèle CVSS. Sur la base des coûts des incidents sur ces actifs, il sera possible de déterminer les dommages potentiels évités. Le SIEM lui-même permet également d’économiser du temps pour les analystes et aide à trouver ces heures supplémentaires nécessaires à d’autres tâches de sécurité telles que répondre aux demandes d’audit et de gestion des risques, effectuer des analyses de causes profondes et des enquêtes.

Les cas d’utilisation du SIEM constituent un héritage précieux

Le dernier cas que nous voyons souvent est une situation où quelqu’un hérite du SIEM. Personne ne sait pourquoi le système a été acquis en premier lieu car les employés initiaux sont partis, de nouveaux sont arrivés et cette situation s’étend à tous les niveaux, des managers haut placés aux spécialistes de terrain. Imaginez : vous arrivez à travailler dans une nouvelle organisation qui possède un SIEM. La direction dit : “Nous avons intégré tous les journaux d’audit et cela a coûté plusieurs milliers/millions de dollars à l’entreprise… Vous pouvez sûrement faire quelque chose avec ça ? Je veux dire, la tâche à accomplir est assez simple, nous avons des documents, la technologie est mature et tout fonctionne presque parfaitement ! Donc, juste quelques ajustements sont nécessaires ici et là et nous obtiendrons une prise de conscience totale de la sécurité et une visibilité réseau. Cela serait très utile !” Un projet SIEM ambitieux ou même un SOC devrait commencer par quelque chose de simple. C’est en fait le ROI dans sa forme la plus pure. Ici, nous devons nous concentrer sur des gains rapides pour montrer que la technologie a été achetée pour une bonne raison. Pour réussir cette tâche, il est préférable de sélectionner des cas d’utilisation qui ont déjà été construits et testés pour les technologies que vous avez dans votre organisation et de sélectionner des solutions ciblées pour des menaces et risques spécifiques qui sont les plus actifs dans la nature, tels que le Ransomware, l’APT, la surveillance Windows, le VPN, la sécurité SSL. Et puis nous aurions besoin de les ajuster rapidement pour correspondre aux moteurs de ROI.

Pourquoi le ROI du SIEM est-il si bon en théorie et pourtant si loin de la réalité ?

Une leçon tirée de la supervision de plus d’une centaine de mises en œuvre : juste parce qu’un système SIEM est mis en place dans une organisation ne signifie pas qu’il collecte toutes les données qui étaient prévues et connectées lors de la phase d’intégration initiale. L’intégration est un processus, appelez-le continu si vous voulez. Et un manque de données = absence de ROI. Et il ne s’agit pas seulement de l’acquisition : comme tout système analytique, le SIEM suit le principe “garbage in = garbage out”. En termes simples, il ne produira pas de bons résultats si les défis liés aux données sont ignorés et dans le cas d’un audit de conformité, les données requises peuvent ne pas être disponibles si la Qualité des Données et l’Acquisition des Données ne sont pas surveillées. Nous savons également que l’infrastructure informatique de toute entreprise n’est pas statique, l’architecture change constamment à mesure que de nouveaux services sont introduits et supprimés, le format et le transport des données de journal changent, les configurations de firmware et OS changent et cela rend le parsing des événements pour garantir la qualité des données un processus qui doit être continuellement affiné. Si la qualité n’est pas contrôlée avec au moins 0.25 ETP pour la tâche, alors l’utilité des données diminuera constamment et au moment d’un audit, disons PCI, l’entreprise pourrait ne pas le réussir. Les problèmes de performance peuvent également conduire à une situation où les rapports échouent au moment où vous en avez besoin et généralement c’est lorsque les auditeurs ou la direction les demandent “pour hier”. C’est particulièrement critique pour SOX.

Le SIEM n’est pas auto-suffisant : qu’il s’agisse d’un logiciel sur site ou d’un SaaS, il nécessite du personnel formé qui fait partie de l’équipe interne ou du service d’externalisation. Le calcul incorrect de l’investissement est assez courant pour les projets SIEM. Les investissements dans la technologie SIEM au cours des 5 premières années devraient représenter jusqu’à 20-30% du budget total du projet. Il est nécessaire d’investir dans l’équipement et l’équipe, notamment dans la formation, la rétention du personnel et l’évolution des opérations. Une autre erreur est de supposer que l’achat d’un SIEM réduira significativement la charge de travail, au contraire, cela apportera en réalité un certain nombre de nouvelles tâches et compétences requises. Vos experts ont simplement l’opportunité de travailler avec de grandes quantités de données de sécurité, les analyser et leur donner un sens pour réduire les risques, ce qui était auparavant impossible. Ainsi, une planification des ressources inappropriée est une autre raison pour laquelle il n’est pas possible d’obtenir un ROI du SIEM.

Enfin, une approche de la mise en œuvre des Cas d’Utilisation pour le SIEM nécessite de comprendre que les cas d’utilisation ne sont pas implémentés comme un événement unique, et leur qualité se dégradera rapidement s’ils ne sont pas continuellement améliorés et ajustés. La solution la plus efficace et en même temps simple ici est d’utiliser des cas d’utilisation déjà disponibles et de ne pas réinventer la roue (cas pour la surveillance Windows, Cisco, antivirus, etc.). Il est nécessaire de concentrer les efforts de l’équipe sur le développement de cas d’utilisation spécifiques pour votre organisation. Pour vérifier que vous construisez les cas d’utilisation requis : si un cas d’utilisation peut être copié dans le SIEM d’une autre entreprise et qu’il y fonctionne avec la même valeur, cela signifie qu’il est universel. Et il y a une forte probabilité qu’il soit déjà disponible sous une forme freemium ou commerciale qui nécessite un minimum de réglage pour produire une valeur de sécurité.

Ainsi, nous pouvons définir 5 processus qui garantissent un ROI positif du SIEM

1. Surveiller et maintenir l’Acquisition des Données et la Qualité des Données
2. Surveiller, maintenir et améliorer continuellement les Cas d’Utilisation SIEM
3. Planification technique appropriée du projet et de l’architecture
4. Planification et ajustement des ETP à l’avance pour éviter la surcharge de l’équipe
5. Un plan clair pour l’investissement dans l’équipe : formation, rétention et développement

Donc, ici nous avons les principaux moyens d’obtenir du ROI à partir du SIEM et certaines raisons pour lesquelles ils ne fonctionnent pas toujours comme prévu. Quelle est votre expérience pour obtenir du ROI à partir d’un SIEM ?