Application Programming Interfaces (APIs) have become so integral to modern software architecture and the digital economy that regulators and standards bodies alike are now prioritising their security to keep data secure, writes Andy Mills, VP of EMEA, Cequence Security.
Regulations like GDPR, the Payment Service Providers Directive 2 (PSD2), and the Payment Card Industry Data Security Standard (PCI DSS 4.0) either indirectly or directly require them to be protected and secured. However, as legislation is updated, we can expect regulatory zeal to increase in this area.
Compliance in an API context can mean two things. Initially, it was used to describe the need for APIs to comply with a build specification to ensure APIs are produced to a uniform standard and use the same code, making it more straightforward to manage them. In contrast, regulatory compliance refers to the need to make the API conform to the demands specified in a government or industry standard, particularly in heavily regulated sectors. API governance is often used to describe the oversight of both forms of compliance and the implementation and enforcement of effective security practices.
Protecting data and GDPR
To make matters more complicated, the security of the data is often specified in these regulations, which implies that security steps must be taken to secure the API. An excellent example is GDPR, which governs access to personal data at rest or in transit, which must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing”. It seeks to ensure data security is secure by design and by default, so, from an API perspective, this points to the need to bake security into the development process using approaches such as ‘shift left,’ which sees security assessed pre-production.
Therefore, the most relevant aspect of GDPR is the security of processing, dealt with in depth in Article 32, with 32.1.b., stating the need “to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and service” and 32.1.d, which requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures.”
In layman’s terms, this means that the operational resilience of the API must be assured while the measures put in place also need to be robust and demonstrate their ability to mitigate the risk of a data breach. APIs left unmonitored or exposed would therefore be in breach, which should be a wake-up call for those organisations with shadow APIs. But the regulations also indicate the need to continuously monitor API activity to demonstrate due diligence.
GDPR is set to be replaced by UK GDPR following our departure from the EU and is currently wending its way through parliament under the Data Protection and Digital Information Bill, which is expected to come into effect in the spring of 2024. However, it is unlikely to have any fundamental changes concerning technical controls, particularly given that the UK wants to maintain imperil the EU-UK adequacy decision, which allows data to flow freely between the two.
PSD2: a testbed for API compliance
The financial sector has been the most proactive when it comes to API compliance regulations. Under PSD2, several changes have been introduced to boost service innovation while protecting consumer data, helping to pave the way for open banking.
PSD2 mandates banks to share customer financial data with authorised third-party providers (TPPs), and it does this through AIS (access to transaction data) and PIS (the ability for third parties to initiate payment), all via secure APIs. It’s spawned numerous use cases that have streamlined user verification, affordability and approvals, and it’s for this reason that you’ll have been presented with new ways to authenticate under Strong Customer Authentication (SCA).
However, it was expected that, after its introduction, more European banks would start to adopt open API standards, prompting a review last year. The PSD2 evaluation report published by the European Commission found that while APIs provide much richer data sources compared to when screen scraping was used before, the way in which they have been regulated has seen a few issues emerge.
Due to differences between the APIs used for processing, there is now a two-tier system of mandated and non-mandated (or ‘premium’) APIs and market fragmentation The report claims, “APIs vary greatly from bank to bank, even though they sometimes claim to use the same standard. Furthermore, they often do not work properly. For example, TPPs often do not receive the correct status feedback for scheduled PISP payments. The availability of APIs remains patchy, the scope of the data being accessed remains unclear, and the eIDAS certification’s reliability is inconsistent across the EU”. A damning assessment indeed.
One API to rule them all
As a result, TPPs have called for more API standardisation and better regulation over those controlling the APIs that provide access (PSD2 sets a performance criterion for APIs but the standards used are left to the industry). This is because access is made difficult by the API provider (the report notes that without incentives or enforcement, some banks limit or at least complicate access to their data). But also, the lack of standardisation prevents the TTP from dealing with multiple banks and benefiting from economies of scale, forcing them to use aggregators. In fact, the report acknowledges that aggregators are “a market solution to the absence of a PSD2 API standard and the large number of APIs”.
That said, there are opponents to a standardised API, with some arguing that it would hamper innovation and the ability of banks to develop their own interfaces. Currently, there are several competing standards rather than a definitive one, and while this has slowed progress, it has not impeded it. Others argue that making standards more transparent would make more sense rather than going for a single API standard.
As mentioned, another major issue is Premium APIs, which allow those wishing to offer AIS or PIS to provide their customers with services that go beyond PSD2. This is problematic as it can see unlicensed TPPs gain access to similar information to that provided via licensed PSD2-compliant APIs. Then there’s the fact that some API aggregators offer licence-as-a-service, enabling TPPs that do not hold a PSD2 licence to offer AISs and PISs to their customers. Both effectively undermine the value of regulated PSD2 APIs and may even give the unlicensed TTP a competitive advantage.
SCA also seems contentious. Only 58 per cent of those questioned in a related survey said it had contributed to a high level of protection for the payment service user. Some stated that while data sharing (AIS) was much better than before (exporting and sending CAMT/MT940 files), within the commercial APIs provided by banks, unlicensed parties could still connect to banks. This effectively creates a hole in the protection layer that PSD2 provides. Moreover, digital payment fraud and social engineering attacks that persuade the user to make a payment were also said to be on the rise.
The report illuminates that we’re still in the early stages when it comes to the rollout of open banking and that attacks via APIs remain a real issue. A reluctance to provide access, poor results and a lack of interoperability are all stymying adoption, while the emergence of alternative pathways threatens to destabilise the standard. European regulators will want to turn this around, so we can expect to see APIs, their functionality and security hotly debated this year, and perhaps even the advent of PSD3.
PCI DSS gets to grips with APIs
Staying on the topic of finance, the latest incarnation of the Payment Card Industry Data Security Standard, PCI DSS 4.0, has also been amended to accommodate APIs. An API would come into scope for any organisation hosting an API interface to receive or transmit cardholder account data. Released in March 2022, version 4 is set to become mandatory for most merchants and processors from April 2024 and its requirement 6 (Develop and Maintain Secure Systems and Software) is related to API security.
There is provision for preproduction security testing, for instance, in section 6.2 on custom-developed software. It stipulates that code should be developed and subjected to code reviews to ensure it adheres to secure code guidelines, with existing and emerging vulnerabilities looked for and corrections made before the release of the API.
The new specification also lists attacks to prevent/mitigate in section 6.2.4, which is business logic abuse referred to as “attempts to bypass application features and functionalities through the manipulation of APIs.” Even perfectly coded APIs can still be compromised using business logic abuse, which signature-based defence systems cannot detect and are powerless to stop. The giveaway is the behaviour and the requests being made to the API, changes in web traffic volumes, and burst rates, which makes continuous monitoring of all API calls a must. AI models can learn business logic. Going forward, we will see more widespread use of Generative AI test suites for each API.
Requirement 6.3.2 calls for the security of bespoke software, including libraries, while section 6.4 focuses on protecting public-facing web applications against attack. External APIs are at higher risk of discovery, so additional safeguards are needed, such as regular annual reviews or automated technical solutions that can detect and prevent attacks (6.4.1). Requirement 6.4.2 calls for the continuous detection and prevention of web-based attacks. It details on what such an automated technical solution should do, from actively running i.e., continuous monitoring to generating audit logs and then blocking or generating an alert in the event of an incident to trigger an immediate investigation.
Revisions for developers
From a developer’s perspective, the PCI SSC has 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 to protect transactions and data, minimise vulnerabilities, and defend against attacks. It now 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.” Both are important because they help amplify the importance of combination attacks where threat actors mix and match attack methods, an increasingly common tactic.
The changes to both the PCI DSS and PCI Secure Software Standard reveal that API security will now need to be prioritised by merchants and processors. APIs must be securely developed, continuously monitored and managed 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. To do that, API-specific tools that use behaviour-based detection and defence tactics for blocking and frustrating attackers will need to be deployed.
These three standards – GDPR, PSD2 and PCI DSS 4.0 – all have compliance criteria applicable to APIs and as the regulations evolve, so too will the requirements to become more defined and demanding. The attention of the regulators reflects a growing recognition of the importance these APIs play in the access and movement of data across the digital ecosystem and their ability to enable sectors to innovate and flourish.
But there’s a clear message for those who must observe these regulations. Governance, risk and compliance (GRC) efforts must now incorporate API security and solutions must be deployed that can produce the evidence necessary to demonstrate all efforts have been made to comply. Otherwise, be prepared to face the prospect of punitive penalties, a compromised reputation and financial repercussions, including lost customers.
