Latest Stories

Stay up-to-date with everything at Approach

Blog article

A pentester’s guide to DORA compliance and cyber security testing

Publication date

11.06.2024

DORA is reshaping cyber security in the financial sector—explore its impact, compliance essentials, and the role of ethical hacking in ensuring resilience.

Introduction

Hello, I’m Alix, a pentester at Approach Cyber. If you’ve clicked on this blog post, chances are you’re intrigued by the Digital Operational Resilience Act (DORA) [1], just as I was. Given its growing importance, I decided to delve into what it really entails. In this blog post, you’ll uncover the scope of DORA—essentially, the « when, » « what, » « who, » and « why » behind it. Moreover, I’ll shed light on a topic that closely aligns with my day-to-day work: Digital Operational Tests. Specifically, I’ll explore the areas a pentester like myself can address within these tests. Whether you’re wondering if DORA applies to your company, what tests you need to prepare for, or if you’re simply keen to grasp the basics of DORA, this blog is made for you! So, without further ado, let’s dive right in.

What is DORA?

Mark your calendars: Starting January 17th, 2025, the European financial sector is set for a big change! On this date, the Digital Operational Resilience Act (DORA) will be implemented. Just like the General Data Protection Regulation (GDPR)[2], DORA is a European regulation[3]. This means that right from the start, it will directly apply to a wide range of entities without the need to be turned into national law, unlike directives.

DORA, for who?

Before we dive deeper, it might be helpful to determine if DORA will apply to you. Diving into Article 2 of DORA, it’s clear that it reaches well beyond traditional financial institutions. Including credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, and insurance companies, just to name a few [4]. While this list already seems quite extensive, DORA incorporates flexibility for micro-enterprises[5], small enterprises, and small and medium-sized enterprises (SMEs) in its 4th article. Additionally, DORA also applies to ICT third-party service providers of financial entities without any exception.

DORA's scope MEME

Yes, you read that correctly. ICT third-party service providers are definitely on the list, and you might be wondering, « Why is that? ».

Bringing ICT third-party service providers within DORA’s scope is a strategic move. The aim is to reduce the risks associated with supply-chain attacks, such as the infamous SolarWinds incident[6]. During this cyber security breach, an Advanced Persistent Threat (APT) group known as APT29[7] managed to infiltrate SolarWinds’ network. They implanted malicious code in an update of the Orion Software. This triggered a cascade of compromises that endangered numerous organisations, including key government bodies and major corporations.

DORA’s framework includes ICT third-party service providers because of this very threat.

The objectives?

So, why DORA? It was established to fortify the resilience of the EU financial sector. Thereby making sure all players can keep their ICT systems and services available, intact, and confidential. But what do we really mean by resilience? The regulation views digital operational resilience as the ability to construct, maintain, and evaluate the ICT essentials that safeguard the networks and information systems financial entities depend on.

Simply put, DORA ensures the continuous flow and quality of financial services, even when faced with disruptions.

The consequences?

Now that we’re more familiar with this new regulation, it’s important to understand the repercussions of non-compliance.

DORA doesn’t just suggest—it insists on being ready for and able to quickly recover from ICT disruptions. The regulation arms competent authorities with the power to oversee, investigate, and impose sanctions to ensure adherence, as highlighted in DORA’s Article 50[8]. Failing to comply with DORA’s requirements could lead to serious penalties. This includes the suspension of operations, the necessity for public disclosures, and significant financial penalties. Following DORA’s guidelines isn’t just about checking off compliance boxes. It is a continuous commitment to enhancing our defences against the dynamic cyber threats targeting the financial sector, ensuring the resilience and integrity of our digital operations.

Financial entities' ICT third party service provider after reading DORA's scope

 

DORA’s digital operational testing program

And now, onto the techy stuff we all love. Article 25[9] of DORA outlines the digital operational resilience tests that financial entities must undertake. These tests range from ‘vulnerability assessments and scans’ to ‘penetration testing’. The scope is extensive, covering open-source analyses, network security assessments, gap analyses, physical security reviews, and, where possible, source code reviews. It also includes scenario-based and compatibility tests, as well as performance and end-to-end testing. By covering every aspect of an information system’s security, DORA aims to ensure its robustness and resilience.

However, it is important to remember that DORA’s 4th Article[10] introduces an aspect of flexibility and consideration in its approach. It establishes the principle of proportionality, accentuating that the implementation of cyber security measures and resilience tests should be aligned with the size, risk profile, and operational complexity of each financial entity. Smaller entities or those facing different types of risks are thus able to adopt a cyber security strategy that is both effective and manageable, tailored to their specific circumstances without being overwhelming.

In the next few paragraphs, I will debunk everything that can be covered by an ethical hacking team. Unfortunately this will not include ‘Gap analysis’, ‘compatibility testing’, ‘performance’ and ‘source code reviews’ as those are out of scope of my current role at Approach Cyber.

Asking a p

 

Vulnerability scans and assessments

Diving into « vulnerability scans and assessments, » highlighted not just in Article 25 but also in Article 8[11] of DORA, emphasizes the importance of continuously identifying ICT risks. A vulnerability scan is primarily an automated process aimed at detecting systems’ known security weaknesses. Serving as a good component for routine security upkeep, it provides a comprehensive overview of potential vulnerabilities. Yet, it’s crucial to understand that these scans are not a stand-in for manual penetration testing. While scans can pinpoint known vulnerabilities, manual penetration testing delves much deeper. It involves a tester mimicking real-life attacks and employing creative thinking to uncover complex vulnerabilities and exploit sequences that automated tools will overlook.

vulnerability scan is not a pentest - MEME

 

Open-source analysis?

Next on DORA’s agenda is open-source analysis, which, in my view, is closely linked to open-source intelligence (OSINT)1. For the uninitiated, OSINT entails the gathering, storing, and analysis of data that is publicly available. This can include anything from leaked passwords to confidential company information. While regularly monitoring such information might not be standard practice for many organisations, it’s a must-do for teams conducting red team (end-to-end) exercises. Speaking of red teams, these exercises are not just routine security checks neither do they are just about testing the security of systems or applications. They’re also about examining organisational policies and the human element to identify the most critical path of exploitation. And evaluate the effectiveness of the defences and procedures in place.

Network Security Assessments

Moving on to the next point, DORA includes network security assessment among its requirements. In a pentester’s jargon, this typically refers to internal infrastructure penetration tests as well as user directory pentests. Those kinds of tests cannot be omitted in a mature organisation assessment. It allows to identify potential gaps in network components and assessing not only vulnerabilities but also privilege escalation2 and post-execution vectors (step 5 to 7 of the below).

Lokcheed Martin Cyber Kill Chain by AnLoMinus

As the business grows and its infrastructure evolves, the complexity of maintaining up-to-date devices, accounts, and policies increases. Even minor misconfigurations can significantly impact the overall Information System (IS)[12].

While DORA specifically requires annual infrastructure and User Directory testing, this best practice is recommended for all organisations, not just those in the financial sector. Performing these tests is essential to maintain a proactive cyber security posture and prevent breaches.

Asking a pentester how he got in the network - meme

 

Physical security and end-to-end testing

As we move towards the penultimate topic of our discussion, physical security reviews and end-to-end testing take the spotlight. These reviews are an essential component of a comprehensive security strategy. They focus on the physical aspects of safeguarding an organization which are often included in red team exercises. They encompass a wide range of tactics, from assessing the security of Wi-Fi and wired networks to the known USB drop tests. A key factor in these reviews is understanding and mitigating social engineering risks[13].

Red Team depth - meme

 

Threat-Led Penetration Testing (TLPT)

Finally, scenario-based penetration testing, or threat-led penetration testing (TLPT). TLPT involves auditing live production environments based on predefined scenario defined by the financial entity but validated by the competent authorities. It is mandatory that these tests be conducted at least every three years by an external entity. Especially if the financial organisation already has its own internal ethical hacking team. As a result, the entity must present a summary of relevant findings, corrective action plans, and compliance documentation to the authorities.

While the regulatory technical standards, such as;  criteria, methodologies, and processes; are defined in the TIBER-EU framework[14][15], the details of which are beyond the scope of this blog. However, as described in DORA’s 26th Article[16], ICT third-party services are within scopes of those kind of tests, the financial entities always retain full responsibility for ensuring compliance with the regulation.

DORA’s penetration testing requirements foster an ongoing and dynamic interaction between the red team and the blue team. Because the financial sector necessitates a cyber security strategy that encompasses both offense and defence. In this context, penetration testing enables companies to anticipate potential breaches and achieve a state of readiness and resilience. This proactive approach aligns with DORA’s vision of operational robustness, ensuring that organisations are not only prepared to face current threats but are also equipped to adapt to future challenges.

Stay ahead of the game with Approach Cyber’s ethical hacking services.

Ready for pentest - meme

And ensure your system is ready for updates.

not ready for pentest - meme

May the balance between the red and blue persist in strengthening our digital defences.

Conclusion

And there we have it, a comprehensive (I hope) walkthrough of the Digital Operational Resilience Act, or DORA, as we’ve come to know it throughout this blog. We started with the basics—the ‘what’, ‘who’, ‘when’, and ‘why’—and delved deep into the realm of digital operational tests. Here, as a pentester, I could share a slice of my day-to-day life at Approach Cyber. From understanding DORA’s wide-reaching scope to breaking down the essence of resilience testing, our journey has been about unpacking how these regulations can shape the backbone of financial sector cyber security.

I genuinely hope this piece has shed some light on DORA for you. Whether you were curious about its application to your organisation, the specifics of compliance testing, or just keen on the cyber security field’s evolving landscape. Feel free to leave a comment or share this post on LinkedIn if you think it could benefit others. You can find another blog of mine here.
And a big thank you for sticking through to the end of this discussion.


  1. This is my ethical hacker point of view. As ‘open-source security and risk analysis (OSSRA)’ fall under the scope of ‘source code review’ more information : https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2023.pdf ↩︎
  2. As defined in NIST SP 800-115, Section2.4.1, page 16, paragraph 5. ↩︎

OTHER STORIES

No related content yet

Contact us to learn more about our services and solutions

Our team will help you start your journey towards cyber serenity

Do you prefer to send us an email?