If I say, “Tell me about your home security system,” you might describe the sensors that are on your windows or the keypad that is close to the entry door. You may tell me that you installed a doorbell cam, or maybe say, “I don’t have a security system on my house. I’m not sure I need one.”
What you might not tell me about may be areas of your home security where you are vulnerable but where you haven’t thought about the risk. Maybe you keep a garage door opener in the car that’s parked outside every night. The weather in May is gorgeous, so you like to keep the windows of your home open. You rarely take the time to arm the security system when you leave.
If we think of the insurance company as a home, it has similar types of vulnerabilities that are ripe for exploitation.
Where are insurers most vulnerable?
An application programming interface (API) gateway protects the enterprise from outside hacking by closing up the points of vulnerability you may never have considered. At a high level, there are three types of security vulnerabilities:
- Role-based vulnerabilities. This is the wrong person having access to the wrong items and areas.
- Data-based vulnerabilities. These might include the open spigots of data spilling into the outer world because “someone left the data on.”
- The API function itself. This would include open access to an application through the system or developer toolkit.
In our previous blog on API security, we discussed role-based security and not allowing full access to every API for every internal associate – from developers to business users. This is essential just to keep everything structurally secure. But the idea of security roles is just as applicable when it comes to outside access. APIs are rapidly growing in use. The dramatic increase in embedded insurance, partnerships and platforms means that insurers are finding themselves with a host of new people who need to access some level of systems and processes. Keeping track of system keys and keeping watch over access has to become an automated process. The API gateway will be this essential guard at the gate. It will keep roles straight and prevent anyone from accessing systems through exposed API endpoints.
Data leakage is a completely different type of issue. In today’s API environments, keeping track of who, how and when an API is being used is largely a matter of someone within IT who is tasked with knowing the complete system architecture. The use of an API at the time it was installed may have been perfectly secure. Data was moving from point A to point B and was facilitating whatever transaction it needed to facilitate. Over time, however, system teams may upgrade an API or shift its usage. This might be happening on the other end of a partner system. It doesn’t mean that the flow of the data has been turned off, just that it is no longer fulfilling its original purpose. This presents two security issues. The data may fall into the wrong hands, and hackers may also have a route into core systems. All of these issues are real and multiplied within companies that govern their own APIs directly from their internal systems, not yet using cloud API platforms.
See also: How API Hub Can Spark Innovation
API gateways — a portal for secure access
Use cases help us to identify the disparities between a secure environment and an insecure environment. Let’s say your company has 50 APIs with no gateway in place (all of them windows with potential outside access) and you begin to measure your potential exposure. You catalog how many outside users have access to these APIs end-to-end and realize that the system security that you have in place is piecemeal and not completely visible anywhere on a dashboard or console. Your business may have imagined it was more secure than it actually is.
An API gateway would fix these issues. It will add a horizontal shared orchestration layer on top of the APIs, so end users are only accessing up-to-date, usable APIs that they need at a console level. The console works as well on the inside as it does on the outside of a company’s systems. A dashboard will give system administrators complete visibility into usage, breakage, volume and invalid attempts at entry. Customers will end up with less API complexity and an environment that is understandable and manageable. Still, some companies may wonder how secure they can be if they are operating in a hybrid cloud environment that still houses on-premises systems.
“If we’re never going to fully be on the cloud, only our cloud-based systems will be secure. Right?”
Part of the beauty of an API platform in the cloud is the gateway’s ability to make the full environment more secure by securing API endpoints.
Let’s say for a moment that you are currently running in a hybrid environment. In some cases, your back-end systems are situated in the cloud. Others are on-premises. It would make sense that you might need two different gateways or two different API platforms. Yet that is not the case. With an API-platform approach, your multi-nodal systems can all be managed at the API gateway level. Your nodes could be different, or the processing could be in the cloud or on premises. A gateway can make points of entry and exit secure. It can add security to every system where APIs are hooked in.
The last hurdle to implementing an API Platform
One of the last hurdles that organizations have when it comes to adopting a new API approach is simply understanding how easy it is. We have been trained that nothing is truly easy when it comes to systems, so we think, ”Why would setting up an API platform be any different? Insurance is a different kind of industry, and we have different protocols. Won’t we need to set up insurance-specific security standards?”
Yes, insurance is unique. Standards and governance principles are specific to every industry and insurance is no exception. No, you will not need to fuss over insurance-specific standards. Cloud providers have made it super-simple for insurers to set up their gateways. Insurers will find that they don’t need to write code to define rules or build out environments. They will be using drag and drop, picking and choosing options for gateway setup. It is part of the interface.
In addition, the modern cloud-based or cloud-native API platforms, like AWS or Azure, have prebuilt frameworks or prebuilt activators already built out, whether it is for specific functional needs, like claims processing, or for specific industries, like healthcare or insurance. They have prebuilt rules templates, which, as a new customer, or a new deployer, you can simply plug in. When you copy and paste the framework into your gateway, it inherits the rules that are defined for our industry. Once connected, you’ve created an industry-specific API gateway, and your organization is now far more protected because you’ve reduced key points of vulnerability.
At Majesco, realizing an API-centric enterprise for our clients means a concerted program to craft an end-to-end API orchestration platform founded on a cloud-native API management service. Exciting developments are underway in this regard. Stay tuned for more in the coming months!
