Best Practices to Help Meet PCI DSS v4.0 API Security Compliance

The original version’s requirements cover security mainstays that are as important now as they were when they were published in 2006. For example:

• Monitoring and controlling access to all administrative accounts on any IT systems processing or storing cardholder data

• Assigning access to system and cardholder data on a need-to-know basis and defining access requirements by role

The trouble is that today’s threat landscape is more complex than it was in 2006.

Yes, organizations must still address attackers’ tendency to target areas such as privileged accounts and users with excessive permissions. However, today’s enterprises also need to adapt their compliance programs to account for threat actors who frequently target the thousands of APIs that are living within payment technologies. These attackers know that APIs are easy to exploit and can provide an efficient way to steal cardholder data.

Therefore, to comply with PCI DSS v4.0, your organization will need to understand and defend against API threats. In this blog post, we’ll share insights on the risks, requirements, and ways to comply.

Overall, PCI DSS v4.0 is centered on four key objectives:

1. Continue to meet the security needs of the payment industry

2. Advocate security as a continuous process

3. Give enterprises flexibility (e.g., new tools, new controls) in how they meet requirements

4. Enhance validation methods and processes

PCI DSS v4.0 explicitly calls out APIs as a key area that requires visibility and protection. All four objectives come into play. But number three (the flexibility to use new tools and controls) is particularly important, given the unique risks of APIs. For example:

• APIs live at the core of your customer-facing digital products and services. The average enterprise has between 15,000 and 25,000 APIs, depending on its size, all designed to facilitate a nonstop exchange of data. 

• This data includes sensitive customer information. For every digital payment, there’s an API behind the scenes, transmitting data between applications, systems, third parties, and more.

• Just one compromised API can result in millions of records being stolen, held for ransom, or published for the world to see. And exposed or misconfigured APIs are prevalent; easy to compromise; and often unprotected, unseen, and unmanaged.

Regulators are aware of the risk to APIs, and your business must show it has the visibility and controls in place to prevent data from being compromised.

Payment card data is compromised in more than one-third (37%) of breaches according to Verizon’s 2023 Data Breach Investigations Report. PCI DSS v4.0 includes new requirements around multi-factor authentication and password length to secure the human element of the payment industry’s attack surface.

However, it’s important to remember that data breaches aren’t always due to well-publicized, human-centric attack methods like phishing for employees’ passwords.

For example, 18% of attacks on ecommerce businesses entail malicious code embedded in card processing web pages. Today’s threat actors are growing more sophisticated, targeting automated nonhuman components of the IT environment that are often not secured properly — like APIs.

Seventy-eight  percent of enterprises have experienced an API-related security incident, according to our research. Recognizing the urgency of API threats, PCI DSS v4.0 includes new API security rules, guidelines, and best practices. Let’s learn more by exploring Requirement 6.2.3 first.

Requirement 6.2.3 centers on the need for organizations to review their bespoke custom application code (i.e., applications developed by a third-party vendor, but not standard commercial off-the-shelf applications) to ensure that no vulnerabilities are released into production.

This requirement offers guidance to confirm that an organization’s software securely uses external components’ functions (libraries, frameworks, APIs, etc), which speaks to the key role APIs play in the broader software supply chain — and what it takes to protect it.

APIs have become the default method of connectivity and data exchange in modern application environments. With that in mind, securing APIs with both a preproduction (shift-left) approach and postproduction (shield-right) approach is essential to making your digital business resilient against attacks.

Here are six API security best practices to help with compliance with requirement 6.2.3.

1. Confirm the use of API-based components and their security posture (e.g., find any misconfigurations leading to vulnerabilities, including the use of weak encryption ciphers as called out in the standard)

2. Validate normal and expected behavior of API use and implement controls to block suspicious actors from abusing your systems (e.g., check the application’s behavior to detect logical vulnerabilities)

3. Detect third-party frameworks used to power your APIs and determine if any are outdated and vulnerable

4. Build a full inventory of all your APIs, including the different versions of the APIs you are running, which will give you insight into potential undocumented features and backdoors you need to manage

5. Validate the security of your API code and avoid putting any API-related vulnerabilities into production

6. Implement secure coding best practices for APIs, which will allow you to adopt a programmatic approach to securely delivering code on a continuous basis

The PCI SSC also added two other sections comprising API security to PCI DSS v4.0. Here’s a summary of the two additional requirements you’ll need to meet.

• Requirement 6.3.2 applies to maintaining an inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software, to facilitate vulnerability and patch management.

• Requirement 6.2.2 addresses training for software development personnel working on bespoke and custom software. It states developers need to be trained at least once every 12 months on security relevant to their job function, including secure software design and secure coding techniques. This training includes security testing tools, and how to use those tools for detecting vulnerabilities in software.