Back in 2010, Kin Lane – aka the API Evangelist – set out the idea that Application Programming Interfaces (APIs) “are driving the Internet and our economy”.
Fast forward over a decade and we see the prescience of this statement everywhere. Indeed, everything from users, bots and applications to a myriad of cloud services leverage APIs to enable a huge range of key capabilities that power modern digital infrastructure.
But alongside the benefits of APIs also come risks with the potential to expose data, impact company continuity and jeopardise public trust.
For instance, the Power Apps breach last year was caused by misconfigured APIs and hit large US enterprises as well as some state and big-city governments. In addition, the IBM Security X-Force Cloud Threat Landscape Report for 2021 indicated that APIs were involved in two-thirds of the cybersecurity incidents examined.
At the same time, Zero Trust Architecture (ZTA) has emerged as a critical approach for maintaining the security of enterprise infrastructure in an era of ubiquitous digital connectivity (much of it via APIs).
ZTA’s popularity on enterprise road maps has also been given a major boost by President Biden’s Cybersecurity Executive Order last year, which required ZTA for parts of the government. In this context, the combination of API- and ZTA-based technologies could eventually be decisive in addressing the unrelenting wave of cybercrime.
Addressing API Vulnerabilities
Traditionally, businesses have tackled security by placing their trusted infrastructure and applications within a perimeter. In this situation, the key priority was safeguarding company assets and networks from unauthorised external access.
However, just because hosts that share a trust zone are nominally protected from outside attackers, it doesn’t mean they are sufficiently protected from each other. As a result, systems were exposed to greater attack risk, with intruders impersonating internal users to breach perimeter security before moving laterally inside the network.
Using this approach, they could gain access to the victim’s internal resources and steal information simply because, today, the perimeter is no longer an effective barrier to intrusion, especially with more resources moving to the cloud and more workers home-based than ever before.
What’s more, APIs have become major entry points into systems, and they will continue to be important components in data access management well into the future. In particular, their usual defence mechanism – using API keys to limit access to a certain API – has likewise failed them, not least because they may be already stolen or circulated.
Now a well-known weakness, it’s a situation that also makes it hard to validate the caller’s genuine identity when submitting an API key. For business security, powerful techniques of authenticating API access in a fine-grained context and guaranteeing proper API configuration have become critical, and ZTA can provide that added layer of robust protection.
However, it’s vital to remember that ZTA isn’t a stand-alone IT infrastructure architecture. To begin with, it is a mindset that acknowledges attackers can be discovered both within and outside the network, and as a result, no one can be trusted, not even robots.
ZTA is also a collection of best practices for enhancing security with a fine-grained approach to protecting organisational assets. In Sci-Fi terms, it’s useful to think of them as powerful personal force fields around each individual rather than protecting an entire ship at once.
Key Considerations
Implementing ZTA means internal and external entities are treated as one and the same, with no entity given access to resources unless and until it has been validated and demonstrated to be who or what it claims to be in accordance with company’s standards.
This holds true for all resources and communications, which should be governed by well defined access restrictions. Applications and services must constantly ensure that the entity attempting to access a resource is authentic.
This requires organisations to focus on some key considerations, most notably is it acceptable for each actor to access this information from a certain place, regardless of where that location is? Secondly, can this microservice accept data from another microservice?
ZTA has two basic ways to establish and govern policies for these decisions. Firstly, Policy Decision Points (PDPs) are used to model and govern policies (PDPs) and secondly, enforcement points (PEPs) put those policy decisions into action.
An API gateway is one useful technique for organisations using a large number of APIs to do this. Enterprises that use an API gateway to speed up their ZTA efforts should use a token-based API access and authorisation solution now (e.g., OAuth or OpenID Connect).
With an API gateway and a token-based strategy for API access and authorisation, the least privilege use may be enforced. That security concept grants only the level of access necessary to complete the task at hand.
Ultimately, to fulfil complex enterprise security requirements and scale into the future, ZTA that employs APIs, token-based access and authorisation alongside API gateways can be customised with distributed policy enforcement.
In an era of multi-cloud, on-premises, and geo-distributed installations, these capabilities will become increasingly important if API security is to be improved in the short and long term.
By Liad Bokovsky, Senior Director of Solutions Engineering at Axway.
