How Securing APIs Factors into DORA Compliance
Complying with data protection regulations isn’t easy, but it has traditionally involved dealing with familiar risks. For example, ensuring that your IT admins have the right amount of access to systems touching sensitive information. Review, remediate, report, and repeat.
In the past, compliance has been cumbersome, but your team has made it work. 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 electronically engages with your organization, an API is transmitting data behind the scenes — and that data is often sensitive. Today’s threat actors know that APIs can provide a direct route to enterprise data.
New language in compliance regulations and frameworks
What does this have to do with compliance regulations and frameworks? Well, regulators also know about API risks; in fact, 44% of organizations have been fined for API security incidents.
Therefore, if you’ve seen new language in regulations that indicates the need to inventory, assess, or secure APIs, there’s a good reason for that. 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 US$5.05 million) when an organization is highly noncompliant.
Explicit (and implicit) requirements for APIs
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 that transmit 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 of that type of regulation – the European Union’s Digital Operational Resilience Act (DORA) – and discuss why API security is an important 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 has a binding, comprehensive risk management framework for information and communication technology (ICT).
More than 22,000 financial institutions and IT service providers in the European Union are impacted by DORA’s requirements. 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.
DORA Article 3
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
Best practices to meet DORA requirements
An API’s primary function is to facilitate 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 find out how organizations can comply via a shift-left approach to APIs.
DORA, API testing, and the role of shifting left
API and application development teams are under pressure to work as quickly as possible. Speed is an essential part of the development of every application, which makes it easier for a vulnerability or design flaw to happen and subsequently go undetected.
DORA-regulated organizations need to implement regular testing programs (such as network security tests, pen tests, and web app tests) that identify potential gaps, vulnerabilities, and/or deficiencies that can impact the stability of their digital operations.
Therefore, it’s important to conduct mandatory reviews based on threat-led pen 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.
Best practices for API testing
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 to reduce 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) API Security Top 10 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.
The true stakes of compliance
What’s really at stake when your APIs are vulnerable, accessed, or compromised?
There’s an obvious impact on your business operations and revenue. And we’ve talked about the fines. But, more important, trust is at stake — among your customers, employees, and of course, the regulators that cover your industry. Indeed, 51% of security professionals admit that an API security incident’s impact has led to a loss of customer goodwill and churned accounts.
Regulations like DORA may have been designed to protect an organization’s resilience. But, in the end, they have one goal in common: to protect the data that your customers have entrusted to you.
It might seem like more assessments and more testing will just require more hours from your already overstretched team — but it doesn’t have to be like that.
Protection is easier than you think
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, Akamai API Security (formerly Noname Security) offers the protection that enterprises need — not only to comply with regulations, but to secure the data your customers trust you to safeguard.