Payment card data theft remains a huge problem and still accounts for almost a fifth (19%) of breaches, with that rising to 25% in the retail sector, according to the Verizon 2024 Data Breach Investigations Report (DBIR). What’s more, the report also found payment card data is also being siphoned off during ransomware attacks against e-commerce sites and the information obtained in this manner is responsible for 57% of breaches involving stolen payment cards. Protecting this data is imperative which is why we’ve seen an overhaul of the Payment Card Industry Data Security Standard (PCI DSS) standard.
PCI DSS 4.0 was brought in back in April when v3.2.1 was retired but only 13 of the 51 requirements are now mandatory. This is because the majority are classed as complex and so are likely to require the entity to make significant changes to processes and systems. Consequently, extra time has been allocated to these requirements to enable these organisations to comply and so they are classed as best practice today and won’t become mandatory until April 2025.
The latest version, PCI DSS 4.0.1, has been welcomed due to its outcome-oriented approach which is more flexible, less prescriptive, and treats security as an ongoing process. It’s also now much more relevant, reflecting emerging threats and technologies, and changes to terminology more accurately reflect how payment data is processed. Technological controls have also been updated so we now see the introduction of additional authentication such as multi-factor authentication (MFA) when accessing the cardholder data environment (CDE), for instance.
But PCI DSS 4.0 is also notable for elevating the attention paid to Application Programming Interfaces (APIs) which play a crucial role in connecting systems, enabling seamless transactions, and facilitating real-time data exchange. From an attacker’s point of view, it’s much more convenient to bypass the application and go straight to the API. This avoids the need to change the application user interface or write complex and often fragile screen-scraping code in order to capture payment card data, a practice known as skimming. Moreover, API attacks can yield more information that then allows the attacker to penetrate deeper into the entity’s systems. It’s for these reasons that API security in a payment processing context is becoming a pressing issue.
PCI DSS 4.0.1 contains a number of new requirements relevant to API security. Requirement 4.2.1, for example, now demands the entity confirm that the certificates it is using for the transmission of Primary Account Number (PAN)transmissions over open, public networks are valid and not expired or revoked. This will require the application of strong cryptography of PAN data when it is transmitted over external networks, which is why it is classed as one of the more complex requirements, step one of meeting the requirement will be identifying the API endpoints that transmit that PAN data.
Requirement 6 pertains to the development of secure applications and systems and it has seen 6.2 revised to apply to bespoke or custom software. It also includes some important clauses for API development, such as 6.2.3 which requires the inspection of application code to identify and correct potential coding vulnerabilities prior to production. Critical to this is the secure integration of external components such as libraries, frameworks and APIs. With respect to the latter, this necessitates APIs are assessed for any weaknesses such as misconfigurations, vulnerabilities or weak encryption cyphers which then need to be managed or remediated.
Of course, testing shouldn’t just be carried out at the preproduction stage. Testing during runtime is just as important as well as monitoring API behaviour patterns. This can then help ensure compliance with Requirement 6.2.4 which seeks to avert or lessen the impact of common software attacks and related vulnerabilities through software engineering techniques or other methods, which in the case of API attacks can vary enormously from simple injection attacks to highly subtle business logic abuse.
Another new requirement is 6.3.2 which specifies the need to maintain an inventory of bespoke and custom software, such as APIs, along with third-party software components integrated into the software, to aid in vulnerability and patch management. Knowing which third-party components are used in the entity’s software, and monitoring the availability of security patches to address known vulnerabilities is vital when it comes to ensuring the security of the software.
Of critical importance is requirement 6.4.2 which replaces 6.4.1 which previously stipulated that an organisation can manually assess their vulnerabilities as a detective control OR use a preventative control. The new requirement demands an automated, preventative control is deployed that continually detects and prevents web-based attacks toprotect public-facing apps.
While many entities will already have automated application security solutions in place, their ability to both detect and prevent attacks with respect to APIs is likely to be limited. Web Application Firewalls (WAFs), for instance, take a signature-based approach which means they are unlikely to be able to detect reconnaissance activity and attacks that to all intents and purposes look like regular legitimate traffic. Even if they do block an attack, they’re unable to track the threat as it pivots and then take evasive action such as by using deception to exhaust the attacker’s resources. For this reason, this is classed as complex not just because entities will need to move from a manual to an automated approach but also because they will need to assess their capability to detect and prevent attacks from escalating.
These are some of the complex requirements under PCI DSS 4.0.1 which relate specifically to API security and meeting them is likely to be demanding. In order to do so, the entity will need to review its current provisions and what additional measures must be put in place and it’s imperative that this is done sooner rather than later. Delaying until nearer the deadline will place the entity under pressure to comply, with the main focus being on satisfying the QSA rather than on achieving the continuous compliance lifecycle envisaged by the new regulations. Viewing PCI DSS as an ongoing process will make it less painful to phase in changes and will also confer the most benefit, ensuring the entity’s security posture is maintained efficiently and that PCI DSS becomes just part of day-to-day operations.