Still work to be done securing Open Banking as PSD2 deadline looms

I blogged yesterday about a conversation I had with an anti fraud expert about PSD2/open banking security. This post was focussed on the risks that human behaviour combined with the opening up of banking could increase the risks of social engineering from fraudsters. You can read it here.

There was also news yesterday of a study that shows that most fintech startups, like most banks, are failing to address vulnerabilities in the web and mobile application. Food for thought with the likely confusion that early open banking will bring to the market for consumers.

Banks and retailers have been given an extra 18 months to meet PSD2’s Strong Customer Authentication (SCA) rules as I previously wrote and have an interesting opinion piece from James Maude, head of threat research at UK security software company Netacea, on open banking security, which I thought timely.

Banks still unprepared for open banking security

By James Maude

Open Banking was the UK’s attempt to get ahead of PSD2 regulation, with an ambitious timetable for the biggest banks to create open Application Programming Interfaces (APIs). Despite this head start, the banks are underprepared for PSD2’s second major requirement, the demand for improved anti-fraud measures.

However, retailers and banks have a short reprieve. Strong Customer Authentication (SCA), the new EU rule that demands certain payments use two factor authentication, has just been kicked down the road by the Financial Conduct Authority (FCA).  It was predicted that 25% of payments were set to fail, thanks to a lack of preparation, so an extended deadline of eighteen months is bound to be a relief.

Criminals and fraudsters will also be relieved. SCA will make their jobs significantly more difficult—they’ll have to work a lot harder to bypass extra authentication methods. Without this extra step, it’s far easier to perform card cracking, using bots to check thousands of stolen card details. These details, leaked by data breaches and sold on the dark web, are much less effective if hackers need to also try to subvert one-time passwords and other security methods.

The issue that banks and other financial service providers face is that when one method of attack is thwarted, cybercriminals won’t simply give in—instead, they look for another way in and PSD2 presents a prime opportunity: APIs. The UK has already gone some way to adopting banking APIs thanks to its Open Banking initiative, opening up banking data to fintechs and other providers for the benefit of consumers and to encourage competition. The introduction of SCA means these APIs are more likely to be targeted.

Access to APIs is restricted to regulated third party providers (TPPs) that have been subject to extensive verification of their security, operational governance and risk management controls. But this doesn’t mean that they are necessarily 100% safe from attack. APIs can extend the ways in which an attacker will attempt to gain entry—through the TPP, mobile applications, or access to the API directly. Plus, while Open Banking has defined API standards, PSD2 is more open to interpretation, potentially leading to confusion over exactly how a secure API should be implemented.

The problem for banks is that, even if they take every precaution to make sure that the API is secure, there are ways to attack it that are out of their control. A hacker with access to a TPP’s system could use it to scrape personal details, but it doesn’t have to be quite so direct. An improperly secured and poorly designed third-party app configured to share the bank’s data is a direct link to an API that can be exploited in a “supply chain” attack—in which instance, automated attacks that test credentials and card details and commit fraud become possible.

Blocking IPs and blacklisting will only go so far to beating this problem—but APIs also present a new problem. The influx of third-party data will mean banks will no longer fully understand the data traffic on their systems. Previously, while there was some understanding of a user’s behaviour, this will be lost on the other end of an API. The potential issues, however, go beyond a loss of market intelligence.

Right now, bots (both good and bad) and humans are interacting with online and mobile banking. Banks understand this traffic, know what it looks like and can identify ill intent to block some common automated attack techniques. But they do not have the same knowledge and understanding of traffic to new APIs. Their ability to separate the good from the bad will be limited—not only is this a new attack vector, it’s one where an attack won’t be immediately obvious.

PSD2 is a much-needed legislation that presents financial institutions with new challenges. It also presents ample opportunity for banks to update legacy systems, collaborate and improve their security platforms. But banks not only need to secure their APIs, they need to quickly get up to speed as to what is normal use and what bad intent looks like. PSD2 represents a new spirit of openness, but it’s vital that embracing this does not expose financial service providers or their customers to additional risk.