“Money, it’s a trip.” - Roger Waters
Our money has moved online. In the last decade, assets held in online financial systems doubled, while outpacing asset growth in more traditional financial systems. In 2022 alone the total value of online payments crossed the $8 trillion mark. Some analysts believe that by 2030 over a quarter of all bank valuations will be in fintech banking. Thanks to the internet age, moving money has never been easier. But it has also never been more fraught with peril.
Data breaches have become a regular part of life, and though high profile data breaches such as the Equifax breach take over the news cycle, most go largely unnoticed by the public writ large. Since 2020 an average of 343 million individuals have their personal or financial data compromised annually. As a result billions and billions of credit card numbers, social security numbers, and other personal identifiers are traded like commodities on the least savory parts of the open web.
For these reasons developers working in fintech pride themselves on creating the best possible operational security for their platform and the companies and individuals who rely on them. But there is one vector for exploitation that often can get overlooked: third party APIs.
But before I can illustrate that point, I think it’s worthwhile to give a high level overview of how cloud services and storage providers operate.
In the early internet age hosting an applications’s infrastructure was a relatively straightforward affair: your team bought or rented servers, that server was connected to by users and, assuming you were adequately configured to handle the load, things hummed along swimmingly. If demand increased, you acquired more server space and hopefully got it integrated into your infrastructure before the demand outpaced your capacity. If you weren’t quick enough, your users were greeted with a 500 error.
It’s not hard to understand why so many platforms were so eager to make the move to cloud hosting solutions. It was a transition that kicked off the SaaS revolution that we’re currently in the midst of. Providers like AWS, Google Cloud Services, and Microsoft Azure provided a host effective, scalable solution that gave web services unparalleled uptime and rock steady performance reliability.
Unlike traditional hosting solutions where each service operated on distinct hardware or server shards, cloud hosting utilized virtualization. Virtualization allows for one piece of hardware to operate as multiple distinct software environments that utilize one massive pool of storage, memory, and compute power that is constantly being allocated and reallocated by a hypervisor service. There are huge benefits, as unused resources in one environment can be temporarily reassigned to another environment that has more demand. But the computational breakthrough that made affordable cloud computing possible at scale also created a new vector for attack.
By exploiting a security vulnerability in the hypervisor of a cloud computing solution, a hacker can quickly gain access to all the data that hypervisor has access to. This process, sometimes referred to as hyperjacking, can enable skilled hackers to access massive amounts of data from multiple services and businesses at one time. This is the primary reason that most large banks and governments that utilize cloud storage like AWS require their deployments to be on dedicated, or bare metal, servers that are disconnected from the rest of the provider’s cloud infrastructure.
Whether digital or physical, there are two main types of security: proactive and reactive. Most major privacy laws– including GDPR in the EU and GLB in the United States– only require that, in the event of a data breach, services inform their local government and all affected parties in a timely and detailed manner. This is reactive security, security after the fact. Something bad happened, you learn how to protect against it, and you move on. Proactive security is all about stopping breaches before they happen.
Most fintech platforms pride themselves on taking proactive security measures. This is achieved in a few different ways. The first is the aforementioned bare metal and onprem deployment solution. In this solution, fintech companies keep all of their data and services in either a self-hosted data center or on a dedicated server provided at extra expense by a cloud provider.
The second is known as hybrid cloud hosting. In hybrid cloud, most of the application infrastructure is hosted via normal cloud virtualization, while any sensitive data remains stored in a self-hosted data center, onprem deployment, bare metal deployment, or any combination of the three. Hybrid cloud provides the benefits of cloud computing while maintaining the operational security of bare metal and self hosting.
According to accenture, 61% of financial service providers utilize hybrid cloud, while an additional 9% use onprem or bare metal. This proactive approach is one of the key value props for many fintech companies, and in many cases is even a requirement of the service license agreements fintech platforms have with larger clients. Breaking this promise in even the smallest way not only creates a massive security vulnerability, but can also be in violation of their SLAs.
Here’s where it gets tricky. Most API providers operate by allowing developers to quickly integrate functionality that is largely powered by the provider’s infrastructure. In most cases this is a big feature: the hard part of adding functionality like in-app chat or file management isn’t in creating a compelling user experience, it’s in providing a properly configured server environment that can manage the specific demands of that functionality.
But therein lies the rub. Because if you’re a fintech company that has made promises to your customers and clients that all sensitive information will remain stored in a private cloud or onprem server, and you’re utilizing an API that operates on a public cloud with virtualization, you are now in a position where some confidential information remains on your private cloud while other confidential data is moving freely through a public cloud vulnerable to hyperjacking.
In order to maintain operational security and keep your promises to customers, it’s important to make sure that any API providers you do business with can provide a bare metal, onprem, or self hosted solution. Surprisingly, this is not something that is universally offered. However there are providers, like Weavy, that are happy to work with your team to craft a deployment strategy that meets the needs of your platform and its customers.
If your team is looking for an enterprise API and wants to talk to an expert, you can reach out here:
To access live chat with our developer success team you need a Weavy account.
