Protecting Financial APIs and Managing Supply Chain Risk

The adoption of financial technology, or fintech, tools is at an all time high, and consumers expect easy digital access to their finances – they want to transfer money, check insurance claim status, and manage their investments online. In a study of fintech’s impact, 93% of consumers reported seeing real benefits from their fintech apps in 2022, an increase from 90% in 2021 and 84% in 2020 (Plaid). Financial institutions are highly motivated to offer homegrown tools as well as connect to third-party solutions in order to attract and retain customers.

Financial ecosystems are growing in complexity to deliver these capabilities, but unfortunately, these extended supply chains leave financial institutions at risk of breach and financial loss. In their 2022 Data Breach Investigations Report, Verizon estimates that supply chain breaches were responsible for 62% of system intrusion incidents (Verizon). Why is this type of abuse so prevalent, and how can financial institutions appropriately manage this massive risk vector?

To answer this question, it is important to understand how these ecosystems are constructed. Connections between ecosystem partners are usually set up via financial APIs, allowing for easy sharing of data. With the rise of these financial ecosystems, financial institutions are prioritizing API development: the percentage of bank and credit unions that have invested in or developed APIs grew from 35% in 2019 to 47% in 2021, with another 25% planning to invest in 2022 (Pyments). APIs are ubiquitous and sit at the core of modern digital financial services. 

Unfortunately, protecting these APIs isn’t as simple as it appears – it is easy to stand up an API endpoint, but ensuring its security is much harder. Most organizations assume that API security is built into the code that uses the API by the programmer, while programmers are far more focused on getting code out the door quickly and tend to believe that the API gateway software vendor is responsible for security. That vendor, in turn, may only provide the most basic protections while assuming the end customer’s security team will pick up the slack.

This results in connections that are easy to exploit, and these problems are only exacerbated by rapid development processes such as Agile. Note that Agile itself isn’t the problem – rather, without a mature DevSecOps process, it can lead to rushed development where security requirements are often overlooked, and updates to functionality may thus make the application less secure overall. Bad actors are well aware of the confusion around API security, and seek to exploit these vulnerabilities. This is one of the factors contributing to the high percentage of breaches involving supply chain partners.

The fact is that financial API security needs several layers to be truly effective.

API connections are categorized in two ways: exposed and unexposed. Exposed APIs are open to the public, giving easy access to business logic through an interface to any third party. Naturally, even with an exposed API, the business can control what it shows and to whom, but this type of API does greatly speed connections with third parties that make up the supply chain.

Meanwhile, an unexposed API is a point-to-point connection between two specific parties. While this seems inherently more secure on the surface, it does make growing the ecosystem more cumbersome, and the security problems that can arise are not actually dissimilar. An organization that thinks it is fully protected by utilizing only unexposed APIs must ask: “Are we willing to trust every organization we’re connected to and every single one of their employees, all of their contractors, and all of the other companies they're connected to?” If the answer to these questions is no, then avoiding exposed APIs doesn’t actually negate risk.

Here’s why: in either case, the API has a certificate that encrypts the channel, and the organization and the trusted third party in question share a secret, which anyone interacting with the API must know in order to interact with it. Unfortunately, much like a password or any knowledge-based authentication question, a secret can be hacked. What makes this baseline level of API security inadequate is the fact that the organization usually has no control over security protocols at the third party and all of their connected entities. A breach at a third party can lead to an API exploit at any connected organization.

As an example, imagine a bank has an API connection with a third-party payments provider. Now, imagine that this payments provider is hacked by a cybercriminal intending to get at the bank’s data. Whether this API is exposed or unexposed doesn’t matter in this case: if the hacker has infiltrated the third party and knows the shared secret, they can access the bank’s data via the API posing as the payments provider – and access whatever the bank has indicated the payment provider may see. Worse, a skilled hacker may manipulate the connection in a variety of ways once they’ve gained access, by tweaking object IDs inside of the API to gain access to further information or even injecting malicious data or commands disguised as parameters or file uploads.

These types of attacks are very common, as mentioned above. Unfortunately, given the nature of the financial supply chain, operating without API connections isn’t an option. Instead, organizations must look beyond the basic protection offered by channel encryption and shared secrets to protect themselves from supply chain risk.

API gateways provide the next level of protection for a financial institution’s APIs, making it more difficult for a hacker to slip through – although the protection they provide is still incomplete. Why? Gateways do several useful things, providing a governance function that brokers the connections between entities and acts as a central point that routes API requests, aggregates API responses, and enforces service level agreements. A gateway provides authentication and authorization functions, controls traffic, stops denial of service attacks, and adds telemetry and analytics, helping organizations better understand how APIs are being used. 

However, API gateways don’t inspect all the data being passed between the endpoints, which is critical to fully protecting the API. For example, imagine going to the airport and passing through security. The agent checks the passenger’s boarding pass and identification before waving them through. These activities are similar to the API gateway’s configuration and the programmer’s use of a shared secret to establish the connection. Assuming the identification and boarding pass are legitimate, is the passenger ready to board the plane?

Anyone who has flown knows that the answer is no, of course. It’s not good enough to have a valid form of identification and a boarding pass. Airport security checks what the passenger is carrying on their person and in their bags. Without this check, someone with a valid passport and boarding pass could still bring something dangerous onto the airplane. This is why each passenger’s carry-on luggage goes through the scanner. The agent reviewing the feed has seen millions of travelers. This agent is trained to look for anomalies – and luggage that seems off sticks out to the trained eye and can be pulled for deeper screening.

This is why looking at the data passing between endpoints is absolutely critical.

Remember the exploits discussed earlier in this article? Let’s assume the hacker in question has infiltrated a trusted third party and gained access to the shared secret. Now, this cybercriminal has managed to authenticate into the bank’s API gateway as a seemingly authorized user. This can lead to unwanted disclosure of information, account takeover, or even the ability to modify or delete information that the bank never intended to share. Alternatively, the hacker may try to inject malicious code or commands into the API by disguising them within the content that’s trusted or expected. These are some of the most common attack types when a weak link in the supply chain is used to breach a financial institution,

If the only checks in place are the shared secret and the API gateway, these types of attacks can go undiscovered in the moment. If the bank does realize this type of attack has occurred later by parsing the information from the analytics provided by the gateway, the damage will have already been done. In order to respond to these threats in real time, the organization needs an API security solution that looks at the data passing between endpoints, identifies abnormalities in real time, alerts the appropriate security team, and takes immediate action.

As financial institutions increasingly leverage APIs to build their financial ecosystems, they cannot blindly trust that programmers built strong security into these connections – the fact is, even if developers were to focus heavily on security, it’s practically impossible to account for every potential security scenario in the initial code. It’s also a mistake to assume that API gateways offer adequate protection.

At Ping Identity, we understand how important APIs are to the success of your digital initiatives, and we know that you need to address the risk posed by the supply chain. Our solution for financial API security and intelligence acts like the airport baggage scanner in the earlier example, leveraging machine learning to watch the data, learn what’s normal, alert security teams on anomalies and bad behavior, and even take immediate targeted action in the case of an exploit.

APIs are the future of digital services, and cybercriminals are constantly finding new and creative ways to exploit them. Financial institutions need to reinforce their defenses, and Ping Identity can help.

Want to learn more about this topic? Check out our white paper, The Need for API Security and Governance for a deeper dive.