API Data Protection in Gateways
Sonal Rattan and Peter Lancos are the founders of eXate. In banking, moving and sharing data is a challenge. This article by Sonal and Peter discusses the secure exchange of data.
Due to the pandemic, the world has become more digital and API-driven. But, 91% of companies have had a breach with respect to an API, and 85% have had breaches on multiple occasions. This problem needs to be addressed.
With digital transformation, everything is now API driven. Nothing is data-at-rest. Everything is data-in-motion. 87% of people will not do business with a company they don’t trust.
Regulations started in Europe. In the US, states are putting in their own regulations. You also have government and central regulations. E.g., the US privacy act of 1974, the Gramm-Leach-Bililey Act, HIPPA, and COPPA. Every country has different rules. So, how do you automate all these rules and regulations?
Weichert Realtors had a data breach. They were fined 1.2 million. The key here is the New Jersey Attorney General makes it very clear; you are expected to protect your data. It’s the law, if you don’t do it, we’re going to come after you, and we’re going to find you.
Twitter was fined $150 million. Why? They stored your phone number for two-factor authentication. But someone used those numbers for marketing calls. This is illegal. The data that is stored is to be used only for the purpose that the user has given consent.
We, as a company, help you protect your data.
The demand for data is growing as digital transformation has hit. We are creating more of it; we want to use more of it. But these regulations are hindering it a little bit. But what we’re trying to do is protect people. While trying to create points where we can access data, we need to understand the governance behind it – who’s accessing it? Why are they accessing it? What’s the purpose of use? We want to make our API program scalable. But how do we do it without exposing our company to much more risk? We must ensure that we’re compliant and that governance will be a key part of any API program. These are things that we should be thinking about as organizations regarding how we ethically monetize data.
In large organizations, a large number of APIs are generated. Some of them are replicas as data needs differ. But are we replicating the security and governance patterns as we create replicas?
Before starting these programs, we must create security and governance patterns in our architecture.
We, like most companies, started with a Gateway in the middle. We had an API producer and an API consumer. This is all transparent and easy to manage when we have one customer object. But when the APIs become popular, it gets very complex. You will have US consumers and UK partners, resulting in a mesh with micro-gateways. But as the system becomes more complex, we tend to lose sight of what is happening and who is consuming the data. We do not know our potential breaches.
Why didn’t we build governance and compliance within our gateways? Even if we’re using micro gateways, we want to be able to do a consistent pattern from a security perspective on how we want to address how our data is being used.
At the Gateway, we know the data. We know the consumer, we’ve got a bit of information, and we can make a good decision at that point, whether or not that person should have access to that information, should they have access to the entire record set. Some people may use GraphQL; some may use REST. You should know the contracts and what you are getting. There should be predictability and reliability.
So we can work on a simple pattern. We can reuse our APIs. We can create one customer object and one account object. Having an API program with thousands of APIs is not the best idea from a governance and risk perspective. We want to reduce that footprint. We want to make it reusable and maintainable.
So, look at a continuous circle. Have a fast strategy where we want to locate and identify where our information is. We want to analyze it. We want to know what information is passing through our gateways. Is it personally identifiable information? Is it nonpublic information from a banking perspective? Is it healthcare information about what prescriptions I’ve had? It’s all well and good knowing about it. But the risk is when you don’t do something about it. We, as a company, will look to help solve it immediately from just looking at it, we can start blocking information coming out of your APIs. But everyone’s evolving; everyone’s changing continuously. So, we have to keep testing and ensuring that we’re continually checking what’s going through our APIs, whether there are new risks, and then trying to solve them and keep going around.
To conclude, gateways are doing more to enable more data in motion. We’re going out to market with gateways with privacy built into them. We are looking to apply those patterns over all of these different technologies, so we can make sure that it’s private but usable.
We will ensure that we’re not exposing our company to more risk. And then, finally, in the future, we’re trying to embed data protection, reduce costs because you’re not creating multiple APIs, and innovate because you can spend time on innovation instead of building privacy into every single layer.