What does PCI DSS 4.0 mean for API security? asks Hadar Freeling, principal solution engineer at Salt Security.
In March 2022, the PCI Security Standards Council (PCI SSC) issued the fourth iteration of the PCI Data Security Standard (PCI DSS). The PCI DSS is a global standard to which any entity that transmits, stores, handles, or accepts credit card data must adhere. As APIs play an increasingly significant role in online payments, the introduction of PCI DSS 4.0 brought with it more stringent security regulations with far-reaching ramifications for API security specifically.
The majority of these regulations fall inside requirement six – Develop and Maintain Secure Systems and Software. Let’s take a look at two of the most API relevant requirements and lay out what needs to be done to comply.
6.2 – Bespoke and custom software are developed securely
In recent years, industry experts have been increasingly advocating for cyber-secure software development – known colloquially as “shift left”. Requirement 6.2 is a reflection of this. In essence, the council wants organisations to eradicate vulnerabilities as early as possible in the development stage to reduce the risk of being compromised. Organisations should implement a Secure Software Lifecycle (SLC) program to achieve this, preventing vulnerabilities from making it to production.
6.2.3 – Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
Code reviews ensure code is developed according to secure coding guidelines.
Code reviews look for both existing and emerging software vulnerabilities.
Appropriate corrections are implemented prior to release.
The above control language expresses a requirement for organisations to perform code reviews – including APIs – before reaching the development stage. While this isn’t exactly a novel idea, many organisations still do not ensure their Swagger files meet the Open API Standard (OAS). Unfortunately, a lack of confidence in the accuracy and compliance of API Swagger files is a major problem for contemporary API developers.
To ensure everything is up to scratch, look for API specific security tools that cross reference your Swagger Files against PCI DSS 4.0. The best tools will highlight discrepancies between the contents of Swagger files and what API traffic actually looks like.
6.2.4 – Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
Injection attacks, including SQL, LDAP, XPatch, or other command, parameter, object, fault, or injections-type flaws.
Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorisation mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.
The most notable element of Requirement 6.2.4 is the inclusion of business logic attacks – an addition the regulations have not seen before. This is most likely a reflection of the soaring number of business logic attacks – especially those involving APIs.
According to a recent report APIs are being updated faster than ever – 11% of respondents said they update their APIs daily, while 31% updated them weekly. This poses a problem because API business logic flaws can be introduced both whe APIs are deployed and when they are updated. The more APIs are updated, the higher the risk of business logic flaws.
As the old adage goes – modern problems require modern solutions. Keeping up with business logic flaws and, by extension, PCI DSS 4.0, requires a continuous, automated solution capable of uncovering API-specific business logic vulnerabilities.
6.4 Public-facing web applications are protected against attacks
Public-facing applications are, by their nature, at a higher risk than their non public-facing counterparts. For this reason, PCI DSS Section 6.4 lays out some extra controls to protect them.
6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against know attacks as follows:
Reviewing public-facing web applications via manual or automated application vulnerability security methods or tools as follows:
At least once every 12 months and after significant changes
By an entity that specialises in application security
Including, at a minimum, all common software attacks in Requirement 6.2.4
All vulnerabilities are ranked in accordance with requirement 6.3.1
All vulnerabilities are corrected
The application is re-evaluated after the corrections
OR
Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
Installed in front of public-facing web applications to detect and prevent web-based attacks
Actively running and up to date as applicable
Generating audit logos
Configured to either block web-based attacks or generate an alert that is immediately investigated
6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks
Actively up to date as applicable
Generating audit logs
Configured to either block web-based attacks or generate an alert that is immediately investigated.
6.4.1 is a novel control, focused on public-facing web applications and requiring organisations to protect these applications against new threats and vulnerabilities. To reduce the risk of attack, the PCI DSS offers organisations two options: review application vulnerabilities or implement something that will detect and prevent these attacks. They also suggest web application firewalls (WAF) as a “technical solution that detects and prevents web-based attacks.” This would fall under the “automated technical solution” as outlined previously.
To meet these requirements, organisations should look for API specific security solutions which can perform blocking actions on upstream or inline devices, at the API Gateway or internet gateway. Salt provides a robust set of integrations, both inbound and outbound, to make deployments and enforcements quick and easy.
As far as 6.4.2 goes, it does little more than extend the 6.4.1 control to require organisations to deploy a solution that protects their web-facing applications from attacks. While the 6.5.1 control allowed organisations the option of using a detective tool (a vulnerability assessment tool) or a preventative control (automated technical solution to detect and prevent attacks), 6.4.2 specifically mandates a preventative control. To meet this control, organisations should look for security vendors that detect and prevent attacks against the publicly-facing APIs their APIs rely upon.
To conclude, while these regulations are stringent, they are necessary to stay safe in the contemporary threat landscape. Considering API attack traffic grew by 117 per cent throughout 2022, organisations need to be wary of API security issues, and these regulations reflect them.
