Open Banking — Security Implications of the Global Trend
Open banking originated and is most evolved in Europe, but its concepts have reached just about every corner of the globe with financial services and FinTech companies around the world taking notice. While lots of companies do not yet fall under specific open banking regulations, many have used its constructs as a framework for modernization.
Open banking aims to give consumers more control over their financial data and, ultimately, their financial lives. Open banking also creates new opportunities for those in the financial industry to innovate and create new, differentiated services for their customers and enable new revenue streams.
APIs are at the core of open banking, enabling financial institutions to standardize how they create and connect to an ecosystem of providers to exchange financial data. To a large degree, open banking has ushered in a democratization of banking across the globe and this has all been possible thanks to APIs.
Just because it’s a “standard” doesn’t make it secure
While open banking defines standards around how APIs should be structured to enable predictable integrations, it provides no standard to meet the majority of security requirements for APIs. Much of the focus for security in open banking centers on the basics — authentication, authorization, and encryption. These technologies are all foundational for any security program, but they fall short of meeting the security challenges that APIs create.
APIs have best practices to define how to implement things like authentication and authorization, but these best practices leave a lot of room for interpretation.
As an example, more than one way exists to implement a service through an API making each API unique with unique logic. With unique logic, it’s difficult to standardize on how authorization should be applied. Furthermore, considering many services under the open banking umbrella combine multiple APIs, the result is unique APIs with unique logic connecting to other unique APIs with unique logic. This combination of APIs results in a multiplicative effect with new logic and ultimately unique vulnerabilities.
Why the basics aren’t enough to secure APIs
It should be no surprise that API attacks are on the rise. Recent headlines have included API breaches and vulnerability disclosures and the likes of well-known brands such as LinkedIn, Peloton, and Experian. The analyst firm Gartner has been saying for years that “by 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.” That’s just six months away, and Gartner recently updated their prediction to say that “By 2024, API abuses and related data breaches will nearly double.”
For attackers, authentication is a low bar to step over. It can be easy to get a legitimate login, phish credentials, or in extreme cases, brute force their way into an API.
After authentication, encryption does little to protect data since the primary use for encryption is to protect data in motion. An authenticated user can easily access unencrypted data from their endpoint without jumping through hoops with a man-in-the-middle approach.
Once authenticated, authorization is responsible for controlling what a user can and cannot do. In theory, authorization should take care of a lot of security. In reality, getting authorization 100% right for APIs is an unrealistic goal. That’s why Broken Object Level Authorization is the number one threat on the OWASP API Security Top 10 and the most commonly found vulnerability in all APIs.
Why is authorization hard? APIs have complex logic, and applications are a combination of multiple APIs with complex logic. Today’s applications also often combine APIs developed by multiple internal and external teams combining different approaches to creating that logic. Something especially true when it comes to open banking APIs.
Consider also that authorization requires multiple levels. Customers, partners, developers, and admins are just a few of the dimensions to consider when defining authorization policy.
Another factor is that many APIs are constantly changing with updates and new functionality. These updates can change the logic and have an impact on the authorization requirements. It can be difficult, if not impossible, for teams to keep up with the rate of change and keep policies in sync to enforce proper authorization without making mistakes.
Why traditional solutions don’t protect APIs
Beyond the basics there are a class of traditional tools that include WAFs and API gateways that also fall short when it comes to protecting APIs. An earlier blog post, Stopping API Attacks: Columbo, Correlation, and Context, details where these traditional solutions fail. In short, API attacks are low and slow as an attacker performs reconnaissance to uncover the structure of an API, understand the logic, and look for vulnerabilities. Traditional tools have architectures that limit their ability to gain the context needed to detect this low and slow activity.
Because of proxy architectures, traditional tools are limited to inspecting each transaction in isolation using signatures and policy to detect and stop known malicious traffic. Since each API has unique logic and vulnerabilities, it’s impossible to create a signature to look for an attack pattern. It’s also close to impossible to create and maintain policies for each unique API, especially since they’re likely constantly changing.
Learn why apps are built on APIs, the security risk APIs present, and best practices for securing APIs.
Download NowWhat is needed to protect open banking APIs
APIs require a new approach to security rooted in a new architecture — one that can go beyond looking at individual transactions in isolation. Big data is required to capture all API traffic, and utilizing artificial intelligence (AI) and machine learning (ML) is the only way to analyze that volume of data.
APIs also require security at every step of the lifecycle, another limitation of traditional tools. With an architecture of big data, AI, and ML, a solution can provide benefits across the entire lifecycle of the API.
Discovering APIs
Understanding the attack surface is critical for any security strategy, and is especially challenging with APIs that are constantly changing. A solution must be able to not only discover all APIs to uncover unknown shadow and forgotten zombie APIs but must also be able to perform discovery continuously to keep up with the constant release of new and updated APIs. Discovery is a function that benefits from automation, given that APIs in an average organization can easily number in the thousands, and those APIs are likely changing on a regular basis.
Knowing that an API exists is not enough. Understanding an API at a granular level is critical to understanding the intended functionality and if the API exposes sensitive data such as personally identifiable information (PII).
Development-created documentation can be inaccurate and incomplete, especially as new versions of an API are released. It’s also not uncommon for documentation to lag behind a new release or for developers to fail to update documentation altogether. Inaccurate documentation not only has security implications as security teams lack an accurate understanding of the attack surface but can also impact reusability within your organization and with partners — an important factor in open banking.
Stopping API attacks
A solution with an architecture combining big data, AI, and ML can capture all API traffic to create a baseline of normal activity and look for deviations. However, identifying deviations alone is not enough since many deviations can legitimately stem from unique users, unique partners, user mistakes, or changes to an API. This is where context and the correlation of activity are critical.
Combining context and correlation, a solution can build a profile for each user to identify if the deviation is an isolated incident (e.g., a user mistake), caused by a change to the API, or a pattern of malicious activity coming from an attacker probing for vulnerabilities. Correlation not only allows the solution to pinpoint and stop an attacker early in their process, but it also minimizes false positives to near zero. A solution using a combination of context and correlation should not alert on each deviation but rather focus on the user to alert and take action when that user has hit a threshold of risky deviations.
Another benefit of analyzing all activity with a combination of context and correlation is identifying a malicious user early in their process. Unlike traditional tools that can only identify known malicious traffic, a solution using context and correlation can predict that a user is acting in a potentially suspicious way and stop them before they send actual attack traffic to exploit a vulnerability.
Remediating gaps
Dev teams play an important role in security, but it’s inevitable that any software will release with gaps despite employing development best practices and scanning tools. APIs are no different. Arguably, APIs are more susceptible to gaps because APIs go hand in hand with rapid development practices and frequent release cycles, meaning that dev teams might compromise security to meet tight schedules.
Runtime protection is critical to prevent exploitation of any vulnerability that makes it to production. But relying solely on runtime protection leaves you in a situation of playing a virtual game of whack-a-mole. Gaps must continually be identified and eliminated by dev teams to improve security posture.
A runtime API security solution can uniquely provide a real-world view into vulnerabilities with valuable remediation insights. These insights are not simply best practices and identification of theoretical vulnerabilities but rather gaps that an actual attacker has tried to exploit. A solution can and should provide these insights and details on what normal usage of the API looks like and recommendations on how to close the gap — all essential details to help development teams prioritize and eliminate gaps quickly.
In addition to real-world insights, an API security solution should analyze APIs to identify gaps before an attacker finds them to allow developers to proactively eliminate potential vulnerabilities while simultaneously sharpening their API security best practices.
Protecting open banking APIs with Salt Security
Salt Security is an API protection solution used by FinServ and FinTech companies such as Ally Bank, Finastra, City National Bank, Payoneer, Celsius, and others to protect open banking APIs and other APIs critical to their services. The Salt solution has an architecture built on big data, AI, and ML to help customers discover all APIs and exposed data, stop attackers early in their process, and provide insights to developers to enable a model of continuous improvement for security. Salt has a flexible, easy model for deployment, does not require changes to application code, and is not inline, so there’s no impact on developers or applications.
If you’re building open banking APIs or other applications that use APIs, reach out for a personalized demo to learn how Salt can make your APIs attack proof.
