Strengthening API Security in 3 Steps

Dr Paul A. Watters , Strategic Cyber Consultant, Ionize

Dr Omaru Maruatona , CEO, Aiculus Ltd

The recent headline was clear – “JP Morgan Chase … is now routing all inquiries through its secure application programming interface instead of allowing these services to collect data through screen scraping1.”

To the non-specialist, this kind of headline may seem completely innocuous; to the specialists in Enterprise Application Integration (EAI), the end of era, as old-style, mainframe-embedded services often operating through dedicated data lines at great cost, could finally make the transition to an open and automated internet.

What could possibly go wrong?

The approach really signals a seismic shift in banking – and supported to a large extent by regulatory zeitgeists like “Consumer Data Right”2, “Open Banking”3 and the like. These initiatives are designed to introduce competition between financial services providers at a very granular level; from the consumer perspective, no longer should one monolithic bank be providing all of the backend services involved in money management. Through a whizz-bang set of magical tricks, providers can be selected optimally (sometimes behind the scenes) with a single, coherent view of one’s financial status presented through an app.

Again – we ask the question – what could possibly go wrong?

In security, generally speaking, the easier and less restrictive that something becomes, the greater the potential for abuse. This is certainly the case for the widespread use of APIs – we are not dinosaurs advocating for a return to isolated, expensive mainframe systems. Yet, it is also true that unregulated, uncontrolled APIs being exposed on the internet have also been the scourge of a number of recent data breaches4.

Screen scraping provided an unintentional layer of protection – almost, you could say, security through obscurity, or just the practical difficulties of exploiting what was a semi-automated and cumbersome process. We can’t go back to the old days. In order to support CDR, open banking and other initiatives, what is the best way forward?

Let’s look at the basics. An exposed API is typically going to be made through port 80 (not secure!) or port 443 (secure!); these ports are almost always opened through the firewall, otherwise standard web traffic will not be allowed in or out of the network. So a standard perimeter defence is not going to protect an open API, particularly if the authentication credentials are correct or if it requires no authentication at all, which some APIs do.

In all likelihood, open API deployments will need to consider a risk-based approach. This means monitoring inbound requests and outbound traffic, to determine whether it constitutes a data breach (or not). Another difficulty is that data breaches are rare, so there is great potential for time-consuming false positives to be generated with low frequency (true positive) events. We believe that one way to approach the problem is to adapt the kinds of techniques and strategies used by banks to detect fraud – this approach, using Artificial Intelligence, uses both rules and data mining to score whether transactions are likely to be fraudulent (or not). By scoring each request and response to an API request, high risk transactions can be paused, investigated and/or rejected. This is the approach that Aiculus has taken with the development of our API security product, building on Dr Maruatona’s experience in designing banking fraud detection systems using ripple-down rules and Prudent AI5.

A complementary approach is API red-teaming; at Ionize, our approach builds on our standard methodology for web application penetration testing. After scanning for known vulnerabilities from the infrastructure and web stack, we then try to build and test queries and requests that could be used to bypass any technical controls that have been put in place. Many open APIs use the Simple Object Access Protocol (SOAP) – essentially providing remote method invocation using a HTTP/HTTPS request – and unsurprisingly, there are numerous documented approaches to SOAP hacking6, which could be exploited for a data breach.

Finally, and perhaps an over-riding consideration, is having proper architectural reviews done on system, network and data design, well in advance of any implementation of any kind. A typical Ionize architectural review will ask broad and probing questions of the design team, such as:

• Are there any situations where a query needs to return ALL data elements from one or more tables? If not, then data should be segmented to prevent whole customer databases from being downloaded.

• Do all network services within a subnet need to be exposed? If not, then the most restrictive access permissions at all network layers should be implemented.

• Are user roles and access permissions well-defined and consistently implemented? How are networks agents authenticated – are static strings as security tokens visible in system memory, on process lists, or sniffable on the network?

This list is not meant to be exhaustive, but illustrative, of a typical 10-day API penetration testing engagement.

In summary, to protect APIs, we recommend:

• Security architectural advice from a blue team prior to development and implementation
• Penetration testing prior to system deployment, and at regular intervals as patches and tech stack upgrades may introduce new vulnerabilities
• Real-time monitoring and risk scoring of all API requests and responses, using AI, to block suspicious requests that might be indicative of a data breach.

[1] https://www.americanbanker.com/news/jpmorgan-chase-says-it-has-fully-eliminated-screen-scraping

[2] https://www.insurancenews.com.au/local/optus-breach-increases-caution-over-consumer-data-right

[3] https://www.finextra.com/newsarticle/41271/saudi-arabia-unveils-open-banking-framework

[4] https://www.complianceweek.com/cybersecurity/cyber-risk-management-lessons-from-optus-data-breach/32223.article

[5]Maruatona, O., Vamplew, P., Dazeley, R., & Watters, P. A. (2017, November). Evaluating accuracy in prudence analysis for cyber security. In International Conference on Neural Information Processing (pp. 407-417). Springer, Cham.

[6] https://brightsec.com/blog/top-7-soap-api-vulnerabilities/