How API Security Factors into DORA Compliance

Complying with data protection regulations isn’t easy, but it has traditionally involved dealing with familiar risks. For example, do your IT admins have the right amount of access to systems touching sensitive information? Review, remediate, report, and repeat. Compliance has been cumbersome, but workable. The problem is, today’s attack surface is nowhere near workable. And it’s evolving to include threats that most compliance programs aren’t yet accounting for. 

A key example: API breaches.

Every time a customer, partner, or vendor engages with your organization digitally, there’s an API behind the scenes facilitating a rapid exchange of data, often sensitive. Today’s attackers know that, to steal your data, they don’t always need to engage in complex, multi-step schemes. Instead, they can bypass the go-between – for example, your applications and the people using them – and directly target your APIs.

What does this have to do with the Digital Operational Resiliency Act (DORA)? Well, your regulators also know about API risks, to the point where 44% of organizations have been fined due to API security incidents. 

So if you’ve seen new language in regulations that indicates the need to inventory, assess, or secure APIs, there’s a good reason. Exposed or misconfigured APIs are prevalent, easy to compromise, and often unprotected. And just one breached API can result in millions of records being stolen. Meanwhile, the stakes of compliance keep rising. The average cost of a data breach rises by 12.6% to $5.05 million when an organization is highly non-compliant.

In some regulations and frameworks, APIs get explicit mentions. For example, version 4.0 of the Payment Card Industry Data Security Standard (PCI DSS) contains guidance to confirm that an organization’s software securely uses the functions of external components. This includes APIs transmitting payment data from a mobile app to a bank’s system.

In other instances, APIs aren’t mentioned by name, but the requirements clearly focus on securing the technologies that rely upon your APIs to function. In this post, we’ll highlight a key example – the EU’s DORA regulation – and discuss why API security is a key part of meeting its requirements.

How API Security Fits Into DORA requirements

DORA is designed to help financial services organizations in EU member states withstand and recover from cyberattacks. With DORA, the sector will have a binding, comprehensive risk management framework for information and communication technology (ICT). More than 22,000 financial institutions and IT service providers in the EU are affected. Of note, this includes third parties that provide financial firms with ICT systems and services, including cloud service providers. DORA also calls for financial institutions to develop ICT third-party risk strategies and conduct due diligence to vet providers’ suitability. 

How does API security fit into DORA? Let’s explore the nature of DORA Article 3, which requires organizations to use ICT solutions and processes that:

• Minimize data-related risks, unauthorized access, and technical flaws.
• Prevent data unavailability, data loss, and integrity and confidentiality breaches.
• Ensure data transfer security.

An API’s primary function is facilitating a ‌fast, reliable transfer of data. Therefore, discovering, performing risk assessments for, and securing every API that touches enterprise data is essential for meeting DORA requirements. Here are some best practices to factor in:

• Discover every API in your IT environment, managed and unmanaged.
• Assess each API’s risk factors (e.g. the types of data they’ve been exchanging and who or what can access that data).
• Remediate any vulnerabilities such as misconfigurations or weak authentication mechanisms.
• Continuously test your APIs for resilience against both traditional and emerging breach and attack methods.

On that last note, DORA requires organizations to implement regular testing programs to identify gaps and vulnerabilities that can jeopardize the stability of an organization’s digital operations. This includes the APIs embedded across your organization’s digital business – your applications, infrastructure, and environments. 

Now, let’s take a deeper dive into DORA’s testing requirements and how organizations comply through a Shift Left approach to APIs.

DORA, API Security, and the Role of Shift Left

API and application development teams are under pressure to work as quickly as possible. Speed is essential for every application developed, making it easier for a vulnerability or design flaw to happen and subsequently go undetected. 

DORA-regulated organizations need to implement regular testing programs that identify potential gaps, vulnerabilities, and/or deficiencies that can impact the stability of their digital operations. Just a few examples: network security tests, penetration tests, and web-app tests. 

Therefore, it’s important to conduct mandatory reviews based on threat-led penetration testing, depending on the size, risk, and business profile of your financial enterprise.

Equally important: regularly testing your APIs for vulnerabilities, including misconfigurations, lack of authentication controls, and unintended exposure to the public internet. By applying a Shift Left approach to your APIs, you can stop vulnerabilities from reaching production, innovate faster, and ensure compliance with regulations such as DORA.

Here are a few best practices for API testing:

• Run a wide range of automated tests that simulate malicious traffic.
• Discover vulnerabilities before APIs enter production, reducing the risk of successful attacks.
• Inspect your API specifications against established governance policies and rules.
• Run API-focused security tests that either run on-demand or as part of a CI/CD pipeline.

DORA outlines examples of security testing that include web-based API tests. This includes using public-facing resources such as the Open Web Application Security Project (OWASP) top 10 threat list. The OWASP Top 10 helps organizations identify configuration errors, weaknesses, logic flaws, and code issues that allow attackers to gain access and control enterprise resources.

Bringing it All Together: The True Stakes of Compliance

What’s really at stake when your APIs are vulnerable, accessed, or compromised? 

There’s an obvious impact on business operations and revenue. And we’ve talked about the fines. But more importantly, trust is at stake… among your customers, employees, and of course, the regulators covering your industry. Indeed, 51% of security professionals admit an API security incident’s impact has led to loss of customer goodwill and churned accounts. 

Regulations like DORA, on their surface, may be designed to protect an organization’s resilience. But in the end, they have one thing in common: protecting the data that your customers have entrusted to you.

It might seem like adding another risk variable into your compliance program is like opening a Pandora’s box – more assessments, more testing, more hours required from an already overstretched team. But it doesn’t have to be like that.

The best practices we discussed in this piece are available. They’re often automated. And with the right provider, they can seamlessly integrate with your existing tools for security and compliance. For every requirement covered in this post, Noname Security’s comprehensive API Security platform offers the protection that enterprises need – not only to comply with regulations, but to secure the data your customers trust you to safeguard.

If you’re interested in learning more about the visibility, controls, and capabilities needed to fully secure your organization’s APIs, check out our API Security Buyer’s Guide.

¹ Noname Security, “The API Security Disconnect,” 2023