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

Lorsqu’on met en œuvre et opère un dispositif de détection, l’une des métriques nécessaires à la gouvernance cybersécurité est la mesure de sa couverture. Dans le premier article de cette série que vous pouvez retrouver ici, nous avions pu montrer la complexité de l’un des deux indicateurs les plus utilisés : la couverture des actifs de l’organisation.

Place aujourd’hui à la seconde mesure communiquée par de nombreux SOC ou fournisseurs de solution : La couverture d’une bibliothèque de menaces.

On souhaite valider ici que les méthodes de détection permettent de couvrir l’étendue des attaques et étapes d’attaques connues. Et pour cela, des normes de place se sont succédées : les indicateurs de la norme ETSI ISI 001, très en vogue il y a quelques années, la Cyber Kill Chain Lockheed Martin et évidemment MITRE ATT&CK qui est devenu la référence de fait.

Trois biais principaux sont à considérer si on calcule un pourcentage de couverture de ces référentiels :

• Le niveau de granularité n’est pas nécessairement adapté aux risques qu’on souhaite couvrir. À titre d’exemple dans ATT&CK Entreprise, l’étape de persistance sur un poste de travail peut se faire via 13 ou 14 techniques différentes, et plusieurs dizaines de sous-techniques. À l’inverse, le vol d’une session Exchange Online via phishing suivi de la collecte des mails d’un dirigeant sera un scénario reposant sur 2 ou 3. Mais ces 3 techniques ont potentiellement beaucoup plus de poids dans les scénarios redoutés de l’entreprise que la couverture de l’ensemble des moyens de persistance sur un poste. Une couverture ATT&CK ne sera donc pas nécessairement alignée avec une couverture de risques.

• La notion de spectre de détection indique que pour une même technique d’attaque, on peut mettre en œuvre des détections à plusieurs niveaux. Par exemple, un attaquant réalisant du Kerberoasting pourrait être détecté entre autres via des logs AD (demande de tickets de plusieurs comptes depuis la même source dans une fenêtre temporelle réduite), mais aussi via des logs système (arguments de ligne de commande caractéristiques d’outils connus). Un SOC ayant mis en place ces deux alertes ne détecterait cependant pas un attaquant qui utilise un outil non public ou obfusqué et ne teste qu’un compte toutes les deux heures. Couvrir une technique ne veut donc pas dire couvrir l’ensemble des méthodes possibles de mise en œuvre.

• Enfin, cette approche n’incite pas à corréler des signaux faibles : en effet, certaines techniques individuelles peuvent être difficiles à détecter, car noyées dans une masse d’événements légitimes. La clé pour les identifier est alors de rechercher l’enchaînement de techniques qui partageraient un indicateur commun (même actif, même IP externe…). On ne couvrirait donc pas ces deux techniques prises indépendamment mais uniquement un scénario où elles sont enchaînées et corrélables. Peut-on alors considérer qu’on détecte chacune d’elle dans notre calcul de couverture ?

On voit que ces indicateurs élémentaires, pourtant largement utilisés, peuvent cacher de grandes disparités dans leur implémentation, et ne donnent pas nécessairement de visibilité sur la couverture réelle des scénarios de risques identifiés comme prioritaires par l’organisation.

Dans la suite de cette série d’articles, nous évoquerons des pistes pour mesurer autrement cette couverture, au service de la gouvernance des risques. À très vite.