La décision que ce guide vous aide à prendre
Choisissez la mission en fonction de l’obligation et de la décision à traiter. Un test d’intrusion conventionnel examine un périmètre technique convenu ; le TLPT DORA ajoute un processus défini avec les autorités, du renseignement sur les menaces, le périmètre des fonctions critiques et une clôture formelle. Une organisation peut avoir besoin des deux à des fins différentes.
Pour la personne responsable de la mission. Distinguez les missions selon leur objectif, leur gouvernance et leur modèle de couverture. Un constat technique peut contribuer à un TLPT sans que l’évaluation dont il provient devienne pour autant un TLPT.
La différence tient à la question mise à l’épreuve
Un test d’intrusion classique examine généralement les vulnérabilités dans un périmètre technique défini. Un test d’intrusion fondé sur les menaces pose une question plus large : comment un adversaire crédible pourrait-il affecter les fonctions critiques de l’organisation, et comment son personnel, ses processus et sa technologie réagiraient-ils ?
La distinction ne se limite pas à la durée ou à l’intensité. Un TLPT DORA comprend une procédure avec l’autorité compétente, du renseignement sur les menaces ciblé, des exigences applicables aux équipes de test, un périmètre lié aux fonctions critiques ou importantes et des travaux formels de clôture. Qualifier un exercice de « red teaming » ne prouve pas que ces exigences ont été respectées.
Lire le texte du diagramme
- Évaluation technique
- Évaluer les systèmes et contrôles définis
- Exercice guidé par la menace
- Suivre des chemins crédibles jusqu’à leur impact sur les fonctions
- Gouvernance
- Appliquer le processus de livraison requis
Comparez les modèles de prestation
| Dimension | Test d’intrusion classique | TLPT DORA |
|---|---|---|
| Point de départ | Souvent, une liste technique des actifs ou un périmètre applicatif défini. | Fonctions critiques, menaces pertinentes et périmètre validé par l’autorité compétente. |
| Base de menace | Peut utiliser des techniques standard et un modèle général d’attaquant. | Le renseignement ciblé sur les menaces éclaire des scénarios réalistes. |
| Environnement | Cela dépend de la mission convenue. | Systèmes de production critiques en service concernés. |
| Capacité de défense | Peut-être en dehors de l’objectif du test. | La prévention, la détection et la réponse font partie de l’apprentissage. |
| Gouvernance | Défini par la mission et les normes applicables. | DORA, RTS, intervention de l’autorité et rôles spécifiques des participants. |
| Clôture | En général, un rapport technique et un suivi convenu. | Rapports des équipes rouge et bleue, relecture, purple teaming, synthèse et processus de remédiation. |
Pourquoi les organisations peuvent avoir besoin des deux
Le programme général de tests de DORA et son obligation de TLPT avancé répondent à des objectifs liés, mais distincts. Les tests techniques courants peuvent détecter des faiblesses avant qu’elles ne s’intègrent à un parcours d’attaque plus large. Le TLPT peut ensuite montrer si plusieurs niveaux de contrôle fonctionnent ensemble dans des conditions réalistes.
La découverte d’un grand nombre de vulnérabilités ne rend pas un test équivalent à un TLPT. De même, un exercice fondé sur les menaces n’a pas pour objectif d’inspecter de manière exhaustive chaque actif à la recherche de toutes les failles possibles. Les objectifs et les exigences en matière de preuves doivent rester clairs.
Lire le texte du diagramme
- Constat relatif à une API
- Une autorisation précise a échoué
- Observation guidée par la menace
- Un scénario a révélé un problème de résilience
- Surface non testée
- L’absence de couverture ne permet pas de tirer de conclusion
Inadéquation des exigences d’achat
Une demande d’achat qui se limite à solliciter un « test d’intrusion DORA » est ambiguë. Un prestataire peut chiffrer une courte évaluation applicative, tandis qu’un autre peut prévoir un TLPT en plusieurs étapes, avec du renseignement sur les menaces et d’importantes obligations de clôture.
Précisez si l’entité a été désignée pour un TLPT, quelle autorité est concernée, quelles sont les fonctions critiques probables, la période de test et les livrables attendus. Demandez aux fournisseurs d’expliquer comment leur approche répond aux exigences applicables. Comparez des offres reposant sur des hypothèses équivalentes en matière de périmètre, de ressources et de gouvernance.
Ne commandez pas un test au seul motif que la proposition utilise le bon acronyme. Vérifiez l’équipe proposée et les éléments probants au regard de l’article 27, puis convenez des mesures de protection opérationnelles avant le début des tests.
Lire le texte du diagramme
- Situation de départ
- Accès, assistance et hypothèses
- Activité observée
- Actions et réponse défensive
- Limitations
- Parcours non testés et systèmes exclus
Reconnaître une évaluation préparatoire utile
Une banque qui prépare un exercice avancé peut commander une revue ciblée d’une API de paiement, d’une voie d’accès privilégiée ou d’un pipeline de déploiement. Ce travail peut mettre au jour des faiblesses, améliorer la connaissance du périmètre et clarifier les mesures de protection opérationnelles. Consignez-le comme une évaluation distincte, avec ses propres points de départ et limites. Ses résultats peuvent contribuer à la préparation, mais ils ne remplacent ni le renseignement sur les menaces, ni la coordination avec les autorités compétentes, ni les autres éléments du processus TLPT applicable.
Notre comparatif des tests d’intrusion bancaires traduit cette distinction en questions à poser lors des achats. Il aide l’équipe commanditaire à déterminer si elle a besoin d’une couverture d’une surface technique définie ou d’une évaluation plus large d’une fonction critique face à une menace crédible.
Demandez ce que chaque résultat établit réellement
Un test d’API peut montrer qu’un client synthétique peut modifier sans autorisation l’état d’une transaction. Un exercice fondé sur les menaces peut examiner comment un adversaire pourrait atteindre un objectif lourd de conséquences et comment l’organisation détecte l’attaque et y répond au fil du parcours. Ces deux observations peuvent être pertinentes, mais aucune ne garantit une couverture exhaustive de l’autre question. Le rapport doit relier ses conclusions à la situation initiale testée, aux actions et aux observations, et signaler comme telles les conséquences qui n’ont pas été testées.
Pour les produits fournis par l’intermédiaire de plusieurs API et prestataires de services, le guide sur le périmètre des tests d’API fintech apporte des éléments pratiques pour la partie technique de cette cartographie. L’entité doit toujours déterminer le périmètre TLPT approprié et sa gouvernance dans le cadre du processus pertinent. Utilisez des noms de mission clairs dans le dossier d’achat, le registre des preuves et les rapports à la direction afin que ces responsabilités restent visibles.
Lire le texte du diagramme
- Définir l’objectif
- Identifier la décision que l’exercice doit éclairer
- Distinguer la préparation
- Distinguer clairement les évaluations ciblées
- Convenir du processus
- Clarifier le périmètre et les obligations de gouvernance
Poursuivez votre préparation
Sources primaires
- DORA · règlement (UE) 2022/2554
- RTS TLPT · Règlement délégué (UE) 2025/1190
- BCE · Cadre et orientations TIBER-EU
Informations générales, ne constituant pas un conseil juridique. Veuillez confirmer les exigences applicables et les modalités des tests auprès de l’autorité compétente.
Ce guide et les publications sectorielles associées, accessibles par les liens ci-dessus, sont publiés par Atlant Security. Les exemples techniques sont fournis à des fins de planification et ne prétendent pas décrire des tests réalisés pour des clients.
Publié par Atlant Security. Sources, politique éditoriale et corrections.
