La cybersécurité, désormais bien (mieux) installée dans le paysage institutionnel de nos sociétés développées, n’échappe pas au morcellement de la pensée et des pratiques qui est le devenir de tout domaine un tant soit peu dynamique. À ce titre, quelque néophyte qui tenterait de comprendre le quotidien d’une équipe de cybersécurité relativement pluridisciplinaire serait très vite abasourdi devant la masse de termes obscurs, expressions anglicisantes et autres néologismes qui peuplent nos journées. Si on ajoute à cela l’incroyable fertilité de la pensée marketing, jamais avare de nouveaux concepts (pseudo-)révolutionnaires, il y a de quoi frôler l’overdose sémantique.
Nul doute qu’en tant que lecteur attentif de MISC, les mots-clés ci-dessus n’ont aucun secret pour vous. Pourtant, accaparé comme on peut l’être par nos tâches quotidiennes, il peut arriver que l’on perde de vue le fait que certaines d’entre elles prendraient plus de valeur dès lors que l’on cesserait d’accorder de l’attention aux risibles petites frontières entre activités techniques que d’obscurs garde-chiourmes ont érigé un jour, par ennui.
Sans aucune prétention à l’exhaustivité, cet article se propose de constituer un très modeste vadémécum d’exemples de synergies entre activités de cybersécurité. Le spécialiste averti pas plus que le RSSI chevronné ne seront surpris des exemples qui vont suivre ; toutefois, peut-être cet article donnera-t-il des idées à certains… idées que je serais ravi de recevoir, donc n’hésitez pas à me les envoyer pour que nous en discutions !
Une fois n’est pas coutume [1, 2], m’étant plus souvent fait le critique acéré (mais non acerbe !) de nombre de référentiels, cet article va en utiliser un ; en l’occurrence les différents « profiles » définis par le NIST dans son approche de la cybersécurité [3], afin de proposer un début de classement des synergies selon le moment où celle-ci peut avoir un intérêt.
À des fins de praticité, imaginons que, pour tous les exemples qui vont suivre, nous sommes en présence d’une équipe cybersécurité, au sein d’une société de taille conséquente, active dans le secteur de la finance. L’équipe en question est fournie et hautement pluridisciplinaire : auditeurs, analystes SOC et investigateur numérique, chef de projet, développeur, et même, soyons fous, deux managers compétents. Le SI à protéger est équipé des technologies essentielles dans un environnement sectoriel exigeant : un EDR, un AD, un proxy, un firewall, un CASB, des sondes, etc. Enfin, la société dispose d’un service de SOC interne, exploitant un SIEM ainsi qu’une TIP qui lui sert à capitaliser Indicators of Compromise et Techniques, Tactiques et Procédures (IOC et TTP[4]).
1. IDENTIFY – Analyse de risques cyber & Red Team
Comme toute société un peu éclairée en cybersécurité, la nôtre réalise une analyse de risques cyber de type EBIOS RM [5], tous les ans et demi. À ce titre, elle dispose d’une liste conséquente de scénarios opérationnels offensifs contre lesquels elle cherche à se protéger, et qui lui servent à la définition puis à l'implémentation de mesures de sécurité permettant d’adresser les risques de concrétisation de ces scénarios.
De même, notre société fait pratiquer, tous les deux ans, un audit de type « Red Team » ; ses deux auditeurs déroulent alors un scénario d’attaque de leur choix, assez convenu et très rapidement défini, et les conclusions de l’audit alimentent le plan global d’amélioration continue que suit l’équipe.
Synergie possible : enrichir les scénarios produits lors de l’analyse de risques de leur traduction au format Mitre ATT&CK, quelques Techniques par Tactics ; par exemple, si un scénario « Attaque de la société par un ransomware » est défini, en imaginant ou anticipant les Techniques ATT&CK qui pourraient être utilisées s’il se concrétisait, phase après phase, il devient possible, par la suite, de demander aux auditeurs non pas de choisir eux-mêmes un scénario offensif quelconque, mais de sélectionner le scénario « Attaque de la société par un ransomware », et de le dérouler. Cela permet d’éprouver la réalité des mesures de sécurité prises, d’identifier de potentiels « trous dans la raquette », le tout en conditions quasi réelles, une Red Team imitant au maximum une cyberattaque réelle.
2. PROTECT – Red Team & CTI
Imaginons maintenant que notre société, non seulement pratique régulièrement un audit de type Red Team, mais dispose également de capacités de capitalisation de connaissances sur la menace cyber. En effet, elle dispose d’une instance d’OpenCTI [6], au sein de laquelle elle entre les informations qu’elle collecte, de la part de diverses sources, sur les groupes d’attaquants susceptibles de la cibler. À ce titre, par exemple, elle suit tout particulièrement FIN7 [7] ; ce groupe, actif depuis 2013, cible une grande variété de secteurs, y compris celui de la finance, afin de compromettre des structures pour y déployer un ransomware.
Synergie possible : cette fois, au lieu de demander à sa Red Team de se baser sur les scénarios d’une analyse de risques, notre société peut faire en sorte que les Techniques retenues s’inspirent, voire imitent au maximum ceux de FIN7. Il est compliqué d’imaginer qu’il sera faisable (ou même utile) de copier très précisément l’attaquant, tant au niveau de son infrastructure ou des malwares utilisés ; toutefois, dès lors que l’on sait que FIN7 apprécie la pratique du spearphishing comme Technique d’Initial Access, qu’ensuite il affectionne l’utilisation de PowerShell et la création de clés de registre pour assurer sa persistance, dérouler ce genre de comportement lors de la Red Team permettra, a minima, de se rassurer (ou, au contraire, de s’inquiéter !) quant à une attaque réelle de cet attaquant.
Bonus : bien penser, en construisant son analyse de risques, à exploiter la connaissance sur la menace de groupes susceptibles de toucher la structure !
3. PROTECT – CTI & Réponse à incident
Dès lors qu’une équipe répond régulièrement à des incidents de cybersécurité réels, elle est amenée à collecter nombre de données techniques liées à l’incident : des IOC, bien sûr, mais peut-être aussi les Techniques observées, bien ordonnées par phases ou Tactics, par groupe d’attaquants, par secteur, etc.
Synergie possible : faire en sorte que les investigateurs numériques capitalisent, ou fassent capitaliser, toutes ces données au sein de l’OpenCTI de la société, va représenter une potentielle plus-value importante pour la cybersécurité de la société. En effet, non seulement les IOC peuvent alimenter/enrichir le SOC, mais en cas de réponse à incident, il peut être possible d’anticiper les futurs comportements d’un attaquant, en consultant les éléments capitalisés à son sujet.
4. PROTECT – CTI & SOC
L’amélioration continue de la détection qu’offre un service de SOC est, et doit être, un chantier permanent et prioritaire. À ce titre, développer ou obtenir des capacités de détection fines et complexes, ainsi que, si possible, acquérir des compétences en ingénierie de la détection permettant de créer et enrichir ses propres cas d’usage est le B.A.-BA de ce que l’on demande à un SOC.
En parallèle, disposer d’une TIP régulièrement enrichie par une personne en charge du suivi des menaces, offre de nombreux avantages (cf. ci-dessus).
Synergie possible : si l’on sait que FIN7 est susceptible d’attaquer la société, et que de nombreuses connaissances ont été capitalisées à son sujet, alors il doit être possible de comparer le comportement offensif que le groupe sera en mesure d’adopter avec la couverture de détection que le SOC assure. Par exemple, si l’on dispose, là encore au format Mitre ATT&CK, d’une cartographie de Techniques utilisées par l’attaquant, et qu’un travail de fond a été effectué par le SOC, permettant de documenter ses capacités de détection au format Mitre ATT&CK, on dispose alors de deux « layers » qu’il est possible de superposer au sein d’un ATT&CK Navigator [8] et donc d’identifier, le cas échéant, les Techniques offensives non couvertes par le SOC. Autant de pistes pour alimenter son amélioration continue ! Pour une explication détaillée de la procédure à suivre pour superposer deux représentations graphiques de Techniques ATT&CK, voir le document en référence.
5. DETECT – Analyse de risques cyber & SOC
Deux briques que l’on a déjà évoquées, l’analyse de risques cyber et le SOC ; les dernières versions de la méthode EBIOS, si elles ont ceci de puissant qu’elles s’adaptent très facilement à tous les contextes, et permettent ainsi de « coller » aux risques des différents métiers, n’incluent pourtant pas un élément qui, plus le temps passe, pourrait être standardisé. En effet, beaucoup de structures relativement matures d’un point de vue de leur cybersécurité ont ceci de commun qu’elles partagent un socle de technologies. Les éditeurs peuvent changer, bien sûr, mais beaucoup auront, comme on l’a évoqué dans le début de cet article, un EDR, un proxy, un firewall, etc. ; concrètement, cela signifie que tout un pan d’une analyse de risques cyber, dès lors qu’elle anticiperait la possibilité qu’une partie de l’infrastructure de défense soit compromise par un attaquant, aura tendance à ressembler à celles d’autres analyses de risques, étant donné que les socles technologiques seront au moins partiellement similaires. Sauf erreur et concrètement, cela signifie que si deux structures conduisent leur atelier 1 d’EBIOS RM, il est évident que de très importantes similarités émergent.
Synergie possible : en intégrant, dans l’analyse de risques cyber, ceux susceptibles d’affecter l’infrastructure de défense mise en place, et, bien sûr, y accoler des mesures destinées à limiter ces risques, sera de nature à intéresser un service de SOC, étant entendu que s’assurer de la non-compromission de ce qui lui permet d’effectuer efficacement son travail est l’un de ses chantiers permanents !
Bonus : développer une annexe à EBIOS RM de « biens (supports) de cybersécurité », standardisée, avec des pistes de mesures à mettre en place selon le type de technologie déployé (EDR, proxy, firewall, etc.), voire même quelques spécificités liées à tel ou tel éditeur, peut faire gagner du temps dans la production d’une analyse de risques.
6. DETECT/RESPOND – Réponse à incident/Threat hunting & CTI
Malheureusement, même bénéficier de toutes ces compétences et avoir implémenté toutes les synergies précédentes n’a pas permis d’éviter le déclenchement d’un incident ; en effet, le SOC a notifié de ce qui ressemble à une compromission d’un des serveurs web de la société. En investiguant, l’équipe de cybersécurité suspecte une personne gérant les réseaux sociaux de la société de s’être fait compromettre, via un spearphishing imitant un e-mail de LinkedIn.
Synergie possible : les analystes et investigateurs numériques contactent la personne chargée d’alimenter l’OpenCTI interne. L’enchaînement des Techniques ATT&CK, et un IOC en particulier (un nom de domaine), semblent pointer vers le groupe d’attaquant Lazarus [9], que la société suit également avec attention. En exploitant l’intelligence capitalisée, les investigateurs sont en mesure de prévoir une partie du comportement à venir de l’attaquant, donc de mieux contenir l’incident de cybersécurité, et donc d’y remédier.
À noter que l’on peut également imaginer très exactement la même logique, mais en remplaçant une « vraie » réponse à incident par une opération de Threat hunting ; dans ce cas, outre la recherche d’IOC exploitant les éléments capitalisés au sein du SI, les investigateurs peuvent également rechercher les traces d’un « passage » de Lazarus aux différents endroits où, selon la connaissance que la société en a, il pourrait être passé.
7. RESPOND/RECOVER – Red Team & Réponse à incident
L’incident en question a été résolu ; formidable ! Consciente de l’intérêt d’un tel exercice, l’équipe cybersécurité produit un retour d’expériences (REX ou RETEX, pour les intimes) ; ce dernier, comme tout REX qui se respecte, inclut les commentaires critiques, catégorisés, des expériences rencontrées, ainsi qu’un plan d’actions à appliquer pour améliorer la situation la prochaine fois que les conditions de déclenchement d’un incident de cybersécurité similaire seront réunies.
Synergie possible : si le REX inclue une timeline des évènements liés à l’incident, peut-être là encore au format Mitre ATT&CK, alors un audit de type Red Team pourra essayer, quelque temps plus tard, de rejouer celle-ci afin de contrôler l’application des mesures du plan d’actions issu du REX, voire même en challenger la qualité.
8. RECOVER – Exercice de crise & Réponse à incident/Red Team/Analyse de risques cyber
Enfin, sans doute ne serait-il pas possible de faire de notre équipe de cybersécurité évoquée tout du long de cet article, une équipe idéale, si celle-ci n’était pas impliquée, régulièrement, dans un exercice de crise cyber [10]. L’opération permet de tester le dispositif préalablement construit (y compris l’important travail de définition des conditions de déclenchement et de sortie d’une crise, et les moyens associés), sensibilise les acteurs aux procédures existantes, évalue les capacités de prise de décision dans l’urgence, etc.
Synergie possible : selon la même logique que précédemment évoquée lors de quelques exemples précédents, il est tout à fait possible, voire souhaitable, de nourrir le scénario de l’exercice de crise en question d’expériences passées :
- Un incident qui a été mal géré (mais faisant l’objet d’un REX pertinent) ?
- Un audit de type Red Team qui a démontré des trous béants dans la sécurité de la structure ?
- Un scénario étudié dans la dernière analyse de risques, et dont la possible occurrence inquiète très fortement la société ?
… autant de pistes intéressantes à étudier lors de la phase de définition des grandes lignes du scénario d’un exercice de crise !
Le retour d’expériences, parent pauvre de la réponse à incident ?
Si tout le monde s’accorde pour souligner l’importance de la production de retours d’expériences, en réponse à un incident de cybersécurité, force est de constater que rares sont les structures à traduire cette importance en réalité concrète. Les raisons invoquées sont multiples :
- priorisation d’autres sujets ;
- charge de travail trop importante ;
- désintérêt de tout ou partie de l’équipe pour la production d’un tel document (ben oui, rédiger un rapport, quel ennui) ;
- absence d’une doctrine et méthodologie claire en la matière, permettant la réalisation et surtout le suivi de REX.
Pourtant, l’intérêt d’un tel exercice est d’autant plus important que de nombreux incidents, s’ils peuvent devenir très spécifiques au fur et à mesure que les phases de la cyber kill chain [11] s’enchaînent, partagent souvent des caractéristiques : vecteur de compromission, techniques de persistance, méthodes de latéralisation ou d’escalade de privilèges.
Peut-être nous proposerons-nous d’étudier, dans un futur article, ce qui constitue un REX efficace et actionnable, et qui évite les écueils, lourdeurs et autres poncifs que l’on attribue trop souvent à ce genre d’exercice.
Conclusion
Ceci conclut notre petit vadémécum ; d’autres exemples auraient pu être évoqués, et, encore une fois, je serais ravi d’en discuter avec chaque lecteur intéressé, mais l’article n’a jamais prétendu tous les concaténer.
D’aucuns pourront aussi faire la remarque qu’en décrivant, en introduction, cette fiction qu’est une équipe de cybersécurité douée absolument partout et suffisamment solide et soutenue pour se permettre de pratiquer elle-même toutes les activités évoquées, est un doux rêve. Dont acte, bien sûr. Sentez-vous libre de vous éloigner de l’image complètement idéalisée que j’ai peinte ici, selon les capacités et forces de vos propres équipes ; le secteur privé de la cybersécurité, en Europe et en France notamment, est suffisamment dynamique et compétent pour vous permettre, moyennant finance, d’externaliser certaines des missions discutées dans cet article.
Cela n’engage que moi, mais, par exemple, les activités telles que la réalisation d’un audit de type Red Team, la réalisation d’une analyse de risques cyber, ou même l’appui à la réalisation d’un exercice de crise, sont autant de missions que de nombreux pure players seraient ravis d’assumer.
Enfin, la démarche utilisée ici semblera, peut-être, couler de source pour certains ; j’espère que, pour les autres, elle aura conduit à relativiser les cloisonnements entre activités, et à contribuer à les faire reconnaître pour ce qu’ils sont le plus souvent : des distinctions sémantiques.
Remerciements
Une fois n’est pas coutume, je vais remercier uniquement des personnes physiquement mortes : merci à Nietzsche, Cioran et Desproges, qui m’ont appris que toute volonté d’enfermement dans un système est, au mieux une défaite de la pensée face au monde, au pire l’expression d’une pulsion refusant la réalité.
J’aurais pu également citer quelques personnes dont le décès intellectuel a nourri les quelques petites idées utiles que j’ai pu avoir, parfois, et dont cet article n’est sans doute que le moins bon témoignage ; l’éducation se base autant sur le mimétisme que sur la contradiction, et donc, pour tout ce qu’ils m’ont appris à leur corps défendant : merci à eux.
Références
[1] A. Gévaudan, « Les taxonomies se cachent pour ne pas mourir », MISC n°113, janvier-février 2021 :
https://connect.ed-diamond.com/MISC/misc-113/les-taxonomies-se-cachent-pour-ne-pas-mourir
[2] A. Gévaudan, « Mitre ATT&CK : la rançon du succès », MISC n°125, janvier-février 2023 :
https://connect.ed-diamond.com/misc/misc-125/mitre-attck-la-rancon-du-succes
[3] NIST Cybersecurity Framework, août 2023,
https://www.nist.gov/news-events/news/2023/08/nist-drafts-major-update-its-widely-used-cybersecurity-framework
[4] Tips for Threat Hunters: Comparison of Indicators of Compromise (IoCs) and Tactics, Techniques, and Procedures (TTPs), Ibrahim Akdagl, août 2023, https://ibrahimakkdag.medium.com/tips-for-threat-hunters-comparison-of-indicators-of-compromise-iocs-and-tactics-techniques-and-47bc268fe7ff
[5] La méthode EBIOS Risk Manager – Le guide, ANSSI,
https://cyber.gouv.fr/publications/la-methode-ebios-risk-manager-le-guide
[6] OpenCTI, GitHub, https://github.com/OpenCTI-Platform/opencti
[7] Techniques ATT&CK du groupe FIN7, Mitre,
https://attack.mitre.org/groups/G0046/
[8] Comparing layers in ATT&CK Navigator, Mitre,
https://attack.mitre.org/docs/Comparing_Layers_in_Navigator.pdf
[9] Techniques ATT&CK du groupe Lazarus, Mitre,
https://attack.mitre.org/groups/G0032/
[10] Crise cyber, les clés d’une gestion opérationnelle et stratégique, ANSSI,
https://cyber.gouv.fr/publications/crise-cyber-les-cles-dune-gestion-operationnelle-et-strategique
[11] Cyber kill chain, Lockheed Martin,
https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
