Conçu pour la vitesse, coincé au point mort : pourquoi certains déploiements de Splunk ES calent

Splunk Enterprise Security (ES) est un moteur haute performance conçu pour traiter des volumes considérables de données et en extraire rapidement des informations haute fidélité.

Pourtant, en tant que Responsable de compte technique (TAM) spécialiste de la sécurité, j’observe régulièrement des environnements dans lesquels cette performance ne se concrétise pas. La plateforme est déployée, les détections sont activées, les tableaux de bord fonctionnent, mais les résultats ne sont pas au rendez-vous.

La technologie est rarement en cause. Il s’agit le plus souvent de problèmes de configuration, de déploiement et de mesure.

L’excellence opérationnelle de Splunk ES ne dépend pas du nombre de détections actives. Elle est le fruit d’un alignement étroit entre l’ingénierie de détection et le risque métier, adossé à un socle de données robuste et évalué selon des objectifs stratégiques.

Des échanges avec des clients nous ont permis de dégager les cinq écueils courants qui font stagner les déploiements Splunk ES, ainsi que des pistes pour y remédier.

1. Une mauvaise compréhension de l’importance de la conformité CIM

Les équipes considèrent souvent la conformité au Modèle d’information commun (CIM) comme un avantage plus qu’une nécessité, et tendent à la négliger pour mettre rapidement le contenu en production. Sur le moment, elles ont le sentiment de progresser. En réalité, des problèmes émergent presque toujours en aval.

Splunk ES repose sur le CIM. Les détections prédéfinies, les tableaux de bord et le framework de threat intelligence consomment tous des données conformes au CIM. Surtout, le CIM est indispensable à l’accélération des modèles de données, qui améliore considérablement la performance et l’évolutivité de la solution.

Si l’on néglige cette étape pour les données utiles à la sécurité, les recherches ralentissent et le framework de threat intelligence perd son intérêt. Ces problèmes ne se manifestent pas immédiatement. Ils apparaissent plutôt lorsque les volumes de données augmentent ou que le contenu de détection prend de l’ampleur. À ce stade, une refonte de l’approche coûterait cher et perturberait gravement les opérations. Mais en mettant les bonnes fondations en place dès le début, elle devient parfaitement inutile.

On croit souvent que toutes les données de Splunk doivent être conformes au CIM pour qu’ES soit efficace. En réalité, des données qui sont rarement interrogées ou produites dans des formats très irréguliers peuvent encore apporter de la valeur sans être conformes au CIM. Certains scénarios d’utilisation exploitent également des données qui n’existent pas dans le CIM.

En soignant les fondations en amont, tout ce qui sera bâti dessus sera plus rapide, plus fiable et plus facile à faire évoluer.

2. Absence de stratégie de détection

Je vois souvent les équipes activer des détections sans stratégie claire pour déterminer lesquelles sont réellement pertinentes dans leur environnement.

Sans stratégie de détection, les entreprises sont incapables de répondre à des questions pourtant simples : quelles détections prédéfinies faut-il activer ? Lesquelles faut-il développer ? Lesquelles peuvent être retirées sans danger ?

En l’absence de plan structuré, les équipes optent pour la facilité et commencent par les données qu’elles importent déjà. Elles activent une grande quantité de contenu prêt à l’emploi ou parcourent sans but les techniques MITRE ATT&CK en quête de lacunes dans la couverture. Résultat : une bibliothèque de détections impressionnante, mais difficile à maintenir et à faire évoluer, et surtout incapable de produire une valeur réelle sur le plan de la sécurité.

Les programmes de détection matures abordent la question dans l’autre sens : les listes de détection sont déterminées par les preuves. Incidents confirmés, conclusions des tests d’intrusion et des exercices purple team, quasi-accidents, changements environnementaux et threat intelligence correspondant à des comportements observables : voilà ce qui détermine les objets à détecter, avant de décider de la méthode à employer.

Une stratégie doit également avoir le bon niveau de spécificité. Des objectifs de haut niveau comme « détecter un ransomware » décrivent des résultats, pas des comportements. Si les objectifs ne sont pas décomposés en comportements spécifiques et observables, les détections deviennent ambiguës et difficiles à évaluer, à ajuster ou à retirer. Avec le temps, cette absence d’ancrage comportemental fragilise le contenu et accroît la dette de détection.

Le manque de fonctionnalités ou de contenu n’est pas en cause. Le problème vient réellement d’une absence de stratégie claire en matière de détection.

3. Une mauvaise compréhension des alertes basées sur le risque

Les alertes basées sur les risques (RBA) représentent l’un des outils les plus puissants de Splunk ES, mais aussi l’un des plus mal compris.

On pense souvent que la RBA élimine les besoins d’ajustement. Ce n’est pas le cas. Si une détection produit des faux positifs, il faut la corriger, qu’elle génère un signal de risque ou une alerte.

Ce qui distingue véritablement la RBA, c’est qu’elle découple la détection des alertes :

• Les détections génèrent des signaux qui traduisent l’apparition d’un comportement.
• Les signaux des différentes entités s’accumulent dans le temps et augmentent le risque.
• Les alertes ne sont créées que lorsque le risque agrégé justifie une intervention des analystes.

Dans les SOC traditionnels, les détections sont conçues pour produire directement des alertes. Elles doivent donc être rares, extrêmement fiables et immédiatement exploitables. Au fil du temps, cette pression conduit à des ajustements excessifs qui laissent des angles morts dans la couverture.

Pour la plupart, les comportements adverses sont trop subtils pour être détectés par une seule alerte directe. C’est pour cela que la RBA s’appuie sur des scores et des métadonnées pour donner du sens à des observations basse fidélité. Avec la RBA, les attaques se manifestent par une accumulation du risque, et non par des détections individuelles.

Les alertes isolées ont encore un rôle à jouer : elles détectent les activités intrinsèquement malveillantes ou extrêmement rares, comme le déversement d’identifiants ou le sabotage direct de contrôles de sécurité. Pour tout le reste ou presque, la conception axée sur la RBA est plus indiquée.

4. Mesurer l’activité plutôt que les résultats

Un autre écueil courant consiste à évaluer la performance d’une pratique avec les mauvaises métriques.

Le volume d’alertes, le nombre de détections activées et les pourcentages de couverture MITRE ATT&CK sont faciles à suivre, mais ces indicateurs ne donnent pas une image claire de l’efficacité des détections.

MITRE ATT&CK est un framework de threat intelligence, pas un modèle opérationnel pour le SOC. On ne détecte pas « T1135 ». On détecte les comportements spécifiques qui peuvent trahir sa présence, comme des requêtes LDAP inhabituelles. Une matrice de couverture colorée n’est pas non plus une position de sécurité. C’est un moyen de se rassurer.

Pour être efficaces, les mesures doivent cibler les résultats à plusieurs niveaux :

• Niveau du signal : est-ce que les détections sont fiables et précises ? Est-ce qu’elles fonctionnent comme prévu ?
• Niveau des alertes et des incidents : qu’est-ce qui nous a échappé ? Qu’ont révélé les exercices purple team et les bilans post-incidents ?
• Cohérence opérationnelle : est-ce que les analystes appliquent systématiquement les dispositions, en faisant des distinctions claires entre les faux positifs et les vrais positifs bénins ?

Sans définitions communes ni processus cohérents, les métriques les mieux intentionnées peuvent induire en erreur et saper la confiance dans la plateforme.

5. Négliger la télémétrie des endpoints

Parmi toutes les lacunes que je vois dans les déploiements ES, le manque de télémétrie des endpoints est certainement le plus grave et le plus sous-estimé.

Les solutions EDR détectent très bien les malveillances sur les endpoints. Mais la valeur de Splunk réside dans la corrélation des comportements à l’échelle de l’entreprise. Si vous n’importez pas la télémétrie dans Splunk, votre visibilité sur le comportement des endpoints se limite à ce que votre solution EDR choisit de mettre en avant. En acquérant les données de télémétrie, vous reprenez le contrôle.

L’importation de la télémétrie des endpoints dans Splunk permet de corréler les informations de tous les domaines : identités, e-mail, cloud et réseau. Grâce à cette approche, la logique de détection peut s’exercer indépendamment des alertes propriétaires, la télémétrie est conservée plus longtemps et elle s’intègre étroitement avec les alertes basées sur les risques. Les équipes qui privilégient le SPL dans le threat hunting peuvent accéder aux données des endpoints au même endroit que les autres.

Il ne s’agit pas de reproduire ce que fait déjà la solution EDR ni de transmettre à Splunk toutes les données brutes sans discrimination. L’objectif est celui d’une défense en profondeur.

Maximiser le potentiel d’ES

Splunk Enterprise Security est une plateforme puissante, mais la puissance ne suffit pas à donner des résultats.

Pour réussir, il ne faut pas se contenter d’activer des fonctionnalités. Les entreprises qui réussissent donnent la priorité aux scénarios d’utilisation axés sur le risque, s’appuient sur un socle de données robuste, axent la conception des détections sur la RBA, basent leurs mesures sur les résultats et exploitent une télémétrie complète.

Lorsque toutes ces conditions sont réunies, Splunk ES cesse d’être un simple outil de détection pour devenir une véritable plateforme d’opérations de sécurité, et les équipes commencent à observer les résultats promis par la technologie.

Appel à l’action

Ces problèmes ont une solution. Le Guide essentiel des alertes basées sur les risques de Splunk offre un excellent point de départ aux équipes qui s’intéressent à la RBA. Si l’un de ces écueils vous parle, prenez contact avec votre équipe de compte pour découvrir comment un TAM spécialiste de la sécurité peut vous aider.