Directive DORA : Comment se mettre en conformité simplement ?

Quel est le rôle de la directive DORA ?

La directive européenne DORA (pour « Digital Operational Resilience Act ») a pour but d’améliorer la résilience opérationnelle numérique des acteurs des services financiers face aux risques grandissants liés à la digitalisation des entreprises et à l’augmentation de la cybercriminalité.

Cette notion de résilience doit se comprendre comme la capacité pour une entreprise de la communauté européenne de pouvoir faire face à un risque d’attaque ou de panne sur son système informatique. Les médias se font de plus en plus l’écho d’attaques informatiques ou de dysfonctionnement matériel entraînant parfois le dépôt de bilan de l’entreprise victime.

La directive DORA est issue du projet de règlement sur la résilience opérationnelle numérique adopté le 10 novembre 2022 par le Parlement européen.

Qui est concerné par le règlement DORA ?

La décision de créer une réglementation européenne spécifique à la protection des données informatiques vient d’un constat : chaque pays membre de la CEE développe ses propres réglementations et outils, provoquant une complexification des échanges d’information et une augmentation des risques TIC (Technologies de l’Information et de la Communication) en cybersécurité.

Il devenait donc urgent de créer un règlement européen permettant d’harmoniser et de simplifier ces pratiques. Tous les organes de direction des entités financières européennes sont concernés :

  • organismes financiers de retraite professionnelle
  • compagnies d’assurance
  • organismes de crédit
  • banques, marchés financiers, OPCVM
  • entreprises d’investissement financier
  • sociétés de gestion
  • plates-formes de négociation
  • contrôleurs légaux des comptes et cabinets d’audit
  • prestataires de services de financement participatif
  • prestataires de services sur crypto-actifs
  • gestionnaires de fonds d’investissement alternatifs

A noter que les prestataires qui interviennent pour ces différentes structures sont également tenus de respecter ce règlement DORA et doivent dès maintenant adapter leurs processus TIC pour se conformer à ces nouvelles dispositions légales qui entreront en vigueur dès janvier 2025.

(Voir la liste complète des entités financières concernées dans l’article 2 du règlement DORA).

Mise en conformité avec le règlement DORA

Votre entité est concernée par la directive DORA ?

Voici les 7 mesures que vous devrez mettre en oeuvre avant janvier 2025 pour respecter le Digital Operational Resilience Act :

1. Gouvernance du risque informatique
2. Formation à la résilience opérationnelle numérique
3. Analyse du système informatique
4. Gestion des risques informatiques
5. Conduite de tests de résilience
6. Encadrement des risques liés aux prestataires SI
7. Mécanismes d’échange d’information sur les risques

1. Gouvernance du risque informatique

Votre direction financière doit mettre en place une gouvernance pilotant la gestion des risques informatiques et la mise en œuvre d’outils pouvant les mesurer, les inventorier, en faire le reporting et surtout réagir en cas de nécessité.

L’organe de direction de l’entité financière aura la responsabilité finale de la gestion des risques informatiques et devra définir les responsabilités et les rôles de chaque fonction informatique.

Il devra déterminer le niveau de tolérance adapté au risque de cybersécurité ou d’incident informatique, approuver les plans d’audits informatiques effectués régulièrement et allouer un budget suffisant à la réalisation de toutes les actions de gestion du risque informatique.

2. Formation à la résilience opérationnelle numérique

Les acteurs de cette gouvernance devront se former aux exigences de ce nouveau mode de pilotage via des formations dont le contenu pédagogique répond aux critères établis dans le règlement DORA (voir article 12).

Ces programmes de sensibilisation à la sécurité informatique devront être intégrés au plan de formation du personnel de manière obligatoire et mis à jour à chaque évolution des dispositions légales. L’acquisition des compétences proposées dans ces modules de formation devra pouvoir être vérifiable.

Si vous souhaitez former votre personnel, Digitemis peut vous proposer différentes formations de sensibilisation au risque informatique.

3. Analyse du système informatique (SI)

La première action à mettre en place consiste à effectuer une analyse complète des risques informatiques pouvant exister sur votre SI, mais également sur ceux de vos prestataires afin de cartographier les échanges de flux (Cloud, applications en mode SaaS, réseau mobile…).

Cette analyse devra permettre d’identifier les points de vulnérabilité informatique pour planifier les actions correctives nécessaires.

Ce contrôle interne spécifique doit pouvoir examiner tous les comptes des systèmes informatiques, y compris ceux situés sur des sites extérieurs, les ressources du réseau et les équipements matériels reliés au réseau informatique de l’entreprise.

Dans le domaine de la banque par exemple, la cartographie des risques de non-conformité est obligatoire (voir arrêté du 03 novembre 2014). Elle permet une évaluation spécifique du risque informatique et des processus métier.

La conformité des droits d’accès de vos employés à votre réseau informatique doit également être passée en revue régulièrement afin que vous soyez en mesure de savoir précisément qui a accès à quoi, comment et suivant quel niveau de permission.

4. Gestion des risques informatiques

Vous devrez ensuite déployer une gestion des incidents informatiques (pannes, cyberattaques,…) pouvant être classés selon différents critères (criticité, durée, équipement concerné…).

Vos outils de résilience informatique doivent être capables de détecter les principales formes de cyberattaques (attaque par déni de service, phishing, ransomware, cassage de mot de passe, injection SQL…), mais aussi d’y faire face.

En cas d’incident informatique par exemple, vous devez disposer d’un contrat appelé SLA (Service Level Agreement) conclu avec votre prestataire informatique. Le SLA définit le niveau de qualité de service exigé, le processus prévu pour que votre réseau revienne à son fonctionnement normal sans perte de données et dans un délai raisonnable.

Cette gestion des risques informatiques comprend tous les protocoles, procédures et logiciels nécessaires à la protection efficace de votre matériel informatique, mais aussi des locaux et zones déclarés sensibles au risque informatique.

Elle doit permettre la protection de ces équipements et locaux, non seulement contre les attaques informatiques, mais aussi les dommages liés à un sinistre ou à une intrusion de personnel non autorisé.

Pour plus de détails sur les critères exigés par la directive DORA, merci de consulter l’Agence Européenne pour la Cybersécurité (ENISA).

5. Conduite de tests de résilience

Vous aurez également à faire procéder à des tests réguliers permettant de vérifier la bonne adéquation de vos équipements informatiques aux exigences de résilience opérationnelle numérique.

Ces tests devront être effectués par des spécialistes en cybersécurité formés à la cyber résilience. Digitemis peut vous accompagner dans cette démarche de tests de résilience opérationnelle numérique.

6. Encadrement des risques liés aux prestataires SI

La directive DORA a prévu des obligations contractuelles minimales pour toute prestation réalisée par un intervenant extérieur et ce, quelle que soit sa criticité. Vous devrez donc mettre en place une supervision de vos partenaires IT critiques et les soumettre à une évaluation sur leur gestion des risques SI.

Selon l’article 28 du règlement DORA, vous devrez respecter à minima certains principes généraux dans vos relations avec vos prestataires informatiques :

  • vous assurer que le prestataire respecte des normes de sécurité adéquates
  • indiquer les lieux de fourniture de services et de traitement des données
  • respecter les dispositions de disponibilité, d’authenticité, d’intégrité et de confidentialité des données, notamment à caractère personnel (RGPD)
  • ajouter des dispositions garantissant l’accès, la restitution ou la récupération des données en cas de nécessité (cessation d’activité, résiliation, …)
  • obligation pour le prestataire de fournir une assistance en cas d’incident
  • obligation pour le prestataire de coopérer avec les autorités compétentes
  • participation du prestataire aux programmes de sensibilisation ou de formation à la résilience opérationnelle numérique

7. Mécanismes d’échanges d’information sur les risques

Le règlement européen DORA (voir article 13) prévoit des mécanismes d’échange entre entités financières d’informations sur les cybermenaces. Des plans de communication doivent être mis en place à destination du personnel, des clients et du public afin de signaler tout incident ou vulnérabilité liés à l’informatique.

Cette stratégie de communication doit être pilotée par une ressource interne à l’entreprise qui fait office de porte-parole auprès du public et, le cas échéant, des médias.

Règlement DORA : quelles conséquences sur votre entreprise ?

Vous l’avez certainement compris en lisant cet article : la directive européenne DORA va demander de gros efforts d’adaptation aux entreprises concernées et des investissements en termes de temps, de ressources et de moyens.

En voici un résumé :

  • formation obligatoire des personnels concernés
  • mesures techniques de sécurité obligatoires
  • tests de résilience opérationnelle numérique
  • suivi des exigences concernant les prestataires de l’entreprise
  • détection des risques et des vulnérabilités
  • notifications auprès du personnel, du public, des médias
  • obligations contractuelles à documenter
  • gouvernance du risque informatique

Non-respect du règlement DORA

Le règlement DORA prévoit que les pays de l’Union Européenne pourront adopter des sanctions pénales spécifiques en cas de non-respect des obligations de résilience opérationnelle numérique, avec l’instauration d’une responsabilité spécifique pour les dirigeants (art. 46 du règlement DORA).

Ces sanctions pourront être appliquées par les « autorités compétentes » de chaque pays européens (en France : AMF, ACPR Banque de France, …), lesquelles disposeront de véritables pouvoirs d’enquête (inspection dans les locaux informatiques, injonction visant à faire cesser l’infraction à la réglementation DORA, astreintes journalières..).

La directive DORA n’est donc pas à prendre à la légère et, si vous n’avez pas encore pris les dispositions nécessaires pour vous mettre en conformité, Digitemis espère que cet article vous aura suffisamment éclairé.

Nous restons bien entendu à votre disposition pour vous apporter toute précision utile.

Je partage

Derniers articles

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article