Piloter la couverture de son SOC, un vrai défi - partie 1

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. Que ce soit pour soutenir une feuille de route d’intégration de sources additionnelles, le déploiement d’outils ou le développement de nouvelles logiques de détection, la notion de couverture revient systématiquement. Cet indicateur est aussi une demande légitime du management, compte-tenu des ressources allouées à cette activité dans les budgets cybersécurité.

Dans une série d’articles 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.

Comment font les SOCs aujourd’hui ?

La plupart des SOC utilisent deux métriques : la couverture des actifs et la couverture d’une bibliothèque de menaces. Elles semblent peu contestables sur le papier, mais présentent en réalité d’importantes limites.

Penchons-nous aujourd’hui sur la première : la mesure de couverture d’actifs.

C’est la façon la plus simple de voir les choses. Historiquement, c’était la seule mesure, poussant à incorporer de plus en plus de logs, entraînant, soit des factures trop importantes, soit des outils aux performances très dégradées.

Mais que veut dire “couvrir un actif” ? Est-ce disposer au moins d’un type de traces ou télémétrie issu de cet actif ? Est-ce disposer de toutes les traces répondant à une politique d’audit définie pour chaque type d’actif ? Et dans ce cas, sur quels critères a-t-on défini le curseur de verbosité lorsque cette politique a été rédigée ?

À titre d’exemple, un serveur hébergeant un applicatif web peut être couvert en termes de journaux systèmes, peut disposer d’un EDR remontant des comportements qui seront également identifiées au niveau système, mais peut aussi être couvert au niveau applicatif (logs du service web). En fonction du type de couverture, on détectera plus ou moins d’attaques, et de natures différentes :

• l’exécution de commandes à la suite d’une exécution de code à distance pourrait être révélée par des logs système peu verbeux,
• le déploiement d’un webshell pourrait être identifiée par un EDR,
• l’exfiltration de données par une aspiration de répertoires mal protégés ou une injection SQL ne serait potentiellement identifiables que par des logs des requêtes web.

Par ailleurs, cette métrique doit prendre en compte un aspect organisationnel. Dans des environnements complexes ou décentralisés, le niveau de déploiement de la collecte est différent en fonction des périmètres (plaques géographiques, entités autonomes, plateformes externalisées…). On ajoute donc une dimension supplémentaire à cet indicateur, qu’il vaut mieux ne pas omettre pour éviter les foudres du management lorsqu’il découvre à la suite d’un incident, qu’une filiale correspondait aux fameux 5% non couverts.

La notion de couverture d’actifs est ainsi déjà, à elle seule, un indicateur complexe à manipuler et communiquer.