The European Parliament adopted the PSD2 (Payment Services Directive) which aims to promote development and use of innovative mobile and online payments through Open Banking.
Several countries are now adopting and launching open banking initiatives based on the European and UK model. Many of these include provisions that enable financial applications to transact and manage finances, as well as for consumer credit firms to access account information for verification and credit checks with customers’ consent.
By adopting Open Banking, banks and FinTech firms are adopting a common framework of APIs to offer customers better and faster services along with innovative products. These include apps that help carry out e-KYC, government document verification, offer tailored insurance products, get credit scores, and much more. And just as websites and mobile applications are vulnerable to malicious bot attacks, so are these APIs.
These standards and requirements come to address several issues such as access violations, broken authentication, code injections and other attacks that may result in identity theft, data leakage or fraud. Many of these attacks today can be carried out by malicious bots, and it is important to pay attention and consider handling bot traffic.
Why Bad Bots are important
In just the first 6 months of 2020, bad bot attacks on APIs grew by 30% over the previous year and are likely to proliferate as attackers find more vulnerabilities that they can exploit.
Recently bad bots made up nearly 54% of all traffic at a major bank’s website where only 39% was human. The bank’s log-in page alone registered 4.3 million bot hits over a two-week period, three times the number of genuine visitors, providing a clear indication that the bank was being heavily targeted by bad bots.
While bot attacks on websites and applications are by now a well-known threat, it is not as widely known that crucial APIs, including those used for Open Banking, are increasingly being targeted by cyber criminals using bots. Modern websites and applications are almost entirely powered by internal and external APIs that drive back-end systems, mobile applications and other essential services to enterprises and their customers
Before blocking all bots, we must remember that APIs are at the core of Open Banking, enabling exchange of data between financial organizations. These APIs are at risk of exposing customers’ PII (Personally Identifiable Information) as well as the business logic of the applications they facilitate. Therefore, we would want to let the business run without interfering the good bots. As advanced bots can mimic real human behaviors today, one should ask how to make a definitive distinction between good and bad bots.
Bad Bots Put Open Banking APIs at Risk
Loss of PII and business data: Breached APIs can expose PII to attackers, putting at risk sensitive personal data including account and transaction details, purchase histories, and much more. For financial institutions, data breaches are among the most harmful in their impact, leading to customer churn, litigation, and potentially large compensation pay-outs.
Application DDoS attacks: As we have seen with banking websites and applications, there are growing numbers of application DDoS (Distributed Denial of Service) attacks on APIs that attempt to overwhelm banking and fin-tech infrastructures. Carried out using sophisticated human-like bots distributed over thousands of IP addresses and device IDs, such attacks can be very difficult for conventional security systems to detect and mitigate. These attacks cause slowdowns and unavailability of critical applications and services, making for a frustrating experience for customers and organizations.
Payment and transaction fraud: Cyber criminals are always on the lookout for vulnerabilities that allow them to execute malicious attacks. While one of the goals of Open Banking is to make transactions easier and more transparent, nefarious botmasters continually probe systems for weak points and are known to sell exploit kits on the Dark Web that leverage sophisticated bots to carry out fraudulent transactions.
Protection of digital banking APIs
Intent-Based Deep Behavioral Analysis, or algorithmics that simply model the API calls and communication patterns, invocation flows and data templates, and classifies human traffic, good bots and bad bots. Specifically, IDBA studies patterns of access to a given application over time, as well as transitions across different nodes, blocking suspicious sequences. Cyber criminals often try to access the API to get the information as quickly as possible (for example, bypassing a Web-based log-in process to navigate to a funds transfer page). Hence, identifying bots that target embedded financial services APIs in different/anomalous manners than how legitimate users (humans and good bots) engage with the application.
Protecting Machine to machine (M2M) APIs. Every financial transaction transmits sensitive data and every access attempt must be authenticated. Conventional bot detection systems rely on the capabilities in the user’s web browser, from writing and reading cookies, to fingerprinting the user and device using the browser’s JavaScript capabilities, and analyzing various parameters and headers that every browser generates. API end-point protection requires a different approach. M2M transactions don’t use a web browser and are harder to analyze, not to mention fingerprint.
M2M communications protocols facilitate the transmission of messages between devices. Detecting and protecting API endpoints from abuse calls for a different set of capabilities, to provide the API server with a purpose-built layer of security when authorizing API requests. This second layer of authentication significantly augments protection for API calls over Open Banking APIs used by financial institutions.
Specialized protection from account takeover attempts. Account takeover comes in different forms, mostly bruteforce (password cracking) or credential stuffing – using known & valid credentials in mass in order to break in. the challenge obviously is to prevent access and data leakage even though the login seems legitimate. unfortunately, sophisticated bots today find their ways around 2FA. and it is even more difficult to confirm when accesses via a mobile or device APIs
Prospective Solution to safeguard Data Transactions
When evaluating solutions, you want to ensure your protections go beyond a generic approach that is typically leveraged for websites. Specifically, look for a solution that can:
- Secure sensitive data from leaking because of bot attacks such as ATO or web-scraping
- Eliminate financial impact of bot attacks on monetization APIs
- Reduce API consumption and utilization costs
- Provide visibility into violations and exploitation of bots targeting APIs with intent-based analytics
