Table of Contents
Les tests de pénétration fondés sur la menace (TLPT) coûtent du temps et de l’argent aux entités régies par DORA. Comment se préparer pour réussir ?
Nota Bene : Cet article est le quatrième et dernier chapitre de notre guide des tests de sécurité pour les entités réglementées par DORA, que nous vous recommandons de lire depuis le début si ce n’est déjà fait.
Avant toute chose, rappelons brièvement ce que sont les tests de pénétration fondés sur la menace (TLPT, pour Threat-Led Penetration Testing).
Les TLPT sont des tests de sécurité renforcés, commandés par l’Article 26 du Digital Operational Resilience Act (DORA), et réservés aux entités financières dont la défaillance aurait des effets systémiques. Concrètement, les TLPT sont des exercices Red Team à grande échelle, qui doivent éprouver l’intégralité de la surface d’attaque de l’organisation ciblée – donc aussi bien ses composantes physiques, qu’humaines et numériques.
Il est essentiel de bien comprendre la nature et les exigences des TLPT avant de pouvoir saisir leurs implications pour les responsables de la sécurité des entités réglementées. Si vous souhaitez approfondir le sujet avant de poursuivre votre lecture, nous vous invitons à lire notre article dédié :
Lire aussi : DORA et les tests de pénétration fondés sur la menace (TLPT)
Le double objectif des TLPT
Les tests de pénétration fondés sur la menace (TLPT) jouent un rôle essentiel dans l’objectif poursuivi par DORA, à savoir élever le niveau de résilience numérique des entités financières de l’Union européenne.
Ils ont une double fonction, qui est de permettre :
- aux entités financières désignées d’évaluer leur niveau de sécurité dans des situations au plus proche du réel ;
- aux autorités compétentes – et par leur intermédiaire à l’UE et aux États membres – de vérifier la résilience réelle des entités stratégiques pour le bon fonctionnement du système financier, en contrôlant l’efficacité de leur programme de tests de résilience.
Les TLPT sont donc les examens finaux du programme de tests de résilience, comme le baccalauréat après trois années d’études secondaires. Mais il y a un bémol pour les entités financières – et là, permettez-nous de filer cette métaphore lycéenne discutable.
Vous pouvez continuer à lire ce chapitre publié sous forme d’article sur notre blog, ou télécharger l’intégralité du guide DORA sur les tests de sécurité ci-dessous au format PDF pour une lecture plus aisée.
DORA : guide des tests de sécurité pour les entités réglementées
Un guide de conformité de 60 pages pour guider les responsables de la sécurité des entités réglementées par DORA à travers les obligations de test de sécurité prévues par le règlement : les tests de résilience et les tests de pénétration fondés sur la menace (TLPT).
Faire le lien entre les tests de résilience et les TLPT
Avant d’affronter les épreuves du baccalauréat, les étudiants de France et de Navarre passent un “bac blanc” pour s’entraîner et évaluer leur capacité à passer le véritable examen. Un confort que n’ont pas les organisations régulées par DORA. En effet, le Règlement amène :
- des mesures et des tests de sécurité obligatoires pour les entités financières – le programme de tests de résilience introduit par l’Article 24 ;
- et des mécanismes de contrôle de ces mesures pour les autorités – les TLPT introduits par l’Article 26.
Mais DORA n’introduit aucune étape intermédiaire, aucun entraînement préalable aux TLPT, aucun moyen pour les entités réglementées d’évaluer leur maturité et leur capacité à passer avec succès un test de pénétration fondé sur la menace.
Soyons clairs : la législation n’interdit pas aux organisations de se préparer, bien au contraire, mais elle n’offre pas de solution toute faite. Il appartient donc aux différentes structures de mettre en place leur propre épreuve préparatoire, leur propre “TLPT blanc”.
Là, certains questionneront peut-être l’utilité d’une telle étape. Après tout, il suffirait de tirer les leçons d’un TLPT peu concluant avant d’en organiser un autre, non ? Hé bien justement, non.
DORA : Guide de conformité complet pour le secteur financier
Un guide de 50 pages pour accompagner les RSSI, les DPO et les services juridiques dans l'application de la réglementation européenne. Aucun blabla, rien que des conseils pratiques et des analyses exploitables.
Un TLPT coûte du temps et de l’argent
La réalisation d’un test de pénétration basé sur la menace coûte du temps et de l’argent.
Du temps, car les processus inhérents à un TLPT sont longs et fastidieux. Il faut évaluer et sélectionner les prestataires de services de Red Teaming et de Threat Intelligence, se synchroniser avec l’autorité nationale compétente – notamment pour valider le contenu de l’exercice –, mobiliser les équipes internes concernées (DSI, Blue Team…), agréger les résultats et en rendre compte, etc. Sans oublier que le test effectif lui-même est chronophage, puisqu’il s’étend généralement sur une période de 6 à 12 mois.
De l’argent, car les différents acteurs du TLPT doivent être rémunérés, à commencer par les prestataires de Red Teaming et de Threat Intelligence. Plusieurs coûts indirects sont également à prendre en compte, comme celui de la mobilisation des ressources internes sur ce sujet, du RSSI aux équipes opérationnelles, d’autant plus dans le cadre d’un test internalisé – dont la conduite est soumise à diverses conditions, nous vous renvoyons ici à notre article sur les TLPT.
Bref, au risque de nous répéter : un TLPT coûte cher, en temps comme en finances. Il est donc dans l’intérêt des entités financières de “réussir” l’exercice autant que possible, et de ne pas en organiser un tous les quatre matins ; rappelons ici que les autorités compétentes peuvent augmenter la fréquence des TLPT pour une entité donnée si elles le jugent nécessaire.
Un enjeu de retour sur investissement pour les entités réglementées
La mise en œuvre d’un TLPT va donc de pair avec des considérations de retour sur investissement. Un test de sécurité de cette ampleur entraîne inévitablement des dépenses importantes, qui pèsent sur le budget alloué à la sécurité. Des dépenses qui doivent par ailleurs être validées par le corps dirigeant, puisque NIS2 et DORA appellent à une responsabilisation de la hiérarchie en matière de sécurité, notamment au travers de la prise de conscience des grands chantiers cybers. Il est évident qu’un TLPT n’est pas un simple exercice de routine, et qu’il doit être porté à l’attention des cadres dirigeants.
D’une certaine manière, investir un tel budget engage aussi le professionnalisme du RSSI et de ses équipes. Ils se doivent d’avoir suffisamment confiance dans les mesures et les tests précédemment mis en place, au moins assez pour attendre que les conclusions du TLPT soient globalement positives.
Après tout, on ne se lance pas dans un TLPT, avec les coûts que cela implique, sans être un minimum confiant dans sa capacité à y faire face. Comme toujours en matière de sécurité : la défaillance est une possibilité, mais la rigueur n’est pas une option.
Directive NIS2 : Guide de conformité étape par étape
Un guide de 40 pages pour accompagner les RSSI, les DPO et les services juridiques dans l'application de la directive. Aucun blabla, rien que des conseils pratiques et des analyses exploitables.
L’importance d’un précontrôle dans la préparation d’un TLPT
En raison de cet impératif de ROI, il est dans l’intérêt des entités financières d’évaluer leur capacité à faire face à un TLPT (c’est-à-dire leur résilience) avant le test. Il faut donc trouver une approche, une forme d’évaluation qui se rapproche au plus près des modalités d’un test de pénétration fondé sur la menace.
A cela s’ajoute une autre condition. Certaines organisations pourraient être tentées d’organiser des exercices Red Team d’entraînement grandeur nature, qui seraient de fait similaires à un TLPT. C’est une solution efficace, mais ceux-ci impliqueront plus ou moins la même charge de temps et d’argent que l’exercice final, et il s’agit là d’un luxe réservé aux RSSI les mieux dotés.
Dans l’idéal, le test de résilience préparatoire à un TLPT doit donc être :
- moins onéreux et moins laborieux que le TLPT, au risque de dupliquer les efforts et les coûts ;
- suffisamment proche des exigences opérationnelles du cadre TIBER-EU, afin d’évaluer au mieux la capacité réelle des entités financières à engager un budget TLPT avec de bons espoirs de réussite.
Ici, le bug bounty apparaît comme une solution idéale, tant du point de vue de la sécurité que des finances.
TIBER-EU et le bug bounty : une philosophie commune
Un bug bounty est un test de sécurité offensif, qui peut être continu ou temporaire. Il s’agit d’une chasse aux vulnérabilités, par laquelle une organisation mobilise la communauté des chercheurs en sécurité pour tester un ou plusieurs actifs numériques – applications web et mobile, cloud, réseaux, IoT, etc. Lorsqu’un chercheur identifie une vulnérabilité, l’organisation lui verse une récompense en fonction du niveau de criticité. En l’absence de détections, l’organisation ne dépense rien.
Le bug bounty s’inscrit dans la même philosophie que les tests TIBER-EU : aider les organisations à comprendre et à améliorer leur résilience en simulant des attaques en conditions réelles sur une durée prolongée, en adoptant les tactiques, techniques et procédures (TTP) appliquées par les acteurs malveillants.
À titre d’illustration, voici un extrait du cadre TIBER-EU tel que rédigé par la Banque Centrale Européenne (BCE), traduit par nos soins :
“Un test Red Team basé sur le renseignement imite les Tactiques, Techniques et Procédures (TTP) de vrais attaquants sur la base de renseignements sur les menaces personnalisés. Ce faisant, il cherche à cibler les personnes, les processus et les technologies qui sous-tendent les fonctions critiques d’une entité afin de tester ses capacités de protection, de détection et de réponse sans aucune connaissance préalable. Il permet à l’entité de comprendre sa résilience réelle en mettant à l’épreuve tous les éléments de son activité par rapport aux TTP des acteurs de la menace qui sont spécifiques à son organisation.”
– TIBER-EU Framework, Service Procurement Guidelines, BCE
Le bug bounty apporte ainsi cinq éléments qui caractérisent un TLPT conduit dans le respect du cadre TIBER-EU :
- la mobilisation d’un grand nombre d’experts en sécurité ;
- qui permet une diversité des profils et des compétences ;
- indispensable à la variété des tactiques et des techniques ;
- avec une approche de la boîte noire (Black Box) sans connaissance préalable sur la cible ;
- et pendant une durée suffisamment longue.
Un test de résilience qui permet de sanctionner tous les précédents
Soyons clair : le bug bounty ne permet pas de tester l’intégralité de la surface d’attaque d’une entité – physique, humaine et numérique – comme le ferait un TLPT. Après tout, il n’amène pas de tentatives d’intrusions dans des locaux ou de méthodes d’ingénierie sociale (encore que).
Mais le bug bounty va autrement plus loin que tous les autres tests cités par l’Article 25 de DORA, que ce soit les scanners ou les tests d’intrusion, pour lesquels le périmètre et la durée sont prédéfinis, et les experts moins nombreux.
Le bug bounty permet de tester en profondeur l’une des trois surfaces d’attaque des entités financières – à savoir la surface d’attaque numérique, au centre de DORA et de la résilience numérique – à travers des tests contrôlés avec une approche Black Box sur des actifs en production. Autant de caractéristiques obligatoires pour un TLPT en accord avec TIBER-EU. Cette mise à l’épreuve en situation réelle permet de valider l’efficacité des tests et mesures de sécurité précédemment adoptés par les entités.
Le bug bounty peut être donc être considéré comme :
- un test de résilience opérationnelle numérique à part entière dans le cadre des obligations de test amenées par l’Article 25 de DORA ;
- mais aussi, et surtout, comme le test de résilience final qui vient sanctionner tous les précédents, et valider la capacité des entités à faire face à un TLPT.
Ils font du bug bounty, ils racontent.
Le bug bounty comme tremplin vers les tests TIBER-EU
Le bug bounty permet une étape intermédiaire entre les tests de résilience et les tests de pénétration fondés sur la menace (TLPT). Il offre aux entités financières une courbe de progression plus douce dans l’apprentissage de la sécurité, en leur permettant d’évaluer les mesures qu’elles mettent en place, leur résilience et leur maturité réelles, ainsi que leur capacité à faire face à un exercice Red Team à grande échelle dans le cadre de TIBER-EU.
Il convient de voir le bug bounty comme un contrôle à mi-parcours entre les tests de résilience opérationnelle annuels (DORA) et les TLPT (DORA, TIBER). C’est une étape intermédiaire qui contribue à renforcer la résilience numérique des entités, tout en ajoutant une dimension concrète qui facilite l’adoption de DORA et du cadre TIBER-EU par le secteur financier.
Il est important de comprendre que :
- Les tests de pénétration fondés sur la menace (TLPT) sont une mécanique de contrôle pour les autorités de l’efficacité du programme de tests de résilience des entités cruciales du secteur financier européen ;
- Là où le bug bounty est un mécanisme de contrôle pour les entités financières elles-mêmes, afin d’évaluer l’efficacité de leur programme de test de résilience, leur aptitude à résister à un TLPT et, surtout, à engager un budget avec de bonnes chances de succès.
Une solution économique pour les organisations
Comme nous l’avons déjà dit, la mise en œuvre d’un TLPT est coûteuse. Si un pré-contrôle supplémentaire est introduit, il est important de maîtriser les coûts afin de ne pas grever le budget. À cet égard, le bug bounty a l’avantage d’être une solution intéressante pour les entités financières, puisqu’il adopte une logique de paiement au résultat.
En effet, toute la philosophie du bug bounty est que les chercheurs en sécurité ne sont pas payés pour leur temps de recherche, mais en fonction de leurs détections et de leur degré de criticité. Si l’identification d’une vulnérabilité donne droit à une récompense, cela signifie aussi que l’absence de détection est synonyme de dépense nulle pour les organisations.
En principe, le bug bounty intervient à un stade du parcours de sécurité où les entités financières sont censées être robustes, à savoir à la fin du programme de test de résilience commandé par le DORA. Si le travail de sécurisation a été bien fait, il n’y a pas de raison que le programme de bug bounty soit particulièrement dispendieux. Au contraire, le nombre de détections devrait rester modeste, confirmant la capacité de l’entité financière à passer à un TLPT.
Sélectionner les chercheurs en sécurité selon les critères TIBER-EU
Le bug bounty permet de sélectionner les chercheurs en sécurité selon les exigences du cadre TIBER-EU, du moins dans le cadre d’un programme mené avec Yogosha. Cela tient directement à la qualité de nos chercheurs en sécurité, et à la rigueur de nos processus de sélection – Yogosha est la seule et unique plateforme entièrement privée à proposer du bug bounty en Europe.
Lire aussi : Bug Bounty, différences entre plateformes publiques et privées
La Yogosha Strike Force (YSF) est une communauté privée et sélective qui regroupe plus de 800 chercheurs en sécurité internationaux qui sont :
- Spécialisés dans la recherche des vulnérabilités les plus critiques en simulant les attaques sophistiquées des pirates informatiques.
- Experts dans de multiples types d’actifs – Applications Web et Mobiles, IOT, Cloud, Réseaux, API, Infrastructure…
- Titulaires de certifications reconnues en matière de cybersécurité – OSCP, OSEP, OSWE, OSEE, GXPN, GCPN, eWPTXv2, PNPT, CISSP…
Nous sélectionnons uniquement les chercheurs les plus talentueux : seuls 10% des candidats sont acceptés, après avoir réussi des examens techniques et pédagogiques. Leur identité et leurs antécédents sont également vérifiés.
Dans le cadre d’un bug bounty réalisé en amont d’un TLPT, nous introduisons des critères de sélection supplémentaires pour les chercheurs en sécurité participants, directement calqués sur les critères de sélection des membres de l’équipe Red Team dictés par TIBER-EU.
A titre d’exemple, voici ci-dessous quelques-uns de ces critères TIBER-EU, et la façon dont nous les intégrons à nos programmes de bug bounty pour les entités réglementées.
| Exigences pour les membres de la Red Team dans le cadre d’un test de pénétration fondé sur la menace (TLPT) (TIBER-EU Framework, BCE) | Critères de sélection des chercheurs de la Yogosha Strike Force (YSF) éligibles aux programmes de bug bounty pour les acteurs financiers |
|---|---|
| “Une expérience suffisante des membres de la Red Team. Attente pour chaque membre : au moins deux ans d’expérience dans les tests de Red Teaming.” | Nous ne sélectionnons que des chercheurs en sécurité ayant au minimum deux ans d’expérience en Red Teaming, après avoir examiné leur parcours professionnel. |
| “Le CV actualisé de chaque membre de la Red Team doit être fourni à l’entité” | Nous pouvons fournir le CV des chercheurs sélectionnés pour participer au bug bounty. |
| “Composition pluridisciplinaire de la Red Team, avec un large éventail de connaissances et de compétences, telles que : compréhension des affaires, tests Red Teaming, tests de pénétration, reconnaissance, renseignement sur les menaces, gestion des risques, développement d’exploits, intrusion physique, ingénierie sociale, analyse des vulnérabilités et combinaisons de ces éléments” | Les 800+ chercheurs de la Yogosha Strike Force (YSF) apportent la diversité des connaissances et des compétences demandées ici. Nous disposons d’experts confirmés et certifiés dans chacun de ces domaines, du pentest au renseignement sur les menaces en passant par l’intrusion physique et l’ingénierie sociale. |
| “La vérification des antécédents de chaque membre de la Red Team est effectuée par le fournisseur de RT” “Des vérifications approfondies des antécédents sont effectuées conformément aux exigences des autorités nationales” | Tous nos chercheurs ont fait l’objet d’une procédure KYC menée par un tiers indépendant, et leur identité et leurs antécédents ont été dûment vérifiés. Des vérifications supplémentaires peuvent être menées au cas par cas pour les besoins des programmes de bug bounty les plus sensibles. |
| “Les membres de la Red Team doivent posséder des qualifications et des certifications reconnues et appropriées – Certified Ethical Hacker (CEH), OSCP, OSWP, OSWE, CISSP, etc.” | Nous pouvons sélectionner nos chercheurs en fonction de leurs qualifications et certifications – OSCP, OSEP, OSWE, OSEE, GXPN, GCPN, eWPTXv2, PNPT, CISSP… L’envergure de la Yogosha Strike Force (800+ experts) nous permet de trouver la quasi-totalité des profils désirés. |
| Source : TIBER-EU Framework |
Yogosha comme prestataire de tests de Sécurité Offensive dans le cadre de DORA
Notre communauté d’experts en sécurité certifiés n’est pas notre seul atout lorsqu’il s’agit du bug bounty dans le cadre de DORA, c’est-à-dire comme étape intermédiaire entre les tests de résilience et les TLPT.
Primo, nous possédons une expertise en matière de tests de sécurité liés à DORA. Avec notre offre de Pentest as a Service (PtaaS), nous conduisons d’ores et déjà des tests d’intrusion comme tests de résilience pour un certain nombre d’acteurs du secteur financier européen.
Nous proposons également une offre de Red Teaming complète dans le cadre des tests de pénétration fondés sur la menace (TLPT). De plus, nous avons rédigé de multiples guides et articles – dont celui que lisez présentement – sur les sujets afférents au Règlement.
Nous sommes donc présents de bout en bout dans la chaîne de tests de sécurité DORA, et nous disposons de l’expertise et des connaissances nécessaires pour ajuster chaque étape de test (PtaaS, bug bounty et Red Teaming) en fonction des objectifs de conformité et de sécurité, mais aussi de la maturité des organisations et de leurs contraintes – budget, passage à l’échelle, etc.
Lire aussi : DORA : le défi du passage à l’échelle des tests de sécurité
Secundo, nous nous imposons des exigences de sécurité à la hauteur de vos enjeux. Yogosha est une entreprise française, soumise à la juridiction de l’Union européenne. Notre plateforme est hébergée via 3DS Outscale et son cloud souverain certifié SecNumCloud (la plus haute norme de sécurité française, établie par l’ANSSI), et les données sont hébergées sur le sol français.
Notez qu’il est possible d’utiliser notre plateforme SaaS en “single-tenant”, c’est-à-dire qu’une instance de l’application vous est entièrement dédiée, dans la région de votre choix, permettant un cloisonnement total de vos données et des options de personnalisation – votre logo, URL paramétrable, etc.
Autre option de déploiement pour les entités financières les plus sensibles : Yogosha est le seul prestataire de bug bounty au monde à proposer une plateforme en Self-Hosted. Une solution idéale pour les organisations aux exigences de sécurité les plus élevées, qui peuvent héberger notre solution où bon leur semble – cloud privé, on premise – pour garder le contrôle total sur leurs données et le contexte d’exécution.
Tertio, il y a notre communauté d’experts en cybersécurité triés sur le volet, la Yogosha Strike Force (YSF), mais nous nous sommes déjà suffisamment épanchés sur le sujet.
À ce stade de la lecture, vous avez compris notre intention : vous dire que nous sommes les mieux placés pour vous aider à tester vos actifs dans le cadre de DORA, que ce soit :
- avec notre offre de Pentest as a Service (PtaaS) dans le cadre de votre programme de test de résilience [DORA, Article 25] ;
- avec nos programmes de bug bounty pour évaluer l’efficacité de vos tests de résilience précédents, le niveau de sécurité réel de vos actifs exposés, et votre capacité à vous confronter à un TLPT ;
- avec nos services de Red Teaming dans le cadre d’un test de pénétration fondé sur la menace (TLPT) [DORA, Article 26]
Il ne nous reste plus qu’à vous souhaiter bonne chance dans la sécurisation de vos actifs, et dans l’organisation des différents tests induits par DORA. Et si d’aventure vous avez besoin d’un conseil à quelque étape que ce soit, voire d’un accompagnement expert, n’hésitez pas à nous contacter.
