Comment planifier les tests de résilience DORA en utilisant l'IA

Aperçu

Vous apprendrez à concevoir et mettre en œuvre un programme de tests de résilience opérationnelle numérique qui satisfait les Articles 24-27 de DORA en utilisant l'IA. Ce guide couvre le programme de tests général (évaluations de vulnérabilités, tests d'intrusion, tests basés sur des scénarios), les exigences avancées de Threat-Led Penetration Testing (TLPT), la portée et la fréquence des tests, la communication des résultats à votre organe de gestion, et l'intégration des tests avec votre cadre de gestion des risques ICT, avec des invites ISMS Copilot spécifiques pour générer chaque composant.

À qui s'adresse ce guide

Ce guide est destiné à :

• Les RSSI et responsables de la sécurité chargés de concevoir et de superviser les programmes de tests de résilience
• Les gestionnaires de risques IT intégrant les résultats des tests dans les évaluations des risques ICT
• Les coordinateurs de tests d'intrusion gérant les activités de test internes et externes
• Les responsables de la conformité veillant à ce que les programmes de tests répondent aux attentes réglementaires
• Les consultants aidant les entités financières à se préparer pour le TLPT ou les 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 ICT et votre inventaire des actifs ICT issus de Comment construire un cadre de gestion des risques ICT DORA en utilisant l'IA
• Vos procédures de classification et de réponse aux incidents issues de Comment mettre en œuvre le reporting des incidents DORA en utilisant 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)
• La connaissance de 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 test externes (en particulier pour le TLPT)

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

Analyse article par article

Le chapitre IV de DORA (Articles 24-27) établit une approche structurée pour les 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 ICT, approche basée sur les risques

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

Art 25

Tests des outils et systèmes ICT

Types de tests spécifiques : évaluations de vulnérabilités, tests d'intrusion, tests basés sur des scénarios, tests de compatibilité, tests de performance, revues de code source

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

Art 26

Tests avancés via TLPT

Tests d'intrusion basés sur les menaces selon le cadre TIBER-EU, tous les 3 ans

Uniquement les entités désignées

Art 27

Exigences pour les 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

Uniquement les entités désignées

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

Fréquence

Basée sur les risques ; les systèmes critiques au moins annuellement

Au moins tous les 3 ans

Le TLPT est moins fréquent mais beaucoup plus intensif

Portée

Tous les systèmes ICT (proportionné)

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

Le TLPT teste les systèmes en direct, pas seulement les environnements de test

Méthodologie

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

Cadre TIBER-EU, basé sur le renseignement sur les menaces

Le TLPT simule les tactiques d'adversaires réels

Testeurs

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

Testeurs externes requis (avec exceptions limitées)

Le TLPT nécessite une équipe rouge externe certifiée

Reporting

Interne (organe de gestion, fonction de risque ICT)

À 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 qui soit intégré à votre cadre de gestion des risques ICT, suive une approche basée sur les risques et soit 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éer un Programme de Tests de Résilience Opérationnelle Numérique pour un [type d'entité] satisfaisant les Articles 24-25 de DORA. Inclure : l'objectif et les objectifs du programme, la gouvernance (surveillance par l'organe de gestion, responsable du programme, rôles et responsabilités), l'approche basée sur les risques 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 à l'inventaire des actifs ICT et aux fonctions critiques/importantes), les types de tests à effectuer (évaluations de vulnérabilités, tests de sécurité réseau, tests d'intrusion, 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é des actifs et type de test, les exigences pour les testeurs internes vs externes, les exigences d'indépendance selon l'Article 27, la communication des résultats et la transmission à l'organe de gestion, le processus de suivi des corrections, l'intégration avec les mises à jour du cadre de gestion des risques ICT, un modèle de calendrier de tests annuels, et la planification budgétaire et des ressources. Appliquer la proportionnalité pour une organisation de [taille d'entité]."

3. Définir la méthodologie de tests basée sur les risques :

   "Créer une méthodologie de tests basée sur les risques pour les tests de résilience DORA. Définir comment nous déterminons : quels systèmes et fonctions tester (en fonction de la criticité des actifs ICT, de l'impact sur l'activité, du paysage des menaces, des incidents précédents), quel type de test appliquer (scan de vulnérabilités vs test d'intrusion vs test basé sur des scénarios), 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. Fournir une matrice de priorité des tests qui mappe la criticité des actifs et le niveau de menace au type et à la fréquence des tests. Inclure des exemples pour un [type d'entité]."

Types de tests et leur application

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

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

   "Créer un programme d'évaluation des vulnérabilités pour la conformité à l'Article 25 de DORA. Inclure : la portée des scans (tous les actifs ICT par niveau de criticité), les outils et la méthodologie de scan, la fréquence des scans (au moins trimestrielle pour les actifs critiques, mensuelle recommandée), la classification des vulnérabilités alignée sur le scoring CVSS, les délais de correction par sévérité (critique : 48 heures, élevé : 7 jours, moyen : 30 jours, faible : 90 jours), le processus de gestion des exceptions pour les vulnérabilités qui ne peuvent pas être corrigées immédiatement, le format de rapport (rapport technique et résumé pour la direction), la méthodologie d'analyse des tendances, et l'intégration avec les procédures de gestion des correctifs. Fournir un workflow de gestion des vulnérabilités."

2. Programme de tests d'intrusion :

   "Créer un programme de tests d'intrusion pour la conformité à l'Article 25 de DORA. Inclure : la portée des tests (périmètre externe, réseau interne, applications web, applications mobiles, sécurité des 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, timing, 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 rapport (résumé exécutif, conclusions techniques, évaluations des risques, recommandations de correction), les procédures post-test (vérification des corrections, re-test), et le format de rapport pour l'organe de gestion. Fournir un exemple de modèle de règles d'engagement."

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

   "Concevoir un programme de tests de résilience basés sur des scénarios pour l'Article 25 de DORA. Créer des scénarios de test couvrant : une attaque par 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 des transactions, une menace interne compromettant des données sensibles, une attaque de la chaîne d'approvisionnement via un fournisseur ICT tiers critique, une défaillance simultanée des systèmes principaux et de secours, la perte de personnel ICT clé pendant un incident, une violation de données réglementaires nécessitant une notification aux clients. Pour chaque scénario, définir : 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 leurs rôles, les procédures d'exécution du test, les résultats attendus, les critères d'évaluation, et un modèle de rapport. Inclure à la fois les formats d'exercice sur table et de simulation."

Étape 2 : Établir les exigences pour les 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 aux testeurs internes et externes :

"Créer une politique d'exigences et de qualifications pour les testeurs selon l'Article 27 de DORA. Aborder : les testeurs internes (indépendance par rapport aux zones testées, certifications pertinentes telles que OSCP/CREST/GPEN, compétence maintenue, 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 vérification et de habilitation de sécurité des testeurs, les exigences de non-divulgation et de confidentialité, et les critères d'évaluation des performances des testeurs. Fournir une liste de contrôle des qualifications pour les testeurs internes et externes, ainsi qu'un exemple de déclaration de travail pour les engagements de test externes."

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

Comprendre les exigences du TLPT

Le Threat-Led Penetration Testing (TLPT) selon 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 les exigences est précieux pour la préparation.

1. Évaluer l'applicabilité du TLPT :

   "Évaluer si notre [type d'entité] avec [taille, importance systémique, profil de risque ICT] est susceptible d'être désigné pour le TLPT DORA selon l'Article 26. Considérer : notre importance systémique dans le secteur financier, la criticité des services que nous fournissons, notre profil de risque ICT 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, fournir une évaluation de préparation au TLPT et un calendrier de préparation. Si elle est improbable, recommander les mesures préparatoires que nous devrions prendre malgré tout."

2. Générer le cadre TLPT :

   "Créer un cadre de préparation et d'exécution du TLPT pour l'Article 26 de DORA, aligné sur la méthodologie TIBER-EU. Inclure : 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, formation de l'équipe blanche (équipe interne informée 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 revue des scénarios de menace par l'autorité compétente. Phase 3 - Tests de l'équipe rouge : engagement de l'équipe rouge (attaques simulées sur les systèmes de production en direct), exécution des tests sur [durée typique : 8-12 semaines], tests contrôlés avec mécanismes de sécurité, activités de l'équipe violette (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, développement du plan de correction, briefing de l'organe de gestion, processus d'attestation par l'autorité compétente. Fournir des estimations de calendrier et des exigences en ressources pour chaque phase."

Sélection des fournisseurs pour le TLPT

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

"Créer un cadre de sélection des fournisseurs pour le TLPT selon 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 menace 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 d'Équipe Rouge : qualifications requises (accréditation CREST, CBEST, ou équivalent, expérience avec les tests TIBER-EU, expérience dans le secteur financier), critères d'évaluation (capacités techniques, méthodologie, composition de l'équipe, historique de sécurité), vérification de l'indépendance (aucune relation de conseil actuelle avec l'entité), exigences en matière d'assurance, et liste de contrôle de sélection. Fournir un modèle de RFP pour les deux types de fournisseurs."

Définition de la portée du TLPT

Une définition précise de la portée est cruciale pour la réussite du 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, identifier : les systèmes et infrastructures ICT 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 ICT tiers qui soutiennent la fonction (et s'ils doivent être inclus dans les tests selon l'Article 26(3)), les surfaces d'attaque potentielles (externe, interne, physique, ingénierie sociale), et les systèmes qui devraient être explicitement exclus pour des raisons de sécurité. Produire un document de portée TLPT adapté à la revue par l'autorité compétente."

Étape 4 : Reporting des résultats et suivi des corrections

Communication des résultats des tests à la direction

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

1. Générer des modèles de rapports de résultats de tests :

   "Créer un modèle de rapport de résultats de tests de résilience pour le reporting à l'organe de gestion selon l'Article 24 de DORA. Inclure : un résumé exécutif (posture globale de résilience, principales conclusions, comparaison des tendances), un résumé de l'exécution du programme de tests (tests réalisés, portée, timing), les conclusions par sévérité (critique, élevé, moyen, faible) avec le contexte de l'impact sur l'activité, la comparaison avec les cycles de tests précédents (amélioration ou dégradation), l'état des corrections pour les vulnérabilités précédemment identifiées, les nouvelles recommandations de correction avec une priorisation basée sur les risques, une évaluation de l'efficacité du programme de tests, l'utilisation du budget et des ressources, et des recommandations pour les ajustements du programme de tests. Le rapport doit être adapté aux membres non techniques du conseil d'administration tout en maintenant un niveau de détail suffisant pour la supervision des risques."

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

   "Créer un dossier de documentation d'attestation TLPT pour soumission à notre autorité compétente selon l'Article 26(6) de DORA. Inclure : un rapport sommaire TLPT (portée, méthodologie, calendrier), les conclusions anonymisées de l'équipe rouge (sévérité critique et élevée), le plan de correction avec calendrier et statut, l'accusé de réception et l'approbation de l'organe de gestion, les leçons organisationnelles apprises, et toute demande de reconnaissance mutuelle avec d'autres autorités compétentes. Suivre le format des directives de [autorité compétente] et du cadre TIBER-EU."

Suivi des corrections

Les tests ne sont utiles que si les conclusions mènent à des améliorations. Établissez un suivi rigoureux des corrections :

"Créer une procédure de suivi des corrections des tests de résilience pour la conformité à DORA. Inclure : comment les conclusions sont traduites en actions de correction, la méthodologie de priorisation (critique : corriger dans les 30 jours, élevé : 60 jours, moyen : 90 jours, faible : prochain cycle de tests), l'affectation et la responsabilisation des propriétaires de corrections, le suivi des progrès et l'escalade pour les corrections en retard, les tests de vérification (confirmation de l'efficacité des corrections), le processus d'exception pour les conclusions qui ne peuvent pas être corrigées (contrôles compensatoires, acceptation des risques avec approbation de l'organe de gestion), l'intégration avec le registre des risques ICT (mise à jour des évaluations des risques en fonction des conclusions des tests), et la cadence de reporting à l'organe de gestion. Fournir un modèle de registre de suivi des corrections."

Étape 5 : Intégrer les tests avec votre cadre de gestion des risques ICT

Intégration des résultats dans la gestion des risques

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

"Définir comment les résultats des tests de résilience s'intègrent à notre cadre de gestion des risques ICT DORA. Inclure : comment les conclusions des tests mettent à jour le registre des risques ICT (nouveaux risques identifiés, ajustements des évaluations des risques, réévaluation de l'efficacité des contrôles), comment les résultats des tests informent la revue annuelle du cadre de gestion des risques ICT selon l'Article 6(5), comment les résultats du TLPT influencent notre stratégie de risque ICT et notre appétence pour le 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 des simulations d'incidents valident ou remettent en question nos procédures de classification et de reporting des incidents. Fournir 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 des menaces changeantes :

"Créer un processus de revue annuelle du programme de tests pour la conformité à DORA. La revue 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é de réelles vulnérabilités ? comment les conclusions se comparent-elles aux incidents réels ?), l'efficience des tests (utilisons-nous les ressources de manière efficace ? y a-t-il des tests redondants ou qui se chevauchent ?), 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 revue (sont-ils inclus dans la portée des tests ?), les retours ou orientations réglementaires sur les attentes en matière de tests, et les ajustements recommandés pour le programme pour le prochain cycle. Produire un modèle de rapport de revue annuelle du programme de tests pour approbation par l'organe de gestion."

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

Calendrier et coordination des tests

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

"Créer un calendrier annuel des tests de résilience pour notre [type d'entité]. Cartographier toutes les activités de test requises au cours de l'année : scans de vulnérabilités (trimestriels pour les actifs critiques, mensuels pour les actifs exposés sur Internet), tests d'intrusion (annuels externes, annuels internes, annuels pour les applications), exercices basés sur des scénarios (semestriels sur table, annuels en simulation), tests de continuité d'activité (annuels de basculement, annuels de restauration des sauvegardes), et activités de préparation au TLPT (si applicable). Inclure : les exigences en ressources pour chaque activité, les exigences de coordination (fenêtres de gel des changements, implication des unités commerciales), les dépendances entre les activités de test, l'allocation budgétaire par trimestre, et les jalons de reporting à l'organe de gestion. Présenter sous forme de calendrier avec une structure de diagramme de Gantt."

Tests des fournisseurs ICT tiers

L'Article 26(3) aborde les tests impliquant des fournisseurs de services ICT tiers. Coordonnez les exigences de test avec vos fournisseurs :

"Créer des procédures pour coordonner les tests de résilience avec les fournisseurs ICT tiers selon DORA. Inclure : 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 avec les fournisseurs, les tests de responsabilité partagée (ce que nous testons vs ce que le fournisseur teste), la gestion des refus de participation aux tests de la part du fournisseur, les approches alternatives de test 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 des fournisseurs tiers (Article 26(3) arrangements de tests groupés), et la collecte de preuves des activités de test des fournisseurs. Aborder les scénarios pour les fournisseurs de 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 :

• Cadre du programme de tests avec une méthodologie basée sur les risques
• Plans détaillés pour les évaluations de vulnérabilités, les tests d'intrusion et les tests basés sur des scénarios
• Exigences de qualification et d'indépendance des testeurs
• Cadre de préparation au TLPT (si désigné ou susceptible de l'être)
• Modèles de reporting des résultats pour l'organe de gestion et l'autorité compétente
• Procédures de suivi des corrections
• Intégration avec le cadre de gestion des risques ICT

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

• Comment gérer le risque ICT tiers DORA en utilisant 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émarrer la mise en œuvre de DORA en utilisant l'IA. Pour le cadre de gestion des risques ICT, voir Comment construire un cadre de gestion des risques ICT DORA en utilisant l'IA. Pour l'intégration du reporting des incidents, voir Comment mettre en œuvre le reporting des incidents DORA en utilisant l'IA.

Pour des invites prêtes à l'emploi, consultez la DORA Compliance Prompt Library. Pour un aperçu réglementaire complet, reportez-vous au DORA Compliance Guide for Financial Entities.

Obtenir de l'aide

Pour un soutien supplémentaire dans 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 ICT
• Téléchargez des rapports de test existants : Obtenez une analyse des écarts en téléchargeant des rapports précédents 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 développer votre document de portée TLPT et vos critères de sélection des fournisseurs avant de vous engager avec votre autorité compétente
• Validez les sorties : Passez en revue tous les plans de test par rapport aux Articles 24-27 de DORA, aux RTS pertinents et au cadre TIBER-EU avant l'approbation par l'organe de gestion