Embed API Security Into Regulatory Compliance: Six Examples to Watch

Why have forty-four percent of enterprises been fined by regulators due to API security incidents? Regulators are beginning to see what attackers already know: exposed or misconfigured APIs are prevalent, easy to compromise, and often unprotected. 

Every time a customer, partner, or vendor engages with your business 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 directly target your APIs.

Does it matter if a 200-page regulatory document explicitly mentions, subtly implies, or vaguely indicates that securing APIs is important? Not really. Because a data breach is a data breach, no matter how or where it was executed. All it takes is just one vulnerable API for your data to be compromised, stolen, or published for the world to see.

Can API security wait, as you prioritize threats your regulators are‌ singling out, like ransomware? Unfortunately, no – the numbers speak for themselves:

• The average enterprise has 15,000 to 25,000 APIs, depending on its size, and the number grows with every digital product or service it rolls out.
• Ninety-two percent of organizations have experienced an API security incident, and most don’t have the controls or tools in place to stop it.
• The average cost of a data breach rises by 12.6% to $5.05 million when an organization is highly non-compliant.

How does this affect your compliance program? If you take a proactive approach to finding every API, assessing each for risk, and securing them from breaches, you’ll be safeguarding your data from the exact outcomes regulators are trying to prevent.

In our new whitepaper, we take a comprehensive look at six regulations and guidelines whose requirements indicate a need for API protection. In this blog post, we’ll highlight key examples.

1. Payment Card Industry Data Security Standard (PCI DSS) Version 4.0

PCI DSS has become a global standard for protecting payment data. If your business accepts major credit cards and processes, stores, or transmits cardholder data electronically, you’re on the hook to comply. 

PCI DSS 4.0 requirement 6.2.3 centers on the need for organizations to review their bespoke custom application code to ensure no vulnerabilities are released into production. Specific to APIs, this requirement offers guidance to confirm an organization’s software securely uses external components’ functions (libraries, frameworks, APIs, etc). 

One of several ways to comply: Validate normal and expected behavior of API usage and implement controls to block suspicious actors from abusing your systems (e.g. check the application’s behavior to detect logical vulnerabilities).

2. General Data Protection Regulation (GDPR)

GDPR is a European Union legislation that aims to strengthen and unify data protection for individuals within the EU. However, GDPR is not limited to EU-based companies; any organization offering consumer goods or services in the EU must comply.

GDPR Article 25 is rooted in least privilege, requiring companies to implement “technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose… are processed.” In turn, API developers should implement user authentication and authorization controls to safeguard the sensitive data flowing through their APIs. 

This is a great example of how API security fits into your enterprise’s big-picture security and compliance programs. Concepts like least privilege aren’t only relevant to us humans; APIs should also have just the right amount of access to do their jobs.

3. Digital Operational Resiliency Act (DORA)

In total, more than 22,000 financial institutions and IT service providers in the EU are affected by DORA’s requirements, which are meant to help organizations withstand and recover from cyberattacks. 

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:

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

Given that APIs’ main purpose is to transfer data, it’s essential to regularly test your APIs for vulnerabilities, including lack of authentication controls, and unintended exposure to the public internet. By applying a Shift Left approach to APIs, you can stop vulnerabilities from reaching production.

Example 4. Health Insurance and Portability and Accountability Act (HIPAA)

HIPAA focuses on data privacy and security rules to safeguard protected health information (PHI) in electronic health records and healthcare IT systems. Any U.S. healthcare provider, plan administrator, or clearinghouse that electronically stores or transmits PHI must comply with HIPAA.

HIPAA’s Privacy Rule specifies that covered entities “must develop and implement policies and procedures that restrict access and uses of protected health information based on the specific roles of the members of their workforce.” Therefore, an organization’s API developers must embed technical safeguards such as authentication, unique user IDs, and role-based access controls to make sure least privilege is in place.

5. Network and Information Security Directive (NIS2)

The EU adopted version 2.0 of the NIS directive in January 2023, building upon the original version’s guidelines for securing IT infrastructure and reporting incidents. 

Of note, NIS2 includes a new emphasis on securing supply chains – enterprises must assess risk and secure their IT supply chains and third-party supplier relationships. Since APIs are often used to integrate external services – from software vendors to cloud service providers – ensuring their security is key to showing regulators your organization is protecting its customers’ data and the broader supply chain from attacks.

6. Guidance for U.S. Financial Services Regulators

The Federal Financial Institutions Examination Council (FFIEC) creates the guidance and standards for federal regulators to oversee the U.S. financial industry. This includes the Federal Reserve and FDIC. The council’s mission is to protect consumers and investors from fraud, abuse, and misconduct.

In reviewing the FFIEC’s guidelines, it’s clear how securing APIs can help organizations protect consumers from fraud and identity theft. For example, the FFIEC recommends building an inventory of all information systems – this includes APIs – requiring authentication and access controls. Authorization is also critical: the FFIEC recommends implementing layered security – for example,  monitoring, logging, and reporting activities to identify and track unauthorized API access. 

Wrap-up: Securing APIs Also Means Securing Trust

The six regulations and guidelines highlighted in this blog post have one thing in common: protecting the data that others have entrusted to you. 

As you know, the stakes of an API data breach are about more than just fines. Trust is on the line, among your customers, employees, and the regulators covering your industry. Regulators need to see you’re applying the right mix of people, processes, and tools to stop attacks like these from occurring.

Would you like to gain a deeper understanding of the API-relevant requirements for the six regulations we discussed? Download our new whitepaper: “API Security and Compliance: What Regulators Need to See.”