By Olaf van Gorp, Perforce Software

The explosion of application programming interfaces (APIs) to enable digital transformation and open finance continues to escalate. APIs are the connectors, the ‘glue’ that connects services of all kinds. They are a fundamental part of the digital revolution that is changing the world right now. Many financial sectors can benefit from this revolution, including insurance.

In its excellent document: “Digital disruption in insurance: cutting through the noise”, McKinsey talks about the triple prize for the insurance industry: satisfied customers, lower costs, higher growth, and how automation can reduce the cost of a claims journey by as much as 30 percent. Those are pretty powerful messages.

APIs are one of the foundations of digitalization. In the insurance sector, that means ecosystems connected by APIs so that insurers and third parties can share data such as customer claim information (with the consent of the customer, of course). Previously time-consuming steps can be simplified and sped-up, with the customer accepting changes to a policy digitally following an accident, for instance. Welcome to the new era of open insurance.

Introducing Risk

The insurance sector also has the opportunity to learn what other markets have, sometimes to their cost: API security is everything. APIs have huge potential, but they also bring in risk. One of the reasons that companies use APIs is because they provide a controlled route through which critical data can be shared, including with third parties. However, that makes the assumption that the API is robust and not vulnerable to attack. If that API is published, and then discovered to have a problem — a weakness that can be exploited — there is little or no time to take remedial action, thereby leaving that API open to attack, unauthorized access to data, or data shared externally without permission. Suddenly, that controlled route is compromised.

While that may sound like scaremongering, here is some perspective. Once a new website is published, it is likely to be attacked within hours. That is the nature of today’s highly sophisticated cyber-attack community. The result of vulnerable APIs? Insurance companies risk putting their data into the public domain. As we have seen across other industries, vulnerable APIs can lead to some high profile data breaches and cyberattacks.

So, protecting both internal and external APIs has to be a priority, and not something that is dealt with as an afterthought down the line. If APIs are the means to ensure a seamless experience across all channels, pulling together all touchpoints to secure data transfer between all parties in the ecosystem, then they need to be trusted. And that means end-to-end security of APIs across their entire lifecycle, starting with their creation.

Software Development Can Be a Source of Risk

An API is just another piece of software. It is a very clever and useful piece of software, but it is basically still software code. In the software industry, it has long been acknowledged that development of software is the top culprit for introducing future software vulnerabilities. That is changing — partly with a shift towards DevOps to create better collaboration across teams — but it is an ingrained mindset with many software developers that sorting out security is not their problem. That has traditionally been exacerbated by the fact that software developers tend to work in a very individual way, siloed from the rest of the organization. Again, movements like DevOps are changing that, but there are still some other hurdles to overcome.

First, the nature of APIs means that the whole project team is probably going to be focused on creating great performance and functionality, possibly also a great user experience too. Security is often not top-of-mind for anyone.

Anyone Can Be an API Author

Second, the simplicity of APIs means that their creation is within the reach of anyone, so reduced level of expertise is needed, and in many cases, those individuals may work at external consultancies or design agencies. That is great in terms of increasing the range of people who can write APIs, but again, the risk landscape is increased. Even if the in-house team have had the security message drummed into them, it is harder to control the experience of external teams, who may also have less experience in software development. Furthermore, everyone is probably under pressure to deliver that API fast.

API Drivers in Insurance and Other Finance Markets

In banking, open banking standards have been a driver towards better API management and security, and for good reason: the volume of APIs is growing fast, and the more vulnerable APIs there are, the greater the number of ingress points for attack. This is why in Europe, the PSD2 mandates security measures that should be implemented at the API level (and by the way, some of those measures are pretty complex).

In the insurance sector, an increasing maturity around API management and security is being propelled by, for instance in the USA, the NAIC Registry, which allows automated filing of standard reporting documentation required of insurance providers for compliance with state regulations.

The Right Culture

Given that API security is both a priority but also a challenge, how can it be improved? The first step is getting everyone involved to understand why API security is important in the first place, why that needs to start with the development stage, and their roles in mitigating any risks. This needs to apply to external contributors as much to internal ones. Think about investing in training developers on API security.

Think Wider Than Mandatory Measures

Open finance standards have some great guidance on better API security, and it is often mandated. However, these may have a very specific scope, so consider looking at the wider picture, and look at other security measures that can be applied. A handy reference is the OWASP API Security Top 10, which covers the ten most common API vulnerabilities and ways to mitigate them.

Get the Processes Right

Processes that support a more secure API development environment should be comprehensive across all deployment policies, approval workflows, users and groups. In addition, they should encompass: authentication, authorization, malicious pattern detection, message content security, rate limiting, and other security policies. Nominate people who must review an API before it is published, with time-stamped approval. That is typically carried out manually, but combined with automation through the software development process’ delivery Continuous Integration/Continuous Delivery pipeline. Ensure that there is a clear audit trail, so that if something does go wrong, then the original cause can be traced and action taken so that the problem is not repeated in the future.

Automate

Given the kind of scale that is usually involved, consistency and repeatability are important, so security policies need to just automatically happen and enforced across all current and future APIs, without needing any extra coding. Additional manual intervention should be avoided, and people should not be able to switch off these policies at will. Introducing an API gateway with in-built security features will help that. That should include policing of contributions from external contributors, but make sure to choose a gateway that can support the different types of API (REST, SOAP, etc), and that automation can take place at scale, particularly since the growth of APIs and the traffic that goes through them will only increase.

Don’t Let API Security Get in the Way

API security should not fall to developers to sort out, because they are busy people who do not need another task. Instead, this should fall to API product managers, security architects, and other individuals more focused on the need for security. Even so, humans should be making the decision, with automated workflows doing the work. Use tools that continually inspect code to detect creates early on and delegate tasks wherever possible to an API management tool for consistent and simplified enforcement of security policies. The more manual intervention can be reduced, across every stage of the API’s lifecycle from creation to deployment, the greater the likelihood that robust APIs will go into production.

Insurance is at a pivotal stage in its adoption of digital technologies, and APIs are a critical part of that journey. Getting the right steps in place now will help insurance companies make the most of the changing landscape, be more efficient, compliant, and competitive, while maintaining (even enhancing!) customer satisfaction. Making sure that APIs are secure right from their early inception through to publishing is an integral part of making all that happen.