On Tuesday 26th November, we hosted an evening of good food and networking to explore API security in the Open Banking environment. Throughout the event, Netacea’s CTO Andy Still and Head of Threat Research James Maude provided their insights, some practical advice for securing your APIs and answered your bot management questions.
What is a bot?
In the context of a web application, bot traffic is any request made by an automated script, tool or process rather than triggered by direct human action. This could be a good bot such as a search engine scanning a website or a bad bot, carrying out credential stuffing activity to break into an account using stolen usernames and passwords.
How does bot activity differ from hacking?
Hackers are using automated processes to carry out illegitimate activity to exploit technical weaknesses in your web-facing systems.
In contrast, bots are automated processes that carry out legitimate activity to exploit business logic weaknesses within your website.
Bad bot activity typically differs to the technical hacking exploits organizations are used to defending against. Often, bots will abuse legitimate business functionality like logging in or ordering goods rather than a technical weakness to directly access a backend database or system.
Take the attacks on Just Eat and Deliveroo over the summer for instance, the attack used ordinary, expected login and ordering functionality to place orders. However, the attackers used stolen credentials and were accessing the accounts for the purpose of fraud and not what the company intended. There were no technical exploits of the underlying systems, just automated abuse of valid business functionality by bots testing stolen credentials.
Why are we talking about PSD2/Open Banking?
PSD2 and Open Banking are designed to open-up banking and financial services markets, driving innovation and competition while giving customers more choice. To do this, banks and financial institutions are building web apps and APIs so that other financial institutions and third parties can access account information and manage payments.
This means that banks and fintechs are building a huge amount of new business functionality to access accounts and make payments. While this functionality is an opportunity to drive the next wave of digital disruption in financial services, it also opens up a whole new attack surface for cyber-criminals who can potentially use bots to break into accounts, transfer money and make payments. The delivery firm attacks above, exemplify how the desire to build new apps and services that are as easy-to-use as possible, can introduce new threats with bot attack vectors.
This is clearly a real concern for all involved in the emerging financial services marketplace as they deal with increasingly sophisticated bot attacks hunting for the weakest link in the banking chain.
Why does PSD2 require the implementation of new APIs?
Open APIs enable third-party access to account information and pave the way for innovation and competition in the market. From the consumer’s point of view, this means they can have one app that accesses information from all their bank accounts, across multiple banks.
While some of these aggregator services have been available for a while now, they have often relied on storing the user’s banking login details and using these to log in and screen scrape information from a bank’s website.
In the financial services industry, this is referred to as “direct access” and can raise questions such as:
- Should a third party be allowed to store a customer’s credentials?
- How does the bank know who is using the credentials?
Open Banking and PSD2 were designed to provide legitimate third-party access to account information using a purpose-built API and access tokens to mitigate the need to store credentials. It also facilitates third party access requests providing the ability to initiate online payments directly from a customer’s account. APIs give greater control to third party providers (TPPs) who can use a bank’s API to deploy their own solutions for businesses and customers, which can be integrated with data held by the bank.
What are the security implications of these new APIs?
API security is crucial and as such, API access should be restricted to regulated TPPs who can securely access the bank’s data. One of the challenges of securing the APIs is that the bank or financial institution may not have the visibility or telemetry of the end-user they previously had when users logged into their bank’s website directly.
With APIs, there is often a supply chain of third parties. For example, a financial aggregator service builds an integration with several banks, they then build their own API that they sell to smaller FinTechs and this API allows them to access customer account information. In such an instance, there are potentially multiple companies and APIs sitting between the customer and their bank. This increases the attack surface and risk.
Establishing a resilient API environment is absolutely crucial to maintaining a truly secure and high-functioning ecosystem in which both interconnected parties are protected.
If anyone of the APIs in the supply chain is exposed, bots could be used to takeover accounts, scrape data and prevent the API servicing real users.
What other challenges exist beyond the APIs?
The APIs required by Open Banking and PSD2 have limitations, they only cover some of the largest financial institutions and only provide access to certain types of account. This means that to build a comprehensive offering, aggregators and FinTechs will often revert to using direct access. This is worrying as direct access was one of the concerns that Open Banking aimed to solve.
The roll-out of these new services has not been smooth sailing, there have been delays, performance issues and deadlines pushed back due to industry concerns. Take, for example, the requirements for Secure Customer Authentication (SCA) for payment transactions; research warns of losses for retailers and lost transactions, which has led to an extended SCA deadline while concerns of added user friction are worked out.
While Open Banking offers a fantastic opportunity for innovation, there is a risk that the rapid pace of innovation is leading to startups prioritizing new features over security. This has been highlighted in reports of breaches and data privacy concerns expressed at a few entrants to the financial market place.
There is a clear need for an excellent integrator experience that provides quality security and performance while being developer-friendly.
How Netacea helps
Netacea works with several clients across financial services to provide insight and intelligence into automated bot threats across their websites, mobile apps and APIs. This comprehensive approach not only provides coverage of the entire attack surface but uses machine learning to understand how users interact with these systems and identify non-human activity and abuse.
By analyzing web and API logs, Netacea provides visibility and mitigations across the full attack surface, making it easier to detect unwanted activity without introducing additional user friction or adding third party code across all systems. This enables businesses to mitigate risk while providing an excellent customer experience.
with Netacea on the job
users and take a bite out of bottom lines. Netacea brings that world to life.