MythBusters API Edition: Zero Trust and its limitations for API Security

Defining “zero trust”

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.

The erosion of trust in modern computing

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.

New ideas spawned from the zero trust movement

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:

• Zero trust architecture (ZTA) - promotes the idea of network perimeters, though they may be referred to as microperimeters. ZTA also still promotes the idea of segmentation and microsegmentation, though enforcement of access control can also now exist closer to workloads. It can result in technology mashup of Kubernetes ingresses, service mesh ingresses, microgateways, sidecar proxies, container runtimes, virtual machine hypervisors in addition to routers, gateways, network load balancers (NLB), and application delivery controllers (ADC). Definitions of workloads, gathered workload telemetry, and behavior analysis of the collected data can be used to make dynamic network access decisions. ZTA aims to reduce the attack surface and limit blast radius in the event of infrastructure or workload compromise.
• Zero trust network access (ZTNA) - focuses on protecting employees as they connect to environments or cloud-delivered (i.e., SaaS) services and read or modify data. ZTNA has emerged as a replacement for traditional remote access mechanisms like VPN. Traditional VPN approaches often did not cut it for organizations, offering poor user experience, low throughput, minimal security benefit, or all of the above. Once a user is in a “trusted channel,” additional security capabilities can be enabled such as conditional access control, DLP, behavior analysis, and anti-malware. Some of these security capabilities are filled by cloud access security brokers (CASB) today. Secure access service edge (SASE) is also emerging, which combines respective security capabilities of CASB and ZTNA.

Why “zero trust” is not API security

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:

• APIs may be designed as public APIs or open APIs – APIs may be designed to be consumed by the broader internet and a large customer base. Public or open APIs are common in retail, eCommerce, FinServ and FinTech industries. This makes the IP address space of API consumers a relative unknown since users and traffic may originate from anywhere. It also becomes difficult to rely on traditional controls like rate limiting since there may be periodic traffic spikes that are perfectly normal. Typically, an organization would start to lean more towards IAM measures to provide some element of protection and sideline the traffic management controls.
• APIs may be public and anonymous – taking the exposed API concerns a step further, an API may be designed to be public and anonymous. Some well-known examples include citizen services or map and navigation services. These types of scenarios make network access control and IAM ineffective.
• API attacks occur in trusted network channels – attackers man-in-the-middle TLS connections through protocol attacks, compromising client-side code, compromising endpoint devices, or compromising network elements.
• API attacks occur in authenticated sessions – attackers piggyback or hijack authenticated sessions by stealing active session cookies, authentication tokens, 2FA challenges, API keys and other authentication material. These are readily extracted from application traffic, client-side storage, or client-side code.
• API attacks occur in authenticated sessions within trusted network channels – the security industry as a whole has long advised that apps and APIs are deemed protected if they use encrypted transport such as TLS as well as authenticate and authorize users. This approach still fails to address the application layer and is only one piece of the API security puzzle. Network, identity and session attacks still work much to the delight of attackers, as evidenced by the many API incidents and breaches where the service provider used HTTPS with TLS and enforced proper authentication.
• APIs are often consumed by machine identities – when you are dealing with pure machine communication and data flows, prompting is a nonstarter. ZTNA solutions and some elements of ZTA like enforcing 2FA simply can’t be used in machine to machine or direct API communication. There is no user to respond to a challenge, and you wouldn’t want administrators to be approving machine communications as they occur. Challenging or necessitating manual intervention creates massive inhibitors in cloud-native design and DevOps initiatives.
• Metadata to inform access controls is often lacking - Metadata about a machine identity to inform access controls may be lacking if appropriate tagging and labeling isn’t performed by owning teams or version control practices are immature in the organization. Compute may also be highly ephemeral such as what often happens with containers and serverless.