Le but de cet article est de démontrer que l’excellente matrice ATT&CK devrait plutôt être utilisée comme support et non comme point central d’une stratégie de supervision SSI. En effet, il est parfois supposé que ATT&CK peut suffire à piloter un SOC, et nous allons nous attacher ici à montrer que ce référentiel ne saurait être utilisé, seul afin d’assurer un pilotage du SOC, qui soit à la fois pragmatique et aligné avec les enjeux sécurité.
La base de connaissance MITRE ATT&CK[1] apparaît aujourd’hui de plus en plus comme un référentiel prépondérant dans le monde de la cyber-sécurité, que ce soit pour des équipes SOC, CERT, CTI, ou T.I. (Test d’Intrusion). On le retrouve notamment, de manière cohérente, utilisé dans les publications spécialisées autour de la menace cyber, telles que celles de FireEye[2], Microsoft[3], ou même la « Threat Landscape » de la CTI Intrinsec[4].
Ce référentiel apporte entre autres l’avantage de permettre à ces différents métiers de la cyber de parler le même langage, autour d’un même référentiel qui énumère et décrit des modes opératoires offensifs, aussi appelés TTP (TTP signifiant « Tactics, technics, and Procedures »[5]), qui évolue même, sous impulsion de la NSA, dans un corolaire de défense (« D3fend »[6]).
Ainsi, par exemple lors d’un entraînement SOC (aussi appelé « purple teaming »), l’équipe côté offensif s’attend normalement à recevoir une liste de TTP qui sont censés être détectables par le SOC. A la fin de l’entrainement, donc du « purple teaming », les deux équipes SOC (« blue team ») et offensive (« red team ») peuvent confirmer, TTP par TTP, ce qui a été détecté et ce qui ne l’a pas été. Ceci permet au SOC de s’améliorer dans le temps, en exploitant le RETEX des non-détections, mais aussi de vérifier la présence de traçabilité avant la détection (et donc la profondeur de couverture de la supervision).
En outre, ce référentiel permet également de formaliser les procédés des attaquants qui sont (le plus) observés, et ainsi définir des tendances, permettant d’orienter les efforts des équipes de sécurité de SOC voire CSIRT. En fait, MITRE ATT&CK est probablement déjà devenu le standard industriel dans le monde de la cyber, pour ce qui est de la documentation des procédés offensifs, côté éditeurs comme sociétés de service.
Cependant, à date, la matrice ATT&CK comporte 14 tactiques, mais surtout 185 techniques et 367 sous-techniques, autant dire que le référentiel est riche, en plus d’évoluer dans le temps ! La couverture à 100% d’un tel référentiel par un SOC semble irréaliste, et surtout, peu pertinente dans le contexte client. La question qui se pose donc, d’un point de vue pragmatique, est : où est-ce que l’effort doit être mis en ce qui concerne l’amélioration des capacités de détection du SOC ? Plus précisément, comment choisir quelles techniques, quelles sous-techniques, et même quelles tactiques doivent faire l’objet d’une supervision SSI, à court, moyen, et long terme ?
En effet, prenons un exemple concret : l’usage de scripts est l’un des TTP les plus courants en ce moment, et correspondant à la tactique « Execution » dans ATT&CK. Ce TTP est notamment souvent utilisé par divers groupes d’attaquants qui se livrent à de l’extorsion d’argent, via rançongiciel[7] (et éventuellement exfiltration d’informations au préalable, avec chantage à la diffusion). Ceci peut représenter un enjeu de sécurité majeur pour une organisation, ou société, donnée.
Mais, si en fait, cette même entité considère que le hameçonnage est également un enjeu de sécurité majeur, alors les TTP de la technique « Command and Scripting Interpreter »[8], référencée T1059, ne seront pas forcément les plus pertinents en termes de détection. A l’inverse, les TTP de la technique « phishing »[9], référencée T1566, semblent bien plus adéquats.
Oui, mais… le vrai problème est que les capteurs[10] nécessaires pour la détection de la T1566 sont assez différents de ceux pour la T1059. Plus précisément, pour la partie « Command and Scripting Interpreter » (T1059), le référentiel ATT&CK liste comme capteurs :
- Command Execution,
- Module Load,
- Process Creation,
- Script Execution
Alors que, pour la partie « phishing » (T1566), là, le référentiel nous indique comme capteurs :
- Application Log Content,
- Network Traffic Content,
- Network Traffic Flow
Nous constatons évidemment que les deux listes n’ont pas de point commun. Les travaux nécessaires à disposer des capacités de détection efficaces pour le SOC, de définition des politiques de journalisation, stratégies de collecte, l’intégration des données dans le SIEM, et la conception des stratégies de détection, en seront donc lourdement impactés. La question fondamentale qui apparaît alors est : comment définir la priorisation des actions du SOC, ainsi que les éventuels moyens à acquérir et/ou déployer (appelés ici capteurs) afin d’atteindre la capacité de détection souhaitée ?
Comme très souvent en cyber-sécurité, il sera question ici de trois bases : la technologie (donc certainement des moyens financiers pour l’acquisition de solutions de sécurité, et le MCO), les personnes (donc certainement des moyens RH à faire valider et concrétiser par des recrutements), et les processus opérationnels (voire organisationnels) pour définir le fonctionnement global ainsi que l’exploitation des technologies de sécurité. Le pilotage global ne peut donc s’improviser, il doit être cadré.
Par conséquent, si le besoin en sécurité est formalisé à travers des événements redoutés de type (pour exemple) : « sollicitation par email d’un utilisateur du S.I., afin de l’amener à réaliser des actions frauduleuses sur le S.I. applicatif (impacts intégrité et confidentialité) », alors le pilotage des efforts à réaliser par le SOC peut être bien plus efficace. D’aucuns auront reconnu ici un scénario proche de « l’arnaque au Président »[11], et clairement, le TTP « phishing » semble plus pertinent, donc les efforts pour assurer la détection seront certainement mis sur les journaux de la messagerie (couches MTA et MDA de la messagerie) incluant l’antispam, ainsi que sur les journaux applicatifs.
Et c’est là certainement que la base ATT&CK montre ses limites, si elle devait être utilisée en tant que référentiel et canevas uniques pour piloter un SOC. En effet, il n’y a pas de formalisation du besoin en sécurité, dans la base ATT&CK, ni même son navigateur[12].
Mais surtout, il n’y a pas non plus dans ce référentiel de vraie formalisation de la notion de risque cyber, si ce n’est que l’on peut très certainement considérer les TTP de la base ATT&CK comme des scénarios opérationnels pouvant aboutir à des événements redoutés [FL3] (dans une logique EBIOS RM[13]). C’est cette approche que le SOC Intrinsec a implémentée depuis plus d’un an, et le RETEX en est très positif.
Conclusion
La base ATT&CK en elle-même ne peut donc être utilisée comme seul référentiel pour formaliser le besoin en sécurité, ni définir réellement les priorités pour le SOC, car elle n’embarque pas, à date, de notion de pilotage SOC. Tout au plus, nous pourrons aboutir à la mise sous forme graphique d’un état des lieux au meilleur des cas, avec le « Security Stack Mappings »[14] par exemple.
Elle peut par contre servir de référentiel incontournable pour les modes opératoires offensifs que le SOC doit détecter, une fois qu’ils auront été validés dans le contexte de l’analyse de risques servant à définir les besoins SOC, et associés aux risques eux-mêmes qui auront été formalisés par l’analyse de risque sécurité.
Dit autrement, ATT&CK peut être utilisée comme une déclinaison technique ou opérationnelle des risques formalisés en bon français dans l’analyse de risques. Et à ce sujet, le SOC Intrinsec recommande de s’inspirer d’EBIOS RM en termes de méthodologie.
Chers EBIOS Risk Managers, le SOC est à votre écoute pour s’améliorer et définir ses priorités !
[1] Cf. https://attack.mitre.org/
[2] Cf. https://www.fireeye.fr/current-threats/annual-threat-report/mtrends.html
[3] Cf. https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/
[4] Cf. https://mailchi.mp/16e75cab7389/threat-landscape-by-intrinsec-5005930
[5] Cf. https://www.mitre.org/publications/technical-papers/ttp-based-hunting
[6] Cf. https://d3fend.mitre.org/about
[7] Cf. https://www.ssi.gouv.fr/administration/glossaire/r/
[8] Cf. https://attack.mitre.org/techniques/T1059/
[9] Cf. https://attack.mitre.org/techniques/T1566/
[10] Capteurs correspondant peu ou prou à « data sources » dans le référentiel ATT&CK, dont la définition a évolué en octobre 2021, cf. https://medium.com/mitre-attack/introducing-attack-v10-7743870b37e3
[11] Cf. https://www.economie.gouv.fr/dgccrf/larnaque-au-president-toujours-tres-frequente
[12] Cf. https://mitre-attack.github.io/attack-navigator/
[13] Cf. https://club-ebios.org/site/tag/ebios-risk-manager/
[14] CF. https://github.com/center-for-threat-informed-defense/security-stack-mappings
