The Practical Guide to Zero-Trust for APIs

Zero Trust is a deceptively simple concept: “treat all networks as compromised” on the surface this may seem straight forward, however when you dive into zero trust past the network layer and into the application layer this simplicity becomes muddy, with entire suites of tools, hundreds of libraries, and an overwhelming amount of different methods for implementing the same ideas. Zero Trust is a popular answer to how to manage the security risks inherent in today’s Cloud-First world, but as we move from networks into applications many organizations struggle to implement these ideas. 

‍

With the interconnected nature of APIs Zero Trust is a natural fit, in fact many APIs already have some of the key ideas of Zero Trust already! In this guide we’ll explore the practical side of Zero Trust APIs and how to build Zero Trust into existing API and cloud infrastructure.

‍

Fundamentally Zero Trust is all about default, just because someone is connected to a corporate network doesn’t mean they are supposed to be there. No access is given by defaults, whether that be to data, services, applications or any other asset. There are four key concepts to Zero Trust, while many security approaches have a built-in approach, one of the key advantages is that many of these requirements for Zero Trust allows for an add-on approach, not requiring large code base changes.

‍

1. All users must verify their identity
2. No access is granted automatically
3. Policies are enforced
4. Security teams have visibility

‍

Treat all APIs as compromised

Before we can use a Zero Trust API we have to first verify our identity, a common approach, especially for third-party and partner APIs often API keys. When developers want to make a new application built with an existing public API the public API needs a way to connect APIs to developer accounts to track usage for billing or misuse purposes. 

‍

A developer will then register an application and receive a unique API key that they send with every API request. This key will link that request to that account. This makes sense for Zero Trust—no API key, no API access. However, API keys are frequently accidentally committed to public code repositories, and API keys will usually grant access to an entire API even if the application only uses 1 or 2 endpoints.

‍

Where does that leave us? We should assume the API key has been compromised. Typically, this involves key rotation, with keys being limited to a timeframe before they are reset and changed. However, APIs are changing to allow scoped API keys and multi-factor authentication, usually through a full identity provider. Multi-factor authentication requires an attacker to have more than just a single API key, generally requiring a full username/password and MFA flow for a new application. While scoped API keys, a developer can choose which API endpoints or functionality an API key should provide access to, providing a layer of access control.

‍

Access control is key to a good zero-trust strategy, but we need to know what we are defending before implementing it. Shadow APIs and zombie APIs are usually the first targets for API discovery. These APIs remain undocumented and unknown to security teams or were never decommissioned and persist even in death. However, this alone won’t reveal the true API boundary, so third-party, internal, and partner APIs must all be added to the API discovery. Once you better understand the API boundary, you can define access control. Working from a deny-by-default approach, carefully select which APIs need what levels of access and where an API requires access to internal systems or APIs.

‍

People, policies, and persistent challenges

Once you’ve identified your APIs and the authentication in place, it’s time to turn your identification and access control into policies. This is where most teams struggle with Zero Trust—not because of the technical requirements but because of the challenge of on-boarding entire teams. Adopting Zero Trust requires organizational change, especially around policy enforcement. Security must become a priority at all levels, supported by continuous education and collaboration between security teams and developers. It's about creating an ecosystem where security is built-in and non-intrusive.

‍

Incorporating security within the DevOps ecosystem is essential for seamlessly applying Zero Trust principles. This is where the concept of non-intrusive security becomes vital. By embedding security into the DevOps pipeline, organizations can ensure that security checks do not hinder development workflows. Automated tools and processes enable security to be a part of the continuous integration and continuous deployment (CI/CD) cycle. This integration allows developers to focus on creating and deploying code without being bogged down by manual security interventions. With security baked into their operations, organizations can proactively identify and mitigate vulnerabilities early in the developmental stage, aligning with Zero Trust principles without disrupting the DevOps momentum.

‍

It’s not just about the pipeline though, policies are a consistent theme in Zero Trust, so ensuring that you are defining policies, implementing them and auditing their use throughout the software lifecycle is key. For APIs it often takes the form of access control, those who access an API are correctly authenticated and have the correct permissions. Access control policies define who can access which APIs and what they can do with that access. Access control policies should be based on the principle of least privilege, which means that users should only be granted the minimum amount of access necessary to perform their job functions.

‍

Once your policies are defined, it is crucial to maintain and manage them effectively. This involves establishing a process for regular review and updates to ensure that your policies continue to align with your organization's security posture and evolving threat landscape. Regular reviews will enable you to identify any gaps or weaknesses in your policies and make necessary adjustments. Additionally, as new threats emerge and technologies advance, your policies may need to be updated to incorporate new controls and safeguards.

‍

A Challenge Worth Tackling

Implementing Zero Trust for APIs presents a multifaceted challenge within organizations. The proliferation of APIs, often referred to as API sprawl, is a primary hurdle. As the number of APIs grows, it becomes increasingly difficult to maintain a comprehensive inventory, track their usage, and manage their associated vulnerabilities. This complexity makes it challenging to define and enforce granular access control policies and other security measures that are foundational to a Zero Trust architecture.

‍

Furthermore, the adoption of Zero Trust necessitates a significant shift in organizational culture and mindset. It requires that every team member, from developers and administrators to end-users, understands the rationale behind the Zero Trust policies and their role in safeguarding the API ecosystem. Fostering this understanding and ensuring consistent adherence to security protocols can be a substantial undertaking, particularly in large organizations with diverse teams and varying levels of technical expertise.

‍

Additionally, the dynamic nature of APIs and the evolving threat landscape require continuous monitoring, assessment, and adaptation of security measures. This demands ongoing investment in security tools and technologies, as well as skilled personnel who can manage and respond to potential threats effectively.

‍

In conclusion, implementing Zero Trust for APIs is a complex endeavor that requires addressing technical, cultural, and operational challenges. Organizations must invest in robust API management solutions, foster a security-conscious culture, and maintain ongoing vigilance to ensure the confidentiality, integrity, and availability of their API ecosystem.