Comment planifier les tests de résilience DORA à l'aide de l'IA

Aperçu

Vous apprendrez comment concevoir et mettre en œuvre, à l'aide de l'IA, un programme de tests de résilience opérationnelle numérique conforme aux articles 24 à 27 de DORA. Ce guide couvre le programme de tests général (évaluations des vulnérabilités, tests de pénétration, tests basés sur des scénarios), les exigences relatives aux tests de pénétration avancés fondés sur la menace (TLPT), la portée et la fréquence des tests, le rapport des résultats à votre organe de direction, et l'intégration des tests dans votre cadre de gestion des risques TIC, avec des prompts ISMS Copilot spécifiques pour générer chaque composant.

À qui s'adresse ce guide

Ce guide s'adresse aux :

• Responsables de la sécurité des systèmes d'information (RSSI) et gestionnaires de sécurité chargés de la conception et de la supervision des programmes de tests de résilience

• Gestionnaires de risques informatiques intégrant les résultats des tests dans les évaluations des risques TIC

• Coordinateurs de tests d'intrusion gérant les activités de tests internes et externes

• Responsables de la conformité veillant à ce que les programmes de tests répondent aux attentes réglementaires

• Consultants aidant les entités financières à se préparer au TLPT ou aux tests de résilience généraux

Avant de commencer

Vous aurez besoin de :

• Un compte ISMS Copilot (essai gratuit disponible)

• Votre cadre de gestion des risques TIC et votre inventaire des actifs TIC issus de Comment construire un cadre de gestion des risques TIC DORA à l'aide de l'IA

• Vos procédures de classification et de réponse aux incidents de Comment mettre en œuvre le reporting d'incidents DORA à l'aide de l'IA

• Une compréhension de vos activités de test actuelles (scans de vulnérabilités, tests d'intrusion, tests de reprise après sinistre)

• Savoir si votre entité a été désignée pour le TLPT par votre autorité compétente

• Une autorisation budgétaire pour les services de tests externes (particulièrement pour le TLPT)

Comprendre les exigences de DORA en matière de tests de résilience

Décomposition article par article

Le chapitre IV de DORA (articles 24-27) établit une approche structurée des tests de résilience opérationnelle numérique :

Article

Titre

Exigences clés

Applicabilité

Art 24

Exigences générales pour les tests de résilience opérationnelle numérique

Établir un programme de tests dans le cadre de la gestion des risques TIC, approche basée sur le risque

Toutes les entités financières (proportionnalité)

Art 25

Tests des outils et systèmes TIC

Types de tests spécifiques : évaluations de vulnérabilités, tests de pénétration, tests basés sur des scénarios, tests de compatibilité, tests de performance, revues de code source

Toutes les entités financières (proportionnalité)

Art 26

Tests approfondis au moyen de tests de pénétration fondés sur la menace (TLPT)

Tests de pénétration fondés sur la menace basés sur le cadre TIBER-EU, tous les 3 ans

Entités désignées uniquement

Art 27

Exigences applicables aux testeurs

Qualifications, indépendance et normes pour les testeurs (internes et externes)

Toutes les entités effectuant des tests

Tests généraux vs TLPT

Comprendre la distinction entre les tests généraux et le TLPT est crucial pour définir la portée de votre programme :

Aspect

Tests généraux (Art 24-25)

TLPT (Art 26-27)

Différence clé

Qui

Toutes les entités financières

Entités désignées uniquement

L'autorité compétente désigne les entités soumises au TLPT

Fréquence

Basée sur le risque ; systèmes critiques au moins une fois par an

Au moins tous les 3 ans

Le TLPT est moins fréquent mais beaucoup plus intensif

Portée

Tous les systèmes TIC (proportionnalité)

Fonctions critiques et importantes, systèmes de production en direct

Le TLPT teste les systèmes réels, pas seulement les environnements de test

Méthodologie

Diverses (scans de vulnérabilités, tests d'intrusion, tests de scénarios)

Cadre TIBER-EU, piloté par le renseignement sur les menaces

Le TLPT simule les tactiques réelles des adversaires

Testeurs

Internes ou externes (avec exigences d'indépendance)

Testeurs externes obligatoires (avec exceptions limitées)

Le TLPT nécessite une équipe rouge (red team) externe certifiée

Reporting

Interne (organe de direction, fonction de risque TIC)

À l'autorité compétente, avec attestation

Les résultats du TLPT sont transmis au régulateur

Étape 1 : Concevoir votre programme de tests généraux (Articles 24-25)

Cadre du programme de tests

L'article 24 exige un programme de tests faisant partie intégrante de votre cadre de gestion des risques TIC, suivant une approche basée sur le risque et proportionné à la taille et au profil de risque de votre entité.

1. Ouvrez votre espace de travail DORA dans ISMS Copilot

2. Générez le document du programme de tests :

   « Créez un programme de tests de résilience opérationnelle numérique pour une [type d'entité] répondant aux articles 24 et 25 de DORA. Incluez : l'objectif et les buts du programme, la gouvernance (surveillance par l'organe de direction, propriétaire du programme, rôles et responsabilités), l'approche basée sur le risque pour la planification des tests (comment les risques déterminent ce qui est testé et à quelle fréquence), la portée des tests (mappée sur l'inventaire des actifs TIC et les fonctions critiques/importantes), les types de tests à effectuer (évaluations des vulnérabilités, tests de sécurité réseau, tests de pénétration, tests basés sur des scénarios, tests de compatibilité, tests de performance, revues de code source, tests de logiciels open source, tests de bout en bout), la fréquence des tests par criticité d'actif et type de test, les exigences pour les testeurs internes vs externes, les exigences d'indépendance selon l'article 27, le reporting des résultats et la communication avec l'organe de direction, le processus de suivi de la remédiation, l'intégration avec les mises à jour du cadre de gestion des risques TIC, un modèle de calendrier de tests annuel, ainsi que la planification du budget et des ressources. Appliquez la proportionnalité pour une organisation de [taille de l'entité]. »

3. Définissez la méthodologie de test basée sur le risque :

   « Créez une méthodologie de test basée sur le risque pour les tests de résilience DORA. Définissez comment nous déterminons : quels systèmes et fonctions tester (basé sur la criticité des actifs TIC, l'impact métier, le paysage des menaces, les incidents précédents), quel type de test appliquer (scan de vulnérabilité vs test d'intrusion vs test basé sur un scénario), la profondeur et l'intensité des tests (basique, standard, avancé), la fréquence des tests (trimestrielle, semestrielle, annuelle), et la priorité des tests lorsque les ressources sont limitées. Fournissez une matrice de priorité des tests qui fait correspondre la criticité de l'actif et le niveau de menace au type et à la fréquence de test. Fournissez des exemples pour une [type d'entité]. »

Types de tests et leur application

L'article 25 spécifie plusieurs types de tests. Utilisez ISMS Copilot pour élaborer des plans détaillés pour chacun :

1. Programme d'évaluation des vulnérabilités :

   « Créez un programme d'évaluation des vulnérabilités pour la conformité à l'article 25 de DORA. Incluez : la portée du scan (tous les actifs TIC par niveau de criticité), les outils et la méthodologie de scan, la fréquence de scan (au moins trimestrielle pour les actifs critiques, mensuelle recommandée), la classification des vulnérabilités alignée sur le score CVSS, les délais de remédiation par sévérité (critique : 48 heures, élevée : 7 jours, moyenne : 30 jours, faible : 90 jours), le processus de gestion des exceptions pour les vulnérabilités qui ne peuvent être immédiatement corrigées, le format du rapport (rapport technique et résumé managérial), la méthodologie d'analyse des tendances, et l'intégration avec les procédures de gestion des correctifs. Fournissez un flux de travail de gestion des vulnérabilités. »

2. Programme de tests d'intrusion (Penetration Testing) :

   « Créez un programme de tests d'intrusion pour la conformité à l'article 25 de DORA. Incluez : la portée des tests (périmètre externe, réseau interne, applications web, applications mobiles, sécurité API, ingénierie sociale), la fréquence des tests (au moins annuelle pour les systèmes critiques, plus fréquente pour les zones à haut risque), la méthodologie de test (OWASP, PTES ou équivalent), un modèle de règles d'engagement (portée, calendrier, escalade, actions interdites), les exigences de qualification des testeurs selon l'article 27 de DORA (indépendance, compétence, assurance), les procédures pré-test (autorisation, confirmation de la portée, communication), les exigences de reporting (résumé exécutif, conclusions techniques, notations de risque, recommandations de remédiation), les procédures post-test (vérification de la remédiation, re-test), et le format de reporting à l'organe de direction. Fournissez un modèle de règles d'engagement type. »

3. Programme de tests basés sur des scénarios :

   « Concevez un programme de tests de résilience basés sur des scénarios pour l'article 25 de DORA. Créez des scénarios de test couvrant : une attaque de ransomware sur les systèmes bancaires/de paiement de base, une panne majeure d'un fournisseur cloud affectant les services critiques, une attaque DDoS pendant les périodes de pointe de transactions, une menace interne compromettant des données sensibles, une attaque de la chaîne d'approvisionnement via un fournisseur de services TIC tiers critique, une défaillance simultanée des systèmes primaires et de secours, la perte de personnel TIC clé lors d'un incident, une violation de données réglementaire nécessitant la notification des clients. Pour chaque scénario, définissez : les objectifs du test, la portée et les systèmes impliqués, le récit du scénario et le calendrier des injections, les critères de succès, les participants et les rôles, les procédures d'exécution du test, les résultats attendus, les critères d'évaluation et le modèle de rapport. Incluez des formats d'exercices de type 'tabletop' (sur table) et simulés. »

Étape 2 : Établir les exigences relatives aux testeurs (Article 27)

Indépendance et qualifications des testeurs

L'article 27 établit des exigences pour les testeurs effectuant des tests de résilience. Celles-ci s'appliquent tant aux testeurs internes qu'externes :

« Créez une politique d'exigences et de qualification des testeurs pour l'article 27 de DORA. Abordez : les testeurs internes (indépendance vis-à-vis des domaines testés, certifications pertinentes telles que OSCP/CREST/GPEN, maintien des compétences, exigences de rotation), les testeurs externes (certifications professionnelles et accréditations, expérience pertinente dans les tests du secteur financier, assurance responsabilité civile professionnelle, vérification de l'indépendance, vérification des références), la gestion des conflits d'intérêts, les procédures de sélection et d'habilitation de sécurité des testeurs, les exigences de non-divulgation et de confidentialité, et les critères d'évaluation des performances des testeurs. Fournissez une liste de contrôle de qualification des testeurs pour les testeurs internes et externes, ainsi qu'un exemple d'énoncé des travaux pour les engagements de tests externes. »

Étape 3 : Planifier le TLPT (Articles 26-27)

Comprendre les exigences du TLPT

Le test de pénétration fondé sur la menace (TLPT) sous DORA est basé sur le cadre TIBER-EU et représente l'exigence de test la plus intensive. Même si vous n'avez pas été désigné pour le TLPT, comprendre ces exigences est précieux pour la préparation.

1. Évaluez l'applicabilité du TLPT :

   « Évaluez si notre [type d'entité] avec [taille, importance systémique, profil de risque TIC] est susceptible d'être désignée pour le TLPT DORA selon l'article 26. Considérez : notre importance systémique dans le secteur financier, la criticité des services que nous fournissons, notre profil de risque TIC et sa complexité, les critères de désignation de l'autorité compétente issus des orientations publiées. Si une désignation est probable, fournissez une évaluation de préparation au TLPT et un calendrier de préparation. Si c'est peu probable, recommandez les mesures préparatoires que nous devrions prendre malgré tout. »

2. Générez le cadre TLPT :

   « Créez un cadre de préparation et d'exécution du TLPT pour l'article 26 de DORA, aligné sur la méthodologie TIBER-EU. Incluez : Phase 1 - Préparation : définition de la portée (fonctions critiques et importantes à tester sur les systèmes de production en direct), engagement et notification de l'autorité compétente, sélection du fournisseur de renseignement sur les menaces, sélection du fournisseur de l'équipe rouge (red team), formation de l'équipe blanche (équipe interne au courant du test), approbations de gouvernance interne. Phase 2 - Renseignement sur les menaces : rapport de renseignement sur les menaces (analyse ciblée du paysage des menaces), scénarios de menace basés sur les acteurs et techniques de menace actuels, analyse de la surface d'attaque, et examen des scénarios de menace par l'autorité compétente. Phase 3 - Test de l'équipe rouge : engagement de l'équipe rouge (attaques simulées sur les systèmes de production en direct), exécution du test sur [durée typique : 8-12 semaines], tests contrôlés avec mécanismes de sécurité, activités d'équipe violette (purple team) si convenu, et documentation des conclusions. Phase 4 - Clôture : rapport de l'équipe rouge avec conclusions et preuves, évaluation de la réponse de l'équipe bleue, élaboration du plan de remédiation, briefing de l'organe de direction, processus d'attestation par l'autorité compétente. Fournissez des estimations de délais et des besoins en ressources pour chaque phase. »

Sélection des prestataires TLPT

Le TLPT nécessite à la fois un fournisseur de renseignement sur les menaces et un fournisseur d'équipe rouge. Utilisez ISMS Copilot pour élaborer les critères de sélection :

« Créez un cadre de sélection des prestataires TLPT pour les articles 26-27 de DORA. Pour le fournisseur de renseignement sur les menaces : qualifications requises (expertise en menaces financières spécifiques au secteur, certifications reconnues), critères d'évaluation (qualité des rapports de menaces précédents, compréhension des menaces du secteur financier de l'UE, sources de données et capacités de collecte), et liste de contrôle de sélection. Pour le fournisseur de l'équipe rouge : qualifications requises (accréditation CREST, CBEST ou équivalent, expérience des tests TIBER-EU, expérience du secteur financier), critères d'évaluation (capacités techniques, méthodologie, composition de l'équipe, antécédents de sécurité), vérification de l'indépendance (aucune relation de conseil actuelle avec l'entité), exigences d'assurance, et liste de contrôle de sélection. Fournissez un modèle d'appel d'offres (RFP) pour les deux types de fournisseurs. »

Définition de la portée du TLPT

Une définition appropriée de la portée est essentielle pour la réussite d'un TLPT. Utilisez ISMS Copilot pour définir la portée des tests :

« Aidez-nous à définir la portée de notre exercice TLPT DORA. Nos fonctions critiques et importantes incluent : [liste des fonctions]. Pour chaque fonction critique, identifiez : les systèmes et l'infrastructure TIC de soutien qui devraient être inclus dans la portée, les flux de données et intégrations qui pourraient constituer des chemins d'attaque, les fournisseurs tiers de TIC qui soutiennent la fonction (et s'ils doivent être inclus dans les tests selon l'article 26(3)), les surfaces d'attaque potentielles (externes, internes, physiques, ingénierie sociale), et les systèmes qui devraient être explicitement exclus pour des raisons de sécurité. Produisez un document de portée TLPT apte à être examiné par l'autorité compétente. »

Étape 4 : Reporting des résultats et suivi de la remédiation

Reporting des résultats des tests à la direction

DORA exige que les résultats des tests soient communiqués à l'organe de direction et utilisés pour mettre à jour le cadre de gestion des risques TIC :

1. Générez des modèles de rapport de résultats de test :

   « Créez un modèle de rapport de résultats de test de résilience pour le reporting à l'organe de direction sous l'article 24 de DORA. Incluez : un résumé exécutif (posture de résilience globale, conclusions clés, comparaison des tendances), un résumé de l'exécution du programme de tests (tests effectués, portée, calendrier), les conclusions par sévérité (critique, élevée, moyenne, faible) avec le contexte de l'impact métier, la comparaison avec les cycles de tests précédents (amélioration ou dégradation), l'état de remédiation des vulnérabilités précédemment identifiées, les nouvelles recommandations de remédiation avec hiérarchisation basée sur le risque, l'évaluation de l'efficacité du programme de tests, l'utilisation du budget et des ressources, et les recommandations d'ajustement du programme de tests. Le rapport doit être adapté aux membres non techniques du conseil d'administration tout en conservant suffisamment de détails pour la surveillance des risques. »

2. Créez la documentation d'attestation TLPT :

   « Créez un ensemble de documentation d'attestation TLPT pour soumission à notre autorité compétente conformément à l'article 26(6) de DORA. Incluez : un rapport de synthèse TLPT (portée, méthodologie, calendrier), les conclusions de l'équipe rouge anonymisées (sévérité critique et élevée), le plan de remédiation avec calendrier et état d'avancement, l'accusé de réception et l'approbation de l'organe de direction, les leçons apprises par l'organisation, et toute demande de reconnaissance mutuelle avec d'autres autorités compétentes. Suivez les directives de format de [autorité compétente] et du cadre TIBER-EU. »

Suivi de la remédiation

Les tests n'ont de valeur que si les conclusions mènent à des améliorations. Établissez un suivi de remédiation robuste :

« Créez une procédure de suivi de la remédiation des tests de résilience pour la conformité à DORA. Incluez : comment les conclusions sont traduites en actions de remédiation, la méthodologie de hiérarchisation (critique : remédiation sous 30 jours, élevée : 60 jours, moyenne : 90 jours, faible : prochain cycle de tests), l'attribution de la responsabilité de remédiation, le suivi des progrès et l'escalade pour les remédiations en retard, les tests de vérification (confirmation de l'efficacité des correctifs), le processus d'exception pour les conclusions ne pouvant être corrigées (contrôles compensatoires, acceptation du risque avec approbation de l'organe de direction), l'intégration au registre des risques TIC (mise à jour des évaluations de risques basées sur les conclusions des tests), et la cadence de reporting à l'organe de direction. Fournissez un modèle de registre de suivi des remédiations. »

Étape 5 : Intégrer les tests à votre cadre de gestion des risques TIC

Alimenter la gestion des risques avec les résultats

DORA exige que les résultats des tests informent et mettent à jour votre cadre de gestion des risques TIC. Utilisez ISMS Copilot pour formaliser cette intégration :

« Définissez comment les résultats des tests de résilience s'intègrent à notre cadre de gestion des risques TIC DORA. Incluez : comment les conclusions des tests mettent à jour le registre des risques TIC (nouveaux risques identifiés, notations de risque ajustées, efficacité des contrôles réévaluée), comment les résultats des tests alimentent la revue annuelle du cadre de gestion des risques TIC selon l'article 6(5), comment les résultats du TLPT influencent notre stratégie de risque TIC et notre appétence au risque, comment les résultats des tests basés sur des scénarios mettent à jour nos plans de continuité d'activité et de reprise après sinistre, comment les tendances des évaluations de vulnérabilités informent nos mesures de protection et de prévention selon l'article 9, et comment les résultats de simulation d'incidents valident ou remettent en question nos procédures de classification et de reporting d'incidents. Fournissez un flux de processus montrant la boucle de rétroaction entre les tests et la gestion des risques. »

Amélioration continue des tests

Votre programme de tests lui-même doit évoluer en fonction des résultats et de l'évolution des menaces :

« Créez un processus de révision annuelle du programme de tests pour la conformité à DORA. La révision doit évaluer : la couverture des tests (avons-nous testé tous les systèmes et fonctions critiques comme prévu ?), l'efficacité des tests (les tests ont-ils identifié des vulnérabilités réelles ? comment les conclusions se comparent-elles aux incidents réels ?), l'efficience des tests (utilisons-nous les ressources efficacement ? y a-t-il des tests redondants ?), les changements dans le paysage des menaces (nos scénarios de test reflètent-ils les menaces actuelles ?), les nouveaux systèmes ou services ajoutés depuis la dernière révision (sont-ils inclus dans la portée des tests ?), les retours ou conseils réglementaires sur les attentes en matière de tests, et les ajustements recommandés du programme pour le prochain cycle. Produisez un modèle de rapport de révision annuelle du programme de tests pour approbation par l'organe de direction. »

Étape 6 : Gérer la logistique et la gouvernance des tests

Calendrier de test et coordination

Établissez un calendrier annuel de tests structuré pour garantir que toutes les activités de test sont planifiées, dotées de ressources et coordonnées :

« Créez un calendrier annuel de tests de résilience pour notre [type d'entité]. Cartographiez toutes les activités de test requises sur l'année : scans de vulnérabilités (trimestriels pour le critique, mensuels pour ce qui est exposé sur internet), tests de pénétration (annuel externe, annuel interne, annuel applicatif), exercices basés sur des scénarios (tabletop semestriel, simulation annuelle), tests de continuité d'activité (basculement annuel, restauration de sauvegarde annuelle) et activités de préparation au TLPT (le cas échéant). Incluez : les besoins en ressources pour chaque activité, les exigences de coordination (fenêtres de gel des changements, implication des unités métiers), les dépendances entre les activités de test, l'allocation budgétaire par trimestre et les étapes de reporting à l'organe de direction. Présentez sous forme de vue calendrier avec une structure de diagramme de Gantt. »

Tests des fournisseurs tiers de TIC

L'article 26(3) traite des tests impliquant des prestataires tiers de services TIC. Coordonnez les exigences de test avec vos fournisseurs :

« Créez des procédures pour coordonner les tests de résilience avec les fournisseurs tiers de TIC sous DORA. Incluez : les exigences contractuelles pour la participation des fournisseurs aux tests (lien avec les clauses contractuelles de l'article 28), les procédures de notification et de coordination des fournisseurs, les tests de responsabilité partagée (ce que nous testons vs ce que le fournisseur teste), la gestion du refus d'un fournisseur de participer aux tests, les approches de test alternatives lorsque le test direct du fournisseur n'est pas possible (tests synthétiques, rapports de test fournis par le fournisseur), le TLPT impliquant les systèmes de fournisseurs tiers (dispositifs de tests groupés selon l'article 26(3)), et la collecte de preuves issues des activités de test du fournisseur. Traitez les scénarios pour les fournisseurs cloud, les fournisseurs de services managés et les fournisseurs d'infrastructures critiques. »

Prochaines étapes

Vous disposez maintenant d'un programme complet de tests de résilience opérationnelle numérique :

• Un cadre de programme de tests avec une méthodologie basée sur le risque

• Des plans détaillés pour les évaluations de vulnérabilités, les tests d'intrusion et les tests basés sur des scénarios

• Des exigences de qualification et d'indépendance des testeurs

• Un cadre de préparation au TLPT (si vous êtes désigné ou susceptible de l'être)

• Des modèles de reporting des résultats pour l'organe de direction et l'autorité compétente

• Des procédures de suivi de la remédiation

• L'intégration avec le cadre de gestion des risques TIC

Continuez avec le dernier guide de cette série DORA :

• Comment gérer le risque tiers TIC DORA à l'aide de l'IA -- Assurez-vous que vos fournisseurs tiers sont inclus dans votre programme de tests et que les contrats soutiennent vos obligations de test

Pour la configuration de base, voir Comment débuter la mise en œuvre de DORA à l'aide de l'IA. Pour le cadre de gestion des risques TIC, voir Comment construire un cadre de gestion des risques TIC DORA à l'aide de l'IA. Pour l'intégration du reporting d'incidents, voir Comment mettre en œuvre le reporting d'incidents DORA à l'aide de l'IA.

Pour des prompts prêts à l'emploi, consultez la Bibliothèque de prompts de conformité DORA. Pour l'aperçu réglementaire complet, reportez-vous au Guide de conformité DORA pour les entités financières.

Obtenir de l'aide

Pour un soutien supplémentaire lors de la planification de votre programme de tests de résilience :

• Demandez à ISMS Copilot : Utilisez votre espace de travail DORA pour générer des scénarios de test spécifiques à votre type d'entité et à votre environnement TIC

• Mettez en ligne vos rapports de test existants : Obtenez une analyse des écarts en téléchargeant vos précédents rapports de tests d'intrusion ou d'évaluation de vulnérabilités pour les comparer aux exigences de DORA

• Préparation au TLPT : Utilisez ISMS Copilot pour élaborer votre document de portée TLPT et vos critères de sélection de fournisseurs avant d'engager le dialogue avec votre autorité compétente

• Validez les résultats : Examinez tous les plans de test par rapport aux articles 24-27 de DORA, aux RTS pertinents et au cadre TIBER-EU avant approbation par l'organe de direction