By Olaf van Gorp, Perforce Software
Insurance is one of the latest sectors to start to benefit from advancements in digitalization. A big part of insurance’s digital transformation is the increasing use of APIs, bits of software that connect different services and apps — whether internally or externally — to connect in a friction-free way. Part of the whole open finance movement, APIs remove the need for complex and costly integrations between disparate systems and networks.
Insurers and associated third parties benefit from being able to share data more easily, processes happen faster, workload and unnecessary costs are reduced, and customers get faster response. It’s an all-round win.
However, while one of the reasons for using APIs is that they provide a controlled route to share confidential and sensitive data, APIs can also potentially introduce risk. If an API contains a vulnerability, then that can lead to problems, including cyberattacks and data breaches. Furthermore, once an API is published, there is usually little or no time to remedy the situation.
To understand how easily these weaknesses can be introduced, let’s look at how APIs are created. First, development has always been the point at which vulnerabilities are inadvertently introduced, potentially leading to issues further down the line, including performance and security problems. Second, development teams have traditionally worked siloed from the rest of the business (even from their colleagues in the IT operations team), with little visibility into their work. Plus, traditionally, security has not been their focus: that was something for the QA or test manager to worry about later.
That culture is changing, particularly with the DevOps movement, whereby the barriers between development and operations teams is broken down, and they work in a more collaborative way. However, with the understandable emphasis on getting an API published as soon as possible, security often still takes a backseat.
Finally, APIs are being created by a much wider group of people (including external agencies), not just software developers. That is good and bad: it makes it easier to keep up with the demand for APIs, but the new breed of API creators may not be trained software engineers, and arguably even more likely to introduce vulnerabilities.
So, what is the solution to this dilemma? APIs are an integral part of the entire financial sector’s future, but they have to be secure. Fortunately, there are some ways in which their security can be improved.
Four ways to improve API security
ONE – create a security-first mindset – get everyone on board on putting security in the spotlight, rather than an afterthought. Bake security into development processes and throughout the API’s entire lifecycle. Make sure everyone understands their roles around risk mitigation, including external contributors. Consider investing in security training for anyone responsible for API development.
TWO – go the extra mile – some compliance and standards already address API security. For instance, in Europe, the banking sector’s PSD2 requires security measures at the API level. In insurance, the NAIC Registry in the USA is putting more emphasis on API security and overall management, with automated filing of standard reporting documentation from insurance providers to meet state-level compliance. We are likely to see more API security requirements worldwide and within all aspects of finance, including insurance. However, open finance standards have a specific scope, and there are other security measures that can be adopted to further reduce risk. A good source is the OWASP API Security Top 10, which covers the most common API vulnerabilities and ways to prevent them.
THREE – put the brakes in place – comprehensive security processes need to cover all deployment and approval processes, people and teams. They should cover: authentication, authorisation, malicious pattern detection, message content security, and rate limiting. An API should also not be published without time-stamped approval from an authorised person, and this is typically a combined manual and automated process, involving the software development’s Continuous Delivery/Continuous Integration pipeline. Finally, make sure that there is a clear audit trail, so that if a problem occurs in the future, it can be traced back to root cause.
FOUR – reduce human intervention – automate security policies as much as possible, because this will not only reduce the risk of manual error, it will also help prevent security becoming a bottleneck. Introducing an API gateway will help achieve this, as well as making it harder for people to switch off security policies at will. Make sure that the chosen API gateway can operate with external contributors, as well as support all the main types of API, and deal with high volume. People still make the final decisions, but automation is the workhorse.
Take away security from developers
This may sound counter-intuitive to what is happening in other parts of software development (especially the Shift Left movement whereby software developers are taken on more responsibility for testing), but take away security from developers. Instead, leave API product managers, security specialists and other people to keep watch on API security. Use software tools to continually inspect code so that any issues are found early. Again, this can be a largely automated process, with humans then taking action depending on the results.
APIs are transforming financial services of all kinds, opening up faster and more efficient ways to communicate. By making security a priority across an API’s lifecycle, this will make it easier to reap the rewards of APIs, to reduce costs, speed up processes, and keep customers satisfied.
