DORA : les tests de résilience opérationnelle numérique

Découvrez tout ce qu’il faut savoir sur le programme de tests de résilience opérationnelle numérique, une obligation pour toutes les entités soumises à DORA.

Nota Bene : Cet article est le premier chapitre de notre guide sur les tests de sécurité pour les entités réglementées par DORA, que nous vous recommandons de lire depuis le début si ce n’est déjà fait.

Les tests de résilience opérationnelle numérique – que nous appellerons tests de résilience par la suite, par souci de concision – sont le premier niveau de test introduit par DORA. Ils sont obligatoires pour toutes les entités dans le scope du règlement, avec une exception pour les micro-entreprises, sur laquelle nous reviendrons.

Vous pouvez continuer à lire ce chapitre publié sous forme d’article sur notre blog, ou télécharger l’intégralité du guide DORA sur les tests de sécurité ci-dessous au format PDF pour une lecture plus aisée.

Un programme “solide et complet” de tests de résilience, avec une approche fondée sur le risque

Les tests de résilience ne sont pas des éléments isolés, mais doivent faire partie d’un “programme solide et complet de tests”, des mots de l’Article 24(3) de DORA. La construction de ce programme est à la charge des entités financières, tant il doit être adapté aux spécificités de chacune. N’attendez donc aucune checklist clé en main, qui serait réplicable pour chaque entité financière de l’Union.

Le programme de tests doit comprendre “une série d’évaluations, de tests, de méthodologies, de pratiques et d’outils” – sur lesquels nous reviendrons – et adopter une approche fondée sur le risque “ en prenant dûment en considération l’évolution du risque lié aux TIC, tout risque spécifique auquel l’entité financière concernée est ou pourrait être exposée, la criticité des actifs informationnels et des services fournis, ainsi que tout autre facteur que l’entité financière juge approprié.” [DORA, A.24(3)]

Les entités financières doivent également tenir compte du principe de proportionnalité édicté dans l’Article 4(2). Le programme doit donc être proportionné à leur taille et à leur profil de risque global, ainsi qu’à la nature, à l’ampleur et à la complexité de leurs services, activités et opérations. Autrement dit, DORA n’implique pas les mêmes obligations pour une grande banque internationale que pour une entreprise d’assurance à la taille modeste.

Remarquons ici que cette philosophie fait parfois grincer des dents au sein des grandes entreprises, tant elle semble déconnectée des réalités de l’ère numérique et du Big Data. En effet, la masse des données détenues par une entreprise n’est pas nécessairement proportionnelle à sa taille – un phénomène accentué par certaines réglementations en gestation telle que le Financial Data Access (FIDA), qui réglemente l’ouverture de l’accès aux données financières.

Par ailleurs, des obligations plus souples ne signifient pas l’absence totale de devoirs. Les entreprises de moindre envergure sont toujours soumises à des obligations de tests de sécurité, et l’accent mis par DORA sur la sécurité des tiers signifiera qu’une entreprise modeste fournissant des services à un établissement plus important devra, par effet de ricochet, effectuer des tests approfondis – notamment en matière des tests de pénétration basés sur les menaces (TLPT).

Un programme à intégrer au cadre de gestion du risque TIC…

Le cadre de gestion du risque lié aux TIC, introduit par l’Article 6, est un élément central de la législation. C’est lui qui doit détailler tous les éléments mis en place par l’entité régulée pour protéger :

• tous les actifs TIC et informationnels, soit les logiciels, le matériel informatique ou les serveurs, mais aussi les données qui sont des actifs à part entière.
• toutes les composantes et infrastructures physiques pertinentes pour la protection des actifs, comme les locaux et les data centers.

Oui, ce sont bien tous les actifs logiciels et les données qui sont visés ici.

… et à la stratégie de résilience opérationnelle numérique

Le Règlement DORA est structuré selon une approche fractale, et le sujet des tests ne fait pas exception à la règle. En effet, le cadre de gestion du risque TIC doit lui-même intégrer une stratégie de résilience opérationnelle numérique, et c’est elle qui, parmi d’autres choses, concrétise l’obligation de test.

“Le cadre de gestion du risque lié aux TIC comprend une stratégie de résilience opérationnelle numérique qui définit les modalités de mise en œuvre du cadre. À cette fin, la stratégie de résilience opérationnelle numérique précise les méthodes pour parer au risque lié aux TIC et atteindre des objectifs spécifiques en matière de TIC, en […] mettant en œuvre des tests de résilience opérationnelle numérique. ” – DORA, Article 6(8)

Cela peut sonner comme une évidence, tant le cadre de gestion du risque et la stratégie de résilience sont liés – le second étant induit par le premier. Rien de neuf sous le soleil pour les RSSI vétérans, même s’il est toujours bon de savoir où et comment organiser ses différentes politiques et documentations. Pour en savoir plus sur le cadre de gestion du risque TIC et la stratégie de résilience opérationnelle numérique, nous vous renvoyons vers notre guide de conformité DORA.

Des exigences plus souples pour les micro-entreprises

Précisons d’emblée que les exigences en matière de tests pour les micro-entreprises ne sont pas aussi rigoureuses que pour les autres entités financières. En effet, les micro-entreprises bénéficient d’un cadre simplifié de gestion du risque lié aux TIC [DORA, Article 16], et les tests de sécurité sont à réaliser en bonne intelligence, en fonction de leurs ressources et de leur exposition au risque. Le texte officiel de DORA est très clair à ce sujet :

“Les micro-entreprises effectuent les tests visés au paragraphe 1 en combinant une approche fondée sur les risques avec une planification stratégique des tests des TIC, en tenant dûment compte de la nécessité de maintenir une approche équilibrée entre, d’une part, l’ampleur des ressources et le temps à consacrer aux tests des TIC prévus au présent article et, d’autre part, l’urgence, le type de risque, la criticité des actifs informationnels et des services fournis, ainsi que tout autre facteur pertinent, y compris la capacité de l’entité financière à prendre des risques calculés.” – DORA, Article 25.3

Là encore, il nous semble important de nuancer ce passage. La sécurité de la chaîne d’approvisionnement est au cœur des grandes législations européennes en matière de cyber, de DORA à NIS2 en passant par le Cyber Resilience Act (CRA). On peut donc s’attendre à ce que les petites entreprises qui fournissent des services aux grandes institutions financières ressentent les effets des exigences qui leur sont applicables en matière de contrôle des risques pour les tiers, et ne soient donc pas exemptées de tout effort.

Lire aussi : NIS2 vs DORA : quelles différences et quelle législation prévaut ?

Quels systèmes faut-il tester ?

Le programme de tests de résilience doit être construit en accord avec le cadre de gestion du risque et ses objectifs. Il ne s’agit pas de tester uniquement les actifs logiciels, mais bien de s’assurer que tous les actifs sont correctement protégés. Il est donc question de tester la sécurité des logiciels, du code, des réseaux, des infrastructures cloud, des infrastructures physiques, etc.

Au moins une fois par an pour les systèmes qui soutiennent des fonctions critiques ou importantes

Dans les mots de DORA, les entités financières doivent soumettre “au moins une fois par an, tous les systèmes et applications de TIC qui soutiennent des fonctions critiques ou importantes à des tests appropriés.”. [Article 24(6)]

Il est entendu que conduire des tests sur ces systèmes une fois par an est un minimum légal, et qu’une fréquence plus soutenue sera plus que bienvenue. Il est d’ailleurs curieux de constater que le régulateur raisonne sur la base de la fréquence de contrôle, alors qu’une approche continue serait plus en phase avec les pratiques et les enjeux de notre époque – agilité, déploiement continu, interconnexions, richesse fonctionnelle en forte croissance…

Par ailleurs, les tests périodiques n’offrent qu’une visibilité restreinte, ancrée dans l’instant, ce qui expose les entreprises aux risques potentiels qui peuvent survenir pendant les intervalles entre chaque test. Les cyberattaquants sont habiles à exploiter rapidement les vulnérabilités, et se fier à des évaluations sporadiques n’est tout simplement pas suffisant dans le paysage actuel des menaces.

Au risque de nous répéter, il est évident que ces tests annuels exigés par DORA sont un strict minimum. Il s’agit ici de tester des systèmes essentiels au bon fonctionnement d’entités financières elles-mêmes essentielles à notre société ; le niveau de sécurité doit être exemplaire.

En adoptant une approche de test continu, il ne s’agit pas tant de faire partie des meilleurs élèves que de ne pas rejoindre les plus atones, qui seront aussi les plus vulnérables. Et en matière de sécurité, les conséquences sont bien plus dramatiques qu’une mauvaise note.

Si vous souhaitez creuser le sujet, nous vous recommandons la lecture de notre article Tests de sécurité : de la nécessité d’une approche continue.

Des tests à conduire en interne ou avec un prestataire

Les tests peuvent être conduits par des prestataires externes, ou internalisés à la condition de veiller à l’absence de conflits d’intérêt pendant les phases de conception et d’exécution du test. Le texte officiel de DORA ne pourrait être plus clair :

“Les entités financières, autres que les microentreprises, veillent à ce que les tests soient effectués par des parties indépendantes internes ou externes. Lorsque les tests sont effectués par un testeur interne, les entités financières leur accordent des ressources suffisantes et veillent à éviter les conflits d’intérêts pendant les phases de conception et d’exécution du test.” – DORA, Article 24(4)

Si DORA autorise l’internalisation des tests, la réalité du terrain amènera probablement la plupart des entités à jongler entre compétences internes et prestataires externes. En effet, les tests à réaliser sont nombreux, éclectiques et récurrents, et seules les grandes entreprises disposent des ressources humaines, techniques et financières inhérentes à une internalisation totale.

Les typologies de tests de sécurité préconisées par DORA

L’Article 25 de DORA précise quelques-unes des typologies de tests à conduire :

• des évaluations et des analyses de vulnérabilité;
• des analyses de sources ouvertes – cf. notre article Comprendre l’OSINT.
• des évaluations de la sécurité des réseaux;
• des analyses des écarts;
• des examens de la sécurité physique;
• des questionnaires et des solutions logicielles de balayage (des scanners de vulnérabilités donc);
• des examens du code source lorsque cela est possible;
• des tests fondés sur des scénarios;
• des tests de compatibilité;
• des tests de performance;
• des tests de bout en bout;
• et des tests de pénétration.

Comme vous pouvez le constater, les tests mentionnés par DORA sont aussi nombreux que variés. Certains relèvent de la Threat Intelligence et visent à recueillir des informations sur les menaces, là où d’autres mettent à l’épreuve la sécurité physique des organisations, comme les bureaux ou les salles informatiques (datacenters).

Il en va de même pour les tests qui visent à éprouver la cybersécurité des systèmes : ils sont éclectiques, ne poursuivent pas les mêmes objectifs, et ne s’inscriront pas de la même manière dans la stratégie de résilience des organisations. Par exemple, certains servent à évaluer la sécurité et/ou le bon fonctionnement des applicatifs produits (ou acquis) par les entités financières, comme les revues de code et les tests de bout en bout, aux côtés des tests unitaires et des tests d’intégration. Ceux-là sont à préférer en amont de la mise en production, au cours du cycle de développement (SDLC) dans le cadre d’une approche DevSecOps.

D’autres tests vérifient la robustesse des lignes de défense, comme les évaluations de la sécurité des réseaux, voire cherchent à détecter les vulnérabilités de manière proactive, de façon automatique (les scanners de vulnérabilités) ou manuelle (les tests de pénétration). Ceux-là font partie de ce qu’on appelle la Sécurité Offensive, ou OffSec.

Le rôle de la Sécurité Offensive dans la stratégie de tests

L’OffSec est une approche proactive de la cybersécurité. Elle est complémentaire des mesures défensives, comme la protection des réseaux et les EDR, mais poursuit des objectifs différents. La Sécurité Offensive ne cherche pas à protéger les actifs numériques, mais à identifier leurs vulnérabilités avant les acteurs malveillants.

Les tests OffSec simulent des attaques contre des actifs en adoptant la posture des cyberattaquants, et leurs méthodes, afin d’éprouver les défenses des organisations, d’identifier leurs faiblesses potentielles, et d’évaluer leur niveau de sécurité réel. L’OffSec permet de tester presque tous les types d’actifs, des infrastructures cloud aux applications web et mobile en passant par les API et l’IoT.

Lire aussi : Qu’est-ce que l’OffSec ? Un guide d’intro à la sécurité offensive

Si l’on vous dit tout cela, ce n’est pas par hasard, mais parce que nous – Yogosha – sommes spécialisés dans les tests de sécurité offensifs.

De la nécessité de moderniser les tests de sécurité

Le pentest, ou test de pénétration, est une approche recommandée par l’Article 25 de DORA. C’est une technique qui vise à simuler une attaque informatique contre un actif, afin d’identifier le gros de ses vulnérabilités, et de s’assurer de son imperméabilité numérique. Le pentesting est un outil de cybersécurité qui existe depuis longtemps, et que les équipes de sécurité connaissent déjà bien. Mais même les méthodes éprouvées ont parfois besoin d’être remises au goût du jour.

Le principe du test d’intrusion occasionnel a été instauré à une époque où la teneur des applications et sites web était stable, le nombre de ressources à auditer faible, et les techniques de pénétration à explorer réduites. Désormais, une application bancaire majeure est réactualisée tous les mois, et les techniques d’intrusion se comptent par centaines.

Il faut donc imaginer un dispositif collaboratif, appuyé sur des communautés de chercheurs en cybersécurité suffisamment massives pour apporter l’assurance qu’aucune technique d’intrusion n’aura été oubliée, pour agir en continu et pallier la pénurie mondiale de compétences.

Pentest as a Service (PtaaS)

Avec le Pentest as a Service (PtaaS), Yogosha propose un nouveau modèle en digitalisant les activités de pentest, pour des résultats en temps réel et des lancements plus rapides – quelques jours contre 3 à 6 semaines pour un pentest traditionnel. Notre plateforme rend les tests plus efficaces et plus fluides, qu’ils soient réalisés en interne par vos équipes de sécurité, ou par la Yogosha Strike Force, notre communauté de plus de 800 chercheurs en sécurité certifiés.

Lire aussi : Pentest as a Service vs pentest traditionnel, quelles différences ?

Le Pentest as a Service (PtaaS) permet ainsi de répondre à l’un des défis majeurs posés par DORA et les tests de résilience : celui du passage à l’échelle de la cybersécurité. Il s’agit d’un enjeu fondamental, qui soulève des questions de processus et de coûts, sur lequel nous reviendrons plus après – le lien est en fin de page.

Bug Bounty

Lorsqu’un niveau de sécurité suffisamment avancé est atteint, les tests d’intrusion montrent leurs limites. Ils sont limités dans le temps, laissent peu de place aux approches originales et sont tributaires de l’expertise d’un petit nombre de personnes.

Ici, le Bug Bounty est une solution toute désignée pour prendre la relève, en permettant aux organisations de se confronter à la réalité du terrain, grâce à la mobilisation d’une communauté de chercheurs en sécurité pour tester tout ou partie des systèmes d’information.

Lire aussi : Pentest vs Bug Bounty, quelle approche pour quelle situation ?

Le Bug Bounty est une chasse aux bugs qui repose sur une logique de paiement au résultat. Les organisations versent des récompenses monétaires – les bounties donc – aux chercheurs pour chaque vulnérabilité valide qu’ils parviennent à identifier. Plus la vulnérabilité est critique, plus la prime est importante. Si aucune vulnérabilité n’est détectée, l’organisation n’engage aucune dépense.

Les chercheurs examinent les actifs en utilisant toute une série d’outils, de tactiques et de procédures pour déceler les vulnérabilités critiques en profondeur, qui échappent à d’autres formes de tests plus calibrées, comme les scanners automatiques. Les vulnérabilités découvertes sont documentées avec leur score CVSS, des preuves de concept (POC) et des conseils de remédiation, et signalées en direct sur une plateforme centralisée de gestion des vulnérabilités, notre Vulnerability Operations Center (VOC).

Le Bug Bounty s’inscrit dans la lignée des approches fondées sur le risque recommandées par DORA, NIS2, le CRA et d’autres législations majeures en matière de sécurité numérique.

Dans le cadre de DORA, le Bug Bounty a le double avantage d’être :

• un test de résilience complet pour évaluer la sécurité des actifs exposés dans des situations contrôlées au plus proche du réel ;
• une façon de faire le lien entre les tests de résilience d’une part, et les tests de pénétration fondés sur la menace (TLPT) d’autre part. Ces deux niveaux de tests introduits par DORA suivent une courbe de difficulté très différente, et le bug bounty intervient comme une étape intermédiaire qui permet aux entités réglementées d’évaluer leur capacité à se confronter à une attaque réelle, mais aussi à s’engager dans la réalisation d’un test de pénétration fondé sur la menace – cf. notre article sur le ROI des TLPT.

Les tests de résilience opérationnelle numérique en bref

Pour résumer, les tests de résilience sont :

• obligatoires pour toutes les entités réglementées par DORA ;
• à regrouper en un programme de tests de résilience opérationnelle numérique ;
  • avec une approche fondée sur le risque ;
  • et construit en adéquation avec le cadre de gestion du risque et de ses objectifs, à savoir garantir que tous les actifs de l’entité – matériels et immatériels, alias les données – sont correctement protégés, et appelant par la même occasion autant de tests de sécurité que nécessaire ;
• à conduire au moins une fois par an pour tous les systèmes et applications qui soutiennent des fonctions critiques ou importantes.

Comme indiqué plus haut dans cet article, la réglementation fixe un minimum légal à respecter, mais la notion même de tests de sécurité ponctuels n’est plus en phase avec les méthodes de développement et les enjeux de sécurité modernes.

Pour être à l’état de l’art en matière de résilience numérique, les entités réglementées devraient, lorsque c’est possible, mettre en œuvre des tests continus, tout en conservant la base des méthodologies qui ont fait leurs preuves. À cet égard, l’Article 25 de DORA dresse une liste non exhaustive des tests à réaliser, parmi lesquels les tests d’intrusion.

Précisons ici que Yogosha propose une offre de Pentest as a Service (PtaaS) taillée pour les entités assujetties à DORA, afin de répondre à cette injonction de réaliser des pentests d’une part, et à la nécessité de les rendre continus d’autre part. N’hésitez pas à nous contacter pour un devis ou une démo.

Enfin, il convient de noter que le nombre, la diversité et la récurrence des tests induits par DORA ne vont pas sans soulever quelques difficultés. En effet, une telle intensification des tests de sécurité est susceptible de s’accompagner d’une augmentation substantielle des coûts et de la charge de travail pour les organisations qui n’y sont pas préparées.

Ce sujet primordial fait l’objet du deuxième et prochain chapitre de ce guide sur les tests de sécurité :