Dora est en vie: ce que les entreprises financières ont en fait à tester maintenant
DORA a remplacé « avez-vous des contrôles de sécurité ? » par « avez-vous prouvé que votre service critique survit à une véritable attaque ? » Voici ce que le régime d'essai exige — et où TLPT convient.
Qui DORA atteint effectivement
DORA est un règlement, pas une directive, qui importe plus qu'il ne semble. Une directive doit être transposée en droit national, de sorte que chaque État membre rédige sa propre version et que l'horloge tourne différemment partout. Un règlement s'applique directement, dans son intégralité, dans toute l'Union à la même date. Il n'y a pas d'écart de transposition pour se cacher.
Son champ d'application couvre essentiellement l'ensemble du secteur financier européen: établissements de crédit, institutions de paiement et de monnaie électronique, entreprises d'investissement, administrateurs de fonds, assureurs, prestataires de services de crypto-actif et infrastructures de marché. Si vous vous asseyez n'importe où dans cet écosystème, DORA est votre problème.
Ensuite, il y a le deuxième anneau, celui qui est régulièrement sous-estimé : les fournisseurs de services TIC tiers. Entreprises d'hébergement, fournisseurs de cloud, fournisseurs de logiciels bancaires de base, processeurs de paiement, entrepreneurs de maintenance. Même si vous n'êtes pas une entité financière vous-même, vous êtes dans le rayon d'explosion de DORA.
Pour les entreprises moldaves, la voie pratique est contractuelle plutôt que législative. Si vous construisez ou exploitez une technologie pour une entité financière de l'UE, votre client est légalement tenu d'imposer des exigences de sécurité, des droits d'audit et de tester la participation par le biais du contrat. L'obligation vous parvient par une signature, bien avant que n'importe quelle loi locale ne rattrape.
Note : Le DORA couvre cinq domaines : gestion des risques liés aux TIC, compte rendu d'incidents, tests de résilience numérique, risques liés aux TIC par des tiers et partage de renseignements sur les menaces. L'essai n'est qu'un pilier, mais c'est pour lui que la plupart des équipes sont les moins préparées.
Le programme d'essai de base
DORA exige un programme d'essai de résilience numérique appliqué au moins une fois par année à tous les systèmes TIC soutenant des fonctions critiques ou importantes. Le mot important est "programme". Ce n'est pas un test que vous achetez une fois et que vous déposez. Il s'agit d'un portefeuille d'activités qui vous donnent ensemble la couverture de différents modes de défaillance.
Ce portefeuille comprend des évaluations de vulnérabilité, des analyses libres, des analyses de sécurité du réseau, des évaluations de la sécurité physique, des questionnaires, des examens de code source, des tests de compatibilité, des tests de performance et des tests de pénétration. Chacun d'eux trouve différentes choses. Un scan de vulnérabilité vous indique qu'un patch est manquant; un test de pénétration vous indique si ce patch manquant est effectivement accessible et exploitable sur le chemin de votre moteur de paiement. Les vérificateurs veulent de plus en plus les deux, plus le raisonnement qui les relie.
Deux conditions s'appliquent à l'ensemble du programme et, selon notre expérience, la plupart des organisations tombent en premier.
La première est l'indépendance. Les essais doivent être effectués par des parties indépendantes de l'équipe qui a construit le système — interne ou externe, mais sans conflit d'intérêts avec les développeurs. Une équipe testant son propre code n'est pas un test indépendant, peu importe la rigueur de la liste de contrôle.
La deuxième est la discipline en matière d'assainissement. Les constatations doivent faire l'objet d'un processus d'assainissement suivi, en fonction du risque pour les fonctions critiques. Un rapport avec 200 constatations et aucun propriétaire, aucune date limite et aucun nouveau test n'est une preuve de résilience; c'est une preuve d'un processus qui s'arrête au format PDF.
TLPT: test mené par des menaces réelles
Au-dessus de la ligne de base se trouvent des tests avancés pour les entités désignées par les autorités compétentes, sélectionnées en fonction des critères de risque et de l'importance systémique. Il s'agit de TLPT — threat-led pénétration testing — et il s'agit d'un animal différent de celui que la plupart des équipes connaissent chaque année.
TLPT fonctionne au moins une fois tous les trois ans, suit le cadre européen TIBER-UE et se distingue d'un test de pénétration classique de trois façons fondamentales.
Tout d'abord, il est construit sur de vrais renseignements de menace. Un fournisseur de renseignement de menace construit les scénarios des groupes qui attaquent réellement votre secteur — leur outillage, leur métier, leurs vecteurs d'accès initiaux préférés. Vous ne testez pas un modèle d'attaquant générique; vous répétez contre un adversaire spécifique qui a déjà été à l'intérieur d'entreprises comme le vôtre.
Deuxièmement, il s'exécute contre les systèmes de production, pas contre un environnement d'essai. C'est précisément la raison pour laquelle il a une gouvernance stricte et une équipe de contrôle étroitement restreinte au sein de l'entité. Une réplique de laboratoire ne vous dira pas si votre détection de fraude voyage quand un attaquant se déplace latéralement dans le rail de paiement réel.
Troisièmement, il mesure la défense, pas seulement l'infraction. On ne dit pas à l'équipe bleue que l'exercice se déroule. Le résultat comprend la rapidité avec laquelle ils ont détecté l'intrusion, la façon dont ils ont réagi, et où le signal existait, mais personne n'a regardé.
Un exercice TLPT dure généralement plusieurs mois et se termine avec une phase de replay : les attaquants et les défenseurs marchent ensemble la chronologie, minute par minute, pour établir où la télémétrie était présente et ne sont pas lus. Dans la pratique, ce replay produit des améliorations plus durables que la liste de vulnérabilité jamais faite. Trouver un trou est utile; découvrir que votre SIEM a eu la preuve pendant onze jours et personne n'a agi sur elle est transformateur.
Baseline versus TLPT: quels changements
Les deux niveaux ne sont pas interchangeables, et les regrouper est une erreur de planification courante. Le tableau ci-dessous présente les différences qui déterminent la portée, le budget et le séquençage. Qui est-ce? Toutes les entités financières intégrées
La colonne de fréquence mérite d'être soulignée. Les tests de référence annuels sont obligatoires pour tous. TLPT n'est pas — il s'applique uniquement aux entités désignées, choisies en fonction du risque, de la taille et de l'importance systémique, principalement les institutions dont l'indisponibilité menacerait la stabilité financière. Si vous n'avez pas été désigné, vous n'êtes pas exempté du test; vous n'êtes exempté que du niveau avancé.
Que faire avant d'essayer TLPT
Un exercice mené par la menace sur des infrastructures non testées produit un rapport prévisible et coûteux: les agresseurs atteignent rapidement des fonctions critiques par des voies banales, et les conclusions vraiment utiles se noient dans le bruit. L'ordre sain est l'inverse de ce que l'urgence dicte habituellement. Fermez d'abord les voies évidentes avec des tests classiques, puis mesurez la détection et la réponse.
En termes pratiques, cette séquence ressemble à ceci :
- Inventaire de vos fonctions critiques et des systèmes TIC qui les soutiennent. Sans cela, la portée du TLPT ne peut être définie et l'exercice s'étalera.
- Exécuter des tests de pénétration externe et interne classiques, et conduire l'assainissement tout le chemin pour re-test. Une conclusion fermée sans un nouveau test est une conclusion que vous devinez.
- Gardez un registre de tiers des TIC et assurez-vous que vos contrats comportent des clauses d'essai et de vérification. Si votre fonction essentielle dépend d'un fournisseur qui ne participera pas, c'est un manque de résilience et non un problème de paperasserie.
- Créer une véritable capacité de détection. Si vous n'avez pas de surveillance centralisée, TLPT va simplement mesurer son absence — à un coût considérable.
Ce dernier point est celui que nous voyons le plus souvent. Les équipes commandent des tests avancés en s'attendant à une vue d'un agresseur de leur périmètre, et reçoivent plutôt une mesure de si quelqu'un observait. Si personne ne l'était, l'exercice a encore fait son travail — mais vous avez payé pour une façon coûteuse d'apprendre quelque chose une évaluation de l'écart de surveillance vous aurait dit pour une fraction du coût.
Attention: TLPT n'est pas un substitut aux tests de référence, et ce n'est pas un premier test. L'exécuter sur une succession non testée brûle le budget sur les conclusions que les tests de pénétration de routine auraient fait surface, et il gaspille la mauvaise volonté de l'équipe de contrôle au sein de votre organisation.
La question du fournisseur, répondu honnêtement
La question que nous entendons le plus des fournisseurs de technologie est de savoir si DORA s'applique à eux. La réponse honnête a deux couches.
Directement, seulement si vous êtes désigné un fournisseur de services tiers TIC critique au niveau européen — un petit groupe nommé spécifiquement. Indirectement, presque certainement oui. L'entité financière que vous servez est tenue d'inclure les exigences en matière de sécurité, les droits d'audit et d'accès, les clauses de résilience et, pour les fournisseurs qui soutiennent des fonctions critiques, la participation à des tests de résilience — y compris les exercices TLPT du client.
Cela signifie qu'une maison de logiciels ou un fournisseur d'hébergement moldave peut se trouver contractuellement nécessaire pour soutenir un exercice TIBER-UE géré par une banque allemande, sans statut local l'obligeant. L'effet de levier est commercial : refuser, et le contrat ne se renouvelle pas.
Important: Si vous soutenez une fonction critique pour une entité financière de l'UE, supposons que vous serez invité à participer à des tests. Négocier les termes maintenant — portée, périodes de préavis, port sûr et traitement des données — plutôt que pendant un exercice en direct sous la pression du temps.
Délais, coût et cas de séquençage
Un exercice TLPT complet se déroule généralement entre trois et six mois, divisé en deux phases : préparation, renseignement sur les menaces, phase d'essai elle-même et fermeture avec rejouage. Le coût dépend du nombre de scénarios, de l'étendue du périmètre et de la participation de fournisseurs externes, et il se situe nettement au-dessus d'un test de pénétration classique.
Cette différence de prix est précisément la raison pour laquelle le séquençage est important. Chaque heure d'assainissement que vous accomplissez avant TLPT est une heure que l'équipe rouge passe sur un problème vraiment difficile plutôt qu'un titre de créance par défaut. Les organisations qui tirent le meilleur parti des tests dirigés par la menace sont celles qui l'ont traitée comme la pierre angulaire d'un programme mature, et non comme le mouvement d'ouverture.
Il y a ici un point plus large sur ce que DORA demande vraiment. Il n'exige pas que vous soyez inaccessible — aucun régulateur sérieux croit que cela est réalisable. Il exige que vous connaissiez vos fonctions critiques, que vous les ayez testées contre des adversaires réalistes, que vous puissiez détecter et répondre quand quelque chose arrive, et que vous puissiez prouver tout cela avec des preuves suivies. Les entreprises qui traitent les tests comme un artefact de conformité réussiront les vérifications et les incidents d'échec. Les entreprises qui le considèrent comme une capacité opérationnelle feront le contraire, et ce sont celles pour lesquelles la DORA a été écrite.