ANDY MILLS asks why APIs, whose security is clearly a priority and which need to be included within ZTA, are being overlooked.

Application Programming Interfaces (APIs) now account for the majority of web traffic and the access they provide to applications and services makes them a key target. By 2024, API breach growth will have doubled, according to Gartner, despite 97 per cent of companies having started or having committed to rolling out Zero Trust Architecture (ZTA) in the next 12-18 months.

You’d be forgiven for thinking that APIs would be prime beneficiaries of ZTA but in fact they’re often sidelined. Consequently, Gartner predicts attackers will look to pivot and target assets and vulnerabilities by scanning and exploiting public-facing APIs which fall outside the scope of ZTA. Indeed, the analyst house predicts we can expect over half of all cyber attacks to be aimed at those areas not covered by ZTA by 2026.

Securing API access has been singled out as a key priority for investment this year, yet only 54 per cent of companies claim to have done so worldwide, says The State of Zero Trust Security 2022 report. Furthermore, only 42 per cent of companies have extended SSO (Single Sign On) or MFA (Multi Factor Authentication) access methods to APIs and only 19 per cent intend to do so.

The big question is why are APIs, whose security is clearly a priority and which need to be included within ZTA, being overlooked?

API idiosyncrasies

Part of the problem is that securing APIs is seen as a step that’s much further on in the maturity of the zero trust deployment. The report suggests there are five phases, from traditional through to emerging, maturing, elevated and evolved, with API security coming in at the fourth phase. But with API widely now regarded as the number one attack vector, many would argue this is leaving it too long and too late. 

It’s easy to see why you might leave APIs until later in the process. To start with, there are multiple ways in which APIs can be configured and used, from aggregated APIs that then use another as the point of entry, to a single API offering access to a service mechanism, to acting as the go-between between various non-compatible applications, to third party or public cloud APIs. This adds further complexity when it comes to implementing ZTA.

API security also has its own unique challenges. Segmentation and deep inspection technology at the layer 7 network level can miss APIs completely, resulting in shadow APIs while application level 4 protection methods such as web application firewalls (WAFs) will use signature-based threat detection and so miss anomalous activity. For these reasons, dedicated API discovery, detection and defence is needed.

ZTA tenets and APIs

However, there’s little doubt that APIs should be included in ZTA from the beginning. The ZTA tenets from NIST state that all data sources and computing services are considered resources and that all communication should be secured regardless of network location. This means that whether your APIs are internal or public-facing, they should be protected.

The tenets also state that access to resources should be granted on a per session basis and that such access should be determined by dynamic policy, including the observable state, and may include behavioural and environmental attributes.

In practice, this means that access should be authenticated, such as through IAM, but that behavioural analyses should then be used to look for any unusual activity ie in terms of the rate of traffic and whether it falls outside the remit of what is considered normal usage for the API.

The organisation should monitor and measure the integrity and security posture of all owned and associated assets, which is a pointer to continuous discovery and inventory of your APIs, and resource authentication and authorisation should be dynamic and strictly enforced before access is allowed.

This means APIs should be continuously monitored, enabling automated response so that in the event of an attack, the traffic can be throttled, blocked or the user’s credentials revoked.

The final tenet states that the organisation must collect as much information as possible on the current state of assets, the network and communications traversing it and use this to improve its security posture. Again, continuous monitoring of the API can help here, enabling requests and traffic to be tracked.

Over time, this can often give an indication of more subtle forms of attack such as business logic abuse, whereby the API’s own functionality is used against it, allowing the business to mitigate this issue within the API and others like it.

No reason to delay

Bringing APIs into the ZTA deployment therefore aligns with API security best practice in numerous ways. It sees the of use runtime discovery and inventory of all APIs, the application of the same security measures to both internal and external APIs, monitoring to identify vulnerabilities documented in the OWASP API Top Ten and to detect suspicious activity that deviates from the norm, and in the event an anomaly is detected, seeks to mitigate the threat through automated defences.

However, within the multi-cloud environment, discovering all the API endpoints exposed by microservices and securing them can be difficult due to the rapid pace of development and inherently distributed nature of these applications.

In this instance, service mesh technology should be used to connect microservices across infrastructures. This controls how microservices share data and handles network traffic, policies and observability but it cannot enforce those policies. For this reason, service mesh must be supplemented with some form of API protection unless such a solution comes pre-integrated.

Fundamentally, what this all points to is that APIs must and should be part and parcel of the ZTA today. Delaying the application of controls to APIs delays the inevitable but could also leave the organisation open to attack, particularly in light of Gartner’s predictions.

As ZTA nails down more of the enterprise, attackers are going to look for outliers and if you haven’t factored in your APIs they could well be the weakness that then undermines all your ZTA efforts.

• Mills is VP for EMEA at Cequence Security.