What is PCI DSS 4.0 and why is API security such a critical component?
Earlier this year, the PCI Security Standards Council issued a new version of the PCI Data Security Standard ( PCI DSS). The PCI DSS is the compliance measuring stick to which entities that transmit, store, handle, or accept credit card data — regardless of processing volume or size – must adhere. With this new version, there have been a few changes and updates to the controls. To read more about what’s new in the standard, you can go here.
Relating to APIs, the PCI DSS adds more information and direction around what is now required. The majority of these controls are called out in requirement 6 – Develop and Maintain Secure Systems and Software. Let’s take a look at two of the most API-relevant PCI DSS requirements.
6.2 Bespoke and custom software are developed securely.
Section 6.2 is focused on software development and the controls around it. The council wants organizations to reduce their vulnerabilities so that their systems are less likely to be compromised. Ideally, organizations have implemented a Secure Software Lifecycle (SLC) program to catch these vulnerabilities early in the development cycle and stop them from ever being released into production.
What you can see from the above control language is that organizations are required to perform code reviews - and this includes their APIs - before moving to production. This is nothing new. Yet, most organizations do not validate that their Swagger files meet the Open API Standard (OAS). At Salt, we talk to many organizations at various stages of their API security journey. Almost all of them tell us that they lack confidence in the accuracy and compliance of their API Swagger files.
With Salt, you can quickly check your Swagger files (either through the UI or our own API) to see if they meet the standard. Salt will also show you where there are discrepancies between what is in the Swagger file and what the actual API traffic looks like.
In 6.2.4, PCI DSS requires software engineers and security teams to try to mitigate or prevent attacks against “common software attacks.” The third bullet calls out business logic attacks. Interestingly, this control did not appear in previous versions. Why was it added? I suspect that the number of business logic attacks - especially those involving APIs - have increased so dramatically that the PCI Council felt it was prudent to include it in the new standard.
Business logic flaws in APIs can either be introduced as they are initially deployed or as they are updated, so it’s also important to continue to search for them throughout their lifecycle. The Q3 2022 Salt Security State of API Security report revealed that APIs are being updated at a faster pace than ever, with 11% of respondents updating their APIs daily and 31% updating them weekly. Therefore, implementing a continuous, automated solution to uncover these API-specific business logic vulnerabilities will be key to meeting the new PCI DSS requirements.
Fortunately, Salt customers have confidence in their ability to meet this standard as it relates to their API business logic flaws. Salt leverages a patented methodology to learn your unique API and its behavior. Leveraging this knowledge, Salt can detect those pesky business logic attacks because they do not share the same pattern as normal users of your APIs.
6.4 Public-facing web applications are protected against attacks
PCI DSS Section 6.4 covers extra controls that must be in place for publicly-facing applications because they are inherently at a higher risk.
6.4.1 is the first control around public-facing web applications and requires organizations to protect these applications against new threats and vulnerabilities. As a way of reducing the risk of attacks, the PCI DSS council gives organizations two options: either review application vulnerabilities or implement something that will detect and prevent these attacks. In their guidance for this control, the PCI DSS gives an example of a web application firewall (WAF) as a “technical solution that detects and prevents web-based attacks.” This would fall under the “automated technical solution” as required above.
This is another area in which Salt would help meet the control. With Salt, your public APIs are protected from attacks. Though Salt is not inline, it can perform blocking actions on your upstream or inline device, at your API Gateway or Internet gateway. Salt provides a robust set of integrations, both inbound and outbound to make deployments and enforcements quick and easy.
6.4.2 simply extends the 6.4.1 control, in that it requires organizations to deploy a solution that protects their web-facing applications from attacks. Whereas 6.4.1 gave organizations the option of either using a detective control (vulnerability security assessment tool, i.e. a code scanner or web vulnerability scanner) or a preventive control (automated technical solution to detect and prevent attacks, i.e. WAF, API security tool), 6.4.2 requires the usage of a preventive control.
Here again, Salt can help you meet this PCI DSS control by detecting and preventing attacks against the publicly-facing APIs that your applications rely upon.
In conclusion
With the industry moving to microservices and API-driven applications, new security threats and attack vectors have emerged. The PCI Security Standards Council has recognized these new threats and has worked to address them in its newest PCI DSS 4.0 standard. Unlike previous versions, protecting APIs is critical to meeting the guidance and achieving the industry-standard PCI certification. With its extensive detection and monitoring features, the Salt API Protection Platform helps companies meet these compliance and security requirements.
If you’re interested in learning more about your API security gaps and how they may lead to future PCI DSS concerns, you can request an API Security Gap Assessment to better understand your API landscape and gain personalized remediation insights.
- You can read in more details about this control and the guidance that is given in the PCI DSS standard at https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf
