As APAC looks to open banking, security risks need tackling

Article by Reinhart Hansen, Director of Technology, Office of the CTO, Imperva

The banking industry is transforming from traditional brick-and-mortar offices to digital experiences powered by apps and application programming interfaces (APIs).

Today, banks seek to offer customers more digital services in a seamless manner, by collaborating with other financial services providers as well as non-financial partners.

One example of this is a mobile wallet that is linked to a bank account and capable of cashless payment at online or offline merchants. Or, an in-app purchase seamlessly tied to a user’s bank or credit card account.

This is all made possible with the advent of open banking, a broad concept that entails “opening up” banks to give customers greater control over their personal data. It enables users to connect to more services easily, instead of dealing with each one individually.

Open banking on the upswing

APAC governments have taken a variety of approaches to open banking.

In India, Thailand, and Australia, banks are required to share customer-permissioned data, and third parties that want to access such data must register with the authorities.

Meanwhile, Singapore, Japan, South Korea, and Hong Kong have adopted a facilitative approach. An industry standard-setting body or government agency issues guidance and recommended standards, and/or releases open API standards and technical specifications.

China is taking a market-driven approach like the US, where there are no explicit industry-wide rules or guidance that require or prohibit the sharing of customer-permissioned data by banks with third parties. This approach allows banks to release their own APIs.

While many APAC countries have not yet developed formal open banking rules, central and major banks are leading the charge, creating structures that dictate how banks can collaborate. This will lead to the swift adoption of open banking over the next few years.

Opening security gaps

Open banking is founded on the use of APIs. Fintechs rely on APIs to gain access to customer data and sensitive financial records to make their applications work effectively. Yet as more APIs are created and more data is shared, cyber risk is also increased.

APIs are fast becoming one of the most attractive entry points for cybercriminals for several key reasons. The first is simply that APIs have access to vast amounts of sensitive data. If cybercriminals are able to access that data and where it’s stored, APIs can suddenly act as a pathway to the internal database. This can be a metaphorical goldmine for a motivated attacker.

Secondly, the last few years have seen explosive growth in the volume of APIs managed by businesses, many of which are being created by development teams without any knowledge or oversight from security. A recent global survey by Forrester Consulting, commissioned by Imperva, revealed that 78% of respondents believe the adoption of APIs is important for their company to stay competitive, hence the rapid adoption and expansion of API libraries.

Thirdly, the vulnerabilities hackers can use to exploit APIs are also on the rise. In 2020, Imperva Threat Research found that the number of API vulnerabilities continued to grow, even as the volume of all other web application vulnerabilities fell. As a result, banks not only have a rapidly increasing number of APIs to manage, but they also have more vulnerabilities to manage.

And finally, the use of newer, more powerful API frameworks such as gRPC and GraphQL is growing among the developer community. These are less mature than older REST and XML/SOAP frameworks. Without appropriate baseline governance standards and security tools, they introduce new vulnerabilities to organizations.

A positive approach

The situation can feel desperate, but it is not an impossible challenge. Firstly, fintechs need to ensure they have full visibility and an always up-to-date inventory of all their APIs and their data exchange patterns. Secondly, they should consider adopting a positive security model around their APIs, meaning that all traffic is blocked as default, with exceptions made for traffic known to be legitimate. Think of APIs as exclusive nightclubs – if you are not on the guest list, you are not getting in. This approach not only helps filter out huge swathes of bad traffic but also helps defend against zero-day attacks.

DevOps teams should look to bake security into their API development, quality assurance, and testing process. Specifically, their development pipeline should look to make use of automation to generate test cases that validate each API endpoint against the OWASP API security model using both known and observed schema. Using observability to generate test cases and test data that helps validate the boundaries of each API endpoint and its associated business logic is paramount to being able to detect and remediate more advanced types of vulnerabilities. Once in production, continuous observability provides governance over API usage.

Beyond that, financial institutions should ensure that they understand the data risks for each API so that varying control and monitoring levels can be applied to each, based on their security, business, and regulatory risk profiles. Having this level of insight greatly increases the awareness of APIs and the risks that each one introduces.

Finally, as an effective defense-in-depth strategy for protecting against known and unknown (zero-day) application and API threats, it’s useful to leverage runtime protection. Runtime protection is the only application security control endorsed by NIST to defend against zero-day attacks. It applies a positive security model around the entire application or API runtime environment by enforcing guardrails around how the app/API can interact with the operating system, the network, and database layers. Through execution visibility at each of these layers, it provides a feedback loop that helps developers address vulnerabilities efficiently through enhanced API design and security testing.

Open banking has been a revolution for businesses and consumers. As demand for such services increases, banks and fintechs alike will find themselves ever more reliant on APIs. Already, the volume is threatening to overwhelm security teams stretched to the brink. Putting in place better processes, a positive security model, and automation where needed, will help alleviate a great deal of this pressure while enabling new services and APIs to be brought online safely.

---

---

---