The Open Banking API Security Imperative

The second Payment Services Directive (PSD2) in Europe, which requires banks to open their payment services to third parties via a series of APIs, has enabled a range of new FinTech products that make it easier for consumers and businesses to manage their finances. Meanwhile, in North America, there is a drive to adopt a newer, common data-sharing standard within banks and FinTech firms that can support interoperability, security and privacy, called Financial Data Exchange (FDX). This standard is designed to deprecate the older data-sharing standard, Open Financial Exchange (OFX). Both PSD2 and FDX are available as an Open API Specification and the institutions are required to implement it on their own.

Too often, the assumption is that the underlying security of banking products is inherently strong. While the banking sector’s abundance of regulations and a culture of caution generally leads to stronger security, we can’t ignore the fact that, like most consumer companies, FinTech firms and banks are all under the same pressure to innovate and deliver products quickly. At the same time, the growth in consumer-authorized data access has ushered in a wide variety of innovative new products from outside of traditional banking and FIs, making the need for speed even more important.

It’s in this rush to get new features and products to market that mistakes can be made leading to data exposure and leakage over the APIs. It’s the nature of APIs that make these mistakes so dangerous. Here are just a few of the reasons why:

• API security is not widely understood. This is critical as we see a lack of API security expertise across all parts of the product lifecycle – from development to QA to security to compliance.
• Developers mistakenly expose more data than they should. Often, the exposure happens in an effort to improve the customer experience, but it can also make it easier for bad actors to abuse the API or business logic. For example, hidden parameters can lead to threats like privilege escalation, and confidential or sensitive data could also be exposed in verbose error messages or response codes.
• Shadow APIs published outside of the security team’s purview are likely rarer in FinTech than other industries, yet they pose a significant risk and must be reined in. Developers and security must work collaboratively to publish secure APIs and manage the entire lifecycle. Similarly, there may be deprecated APIs that were not fully removed from public availability. These too should be managed more effectively.
• APIs make the PSD2exfiltration of data easy and fast, allowing for massive amounts of data to be moved with little effort. This is a great feature for bad actors and headache-inducing for security and compliance teams.

Given the attractiveness of information passing over Open Banking feeds and the commercialization of attack tools and bots, it is imperative that all participants in the production and consumption of Open Banking APIs pay extra attention to the security across the entire app lifecycle. This is a considerable effort, but important as the threat from bad actors will only increase over time.

Get full visibility of the API landscape across your organization

API security begins with runtime visibility. With collaboration across development, operations and security teams, a runtime API security solution helps all involved understand how many APIs are deployed across the organization, their usage patterns and their respective risk levels. These are critical API visibility elements that contribute to a strong and comprehensive API security posture.

Consider some of these questions and think about what it would take to get the answers for your organization:

• How many knowingly published, shadow or deprecated APIs do we have?
• What are they used for, can we see and analyze traffic patterns?
• Do our APIs adhere to specification definitions and how do we maintain conformance?
• Are there any hidden headers, parameters or response codes in our APIs?
• Is encryption enabled for APIs to transmit PII or sensitive data securely?
• Are any APIs accessing regulated data in a way that will jeopardize compliance?

Continuously monitor and assess the security risk of your APIs

With an inventory of your APIs and visibility into the traffic and activity, the next step is to assess the risk associated with the APIs. Considering that many organizations today employ continuous deployment, it is necessary to move beyond periodic assessments and move toward a model of continuous assessment. Get a tool that will help your team automate API risk monitoring with customizations that allow you to map the risk checks to your API specifications as well as your organization’s security policy. Some of the checks may look for issues like:

• Access controls and authentications have been implemented to match the criticality of the data,
• Confidential or sensitive data transmitted across APIs without encryption,
• API traffic coming from known malicious IPs or traffic that doesn’t match known good behaviors

Make risk reduction a priority

Having visibility and understanding risk is great, but doesn’t do much if risk reduction isn’t a priority among the development team. Consider rolling out processes or workflows which make it easier for development teams to be notified of risks in their code and helps them identify remediations or resources who can help identify alternate, more secure, implementations.

Implement strong controls and protections

With automated attacks getter ever easier for bad actors to execute, it’s critical to have a way to identify them and respond appropriately when your APIs are the target. Yet another layer of defense for your Open Banking APIs should be the use of threat prevention tools that can stop traffic that doesn’t conform to your API specifications and also blocks malicious bots.