Before we dive into why “zero trust” has become a myth in API security, let’s establish what we mean by the term since it is often overloaded in the security industry. Traditional security thinking asserted that if we can build trusted environments (commonly network zones) to host applications, systems, and data and operate with least privilege access, then any resources within those trusted environments can be considered reasonably protected. This line of thinking shaped organizations’ perimeter thinking for decades, particularly when it came to building out on-premises data center environments.
Threats regularly erode the concept of trust – especially trust in a perimeter – in modern computing. This erosion comes from external attackers abusing APIs, compromised supply chains, malicious insiders, and a large array of other real-world threats. The problem is exacerbated with modern architecture, where systems are moved out of a controlled data center environment and increasingly connected (usually with APIs) to facilitate business, enable employees, and serve customers. Ultimately, no resources can be deemed safe or secure. Security practitioners must consider a resource to be untrustworthy, enforce least privilege access, and validate continuously whether permissions are appropriate for users, machines, and data.
A number of concepts and technologies emerged from zero trust principles. Software defined perimeters and microsegmentation are frequently mentioned. Two items in particular often arise in API security conversations:
To put it bluntly, the reason ZTA and ZTNA don’t help dramatically in an API security strategy can be distilled down to one key point:
The goal of zero trust is to restrict access, but access is critical in order for APIs to function.
Gone are the days where APIs might exist purely as middleware, sit within inner architecture, and be exposed to only a subset of partners or suppliers, where IP address allowlists or VPN might be suitable controls. Access control methods break down in API security for a number of reasons, including:
Identity forms the foundation for network security in the zero trust world, and the realization soon emerges that authenticating and authorizing machine identities (i.e., services or service communications) is incredibly complex in practice. It must be done seamlessly with an eye towards automation. You can’t challenge a machine identity for authentication material like you can with a user in an interactive session. Secrets management, certificate-based authentication, microsegmenting based on workload labeling and tagging, Kubernetes namespace isolation, Kubernetes network policy, open policy agent (OPA), and service meshes are some tools of the trade depending how far you’ve advanced into the world of cloud-native. Some technology is still emerging, best practices can be at a premium, and engineers often find they are early in the learning curve. Regardless, these approaches still only address access control and do not cover application layer security.
The APIs you build and integrate need to be able to communicate to many different types of user and machine identities across many different environments. Communication paths are difficult for engineers to quickly grok and relax or restrict accordingly. Opening rules in firewalls along with the associated paper trail and change management still common in most organizations will never scale. This shortcoming holds true even if routing rules and configuration are machine assisted, since many organizations still require formal change management as mandated by compliance or regulation.
Technologies designed with zero trust in mind might tout that they parse “application context,” but it warrants further review. They may parse service communications, but they don’t aim to understand application layer or API context. They are about as application-savvy as firewalls of old, understanding ports and protocols used by workloads and little else. My colleague Chris expanded further on the importance of API context in the post Stopping API Attacks: Columbo, Correlation, and Context. Just like real-world security checkpoints on bridges that inhibit vehicle traffic flow, expect access control methods like zero trust to impact API performance and availability. HTTP/S and ports 80/443 inevitably must be open for API communications, particularly for internet-facing, public APIs. The range of identity types you are dealing with may also be immense. As a result, traditional access control approaches, even ZTA and ZTNA, are a nonstarter for many organizations.
I’ll dig in deeper on IAM, API gateways, API management and WAFs in a future blog, but proxy-based mechanisms often claim they provide API security features. If you peel away a few layers of the onion, you’ll find many of these features are essentially network security by another name, possibly labeled as traffic management or threat protection. Some vendors may even claim they are useful for enabling zero trust. The common features that you can often find in any network component along with the associated attacker bypasses include:
Zero trust principles and the technologies that have emerged inevitably promote dynamic access control that is informed by application context, identity, and behaviors. Identities may be users or machines, depending on the scenario. Access control has moved on from basic access control lists, firewalls, and point in-time access decisions at well-defined perimeters to something more distributed and continuous. The intersection of network access control and identity and access management results in identity as the new perimeter. At the end of the day, these approaches and technologies are still about restricting access or connectivity to enforce least privilege in untrusted computing environments.
One of the principle tenants of zero trust is continuous monitoring and behavior analysis to inform access control decisions. This is certainly one component of an API security strategy, since an organization will likely want to terminate access real-time for abusive API calls or sensitive data exposures. Unfortunately, the technology offerings born out of zero trust do not adequately parse application and API-layer behaviors. Organizations focusing on zero trust security principles need to ensure they are also looking at newer breeds of tooling that can augment their zero trust technology investments and provide the context that is necessary to protect APIs and the applications powered by them.
I’d encourage you to take a look at the API Protection Platform offering from Salt Security to fill this gap in zero trust. You’ll find ample resources on our site, but please also reach out for personalized demonstrations or additional technical questions.
.png)
.png)