Traditional security models—such as firewalls and DMZs—were designed to protect the perimeter. The thinking was that if the four walls of a company were protected, then threats would be neutralised before they come anywhere near core IT infrastructure. However, when bad actors inevitably made their way inside, they were often left undetected and free to move about as they extracted sensitive business data.
Fast forward to 2018, and the IT environment is very different. Rather than being walled gardens, IT infrastructure now consists of large-scale mashups of on-premises systems, cloud platforms, SaaS applications, mobile devices and hundreds of APIs connecting it all together. Businesses today do not have a clear perimeter; they live everywhere their customers, partners and employees do.
In a business landscape where perimeters no longer exist, IT teams need a new security model that orients around securing the connectivity fabric itself: APIs. According to Gartner, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications by 2022. It’s time businesses toss aside the traditional security model and instead adopt a zero trust model, where security lies in the APIs themselves.
The power of zero trust security
Moving away from trying to secure entire perimeters, zero trust architectures instead provide verifiable identities to APIs and consumers (e.g., devices and applications), allowing them to exchange data without risk of loss or unauthorised access.
With verifiable identities, each API can perform authentication, authorisation and access control in a distributed fashion. Therefore, access to APIs and the sensitive data they share is granted based on what we know about the caller and its context, in terms of device, location and more. Zero trust architectures also build on top of well-known and proven cryptographic technologies such as encryption, public/private keys, and blockchain. These technologies are combined in a decentralised, distributed, self-service and automated model, effectively making security a de-facto and embedded capability for every API.
The shift to zero trust comes at a time when APIs are becoming increasingly important for organisations. According to MuleSoft’s Connectivity Benchmark Report 2018, organisations generate 25 percent of revenue through APIs and API-related implementations. Security teams must therefore find a balance between making their APIs easy to use and having them tightly controlled to prevent misuse. They must ensure security is built in at the design stage by embracing zero trust.
Building a zero trust architecture
Achieving a robust, secure, API-based infrastructure using zero trust principles requires a four-step process:
- Asset discovery: Compile an exhaustive summary of all APIs currently in use within the organisation. You can’t secure things you don’t know about and so having a definitive list of all elements is critical.
- Take a capabilities-led view: Since APIs are designed for a known purpose, this provides the ability to target the protections in design time based on the capability of the API and further complements API gateway protections during runtime to provide targeted and focused protections.
- Adopt a continuous approach: API security is not a one-off exercise. Constantly discover, monitor and secure the infrastructure to ensure it remains secure while also delivering the performance required by users.
- Deploy a distributed enforcement model: The approach needs to protect the front-end of the API, in addition to the back-end of the API connecting to the data source. Both protections are important and need to be thought through when exposing APIs.
Above all, when it comes to creating an effective zero-trust environment, security must always be treated as a design-time concern with targeted and focused runtime capabilities. All communications between APIs, and with data consumers, must be mutually authenticated, authorised and encrypted, and governed by policy – this policy-based access control should be governed centrally but handled in a distributed way.
Also, the identity of someone seeking access to an API should not be assumed simply because the call is coming from a particular network. Multi-factor authentication and digital signatures should be made a key part of the security infrastructure, not only to authenticate a login but to also authorise actions.
In this way, access to APIs and services can be granted based on what is known about the caller and there is no need for implicit trust to be involved in the process. Instead, the organisation ends up with an effective system whereby API callers need to prove they are legitimate before they can gain access to core data or applications.
This article first appeared on CSO.
