How to Comply with PCI DSS 4.0’s API Security Requirements

Struggling to keep up with evolving regulations isn’t a new thing for IT security teams. After all, for every NIS, there’s a NIS2. But when you consider that 130+ global jurisdictions have enacted data privacy laws whose mandates change, it’s not surprising that only 9% of executives feel highly confident that they can meet all disclosure requirements.

If you’ve been preparing to comply with version 4.0 of Payment Card Industry Data Security Standard (PCI DSS), you might be feeling the same way. 

Created by the Payment Card Industry Data Security Council, 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.

The original version’s requirements cover security mainstays that are as important now as they were when PCI DSS was 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, today’s threat landscape is more complex than it was in 2006. 

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

So among the many changes you’ll need to comply with in PCI DSS 4.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.

Why API Security is Critical for Protecting Cardholder Data

Overall, PCI DSS 4.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 4.0 explicitly calls out APIs as a key area requiring visibility and protection. All four objectives come into play. But number three (the flexibility to use new tools and controls) is particularly important, given APIs’ unique risks. 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 non-stop 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 and your business must show it has the visibility and controls in place to prevent data from being compromised.

Why Regulators Care About the APIs in Your Payment Technologies

Payment card data is compromised in over a third (37%) of breaches according to Verizon’s 2023 Data Breach Investigations Report. This is probably why PCI DSS 4.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, quite often, data breaches aren’t due to well-publicized, human-centric attack methods like phishing for employees’ passwords. 

For example, 18% of attacks on e-commerce businesses entail malicious code embedded in card processing web pages. Today’s threat actors are growing more sophisticated, targeting automated non-human components of the IT environment that quite often, aren’t secured properly – case in point, APIs.

Ninety-two percent of enterprises have experienced an API-related security incident, according to Enterprise Strategy Group. Recognizing the urgency of API threats, PCI DSS v. 4.0 includes new API security rules, guidelines, and best practices. Let’s explore requirement 6.2.3.

Complying with PCI DSS 4.0 – Requirement 6.2.3

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

Specific to APIs, this requirement offers guidance to confirm that an organization’s software securely uses external components’ functions (libraries, frameworks, APIs, etc). This 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 connectivity and data exchange method of modern application environments. With that in mind, securing APIs from both a pre-production (shift-left) and post-production (shield-right) is essential to making your digital business resilient against attacks. 

Here are six API security best practices to follow, for compliance with requirement 6.2.3.

1. Confirm the usage of API based components and their security posture (e.g. find any misconfigurations leading to vulnerabilities, including the usage of weak encryption ciphers as called out in the standard).
2. 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).
3. Detect third-party frameworks used to power your APIs, determining any that may be outdated and vulnerable.
4. Build a full inventory of all your APIs, including the different versions of APIs you are running – thus giving 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 allowing you to adopt a programmatic approach to securely deliver code on a continuous basis.

What Else Does PCI-DSS 4.0 Require for API Security?

The PCI-DSC added two additional sections entailing API security to PCI-DSS 4.0. Depending on when you’re reading this post, the deadline for compliance is either weeks away, or the deadline has passed. Either way, here’s a summary of the requirements you’ll also 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 includes security testing tools, and how to use those tools for detecting vulnerabilities in software.

To learn more about these requirements – and the exact API security controls and capabilities you need to comply – we’ve published a helpful resource. Download our whitepaper, PCI DSS 4.0 Requirements for APIs, for best practices that you can use. 

How Noname Security Can Help You Meet API Security Requirements

For every requirement covered in this post, Noname Security’s API Security platform offers the API protection that enterprises need – not only to comply with PCI DSS 4.0, but to continuously secure the data your customers have entrusted you with.

From the initial stages of development to post-production, Noname Security’s platform entails:

• API Discovery
• Posture Management
• Security Testing
• Runtime Protection

Learn more about Noname’s approach to API security and compliance.