Éléments probants DORA TLPT alignés sur les contrôles ISO 27001

Il est 07 h 40 un lundi matin, et le RSSI d’un établissement de paiement de taille intermédiaire examine trois formulations de la même question inconfortable.

Le conseil d’administration veut savoir si l’organisation peut survivre à l’indisponibilité de son portail de paiement client provoquée par un rançongiciel. L’autorité de régulation veut des éléments démontrant que les tests de résilience opérationnelle numérique ne sont pas un exercice PowerPoint. L’audit interne veut une piste claire reliant les obligations DORA au risque TIC, aux contrôles ISO 27001, aux résultats de test, aux plans de remédiation, aux éléments probants fournisseur et à la validation formelle de la direction.

Le RSSI dispose d’un rapport Red Team. Le SOC dispose de captures d’écran d’alertes. L’infrastructure dispose d’un journal de restauration de sauvegarde. Le juridique dispose d’un outil de suivi de la préparation à DORA. Les achats disposent d’attestations du fournisseur cloud.

Rien n’est relié.

C’est à ce stade que de nombreux programmes DORA TLPT et de tests de résilience échouent. Non pas parce que les tests sont faibles, mais parce que les éléments probants sont fragmentés. Lorsqu’un auditeur demande : « Montrez-moi comment ce test prouve la résilience d’une fonction critique ou importante », la réponse ne peut pas être un dossier rempli de captures d’écran. Elle doit être une chaîne d’éléments probants défendable.

Cette chaîne est précisément le point où un SMSI aligné sur ISO/IEC 27001:2022 ISO/IEC 27001:2022 devient déterminant. ISO 27001 structure le périmètre, l’appréciation des risques, la sélection des contrôles, la Déclaration d’applicabilité, la maîtrise opérationnelle, l’audit interne, la revue de direction et l’amélioration continue. DORA apporte l’exigence sectorielle. La méthodologie de Clarysec et ses outils de conformité croisée relient les deux dans un modèle unique d’éléments probants auditables.

DORA TLPT est un test de gouvernance, pas seulement une simulation d’attaque

Les tests d’intrusion fondés sur la menace, ou TLPT, sont faciles à mal interpréter. Sur le plan technique, ils peuvent ressembler à un exercice de red teaming sophistiqué : renseignement sur les menaces, chemins d’attaque réalistes, furtivité, tentatives d’exploitation, scénarios de mouvement latéral et validation de la réponse de la Blue Team.

Pour DORA, l’enjeu de fond est la résilience opérationnelle numérique. L’entité financière peut-elle résister à une perturbation TIC grave affectant des processus opérationnels, y répondre et s’en rétablir ? Peut-elle prouver que les fonctions critiques ou importantes restent dans les tolérances d’impact ? La direction peut-elle démontrer que le risque TIC est gouverné, financé, testé, remédié et amélioré ?

DORA Article 1 établit un cadre uniforme de l’UE pour la sécurité des réseaux et des systèmes d’information qui soutiennent les processus opérationnels des entités financières. Il couvre la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique, la gestion des risques liés aux prestataires tiers de services TIC, les exigences contractuelles obligatoires applicables aux fournisseurs TIC, la supervision des prestataires tiers critiques de services TIC et la coopération prudentielle. DORA s’applique à compter du 17 janvier 2025.

Pour les organisations également couvertes par NIS2, DORA constitue l’acte juridique sectoriel de l’Union pour les exigences de cybersécurité qui se recoupent. En pratique, les entités financières doivent prioriser DORA pour la gestion des risques liés aux TIC, la notification des incidents, les tests et les risques liés aux prestataires tiers de services TIC lorsque les régimes se chevauchent, tout en comprenant les attentes de NIS2 concernant les structures de groupe, les fournisseurs et les services numériques non financiers.

DORA place également la responsabilité au plus haut niveau. Article 5 impose à l’organe de direction de définir, approuver, superviser et mettre en œuvre les dispositifs de gestion des risques liés aux TIC. Cela inclut la stratégie de résilience opérationnelle numérique, la politique de continuité d’activité TIC, les plans de réponse et de rétablissement, les plans d’audit, les budgets, les politiques relatives aux prestataires tiers de services TIC, les canaux de notification et une connaissance suffisante des risques liés aux TIC grâce à des formations régulières.

La question d’audit n’est donc pas simplement : « Avez-vous réalisé un TLPT ? »

Elle est la suivante :

• Le TLPT était-il relié à des fonctions critiques ou importantes ?
• Était-il autorisé, cadré, sécurisé et soumis à une appréciation des risques ?
• Les fournisseurs, les dépendances cloud et les services TIC externalisés ont-ils été inclus lorsque cela était pertinent ?
• Le test a-t-il produit des éléments probants relatifs à la détection, à la réponse, au rétablissement et aux enseignements tirés ?
• Les constats ont-ils été convertis en traitement des risques, remédiation suivie, retests et reporting de direction ?
• La Déclaration d’applicabilité explique-t-elle quels contrôles de l’Annexe A ISO 27001 ont été sélectionnés pour gérer le risque ?

C’est pourquoi Clarysec traite les éléments probants DORA TLPT comme un sujet d’éléments probants du SMSI, et non uniquement comme un livrable de tests d’intrusion.

Construire l’ossature des éléments probants ISO 27001 avant le début du test

ISO 27001 exige qu’une organisation établisse, mette en œuvre, maintienne et améliore en continu un SMSI qui préserve la confidentialité, l’intégrité et la disponibilité au moyen d’un processus de gestion des risques. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les parties intéressées, les obligations légales et réglementaires, les interfaces, les dépendances, puis documente le domaine d’application du SMSI.

Pour une entité réglementée par DORA, cette étape de définition du périmètre doit explicitement couvrir les fonctions critiques ou importantes, les actifs TIC, les plateformes cloud, les opérations externalisées, les systèmes de paiement, les portails clients, les services d’identité, les plateformes de journalisation, les environnements de reprise et les prestataires tiers de services TIC. Si le périmètre TLPT ne se rattache pas au domaine d’application du SMSI, la piste d’audit est déjà fragile.

Les clauses ISO 27001 6.1.1, 6.1.2 et 6.1.3, ainsi que les clauses 8.2 et 8.3, exigent un processus d’appréciation des risques et de traitement des risques. Les risques doivent être identifiés au regard de la confidentialité, de l’intégrité et de la disponibilité. Des propriétaires de risques doivent être désignés. La vraisemblance et les conséquences doivent être évaluées. Les contrôles doivent être sélectionnés et comparés à l’Annexe A. Le risque résiduel doit être accepté par les propriétaires de risques.

C’est le pont entre DORA et des tests auditables.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint, dans la phase de gestion des risques, étape 13, décrit clairement ce rôle de traçabilité :

La SoA est effectivement un document passerelle : elle relie votre appréciation/traitement des risques aux contrôles réellement en place. En la complétant, vous vérifiez également si des contrôles ont été oubliés.

Pour DORA TLPT, la Déclaration d’applicabilité ne doit pas être un livrable statique de certification. Elle doit expliquer pourquoi des contrôles tels que la sécurité des fournisseurs, la gestion des incidents, l’aptitude TIC à la continuité d’activité, la journalisation, la surveillance, la gestion technique des vulnérabilités, les sauvegardes, le développement sécurisé et les tests de sécurité sont applicables au scénario de résilience.

Un scénario de risque pratique pourrait être formulé ainsi :

« La compromission d’identifiants à privilèges du fournisseur d’identité permet à un attaquant d’accéder aux systèmes d’administration du traitement des paiements, de modifier les configurations de routage et de perturber une fonction de paiement critique, entraînant une interruption de service, des obligations de notification réglementaire, un préjudice client et une atteinte à la réputation. »

Ce scénario unique peut orienter le périmètre TLPT, les cas d’usage de détection, la participation des fournisseurs, l’exercice de reprise, le reporting au conseil d’administration et l’ensemble des éléments probants.

Le Zenith Blueprint recommande également de rendre explicite la traçabilité réglementaire :

Référencer les réglementations de manière croisée : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez le noter soit dans le registre des risques (dans la justification de l’impact du risque), soit dans les notes de la SoA.

Ce conseil est simple, mais il modifie l’échange avec l’auditeur. Au lieu de dire qu’elle a pris DORA en compte, l’organisation peut montrer où DORA apparaît dans le registre des risques, la SoA, le programme de tests, le référentiel de politiques et la revue de direction.

Rattacher les tests DORA aux contrôles ISO 27001 reconnus par les auditeurs

DORA Article 6 attend un cadre documenté de gestion des risques liés aux TIC, intégré à la gestion globale des risques. L’Annexe A ISO 27001 fournit le catalogue de contrôles qui rend cette exigence opérationnelle.

Pour DORA TLPT et les tests de résilience, les contrôles de l’Annexe A ISO/IEC 27001:2022 suivants sont particulièrement importants :

Le Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls aide les organisations à éviter de traiter ces contrôles comme des éléments de checklist isolés. Il cartographie les contrôles ISO/IEC 27002:2022 avec les attributs, domaines, capacités opérationnelles, attentes d’audit et modèles de conformité croisée.

Par exemple, Zenith Controls classe le contrôle ISO/IEC 27002:2022 5.30, aptitude TIC à la continuité d’activité, comme « correctif », aligné sur la « disponibilité », associé au concept de cybersécurité « répondre » et placé dans le domaine « résilience ». Cette classification est utile pour expliquer aux auditeurs pourquoi un exercice de reprise n’est pas une simple opération informatique, mais un contrôle de résilience ayant un rôle défini dans l’environnement de contrôle.

Zenith Controls classe également le contrôle 8.29, tests de sécurité en développement et en acceptation, comme un contrôle préventif soutenant la confidentialité, l’intégrité et la disponibilité, avec des capacités opérationnelles en sécurité des applications, assurance de la sécurité de l’information et sécurité des systèmes et réseaux. Pour les constats TLPT qui remontent à une faiblesse de conception applicative, un comportement non sécurisé d’API, un flux d’authentification insuffisant ou une validation inadéquate, c’est la voie de contrôle vers la gouvernance du développement sécurisé.

Le contrôle 5.35, revue indépendante de la sécurité de l’information, est également important. Il soutient la revue contradictoire indépendante, l’assurance de gouvernance et l’amélioration corrective. Les équipes internes peuvent coordonner les tests, mais des éléments probants auditables exigent une revue, une escalade et une supervision au-delà des personnes qui ont construit ou exploité les systèmes testés.

Protéger le système pendant qu’il est testé

Une hypothèse dangereuse dans les tests de résilience consiste à considérer que tester est automatiquement bénéfique. En réalité, des tests intrusifs peuvent provoquer des interruptions de service, exposer des données sensibles, polluer les journaux, déclencher des défenses automatisées, interrompre des sessions clients ou amener des fournisseurs à activer des procédures d’urgence.

La Security Testing and Red-Teaming Policy de Clarysec Security Testing and Red-Teaming Policy fournit aux organisations un modèle de gouvernance pour une exécution sûre. La clause 6.1 indique :

Types de tests : le programme de tests de sécurité doit inclure, au minimum : (a) le scan des vulnérabilités, consistant en scans automatisés hebdomadaires ou mensuels des réseaux et applications afin d’identifier les vulnérabilités connues ; (b) les tests d’intrusion, consistant en tests manuels approfondis de systèmes ou applications spécifiques par des testeurs qualifiés afin d’identifier des faiblesses complexes ; et (c) les exercices de red teaming, consistant en simulations fondées sur des scénarios d’attaques réelles, y compris l’ingénierie sociale et d’autres tactiques, afin de tester les capacités de détection et de réponse de l’organisation dans son ensemble.

Pour TLPT, l’élément de red teaming est évident, mais la valeur d’audit provient de la conception du programme. Les scans de vulnérabilités, les tests d’intrusion, les exercices de red teaming, les exercices de résilience et les retests doivent former un cycle, et non une collection de tests déconnectés.

La clause 6.2 de la même politique traite de l’exécution sûre :

Champ d’application et règles d’engagement : pour chaque test ou exercice, le STC doit définir le champ d’application, y compris les systèmes et plages IP dans le périmètre, les méthodes de test autorisées, les objectifs, le calendrier et la durée. Les règles d’engagement doivent être documentées. Par exemple, les systèmes sensibles sur le plan opérationnel peuvent être désignés comme soumis uniquement à surveillance afin d’éviter toute perturbation, et tout test en production doit inclure des procédures de retour arrière et d’arrêt. Des mesures de sécurité, telles que des fenêtres temporelles et des canaux de communication définis, doivent être établies afin de prévenir les interruptions de service non intentionnelles.

Cela correspond directement au Zenith Blueprint, phase Controls in Action, étape 21, qui se concentre sur le contrôle 8.34 de l’Annexe A ISO 27001, protection des systèmes d’information pendant les tests d’audit. Le Zenith Blueprint avertit que les audits, tests d’intrusion, revues forensiques et évaluations opérationnelles peuvent impliquer des accès élevés, des outils intrusifs ou des modifications temporaires du comportement des systèmes. Il met l’accent sur l’autorisation, le périmètre, les fenêtres temporelles, l’approbation du propriétaire du système, le retour arrière, la surveillance et le traitement sécurisé des données de test.

Le dossier d’éléments probants auditable doit inclure :

• Charte TLPT et objectifs
• Synthèse du renseignement sur les menaces et justification du scénario
• Fonctions critiques ou importantes dans le périmètre
• Systèmes, plages IP, identités, fournisseurs et environnements dans le périmètre
• Exclusions et systèmes soumis uniquement à surveillance
• Règles d’engagement
• Appréciation des risques des tests en production
• Procédures de retour arrière et d’arrêt
• Modèle de notification au SOC, y compris ce qui est divulgué et non divulgué
• Approbations juridiques, de protection des données et des fournisseurs
• Éléments probants de création et de révocation des comptes de test
• Emplacement de stockage sécurisé pour les livrables justificatifs de test et les journaux

Un DORA TLPT qui ne peut pas démontrer l’autorisation sûre et la maîtrise de l’activité de test peut révéler des lacunes de résilience, mais il crée aussi des lacunes de gouvernance.

Transformer les résultats TLPT en traitement des risques

L’échec post-test le plus courant est le rapport Red Team qui reste sur une étagère. Un rapport de qualité est livré, diffusé, discuté, puis perd progressivement de son élan. Les constats restent ouverts. Les contrôles compensatoires ne sont pas documentés. Les risques acceptés sont informels. Les retests n’ont jamais lieu.

La Security Testing and Red-Teaming Policy rend cette situation inacceptable. La clause 6.6 indique :

Remédiation des constats : toutes les vulnérabilités ou faiblesses identifiées doivent être documentées dans un rapport de constats avec des niveaux de gravité. À réception du rapport, les propriétaires de systèmes sont responsables de l’élaboration d’un plan de remédiation avec des dates d’échéance ; par exemple, les constats critiques doivent être remédiés dans un délai de 30 jours et les constats de gravité élevée dans un délai de 60 jours, conformément à la Politique de gestion des vulnérabilités et des correctifs de l’organisation. Le STC doit suivre l’avancement de la remédiation. Des retests doivent être réalisés pour confirmer que les problèmes critiques ont été résolus ou atténués de manière adéquate.

La clause 6.7 ajoute la couche de gouvernance :

Reporting : un rapport formel doit être émis à la conclusion de chaque test. Pour les tests d’intrusion, le rapport doit inclure un résumé à l’attention de la direction, la méthodologie et des constats détaillés avec les éléments probants à l’appui et les recommandations. Pour les exercices de red teaming, le rapport doit détailler les scénarios, les chemins d’attaque qui ont réussi, ce qui a été détecté par la Blue Team et les enseignements tirés concernant les lacunes de détection et de réponse. Le RSSI doit présenter les résultats synthétisés et le statut de remédiation à la direction générale et, le cas échéant, les inclure dans le rapport annuel de sécurité au conseil d’administration.

Cela s’aligne sur les lignes directrices ISO/IEC 27005:2022 relatives au traitement des risques : sélectionner les options de traitement, déterminer les contrôles à partir de l’Annexe A ISO 27001 et des exigences sectorielles, établir un plan de traitement des risques, désigner les personnes responsables, définir les échéances, suivre le statut, obtenir l’approbation du propriétaire du risque et documenter l’acceptation du risque résiduel.

Chaque constat TLPT significatif doit devenir l’un des quatre éléments suivants : une action de remédiation, une amélioration de contrôle, une acceptation formelle du risque ou une exigence de retest.

L’objectif n’est pas de produire davantage de documents. L’objectif est que chaque document explique la décision suivante.

Les tests de résilience doivent prouver le rétablissement, pas seulement la détection

Un TLPT réussi peut montrer que le SOC a détecté du trafic de commande et contrôle, bloqué le mouvement latéral et correctement escaladé. C’est utile, mais les tests de résilience DORA vont plus loin. Ils demandent si l’organisation peut poursuivre ou rétablir les services métier.

Le Zenith Blueprint, phase Controls in Action, étape 23, explique le contrôle 5.30, aptitude TIC à la continuité d’activité, dans des termes que tout RSSI devrait utiliser avec le conseil d’administration :

Du point de vue de l’audit, ce contrôle est souvent testé avec une seule formule : Montrez-moi. Montrez-moi le dernier résultat de test. Montrez-moi la documentation de reprise. Montrez-moi le temps nécessaire pour basculer puis revenir en arrière. Montrez-moi les éléments probants que ce qui a été promis peut être réalisé.

Cette exigence « Montrez-moi » fait la différence entre la maturité documentaire et la résilience opérationnelle.

La Business Continuity Policy and Disaster Recovery Policy-sme de Clarysec Business Continuity Policy and Disaster Recovery Policy - SME, dans la section « Exigences de mise en œuvre de la politique », clause 6.4.1, indique :

L’organisation doit tester ses capacités PCA et DR au moins une fois par an. Les tests doivent inclure :

La section d’application de la même politique, clause 8.5.1, rend explicite la responsabilité relative aux éléments probants :

Le DG doit s’assurer que les éléments suivants sont maintenus et auditables :

Pour une entité financière réglementée par DORA, le test annuel peut être le seuil minimal, et non l’ambition. Les fonctions critiques ou importantes présentant un risque plus élevé doivent être testées plus fréquemment, en particulier après des changements d’architecture, une migration vers le cloud, des incidents majeurs, de nouveaux fournisseurs TIC, des versions applicatives significatives ou des changements d’exposition aux menaces.

Un dossier solide d’éléments probants de test de résilience doit inclure :

• Analyse d’impact sur l’activité cartographiant la fonction critique ou importante
• RTO et RPO approuvés par les responsables métier
• Cartographie des dépendances système, y compris identité, DNS, réseau, cloud, base de données, surveillance, sauvegarde et services tiers
• Résultats de test de sauvegarde et de restauration
• Horodatages de basculement et de retour arrière
• Éléments probants du fonctionnement des contrôles de sécurité pendant la perturbation
• Modèles de communication destinés aux clients, au régulateur et aux parties internes
• Journaux de participation du commandant d’incident et de l’équipe de crise
• Enseignements tirés et actions d’amélioration
• Éléments probants de retest pour les lacunes de reprise précédentes

C’est également ici que GDPR entre en jeu. GDPR Articles 2 et 3 font entrer dans le périmètre la plupart des traitements SaaS et fintech de données à caractère personnel de l’UE. Article 4 définit les données à caractère personnel, le traitement, le responsable du traitement, le sous-traitant et la violation de données à caractère personnel. Article 5 exige l’intégrité, la confidentialité et la responsabilité, ce qui signifie que l’organisation doit être en mesure de démontrer la conformité. Si TLPT ou les tests de reprise utilisent des données de production à caractère personnel, copient des journaux contenant des identifiants ou valident la réponse à une violation, les mesures de protection de la vie privée doivent être documentées.

Les éléments probants fournisseur sont l’angle mort DORA que les auditeurs n’ignoreront pas

Les services financiers modernes sont assemblés à partir de plateformes cloud, d’applications SaaS, de prestataires de sécurité managés, de processeurs de paiement, de plateformes de données, de fournisseurs d’identité, d’outils d’observabilité, d’équipes de développement externalisées et de fournisseurs de sauvegarde.

DORA Article 28 exige que les entités financières gèrent le risque lié aux prestataires tiers de services TIC dans le cadre de gestion des risques liés aux TIC et demeurent pleinement responsables même lorsque les services TIC sont externalisés. Article 30 exige des contrats écrits de services TIC comportant des descriptions de service, des conditions de sous-traitance, les lieux de traitement, la protection des données, l’accès et la reprise, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation, des clauses renforcées pour les fonctions critiques ou importantes, des droits d’audit, des mesures de sécurité, la participation au TLPT lorsque cela est pertinent et des dispositifs de sortie.

Cela signifie qu’un scénario TLPT ne peut pas s’arrêter au pare-feu de l’organisation si la fonction critique dépend d’un fournisseur.

La Third-Party and Supplier Security Policy-sme de Clarysec Third-Party and Supplier Security Policy - SME, dans la section « Exigences de mise en œuvre de la politique », clause 6.3.1, indique :

Les fournisseurs critiques ou à haut risque doivent être revus au moins une fois par an. La revue doit vérifier :

La Security Testing and Red-Teaming Policy ajoute une exigence fournisseur spécifique aux tests dans la clause 6.9 :

Coordination des tests avec les tiers : lorsqu’un fournisseur critique ou un prestataire de services entre dans le périmètre de la sécurité globale de l’organisation, conformément à la Third-Party and Supplier Security Policy, l’organisation doit, lorsque cela est faisable, obtenir une assurance concernant ses pratiques de tests de sécurité ou coordonner des tests conjoints. Par exemple, lorsqu’un fournisseur de services cloud (CSP) est utilisé, l’organisation peut s’appuyer sur ses rapports de tests d’intrusion ou l’inclure dans des scénarios collaboratifs de red team, sous réserve des stipulations contractuelles.

Pour des éléments probants DORA auditables, l’assurance fournisseur doit être reliée au même scénario de risque que le TLPT. Si le fournisseur d’identité est essentiel à la reprise des paiements, le dossier d’éléments probants doit inclure les diligences préalables relatives au fournisseur, les exigences contractuelles de sécurité, les clauses de support en cas d’incident, la coordination des tests, les rapports d’assurance, les éléments probants des niveaux de service, la stratégie de sortie et les contraintes applicables aux tests.

NIS2 Article 21 importe également pour les fournisseurs SaaS, cloud, de services managés, de sécurité managée, de centres de données, de CDN, de services de confiance, DNS, TLD, de places de marché en ligne, de moteurs de recherche et de réseaux sociaux. Il exige une approche tous risques couvrant l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, l’évaluation de l’efficacité, la formation, la cryptographie, le contrôle d’accès, la gestion des actifs, MFA et les communications sécurisées.

Le résultat pratique est simple : les entités financières doivent construire un modèle unique d’éléments probants qui satisfait d’abord DORA, puis référence de manière croisée les attentes NIS2 lorsque des fournisseurs, entités du groupe ou services numériques non financiers sont impliqués.

Un registre pratique Clarysec des éléments probants TLPT

Supposons le scénario suivant :

« Un acteur de la menace compromet un compte administrateur sur une plateforme de support SaaS, pivote vers l’environnement d’exploitation des paiements, modifie la configuration et perturbe le traitement des transactions. »

Créez un registre des éléments probants comportant une ligne par objet de preuve. N’attendez pas la fin du test. Alimentez-le pendant la planification, l’exécution, la remédiation et la clôture.

Utilisez ensuite l’étape 13 du Zenith Blueprint pour ajouter la traçabilité au registre des risques et à la Déclaration d’applicabilité. Chaque élément probant doit être relié à un scénario de risque, à un propriétaire du risque, à un contrôle sélectionné, à un plan de traitement des risques et à une décision sur le risque résiduel.

Si un constat concerne une faiblesse logicielle, citez les contrôles de développement sécurisé et de tests. La Secure Development Policy-sme de Clarysec Secure Development Policy - SME, dans la section « Exigences de mise en œuvre de la politique », clause 6.5.2, exige :

Les tests doivent être documentés avec :

Si un constat produit du matériel forensique, préservez la chaîne de conservation. La Evidence Collection and Forensics Policy-sme de Clarysec Evidence Collection and Forensics Policy - SME, dans la section « Exigences de gouvernance », clause 5.2.1, indique :

Chaque élément de preuve numérique doit être consigné avec :

C’est le point que de nombreuses équipes manquent. Les éléments probants ne se limitent pas aux rapports finaux. Ils constituent l’enregistrement maîtrisé de qui a approuvé, qui a exécuté, ce qui s’est produit, ce qui a été détecté, ce qui a été rétabli, ce qui a été modifié, ce qui reste exposé et qui a accepté cette exposition.

Comment les auditeurs examinent les mêmes éléments probants TLPT

Les éléments probants DORA TLPT seront lus différemment selon le profil de l’auditeur. Clarysec conçoit les dossiers d’éléments probants de façon que chaque angle d’analyse y trouve ce dont il a besoin sans obliger les équipes à dupliquer le travail.

COBIT 2019 apparaît dans la référence de conformité croisée du Zenith Blueprint pour l’exécution sûre des audits et des tests, y compris DSS05.03 et MEA03.04. L’intérêt n’est pas que COBIT remplace DORA ou ISO 27001, mais que les professionnels de l’assurance de type ISACA rechercheront une exécution maîtrisée, une surveillance, une évaluation et des éléments probants de conformité.

Le récit au conseil d’administration : ce que la direction doit approuver

Le reporting au conseil d’administration doit éviter le théâtre technique. Le conseil n’a pas besoin de charges utiles d’exploitation. Il a besoin d’éléments probants décisionnels :

• Quelle fonction critique ou importante a été testée ?
• Quel scénario de menace a été simulé et pourquoi ?
• La détection a-t-elle fonctionné ?
• L’escalade de la réponse a-t-elle fonctionné ?
• La reprise a-t-elle respecté le RTO et le RPO ?
• Quels fournisseurs ont été impliqués ou ont constitué une contrainte ?
• Quelles faiblesses significatives subsistent ?
• Quel est le coût de remédiation, qui en est responsable et quel est le calendrier ?
• Quels risques résiduels nécessitent une acceptation formelle ?
• Qu’est-ce qui sera retesté ?

C’est ici que la clause 5 ISO 27001 devient importante. La direction doit s’assurer que la politique de sécurité de l’information et les objectifs sont établis, alignés sur l’orientation stratégique, intégrés aux processus métier, dotés de ressources, communiqués et améliorés en continu. Les rôles et responsabilités doivent être attribués. Les objectifs doivent être mesurables lorsque cela est possible et tenir compte des exigences applicables et des résultats du traitement des risques.

Si TLPT identifie que le temps de reprise est de six heures pour une tolérance métier de quatre heures, il ne s’agit pas d’un simple élément du backlog d’infrastructure. C’est une décision de direction impliquant l’appétence au risque, le budget, les engagements clients, l’exposition réglementaire, les contrats, l’architecture et la capacité opérationnelle.

Défaillances courantes des éléments probants dans les tests de résilience DORA

Les revues Clarysec constatent souvent les mêmes lacunes d’éléments probants chez les entités financières et les fournisseurs de services TIC qui se préparent à DORA.

Premièrement, le périmètre TLPT n’est pas rattaché aux fonctions critiques ou importantes. Le test peut être techniquement impressionnant, mais il ne prouve pas la résilience du processus opérationnel qui intéresse les régulateurs.

Deuxièmement, les dépendances fournisseurs sont reconnues mais non étayées par des éléments probants. Les équipes indiquent que le fournisseur cloud, le SOC managé ou la plateforme SaaS est dans le périmètre, mais les contrats, droits d’audit, autorisations de test, clauses de support incident et plans de sortie manquent.

Troisièmement, les tests créent des éléments probants mais pas de traitement. Les constats restent dans un rapport Red Team au lieu d’être convertis en mises à jour du registre des risques, modifications de contrôles, responsables, dates, retests et décisions sur le risque résiduel.

Quatrièmement, la reprise est supposée plutôt que démontrée. Des politiques de sauvegarde existent, mais personne ne peut présenter les horodatages de basculement, les contrôles d’intégrité de restauration, la validation des accès ou la confirmation du responsable métier.

Cinquièmement, les éléments probants de protection des données et forensiques ne sont pas maîtrisés. Les journaux et captures d’écran contiennent des données à caractère personnel, les livrables justificatifs de test sont stockés sur des lecteurs partagés, les comptes temporaires restent actifs et la chaîne de conservation des éléments probants est incomplète.

Sixièmement, le reporting de direction est trop technique. Les hauts dirigeants ne peuvent pas déterminer si la résilience s’est améliorée, si le risque est dans l’appétence au risque ou quelles décisions d’investissement sont nécessaires.

Chacune de ces lacunes peut être résolue en traitant DORA TLPT comme un processus structuré d’éléments probants ISO 27001.

L’approche intégrée de Clarysec pour une résilience auditable

L’approche de Clarysec combine trois couches.

La première couche est la feuille de route de mise en œuvre en 30 étapes Zenith Blueprint. Pour ce sujet, l’étape 13 établit la traçabilité du traitement des risques et de la SoA, l’étape 21 protège les systèmes pendant les tests d’audit, et l’étape 23 valide l’aptitude TIC à la continuité d’activité. Ces étapes transforment TLPT d’un événement technique en cycle de gouvernance documenté.

La deuxième couche est la bibliothèque de politiques de Clarysec. La Security Testing and Red-Teaming Policy définit les types de tests, le périmètre, les règles d’engagement, la remédiation, le reporting et la coordination fournisseur. La Business Continuity Policy and Disaster Recovery Policy-sme fixe les attentes relatives aux tests annuels PCA et DR et aux éléments probants de continuité auditables. La Third-Party and Supplier Security Policy-sme soutient l’assurance fournisseur. La Secure Development Policy-sme garantit que les tests de sécurité sont documentés. La Evidence Collection and Forensics Policy-sme soutient la journalisation des éléments probants et la discipline de chaîne de conservation.

La troisième couche est Zenith Controls, le guide de conformité croisée de Clarysec. Il aide à cartographier les contrôles ISO/IEC 27002:2022 avec les attributs, domaines, capacités opérationnelles et attentes inter-référentiels. Pour DORA TLPT, le modèle le plus important n’est pas un contrôle isolé. C’est la relation entre les tests, la continuité, la gestion des incidents, la gestion des fournisseurs, la journalisation, la surveillance, le développement sécurisé, la revue indépendante et la gouvernance.

Lorsque ces couches fonctionnent ensemble, le problème du lundi matin du RSSI change. Au lieu de trois questions déconnectées du conseil d’administration, du régulateur et de l’audit interne, l’organisation dispose d’un récit unique fondé sur les éléments probants :

« Nous avons identifié la fonction critique. Nous avons évalué le risque TIC. Nous avons sélectionné et justifié les contrôles. Nous avons autorisé et exécuté le TLPT en sécurité. Nous avons détecté, répondu et rétabli. Nous avons impliqué les fournisseurs lorsque nécessaire. Nous avons documenté les éléments probants. Nous avons remédié les constats. Nous avons retesté. La direction a revu et accepté le risque restant. »

C’est cela, une résilience auditable.

Prochaines étapes

Si votre programme DORA TLPT reste organisé autour de rapports plutôt que de chaînes d’éléments probants, commencez par une revue guidée des éléments probants avec Clarysec.

Utilisez l’étape 13 de Zenith Blueprint Zenith Blueprint pour relier les scénarios TLPT aux risques, aux contrôles et à la Déclaration d’applicabilité. Utilisez l’étape 21 pour vérifier l’autorisation sûre, les règles d’engagement, le retour arrière, la surveillance et le nettoyage. Utilisez l’étape 23 pour prouver l’aptitude TIC à la continuité d’activité avec des éléments probants de reprise.

Alignez ensuite vos documents opérationnels avec la Security Testing and Red-Teaming Policy de Clarysec Security Testing and Red-Teaming Policy, la Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, la Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, la Secure Development Policy-sme Secure Development Policy - SME et la Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME.

Enfin, utilisez Zenith Controls Zenith Controls pour cartographier de manière croisée vos éléments probants DORA TLPT avec les contrôles ISO 27001, NIS2, GDPR, COBIT 2019 et les attentes des auditeurs.

Si vous voulez que votre prochain test de résilience produise davantage que des constats, utilisez Clarysec pour le transformer en chaîne d’éléments probants défendable. Téléchargez les boîtes à outils, planifiez une évaluation de préparation des éléments probants ou demandez une revue guidée de la manière dont Clarysec rattache DORA TLPT aux contrôles ISO 27001:2022, de la planification jusqu’à l’approbation par le conseil d’administration.