Protection, prévention et détection
Comment DORA structure les contrôles techniques défensifs des entités financières : gestion des vulnérabilités, patch management, durcissement des systèmes et supervision continue via un SOC.
Table des matières
Pourquoi ce chapitre est central dans DORA
Les chapitres précédents ont posé le cadre général de DORA : gouvernance, cartographie des risques TIC, tiers critiques. Celui-ci descend d'un niveau : il traite des contrôles techniques concrets que le règlement impose de mettre en œuvre pour réduire la probabilité d'un incident et sa gravité s'il survient malgré tout.
C'est un chapitre charnière parce que c'est là que la conformité cesse d'être un exercice documentaire pour devenir un exercice d'ingénierie. Une politique de gestion des vulnérabilités qui existe sur papier mais qu'aucune équipe n'exécute avec discipline n'apporte aucune protection réelle — et n'apportera aucune défense face à un superviseur qui demande des preuves d'exécution, pas des intentions.
L'article 9 de DORA (Règlement UE 2022/2554) impose aux entités financières de mettre en place des mécanismes pour identifier, classifier, documenter et traiter les vulnérabilités TIC, ainsi que des politiques de gestion des correctifs, de chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire et de contrôle d'accès fondées sur le principe du moindre privilège. Ce n'est pas une recommandation de bonne pratique : c'est une obligation réglementaire assortie de sanctions en cas de manquement caractérisé.
La prévention : réduire la surface d'attaque avant l'incident
La prévention regroupe l'ensemble des mesures qui réduisent la probabilité qu'une faille soit exploitable. Trois piliers structurent cette dimension dans DORA : la gestion des vulnérabilités, le patch management et le durcissement des systèmes.
Gestion des vulnérabilités
Une gestion des vulnérabilités opérationnelle repose sur un cycle continu, pas sur un scan ponctuel avant l'audit annuel :
- Découverte — scans automatisés récurrents (authentifiés de préférence, car un scan non authentifié sous-estime systématiquement le nombre de failles détectées) sur l'ensemble du périmètre, y compris les actifs shadow IT et les environnements de test connectés au réseau interne.
- Classification — scoring CVSS complété par le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire métier réel : une vulnérabilité critique sur un serveur isolé sans accès réseau externe pèse moins qu'une vulnérabilité moyenne exposée directement sur un service de paiement.
- Priorisation — arbitrage entre gravité technique et exposition fonctionnelle, avec des délais de traitement différenciés par criticité (souvent 24 à 72 heures pour le critique exploité activement, quelques semaines pour le mineur).
- Vérification de la remédiation — un correctif appliqué doit être revalidé par un nouveau scan, pas simplement coché comme fait dans un outil de ticketing.
Ne priorisez jamais uniquement sur le score CVSS brut. Une CVE notée 9.8 sur un système déconnecté d'Internet et sans accès utilisateur direct est souvent moins urgente qu'une CVE notée 7.1 exposée sur une passerellePasserelleRéseauxÉquipement réseau reliant deux réseaux de couches différentes ou traduisant des protocoles ; en TCP/IP, route les paquets entre sous-réseaux.Voir dans le glossaire VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire accessible depuis l'extérieur. Le contexte d'exposition prime sur le score théorique.
Patch management
Le cycle de correctifs est l'endroit où la théorie s'effondre le plus souvent en pratique. Trois causes reviennent systématiquement :
- Absence d'inventaire fiable des actifs. On ne peut pas patcher ce qu'on ne sait pas posséder. Un inventaire à jour (matériel, OS, middleware, bibliothèques applicatives) est un prérequis, pas une option.
- Fenêtres de maintenance trop rares. Des correctifs critiques qui attendent la prochaine fenêtre trimestrielle laissent une exposition prolongée inacceptable pour DORA.
- Peur de la régression. Un environnement de test représentatif, avec des tests de non-régression automatisés, réduit considérablement la réticence à patcher rapidement les systèmes critiques.
Un patch management "documenté mais non exécuté" est l'un des écarts les plus fréquemment relevés lors des contrôles de conformité DORA. Disposer d'une politique écrite qui prévoit un délai de 30 jours pour les correctifs critiques, alors que l'historique réel montre des délais moyens de 90 jours, constitue un manquement — même si la politique elle-même est correctement rédigée. Les superviseurs demandent des journaux d'exécution, pas des intentions.
Durcissement des systèmes (hardening)
Le durcissement consiste à réduire la surface d'attaque d'un système en désactivant tout ce qui n'est pas strictement nécessaire à son fonctionnement : services inutilisés, comptes par défaut, portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire ouverts sans justification, protocoles obsolètes (SMBv1, TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire 1.0/1.1, FTP en clair).
Des référentiels reconnus — CIS Benchmarks, guides ANSSI, recommandations des éditeurs — fournissent des bases de configuration à décliner par type de système. L'essentiel n'est pas d'appliquer un référentiel à la lettre, mais de documenter les écarts assumés et leur justification métier, car un contrôleur DORA demandera systématiquement pourquoi une déviation existe.
La protection : contenir la propagation d'un incident
La protection ne vise pas à empêcher toute intrusion — objectif irréaliste — mais à limiter son impact si elle survient.
Contrôle d'accès et moindre privilège
Le principe du moindre privilège signifie qu'un compte, humain ou technique, ne dispose que des droits strictement nécessaires à sa fonction, pour la durée nécessaire. Concrètement, cela implique :
- Authentification multifacteur (MFA) systématique pour les accès à privilèges et les accès distants.
- Comptes à privilèges élevés nominatifs et non partagés, avec traçabilité individuelle des actions.
- Revues d'habilitations périodiques, avec retrait automatique des droits en cas de changement de poste ou de départ.
- Séparation stricte entre comptes d'administration et comptes d'usage quotidien.
Segmentation réseau et cloisonnement
La segmentationChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire limite la capacité d'un attaquant à se déplacer latéralement une fois un point d'entrée compromis. Un réseau plat, où un poste de travail compromis peut atteindre directement un serveur de paiement, annule une grande partie des efforts de détection en aval : l'attaquant progresse plus vite que les alertes ne remontent.
En 2023, plusieurs incidents dans le secteur financier européen ont impliqué l'exploitation de passerelles VPN non corrigées, exposées directement sur Internet, donnant un accès quasi direct au réseau interne faute de segmentation entre la zone d'accès distant et les systèmes critiques. Le correctif existait depuis plusieurs semaines avant l'exploitation. Ce scénario illustre pourquoi DORA exige conjointement patch management rigoureux et cloisonnement réseau : l'un compense les délais inévitables de l'autre.
Sauvegardes isolées
Une sauvegarde accessible depuis le même domaine d'administration que les donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire qu'elle protège n'est pas une protection contre un rançongiciel : elle en devient une cible. DORA attend des copies isolées (air gap logique ou physique), testées régulièrement en restauration réelle — pas seulement en vérification d'intégrité du fichier de sauvegarde.
La détection : voir avant que ça casse, ou vite après
La prévention et la protection réduisent le risque ; elles ne l'annulent jamais. La détection est la troisième ligne, celle qui transforme un incident silencieux en incident traité.
SOC, SIEM et EDR
Un centre opérationnel de sécurité (SOC) centralise la supervision continue des événements de sécurité. Il s'appuie typiquement sur :
- SIEM (Security Information and Event Management) — agrégation et corrélation des journaux issus des différentes sources (pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire, serveurs, applications, annuaire).
- EDR (Endpoint Detection and Response) — surveillance comportementale au niveau des postes et serveurs, capable de détecter des comportements anormaux même sans signature connue.
- NDR (Network Detection and Response) — analyse du trafic réseau pour repérer des mouvements latéraux ou des exfiltrations.
Corrélation et seuils d'alerte
Accumuler des journaux ne suffit pas : sans corrélation ni seuils calibrés, un SIEM produit un volume d'alertes que personne ne peut traiter, et les signaux réellement pertinents se noient dans le bruit. C'est ce qu'on appelle la fatigue d'alerte, l'un des facteurs les plus documentés dans les incidents où un signal existait mais n'a pas été traité à temps.
DORA se distingue de NIS2 par son périmètre : DORA s'applique spécifiquement aux entités financières de l'Union européenne (banques, assurances, gestionnaires d'actifs, prestataires de services de paiement, plateformes de négociation) et à leurs prestataires TIC critiques, avec des exigences très détaillées sur les tests de résilience et la gestion des tiers. NIS2 couvre un périmètre sectoriel plus large mais avec des exigences de contrôle technique moins prescriptives. Une entité financière européenne est généralement soumise à DORA en tant que lex specialis, qui prévaut sur NIS2 pour les aspects qu'il couvre.
Indicateurs de pilotage
Un dispositif de protection, prévention et détection ne se pilote pas à l'intuition. Les entités matures suivent un socle d'indicateurs resserré, revu au moins mensuellement par la fonction risque TIC et présenté à l'organe de direction dans une forme synthétique :
- Délai moyen de remédiation (MTTR patch) par niveau de criticité, comparé à l'objectif contractuel interne.
- Taux de couverture des scans de vulnérabilités rapporté à l'inventaire réel des actifs, pas au périmètre déclaré.
- Taux de couverture EDR effectif, avec identification nominative des angles morts.
- Délai moyen de détection (MTTD) et délai moyen de réponse (MTTR incident), mesurés depuis l'événement déclencheur jusqu'à la qualification par un analyste.
- Taux de faux positifs des règles de corrélation, pour objectiver la fatigue d'alerte plutôt que la constater a posteriori.
Ces indicateurs n'ont de valeur que s'ils sont mesurés dans la durée : un instantané favorable la veille d'un audit ne remplace pas une tendance sur douze mois. C'est précisément cette continuité que les autorités de supervision cherchent à vérifier lors des contrôles DORA, en demandant l'historique complet plutôt qu'un rapport ponctuel.
Couches de contrôle et exigences DORA
| Couche | Objectif | Exemples de contrôles | Fréquence attendue |
|---|---|---|---|
| Prévention | Réduire la surface d'attaque | Scans de vulnérabilités, patch management, hardening | Continue / hebdomadaire |
| Protection | Limiter la propagation | MFA, segmentation, chiffrement, sauvegardes isolées | Continue, revue trimestrielle |
| Détection | Identifier un incident en cours | SIEM, EDR, NDR, corrélation d'événements | Temps réel, 24/7 pour le périmètre critique |
| Amélioration | Capitaliser sur les incidents | Retours d'expérience, mise à jour des règles de détection | Après chaque incident significatif |
Pièges fréquents
- Confondre inventaire des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire et couverture réelle. Posséder un EDR ne signifie rien si son déploiement ne couvre que 60 % du parc.
- Segmenter sur le papier, pas sur le réseau. Des VLANVLANRéseauxRéseau local virtuel qui segmente logiquement un LAN Ethernet sans exiger un câblage physique séparé.Voir dans le glossaire existent dans la documentation d'architecture mais les règles de filtrage entre zones n'ont jamais été testées ni auditées.
- Traiter la détection comme un projet fini. Les règles de corrélation se périment : sans révision régulière, un SIEM détecte de moins en moins de scénarios pertinents à mesure que les techniques d'attaque évoluent.
- Sous-staffer le SOC par rapport au volume d'alertes. Un outil qui génère plus d'alertes que l'équipe ne peut en qualifier produit, de facto, une absence de détection.
Checklist opérationnelle
- Inventaire des actifs à jour et rapproché des scans de vulnérabilités.
- Délais de remédiation différenciés par criticité, avec mesure réelle des délais moyens constatés.
- Configuration durcie documentée par type de système, écarts justifiés.
- MFA activé sur tous les accès à privilèges et accès distants.
- Segmentation réseau testée par des exercices de type Red Team ou Purple Team.
- Sauvegardes isolées avec test de restauration réel au moins annuel.
- Couverture EDR mesurée et rapprochée de l'inventaire des actifs.
- Règles de corrélation SIEM revues après chaque incident et à fréquence régulière.
Ce qu'il faut retenir
Protection, prévention et détection forment un triptyque interdépendant : aucune des trois couches ne compense durablement l'absence des deux autres. DORA exige des preuves d'exécution, pas des politiques bien rédigées. Le chapitre suivant aborde la gestion des incidents proprement dite — classification, notification aux autorités et délais réglementaires — qui prend le relais dès que la détection a fait son travail.
L'essentiel à retenir
Ce chapitre détaille les exigences de l'article 9 de DORA en matière de protection et de prévention des risques liés aux TIC dans le secteur financier européen. Il couvre la gestion des vulnérabilités, le cycle de correctifs, le durcissement des systèmes, le contrôle des accès et le chiffrement, puis la détection via SOC, SIEM et EDR. Une attention particulière est portée aux pièges opérationnels : patch management théorique sans exécution réelle, segmentation réseau non testée, alerting bruyant qui noie les signaux faibles. Le chapitre se termine par une checklist directement exploitable pour un audit de conformité DORA.
Questions fréquentes
Est-ce que respecter NIS2 suffit pour être conforme à DORA sur la partie protection et détection ?
Combien de temps a-t-on pour corriger une vulnérabilité critique sous DORA ?
Un SOC externalisé (MSSP) est-il accepté dans le cadre de DORA ?
Quelle est la différence concrète entre un SIEM et un EDR ?
Le durcissement (hardening) doit-il suivre un référentiel précis comme CIS Benchmarks ?
Comment savoir si notre couverture EDR est suffisante ?
Faut-il tester réellement la restauration des sauvegardes, ou la vérification d'intégrité suffit-elle ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).