Piloter la couverture de son SOC, un vrai défi - partie 3
La mesure de la couverture est une des métriques nécessaires à la mise en œuvre et l’opération de toute dispositif de détection. Dans une série d'article ces prochaines semaines, nous allons analyser les limitations des approches les plus suivies, et esquisser des pistes pour mesurer autrement cette couverture, au service de la gouvernance des risques.
Publié le 28/05/2024 par Stefan THIBAULT
SOC Couverture Ingénierie de détection
2 min de lecture
Piloter la couverture de son SOC, un vrai défi - partie 3
Mesurer la couverture de sa détection, comme démontré dans des publications précédentes, ne peut pas se résumer à un taux de couverture d’actifs ou d’un référentiel comme ATT&CK. Ces métriques cachent des disparités trop importantes pour pouvoir s’en servir comme seuls guides des choix d’investissement dans la construction du SOC.
Afin d’esquisser ce qui pourrait être un modèle de pilotage de couverture, construisons tout d’abord un cahier des charges.
De manière générale, le dispositif de détection répond à un double objectif :
Identifier la survenue d’événements redoutés, tels qu’identifiés dans des scénarios stratégiques d’analyse de risque (objectif initial),
Assurer une visibilité permettant soit d’identifier des comportements inattendus (potentiellement non anticipés dans les événements redoutés), soit de disposer d’informations suffisantes pour réaliser des investigations sur l’ensemble des ressources informatiques (objectif dans des environnements plus matures ou plus à même de subir des attaques complexes ou inédites).
Ce second objectif est plus simple à modéliser, puisqu’on peut définir des standards de traçabilité minimale pour chaque composant, et l’imposer de manière systémique.
Pour le premier objectif, cependant, on s’attend à pouvoir mesurer la capacité du dispositif à détecter des comportements ou typologies de comportements sur certains composants ou classes de composants précis. A titre d’exemple, si un scénario redouté comprend une étape de prise de contrôle d’un serveur (n’importe lequel) membre d’un domaine AD, la classe de composants concernée sera celle des serveurs Windows joints au domaine, et les typologies de comportements regrouperont entre autres des actions d’exécution et de contrôle-commande. On a donc des catégories très larges. Si à l’inverse, on vise un scénario dans lequel une des étapes est la modification d’un fichier de paiement sur un partage réseau bien particulier, le seul composant à couvrir sera le service de partage de fichier sur ce serveur, et les comportements seront des accès en écriture. Donc quelque chose de très précis.
Notre modèle doit ainsi pouvoir osciller entre des catégories très larges, et des items unitaires.
Posons-nous ensuite la question du public utilisateur ou destinataire de ce modèle :
Les acteurs en charge du pilotage des risques (RSSI, métiers, équipes GRC…) ont besoin de connaître dans quelle mesure les différents scénarios redoutés sont détectables dans l’environnement, alimentant ainsi la mesure globale des risques résiduels.
Les acteurs en charge du pilotage du SOC ont besoin de prioriser ou choisir les collectes ou les mécanismes de détection à déployer. Cette vision doit donc être à un niveau de précision tactique, pour savoir rapidement quelles zones / filiales / technologies sont encore invisibles, et quelles étapes des scénarios ont moins de probabilité de générer une détection.
On voit donc que le défi réside dans la capacité à gérer des niveaux de granularité différents, tout en restant d’une complexité manipulable pour éviter l’usine à gaz. Nous tenterons dans la suite des articles des approches dont nous testerons les limites.