Le SOC d’un fournisseur fintech exploitait trois plateformes SIEM dans son environnement cloud hybride : Microsoft Sentinel pour les charges de travail Azure, Splunk pour l’infrastructure sur site et une agrégation AWS Security Hub pour les charges de travail cloud natives. Le nombre total de règles sur les trois plateformes dépassait quatre cents règles de corrélation et politiques de détection. L’équipe d’ingénierie de détection se composait de deux analystes seniors qui maintenaient les quatre plateformes en plus de leurs fonctions SOC habituelles. Les quatre cents règles s’étaient accumulées sur six ans : certaines écrites par l’équipe SOC d’origine à la suite de constats d’incidents précis, la majorité héritées des modèles des éditeurs de plateformes et des intégrations de flux de renseignement sur les menaces. Les règles personnalisées propres au paysage de menaces de la fintech (manipulation de transactions, abus API à des fins de fraude financière, bourrage d’identifiants contre les points de terminaison de traitement des paiements) étaient moins de vingt. Les trois cent quatre-vingts autres étaient des règles génériques applicables à n’importe quelle organisation. Lorsqu’un groupe malveillant sophistiqué, motivé par l’appât du gain et ciblant spécifiquement les infrastructures fintech, a commencé à sonder l’environnement du fournisseur, il a utilisé des techniques conçues pour se fondre dans les opérations fintech normales : des schémas d’appels API cohérents avec un traitement légitime de paiements à fort volume, des séquences d’authentification imitant des processus de rapprochement automatisés et des schémas d’accès aux données impossibles à distinguer du traitement par lots standard de fin de journée. Les règles de détection génériques n’ont généré aucune alerte. Les vingt règles propres à la fintech étaient réglées pour d’anciens schémas d’attaque déjà observés par l’équipe. Les techniques de l’acteur malveillant étaient nouvelles.
Que sont réellement les lacunes de l’ingénierie de détection ?
L’ingénierie de détection est la discipline qui consiste à concevoir, construire, tester et maintenir la logique de détection (règles de corrélation, analyses comportementales et politiques de détection d’anomalies) qui permet à un SIEM et à un SOC d’identifier une activité malveillante dans un environnement donné. Les lacunes de l’ingénierie de détection sont les insuffisances de couverture de cette logique : règles non écrites pour certaines techniques d’attaque, règles héritées de modèles génériques sans personnalisation, règles devenues moins pertinentes à mesure que l’environnement et le paysage des menaces ont évolué, et règles jamais testées pour confirmer qu’elles se déclenchent toujours comme prévu.
Le problème de l’héritage des règles par défaut de la plateforme est la lacune d’ingénierie de détection la plus répandue. Les plateformes SIEM sont livrées avec des ensembles de règles par défaut : des centaines de règles de corrélation et de politiques de détection issues du renseignement général sur les menaces et des schémas d’attaque courants. Ces règles par défaut offrent une couverture de détection immédiate dès l’installation et sont utiles pour repérer les menaces courantes. Elles ne sont pas conçues pour les schémas d’attaque propres à un secteur, à une pile technologique ou à un profil d’acteur malveillant particulier. Les organisations qui s’appuient principalement sur les règles héritées par défaut sans développer de logique de détection propre à leur secteur et à leur environnement disposent d’une couverture de détection calibrée pour le paysage de menaces moyen plutôt que pour leur paysage de menaces réel.
Le problème de la dégradation des règles aggrave la lacune liée à l’héritage des règles par défaut. La pertinence des règles de détection se dégrade avec le temps, à mesure que l’environnement change, que les techniques d’attaque évoluent et que les ajustements destinés à réduire les faux positifs restreignent involontairement le champ de détection de la règle. Une règle écrite il y a cinq ans pour détecter un schéma d’attaque précis peut avoir été progressivement restreinte par ajustements jusqu’à ne se déclencher que dans des circonstances correspondant exactement à l’incident d’origine qui l’a motivée, manquant ainsi le schéma plus large qu’elle devait repérer. Les programmes d’ingénierie de détection qui revoient et mettent à jour régulièrement leurs règles maintiennent la pertinence de la détection. Ceux qui ajoutent surtout de nouvelles règles sans retirer ni actualiser les anciennes accumulent une dette de détection.
- Règles par défaut de la plateforme sans personnalisation sectorielle : couverture générique pour un paysage de menaces moyen
- Équipe d’ingénierie de détection de deux personnes maintenant quatre cents règles sur plusieurs plateformes
- Dégradation des règles : les ajustements réduisent le champ de détection avec le temps
- Techniques sectorielles non couvertes : l’acteur malveillant utilise des méthodes propres au secteur
- Aucune fréquence de test des règles : règles non vérifiées pour confirmer qu’elles se déclenchent toujours comme prévu
Pourquoi c’est important
Les lacunes de l’ingénierie de détection comptent pour la TPRM parce que la capacité de détection du SOC ne vaut que par les règles qui ont été construites et maintenues. Un fournisseur doté d’une plateforme SIEM mature et d’un déploiement complet des règles par défaut dispose de l’infrastructure nécessaire à une détection efficace. L’efficacité réelle de cette infrastructure face aux menaces spécifiques pertinentes pour les données du client dépend de la capacité du programme d’ingénierie de détection à construire et maintenir des règles pour ces menaces précises. La maturité de la plateforme et la maturité de l’ingénierie de détection sont deux dimensions différentes d’une même capacité SOC.
La dimension de la chaîne d’approvisionnement est particulièrement pertinente pour les menaces propres à un secteur. Les clients fintech qui partagent des données avec des fournisseurs fintech font face au même paysage de menaces sectoriel. Les clients du secteur de la santé qui s’appuient sur des fournisseurs de technologies de santé sont exposés aux mêmes acteurs malveillants qui ciblent les données de santé. Un fournisseur dont le programme d’ingénierie de détection couvre des schémas d’attaque génériques mais manque de logique de détection sectorielle est un fournisseur dont le SOC manquera les techniques spécifiques employées par les acteurs malveillants les plus susceptibles de cibler les données du client à travers la relation fournisseur.
Là où la plupart des équipes se trompent
L’échec le plus constant consiste à accepter le nombre de règles comme indicateur de la qualité de l’ingénierie de détection. Le nombre de règles mesure le volume. La qualité de l’ingénierie de détection mesure la pertinence, la maintenance et la fréquence des tests.
- Nombre de règles accepté comme indicateur de couverture
- Dépendance aux règles par défaut de la plateforme non évaluée : ratio entre règles personnalisées et règles héritées non demandé
- Capacité de l’équipe d’ingénierie de détection non évaluée au regard de la charge de maintenance des règles
- Couverture des règles sectorielles non vérifiée
- Fréquence des tests de règles non demandée : date de la dernière validation des règles
À quoi ressemblent les bonnes pratiques
Les programmes matures d’ingénierie de détection tiennent un inventaire des règles qui distingue les règles par défaut de la plateforme des règles personnalisées, testent régulièrement les règles pour confirmer qu’elles se déclenchent comme prévu et donnent la priorité à la construction et à la maintenance de règles pour les acteurs malveillants et les techniques les plus pertinents pour le secteur et le profil de menaces de l’organisation.
- Ratio de règles personnalisées : quelle proportion de règles est propre à l’environnement plutôt qu’héritée des valeurs par défaut
- Détection sectorielle : règles écrites pour les techniques d’attaque propres au secteur
- Tests réguliers des règles : règles validées pour se déclencher sur les schémas d’attaque pertinents
- Gestion de la dette de détection : règles obsolètes retirées, règles dégradées actualisées
- Feuille de route de l’ingénierie de détection : lacunes connues et calendrier d’amélioration de la couverture
Outils
Plateformes SIEM : Microsoft Sentinel, Splunk, Elastic SIEM avec développement de règles personnalisées
Les plateformes SIEM fournissent l’infrastructure nécessaire au développement de règles de détection personnalisées. Pour les praticiens TPRM, demander quelle proportion des règles du fournisseur est écrite sur mesure plutôt que fournie par défaut par la plateforme donne l’indicateur d’engagement en ingénierie de détection que le nombre total de règles ne fournit pas.
Renseignement sur les menaces : MITRE ATT&CK, ISAC sectoriels
Le renseignement sur les menaces sectoriel provenant des ISAC et les correspondances de techniques ATT&CK pour les groupes malveillants connus fournissent la matière première de règles d’ingénierie de détection calibrées pour le paysage de menaces spécifique. Pour les praticiens TPRM, demander si les règles de détection du fournisseur sont associées aux techniques ATT&CK les plus liées aux acteurs malveillants de son secteur constitue une question précise sur leur pertinence.
Enjeux de gouvernance
Le défi de gouvernance de l’ingénierie de détection est la capacité. Construire et maintenir des règles de détection sectorielles, testées et de haute qualité exige un temps d’analyste considérable, en concurrence avec les opérations SOC quotidiennes. La réponse de gouvernance consiste à consacrer une capacité spécifique à l’ingénierie de détection, en séparant le travail de développement de la détection du travail de tri des alertes, et à utiliser le SOAR et les tests automatisés pour réduire la charge de maintenance continue.
- Demander le ratio entre règles personnalisées et règles par défaut : quelle proportion est propre à l’environnement
- Demander le nombre de règles propres au secteur : combien de règles portent sur des techniques spécifiques au secteur
- Demander la fréquence des tests de règles : à quel rythme les règles sont validées
- Demander la dernière revue de couverture ATT&CK pour les acteurs malveillants pertinents pour le secteur
- Demander la capacité dédiée de l’équipe d’ingénierie de détection
Si vous êtes une petite équipe
Posez trois questions d’ingénierie de détection à votre fournisseur le plus à risque. Premièrement : quel pourcentage de vos règles de détection est écrit sur mesure pour votre environnement plutôt qu’hérité des valeurs par défaut de la plateforme ? Deuxièmement : disposez-vous de règles de détection écrites spécifiquement pour les techniques d’attaque employées par les acteurs malveillants connus pour cibler votre secteur ? Troisièmement : quand vos règles de détection ont-elles été testées pour la dernière fois afin de confirmer qu’elles se déclenchent sur les schémas qu’elles doivent détecter ? Ces trois questions révèlent si les quatre cents règles sont personnalisées et testées ou héritées et non vérifiées.
- Demander le ratio entre règles personnalisées et règles par défaut
- Demander la couverture des techniques d’attaque propres au secteur
- Demander quand les règles ont été testées pour la dernière fois afin de confirmer qu’elles se déclenchent
- Demander la couverture ATT&CK pour les groupes malveillants pertinents pour le secteur
Ce qu’il faut exiger
Demandez directement :
« Quel pourcentage de vos règles de détection SIEM est écrit sur mesure pour votre environnement plutôt qu’hérité des valeurs par défaut de la plateforme, et disposez-vous de règles spécifiques aux techniques d’attaque employées par les groupes malveillants connus pour cibler votre secteur ? »
Preuves attendues
- Ratio entre règles personnalisées et règles par défaut
- Nombre de règles sectorielles et couverture des techniques
- Fréquence des tests de règles et date du dernier test
- Cartographie de couverture ATT&CK pour les acteurs malveillants du secteur
Il faut demander à un fournisseur qui dispose de quatre cents règles de détection combien d’entre elles sont développées sur mesure pour son paysage de menaces spécifique. Quatre cents règles par défaut et quatre cents règles personnalisées représentent des investissements en ingénierie de détection très différents.
Comment le prouver
- Documentation du ratio de règles personnalisées
- Registres de couverture de la détection sectorielle
- Registres de la fréquence des tests de règles
- Évaluation de la couverture ATT&CK
À retenir
Quatre cents règles. Trois cent quatre-vingts règles par défaut de la plateforme. Vingt règles personnalisées pour d’anciens schémas propres au secteur. L’acteur malveillant ciblant la fintech a utilisé des techniques actuelles propres à la fintech. Aucune alerte. L’infrastructure SIEM était mature. Le programme d’ingénierie de détection n’avait pas construit les règles permettant de l’utiliser contre cette menace précise. Le nombre de règles décrit l’investissement dans l’infrastructure de détection. Le ratio de règles personnalisées et la couverture des techniques sectorielles décrivent si cette infrastructure a été conçue pour détecter les menaces réelles. Les règles par défaut couvrent la moyenne. Les règles personnalisées couvrent le spécifique. C’est le spécifique qui compte.