Guide du pentester pour les tests de conformité DORA et de cybersécurité

Introduction

Bonjour, je suis Alix, pentester à Approach Cyber. Si vous avez cliqué sur ce billet, il y a de fortes chances que vous soyez, tout comme moi, intrigué par la loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act, DORA) [1]. Compte tenu de son importance croissante, j’ai décidé de me pencher sur ce qu’elle implique réellement. Dans ce billet de blog, vous découvrirez la portée de la loi DORA, c’est-à-dire le « quand », le « quoi », le « qui » et le « pourquoi » qui la sous-tendent. En outre, je vais vous éclairer sur un sujet qui est étroitement lié à mon travail quotidien : les tests opérationnels numériques. Plus précisément, j’explorerai les domaines qu’un pentester comme moi peut aborder dans le cadre de ces tests. Si vous vous demandez si les DORA s’appliquent à votre entreprise, quels sont les tests auxquels vous devez vous préparer, ou si vous souhaitez simplement comprendre les bases des DORA, ce blog est fait pour vous ! Alors, sans plus attendre, plongeons dans le vif du sujet.

Qu’est-ce que DORA ?

Inscrivez cette date dans votre agenda : À partir du 17 janvier 2025, le secteur financier européen s’apprête à vivre un grand changement ! À cette date, la loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act, DORA) sera mise en œuvre. Tout comme le règlement général sur la protection des données (RGPD)[2], la loi DORA est un règlement européen[3]. Cela signifie que dès le départ, il s’appliquera directement à un large éventail d’entités, sans qu’il soit nécessaire de le transformer en loi nationale, contrairement aux directives.

DORA, pour qui ?

Avant d’aller plus loin, il peut être utile de déterminer si la loi DORA s’applique à vous. En examinant l’article 2 de la loi DORA, il apparaît clairement qu’elle s’applique bien au-delà des institutions financières traditionnelles. Il inclut les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d’investissement, les prestataires de services de crypto-actifs et les compagnies d’assurance, pour n’en citer que quelques-uns [4]. Bien que cette liste semble déjà assez longue, DORA incorpore une certaine flexibilité pour les micro-entreprises[5], les petites entreprises et les petites et moyennes entreprises (PME) dans son quatrième article. En outre, la loi DORA s’applique également aux fournisseurs de services TIC tiers des entités financières, sans aucune exception.

Oui, vous avez bien lu. Les fournisseurs de services TIC tiers figurent bel et bien sur la liste, et vous vous demandez peut-être pourquoi.

L’intégration des fournisseurs de services TIC tiers dans le champ d’application de la loi DORA est une décision stratégique. L’objectif est de réduire les risques associés aux attaques de la chaîne d’approvisionnement, comme le tristement célèbre incident de SolarWinds[6]. Lors de cette violation de la cybersécurité, un groupe de menace persistante avancée (APT) connu sous le nom d’APT29[7] a réussi à s’infiltrer dans le réseau de SolarWinds. Il a implanté un code malveillant dans une mise à jour du logiciel Orion. Cela a déclenché une cascade de compromissions qui ont mis en danger de nombreuses organisations, y compris des organismes gouvernementaux clés et de grandes entreprises.

C’est précisément à cause de cette menace que le cadre du DORA inclut les fournisseurs de services TIC tiers.

Les objectifs ?

Pourquoi DORA ? Il a été créé pour renforcer la résilience du secteur financier de l’UE. Ainsi, tous les acteurs peuvent s’assurer que leurs systèmes et services TIC restent disponibles, intacts et confidentiels. Mais qu’entend-on vraiment par résilience ? Le règlement considère la résilience opérationnelle numérique comme la capacité de construire, de maintenir et d’évaluer les éléments essentiels des TIC qui protègent les réseaux et les systèmes d’information dont dépendent les entités financières.

En d’autres termes, DORA garantit la continuité et la qualité des services financiers, même en cas de perturbations.

Les conséquences ?

Maintenant que nous connaissons mieux ce nouveau règlement, il est important de comprendre les répercussions de son non-respect.

Le DORA ne se contente pas de suggérer – il insiste sur le fait qu’il faut être prêt et capable de se remettre rapidement des perturbations des TIC. Le règlement confère aux autorités compétentes le pouvoir de superviser, d’enquêter et d’imposer des sanctions pour garantir le respect des règles, comme le souligne l’article 50 du DORA[8]. Le non-respect des exigences de la DORA peut entraîner de lourdes sanctions. Celles-ci comprennent la suspension des activités, la nécessité de divulguer des informations au public et d’importantes sanctions financières. Suivre les lignes directrices du DORA, ce n’est pas seulement cocher des cases de conformité. Il s’agit d’un engagement continu à renforcer nos défenses contre les cybermenaces dynamiques qui ciblent le secteur financier, en garantissant la résilience et l’intégrité de nos opérations numériques.

Programme d’essais opérationnels numériques de DORA

Et maintenant, passons aux choses techniques que nous aimons tous. L’article 25[9] du DORA décrit les tests de résilience opérationnelle numérique que les entités financières doivent entreprendre. Ces tests vont des « évaluations et analyses de vulnérabilité » aux « tests de pénétration ». Le champ d’application est vaste et couvre les analyses de sources ouvertes, les évaluations de la sécurité des réseaux, les analyses des lacunes, les examens de la sécurité physique et, dans la mesure du possible, les examens du code source. Il comprend également des tests de scénario et de compatibilité, ainsi que des tests de performance et des tests de bout en bout. En couvrant tous les aspects de la sécurité d’un système d’information, DORA vise à garantir sa robustesse et sa résilience.

Cependant, il est important de rappeler que le 4e article[10] de la DORA introduit un aspect de flexibilité et de considération dans son approche. Il établit le principe de proportionnalité, en soulignant que la mise en œuvre des mesures de cybersécurité et des tests de résilience devrait être alignée sur la taille, le profil de risque et la complexité opérationnelle de chaque entité financière. Les petites entités ou celles qui sont confrontées à différents types de risques sont ainsi en mesure d’adopter une stratégie de cybersécurité à la fois efficace et gérable, adaptée à leur situation spécifique sans être écrasante.

Dans les prochains paragraphes, je vais démystifier tout ce qui peut être couvert par une équipe de piratage éthique. Malheureusement, cela n’inclura pas « l’analyse des lacunes », « les tests de compatibilité », « les performances » et « l’examen du code source », car cela ne fait pas partie de mon rôle actuel à Approach Cyber.

Analyse et évaluation de la vulnérabilité

La plongée dans les « analyses et évaluations de la vulnérabilité », soulignée non seulement à l’article 25 mais aussi à l’article 8[11] du DORA, met en évidence l’importance de l’identification continue des risques liés aux TIC. Une analyse de vulnérabilité est avant tout un processus automatisé visant à détecter les faiblesses connues des systèmes en matière de sécurité. Il s’agit d’un bon élément pour l’entretien de routine de la sécurité, qui fournit une vue d’ensemble des vulnérabilités potentielles. Cependant, il est essentiel de comprendre que ces analyses ne remplacent pas les tests de pénétration manuels. Si les analyses peuvent mettre en évidence des vulnérabilités connues, les tests de pénétration manuels vont beaucoup plus loin. Ils impliquent qu’un testeur imite des attaques réelles et fasse preuve de créativité pour découvrir des vulnérabilités complexes et des séquences d’exploitation que les outils automatisés ne verront pas.

Analyse en source ouverte ?

Le prochain point à l’ordre du jour du DORA est l’analyse des sources ouvertes, qui, à mon avis, est étroitement liée au renseignement de source ouverte (OSINT)1. Pour les non-initiés, l’OSINT implique la collecte, le stockage et l’analyse de données accessibles au public. Il peut s’agir de n’importe quoi, des fuites de mots de passe aux informations confidentielles d’une entreprise. Si la surveillance régulière de ces informations n’est peut-être pas une pratique courante pour de nombreuses organisations, elle est indispensable pour les équipes qui mènent des exercices de type « red team » (de bout en bout). En parlant d’équipes rouges, ces exercices ne sont pas de simples contrôles de sécurité de routine et ne consistent pas uniquement à tester la sécurité des systèmes ou des applications. Il s’agit également d’examiner les politiques organisationnelles et l’élément humain afin d’identifier le chemin d’exploitation le plus critique. Et d’évaluer l’efficacité des défenses et des procédures en place.

Évaluations de la sécurité des réseaux

Pour passer au point suivant, le DORA inclut l’évaluation de la sécurité du réseau parmi ses exigences. Dans le jargon des pentesters, il s’agit généralement de tests de pénétration de l’infrastructure interne et de pentest des répertoires d’utilisateurs. Ces types de tests ne peuvent être omis dans le cadre d’une évaluation mature de l’organisation. Ils permettent d’identifier les lacunes potentielles dans les composants du réseau et d’évaluer non seulement les vulnérabilités, mais aussi l’escalade des privilèges2 et les vecteurs d’exécution a posteriori (étapes 5 à 7 du schéma ci-dessous).

Au fur et à mesure que l’entreprise se développe et que son infrastructure évolue, la complexité du maintien à jour des dispositifs, des comptes et des politiques augmente. Des erreurs de configuration, même mineures, peuvent avoir un impact significatif sur l’ensemble du système d’information (SI)[12].

Bien que la loi DORA exige spécifiquement des tests annuels de l’infrastructure et de l’annuaire des utilisateurs, cette meilleure pratique est recommandée à toutes les organisations, et pas seulement à celles du secteur financier. La réalisation de ces tests est essentielle pour maintenir une posture proactive en matière de cybersécurité et prévenir les violations.

Sécurité physique et essais de bout en bout

Alors que nous abordons l’avant-dernier sujet de notre discussion, les examens de la sécurité physique et les tests de bout en bout sont à l’honneur. Ces examens sont une composante essentielle d’une stratégie de sécurité globale. Elles se concentrent sur les aspects physiques de la protection d’une organisation, qui sont souvent inclus dans les exercices de l’équipe rouge. Ils englobent un large éventail de tactiques, allant de l’évaluation de la sécurité des réseaux Wi-Fi et câblés aux fameux tests de chute USB. Un facteur clé de ces examens est la compréhension et l’atténuation des risques liés à l’ingénierie sociale[13].

Test de pénétration basé sur la menace (TLPT)

Enfin, les tests de pénétration basés sur des scénarios, ou tests de pénétration basés sur les menaces (TLPT). Les TLPT consistent à auditer des environnements de production en direct sur la base d’un scénario prédéfini par l’entité financière mais validé par les autorités compétentes. Il est obligatoire que ces tests soient effectués au moins tous les trois ans par une entité externe. Surtout si l’organisme financier dispose déjà d’une équipe interne de piratage éthique. En conséquence, l’entité doit présenter aux autorités un résumé des résultats pertinents, des plans d’action correctifs et des documents de conformité.

Les normes techniques réglementaires, telles que les critères, les méthodologies et les processus, sont définies dans le cadre TIBER-UE[14][15], dont les détails dépassent le cadre de ce blog. Toutefois, comme le décrit le 26e article du DORA[16], les services TIC de tiers entrent dans le champ d’application de ce type de tests, les entités financières conservant toujours l’entière responsabilité d’assurer la conformité avec la réglementation.

Les exigences du DORA en matière de tests de pénétration favorisent une interaction permanente et dynamique entre l’équipe rouge et l’équipe bleue. En effet, le secteur financier nécessite une stratégie de cybersécurité qui englobe à la fois l’attaque et la défense. Dans ce contexte, les tests de pénétration permettent aux entreprises d’anticiper les violations potentielles et d’atteindre un état de préparation et de résilience. Cette approche proactive s’aligne sur la vision de DORA en matière de robustesse opérationnelle, garantissant que les organisations ne sont pas seulement préparées à faire face aux menaces actuelles, mais qu’elles sont également équipées pour s’adapter aux défis futurs.

Gardez une longueur d’avance avec les services de piratage éthique de Approach Cyber.

Et assurez-vous que votre système est prêt pour les mises à jour.

Puisse l’équilibre entre le rouge et le bleu persister dans le renforcement de nos défenses numériques.

Conclusion

Et voilà, nous avons fait un tour complet (je l’espère) de la loi sur la résilience opérationnelle numérique (Digital Operational Resilience Act, ou DORA), comme nous l’avons appris à la lire sur ce blog. Nous avons commencé par les bases – « quoi », « qui », « quand » et « pourquoi » – et nous avons plongé dans le domaine des tests opérationnels numériques. Ici, en tant que pentester, j’ai pu partager une tranche de ma vie quotidienne à Approach Cyber. De la compréhension du champ d’application étendu de la loi DORA à la décomposition de l’essence des tests de résilience, notre voyage a consisté à découvrir comment ces réglementations peuvent façonner l’épine dorsale de la cybersécurité du secteur financier.

J’espère sincèrement que cet article vous aura éclairé sur le DORA. Que vous soyez curieux de son application à votre organisation, des spécificités des tests de conformité ou simplement de l’évolution du paysage de la cybersécurité. N’hésitez pas à laisser un commentaire ou à partager cet article sur LinkedIn si vous pensez qu’il peut être utile à d’autres. Vous trouverez un autre de mes blogs ici.
Et un grand merci d’être resté jusqu’à la fin de cette discussion.

1. C’est mon point de vue de hacker éthique. L’analyse des risques et de la sécurité des logiciels libres (OSSRA) relève du domaine de l’examen du code source. Pour plus d’informations : https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2023.pdf ↩︎
2. Telle que définie dans la norme NIST SP 800-115, section 2.4.1, page 16, paragraphe 5. ↩︎