PCI SSC takes aim at APIs

PCI SSC takes aim at APIs

By James Sherlow, Director Field Services Engineer, EMEA, Cequence Security

Application Programming Interfaces (APIs) are the glue between mobile and web applications work and play a vital role in online payments. Consumers and businesses expect a smooth and engaging application experience when conducting transactions and APIs have facilitated this, enabling merchants and financial organisations to swiftly rollout new services. However, as APIs act as highly visible and well-defined doorways into the data and business processes of organisations, they’re also now a prime target for attackers.

Seen as the Achilles heel in ecommerce, attacks against APIs are resulting data breaches are expected to double by next year, according to Gartner. Consequently, the PCI Security Standards Council (PCI SSC) has taken a number of steps to better protect them, starting with new provisions for API security in the latest version of the Payment Card Industry Data Security Standard, PCI DSS 4.0. Largely unchanged for the past decade, version 4.0 is set to become mandatory from April 2024, and all those in scope will need to adopt these new practices to secure their APIs.

The main area pertaining to APIs is in Requirement 6 which requires those in scope to Develop and Maintain Secure Systems and Software. Section 6.2 which applies to custom-developed software stipulates how code should be developed and subjected to code reviews to ensure it is developed according to secure code guidelines, that existing and emerging vulnerabilities are looked for and corrections made prior to release. The section essentially formalises the need to adopt a shift-left approach with regards to API development thereby helping to prevent vulnerabilities making it into production.

API attack patterns demand unique defence

Of particular interest is the list of attacks to prevent/mitigate in section 6.2.4 which now includes business logic abuse for the first time which are “attempts to bypass application features and functionalities through the manipulation of APIs”. Even perfectly coded APIs can be exploited via business logic abuse which means those that are deployed can still be compromised even after being subjected to rigorous development testing. Signature-based defence systems are unable to detect this type of exploit, making it notoriously difficult to spot. However, continuous monitoring of all API calls will enable AI models to learn business logic, leading to Generative AI test suites for each API. This will see the shift-left concept of testing API code move beyond the standard test suites we have today. It’s also worth mentioning that business logic abuse is often perpetrated by bots, so this highlights the need to use bot mitigation and API defences together.

Section 6.4 focuses on protecting public-facing web applications against attack. External as opposed to internal APIs are at higher risk of discovery and abuse and this section makes provision additional safeguards in the form of regular annual reviews or automated technical solutions that seek to detect and prevent web-based attacks (6.4.1). The following section (6.4.2) then provides further detail on what that automated technical solution should look like and be capable of. In addition to being in front of the application and configured to detect and prevent web-based attacks, it should also be actively running ie continuous, generate audit logs, and either block or generate an alert that is immediately investigated.

The example given is of a Web Application Firewall (WAF) but as the name suggests, these have been developed to protect web applications, not APIs. A WAF uses signature-based threat detection to look for attacks with tell-tale code but as previously mentioned, business logic abuse sees the functionality of the API used against it. It is therefore not strictly an attack but a form of exploitation and leaves no signature. Rather, the giveaway is the behaviour and the requests being made to the API, changes in web traffic volumes and burst rates etc. Therefore, an API-specific automated security tool is advisable in order to meet these requirements and to detect and block such attacks.

Additions to the PCI SSS

In addition to the PCI DSS requirements the PCI SSC has also recently updated the PCI Secure Software Standard. First released in 2019 this was updated in May 2023 and seeks to ensure payment software is designed, developed, and maintained in a manner that protects transactions and data, minimises vulnerabilities, and defends against attacks. The latest version includes additions to the Web Software Module and API-specific requirements for “documenting and tracking the use of open-source and third-party software components and APIs in payment software” and “controlling access to payment software web APIs and other critical assets”.

These two additions are important because they help to amplify the importance of several API vulnerabilities, where attackers are actively mixing and matching attack methods. Indeed, it’s a practice that has recently been recognised in the Open Web Application Security Project API Top Ten list of categorised security threats updated for 2023. It now features category API6:2023 which reflects the fact that API security that isn’t functioning properly can be targeted by automated bot attacks which bombard the API with numerous techniques.

What the changes to both the PCI DSS and PCI Secure Software Standard reveal is that API security will now need to be prioritised by merchants and processors. APIs will need to be securely developed, continuously monitored and managed in order to better protect the transaction landscape. And, while shift left testing can help, steps will need to be taken to protect production APIs, especially those that are public facing. Existing automated solutions cannot spot the type of business logic abuse attacks or defend against bot-automated attacks that pivot through numerous tactics, techniques and procedures that we are seeing. In order to do that, the sector will need API-specific tools that use behaviour-based detection and defence tactics for blocking and frustrating attackers.