When it comes to financial services, retail, or any other industry that handles credit card information, Application Programming Interfaces (APIs) play a pivotal role in connecting systems, enabling seamless transactions, and facilitating real-time data exchange. For organizations handling payment card information, adherence to the Payment Card Industry Data Security Standard (PCI DSS) 4.0 is essential for safeguarding sensitive data. API security, therefore, becomes an essential component in meeting PCI DSS 4.0 requirements. This article explores how API security aligns with the PCI DSS 4.0 standard, ensuring the robust protection of cardholder data.

The good news here is that unlike other compliance regulations, PCI DSS is really prescriptive. It recognizes that your code, your APIs, and your applications are going to be a primary target for the threat actors and drives covered organizations to find and fix issues before they’re out in the wild.

PCI DSS Goals

PCI DSS’s four key high-level goals are:

1. Ensuring the standard continues to address the security needs of the payments industry.
2. Providing flexibility and support of additional methodologies (e.g., new tools, technology, controls) to achieve security.
3. Promoting security as a continuous process.
4. Enhancing validation methods and procedures.

When must I comply with PCI DSS v4.0?

PCI DSS v4.0 was published in March 2022, and organizations had to be compliant with 13 broad new requirements by 31 Mar 2024. The remaining 51 requirements, most of which are technical, require compliance a year later. And, the PCI Security Standards Council (PCI SSC) published a limited revision to the standard, PCI DSS v4.0.1 in June 2024. No new requirements arrived with this update, mostly corrections and refinements as we gear up for the older version, PCI DSS v3.2.1, to be retired on 31 March 2025.

The result is that if your organization takes credit, debit, or charge cards as payment, then you need to prepare for PCI DSS v4.0 going into full effect on 01 April 2025. For the curious, only one PCI DSS version is active at any given time. PCI DSS v4.0 will be retired on 31 December 2024, and then v4.0.1 will be active.

How big is the problem?

Financial services, hospitality and travel, and of course, retail make up some of the biggest industries making heavy use of credit cards. According to the Verizon 2024 Data Breach Investigations Report (DBIR), in the retail industry, exfiltration of credentials ranked number one at 38% while payment card information actually went down to 25% this year (from 37%), even though the number of total attacks remained fairly constant. Perhaps it’s an indication of the retail industry putting better controls in place, or perhaps it’s an anomaly. Either way, having 1 in 4 breaches walk off with payment card data is still a large, unacceptable percentage, and one that can be better managed using the right controls.

Levels of PCI DSS Compliance

Different organizations have different levels (1-4) of compliance that they must satisfy based on the number of annual transactions they process. Level 1 bears the heaviest burden given that they process the most transactions, and level 4 the least. BUT, if you’ve suffered a data breach, you may find yourself having to comply with level 1 regardless.

How does PCI DSS relate to API security?

We can’t rely on an application’s user interface (UI) to provide security, as attackers have been bypassing the UI and going directly to APIs to launch their attacks. It’s efficient for the attacker, and they don’t need to worry about changing UIs or having to write complex and often fragile screen-scraping code. Further, API attacks often yield needed clues and context that enable the bad guys to broaden and deepen their attack. Logic flaws are a common target, giving attackers access to information that wasn’t intended.

Requirements

Below are some key requirements where the use of API security and bot management can be a big help in achieving PCI DSS v4.0 compliance.

Requirement 4.2.1

Here, PCI DSS wants to ensure that all Primary Account Number (PAN) information is encrypted with robust cryptography when it is transmitted over open, public networks.

This requirement mandates that PANs must be encrypted during transmission, as cleartext PANs and other sensitive data could be read/intercepted.

Arguably, step one in complying with this requirement is identifying the API endpoints that transmit PANs. Here’s how Cequence helps in this effort:

• Cequence performs API discovery and inventory to make sure you understand the scope of your API attack surface.
• For those APIs lacking documentation, Cequence can auto-generate proper specifications, making it easy to know which APIs are handling PAN or other sensitive data. You want to make sure that you can assure auditors that you are encrypting all API traffic with TLS/HTTPS.

Requirement 6.2.3

PCI DSS requirement 6 broadly deals with the development of secure applications and systems. Proper management of security patches and secure system and application configurations are needed to ensure continued protection against misuse or compromise of cardholder data. The standard points out that in bespoke and custom software, numerous vulnerabilities can be avoided by applying software lifecycle (SLC) processes and secure coding techniques. Having the tools in place that verify that your APIs are working not only as designed, but as intended is of critical importance.

In many ways, this section is all about shifting left, secure software development, integrating security as far left as possible, testing your APIs, and remediating problems before they’re released into production. Use of automated testing tools for detecting API vulnerabilities is how you make this scale and ensure that your efforts don’t have blind spots.

Requirement 6.2.3 focuses on the practice of inspecting bespoke and custom application code to identify and correct potential coding vulnerabilities before being deployed in production. It highlights the importance of securely integrating external components such as libraries, frameworks, and APIs. The standard notes that “code reviews may be performed using either manual or automated processes, or a combination of both.”

Cequence Security helps fulfill this requirement through several methods:

• Cequence allows you to verify the security status of API-based components, identifying any misconfigurations or vulnerabilities, including weak encryption ciphers highlighted in the standard.
• Cequence allows you to baseline normal and expected API usage behavior and establish controls to prevent malicious actors from exploiting your systems. This includes monitoring the application’s behavior to detect logical vulnerabilities.
• Cequence provides a comprehensive inventory of all your APIs and their associated risk. This includes undocumented APIs, offering insights into potential hidden features and backdoors that need management or remediation.
• Since vulnerable code is far more difficult and expensive to address after it has been deployed or released into production environments, testing during pre-production is key. With Cequence you can perform API testing to ensure the robustness of your API code to prevent any API-related vulnerabilities from entering production.

Requirement 6.2.4

This requirement addresses the use of software engineering techniques or other methods to avert or lessen the impact of common software attacks and related vulnerabilities in bespoke and custom software. The attacks specified in this requirement range from simple injection attacks to more complex API business logic abuse. Cequence Security meets this requirement through various approaches:

• Cequence also identifies injection attacks and provides guidance on mitigation techniques necessary to address the underlying causes of these vulnerabilities.
• Cequence enables IT and development teams to thoroughly test their APIs, identifying and remediating vulnerabilities and coding errors, both in pre-production and at runtime. Sensitive data exposure detection allows teams to locate and remediate risk.

Requirement 6.3.2

Requirement 6.3 covers the identifying and addressing security vulnerabilities, with 6.3.2 specifically requiring that organizations maintain an inventory of bespoke and custom software, along with third-party software components integrated into the software, to aid in vulnerability and patch management.

Vulnerabilities in third-party components (including libraries, APIs, etc.) embedded in an entity’s software can render those applications vulnerable to attacks. Knowing which third-party components are used in the entity’s software, and monitoring the availability of security patches to address known vulnerabilities is critical to ensuring the security of the software.

Cequence Security supports this requirement in a couple of ways:

• Cequence creates a detailed and comprehensive inventory of all your internal and external APIs, including third-party frameworks and infrastructure components that affect the security posture of your APIs.
• Cequence tracks and catalogs any changes to the functionality of your APIs.

Requirement 6.4.2

This requirement is so important. It’s new in PCI DSS v4.0, and while currently a “best practice”, it becomes required as of 31 March 2025, replacing 6.4.1 at that time. Where 6.4.1 permitted an organization to manually assess their vulnerabilities as a detective control OR use a preventative control, 6.4.2 requires an automated, preventative control. The requirement mandates that public-facing web applications must be protected, stating that “an automated technical solution is deployed that continually detects and prevents web-based attacks”.

Some organizations might be tempted to think that their existing web application firewall (WAF) is sufficient, and while important, WAFs fall short in several key areas. WAFs do not understand business logic, nor do they detect sensitive data sharing. I recently wrote an article discussing this, “Why do I Need API Security if I Have a WAF and API Gateway?”.

Most organizations have many public-facing apps, so it’s important to have a strategy for protecting all of them, and your tool choice directly affects your ability to do this. We know that many API security and bot management solutions require that each of your applications be modified with vendor code, an SDK, or agents, which really slows down how fast adoption and protection can be achieved. Some applications are actually collections of microservices which can’t be instrumented at all.

Cequence is a great choice for satisfying this requirement because:

• Cequence deploys easily, requiring no app instrumentation, making it the hands-down favorite for achieving consistent, broad coverage across your application portfolio in minutes.
• Cequence uses behavioral fingerprinting to identify and track attackers, lowering false positives and enabling you track threats and attacks, even as attackers re-tool to avoid detection.
• Cequence intercepts bad traffic before it ever gets to your applications, protecting them from attacks, business logic abuse, and sensitive data sharing.
• Using unsupervised AI/ML, Cequence detects and mitigates potential malicious behavior exploiting API business logic at run-time.

How Cequence Security can help you meet PCI DSS v4.0 requirements

The Cequence Unified API Protection (UAP) platform is the only offering that addresses all phases of the API protection lifecycle to defend your APIs from attackers and eliminate unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption. We help organizations achieve PCI DSS v4.0 compliance by employing a Discover, Comply, Protect methodology.

Even perfectly-coded and configured APIs can be exploited through business logic abuse and other sophisticated attacks, so a holistic approach is crucial.

Discover
You can’t protect the technical aspects of an environment you aren’t aware of, so the first step towards securing APIs is to discover them – internal, external, and third-party. You need to continuously update your API inventory, detailing what APIs exist, where they are, whether they are documented, etc.

Comply
Comply with internal governance and external compliance, in this case, PCI DSS v4.0. Cequence API security testing enables development and security teams to quickly identify and remediate API vulnerabilities and coding issues. Predefined, fully customizable tests can be integrated into development and release cycles or executed outside CI/CD pipelines. “Intelligent Mode” offers autonomous test plan creation eliminating a great deal of manual effort.

Protect
Detect threats and attacks, and provide native, real-time mitigation options for the organizations applications and APIs, including deception, rate-limiting, labeling, and blocking.

Resources

PCI DSS v4.0 Resource Hub – https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub
PCI DSS 4.0: Things to do by March 2024, SC Magazine, 23 Oct 2023 – https://www.scmagazine.com/resource/pci-dss-4-0-things-to-do-by-march-2024
Get Ready for PCI-DSS 4.0 Compliance with Vercara’s UltraWAF – https://vercara.com/resources/get-ready-for-pci-dss-4-0-compliance-with-vercaras-ultrawaf

The post Achieving PCI DSS 4.0 Compliance with API Security appeared first on Cequence Security.

*** This is a Security Bloggers Network syndicated blog from Cequence Security authored by John Dasher. Read the original post at: https://www.cequence.ai/blog/api-security/pci-dss-4-compliance-api-security/