While SCA might thwart some cybercriminals, Open Banking APIs present a new opportunity
By Andy Still, CTO, Netacea
Credential stuffing has plagued the financial services industry for a while. It is a technique involving cybercriminals using trial and error to ‘stuff’ stolen usernames and passwords into log-in pages, at high velocity, to gain fraudulent access to accounts. Bank accounts are the jackpot for cybercriminals. Once in, they can move money, make purchases, and even set up direct debits all without detection.
Yet, the advent of PSD2 and its subsequent Strong Customer Authentication (SCA) requirements that needed to be implemented by the 31st December 2020, will hopefully see credential stuffing become a thing of the past for many in the industry. SCA demands that certain payments use two-factor authentication, meaning cybercriminals have to work a lot harder to bypass extra security. Without this additional step, cybercriminals can use bots to check thousands of stolen card details and passwords every minute. These credentials, leaked by data breaches and then sold on the dark web, are much less effective if hackers need to also try to subvert one-time passwords and other security methods.
Making the jobs of cybercriminals harder seldom has negative effects. But the issue that banks and other financial service providers need to face is that when one method of attack is thwarted, cybercriminals won’t simply give up—instead, they will look for another way in. And PSD2, the regulation that demands SCA, gives them an opportunity: APIs.
Trending
APIs: prime targets for cybercriminals?
The UK has already adopted banking APIs thanks to the Open Banking initiative. Aimed at democratising the banking industry, Open Banking requires banks to open up their APIs, allowing third parties to access the financial information needed to develop new apps and services and providing account holders with greater financial transparency. However, these APIs are a prime target for cybercriminals.
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 fully protected from attacks. Businesses have three points of vulnerability—the browser, the mobile apps, and the API server—and all of these can be exploited to initiate attacks.
Read More: Bot operators are expanding their scope: from sneakerbots to general sniperbots
In addition, many businesses don’t seem to fully understand the risks associated with APIs. Our recent research shows that businesses, including financial services, rank mobile and website as about as likely as each other to suffer from a bot attack, with APIs in a distant third. This could be due to a lack of available APIs, but it is much more likely to be indicative of a lack of awareness, visibility or thought around bots using APIs as an in.
However, even if banks take every precaution to make sure their APIs are secure, there are ways to attack them that are beyond their control. A hacker with access to a TPP’s system could use it to scrape personal details. Or a poorly designed third-party app could be used by a hacker to reverse engineer access to an API and use automated attacks to attempt account takeover and commit fraud.
Banks are being asked to secure their APIs. But even if they do this perfectly, they are still vulnerable if the third parties connecting to their APIs are careless. Blocking IPs and blacklisting certain TPPs will provide a partial solution, but a further problem remains—banks will no longer understand their data traffic.
Right now, good and bad bots, alongside humans, are interacting with online and mobile banking. There is enough history available to identify good and ill intent, and block those who are looking to takeover accounts or perform similar attacks. APIs do not have the same history, making distinguishing between the good and bad guys even harder.
Strengthening the industry’s position
Banks not only need to secure their APIs, they also need to quickly get up to speed with what honest and malicious intent looks like. And the best place to start is looking at all the API interactions. Once an overall picture of how TPPs interact with banking APIs is formed, it makes bad behaviour more obvious.
But the bot landscape is evolving so quickly that what looked like good and bad behaviour six months ago will have changed. Regularly reviewing the activity happening on APIs is imperative. The more the industry learns about APIs, the stronger the position they’ll be in to combat attacks in the future.
While traditionally banks have kept information to themselves, Open Banking has changed that forever. And the same openness should now apply to cybersecurity. Banks must initiate conversations with partners, competitors, and customers to bolster the industry’s understanding of attacks and become united in the fight against cybercrime.
