If you have worked in a corporate environment for a while, you have probably witnessed your internal IT network slowly become more dispersed over the years. Most enterprises have moved many resources into the cloud, allowing flexibility for ‘bring your own device’ and remote workers. COVID accelerated these trends, as corporate networks suddenly had to allow access to a slew of remotely distributed devices.

These days, things are very connected and often residing in multiple clouds. Plus, many types of users might be accessing a single resource, from internal teams to remote workers, contractors, partners, and public end users. All this means that the traditional perimeter of a corporate network is dissolving. And as such, the traditional model of placing security at the edge is now antiquated, as it doesn’t block hackers that might be posing as internal users.

Zero trust is a response to this new reality — it means taking a “never trust, always verify” approach by assuming every call to a service is a potential threat, regardless of whether it’s coming from inside or outside the network. With the pervasiveness of cloud vulnerabilities and the persistent possibility of leaked keys and secrets, a zero-trust architecture is arguably a necessary response to the risks of modern software systems.

In our LiveCast on Zero Trust, we explored what it takes to implement zero trust. We highlighted standards that help secure zero trust in a token-based architecture and considered the gateways necessary to implement zero trust access for APIs and microservices. Below, I’ll review the key takeaways from the event to determine how to best go about implementing zero trust in your organization.

Zero Trust ≠ Zero Effort

According to Keith Casey, zero trust doesn’t equal zero effort. Trust nothing.

First, we should note that zero trust doesn’t mean zero effort. While security in the software ecosystem is improving as a whole, there are still countless vulnerabilities present not only in the application layer, but the software supply chain, storage, network, communication, and elsewhere. “There’s a deeper, more visceral layer of risks to think about,” said Keith Casey. “Security is a mess.”

As an API community, our frame of reference is typically the application and how it communicates with the external world. But Casey is quick to realize that a greater picture is necessary to achieve zero trust. “One of the reasons we’re not doing this well as an industry is that most of us are software developers, so we love thinking about how applications are secure.” And without more context, you might overlook some grave assumptions.

For example, Casey shares a story of when he once went on-site to help a client secure their private internal API. While sitting at the table with the client, he nonchalantly logged onto the corporate network, retrieved the company’s internal API documentation, and used Postman to initiate some successful API calls. It turned out that the security of the service had been built with the assumption that anyone on the corporate network would inherently be authorized to use the API. (The company had opened a guest network and, after installing WiFi, had merged it with the corporate network years ago). That essentially meant that anyone in the parking lot who could access WiFi had access to these production APIs! Upon finding this out, it was an unhappy surprise for the network architects, to say the least.

Unfortunately, the above scenario is far more rampant than we think. Due to the disconnect between application developers and network security administrators, glaring holes can easily slip through the cracks. And, as enterprise software ecosystems evolve and the perimeter dissolves, certain security assumptions become false.

Casey summarized the many other cybersecurity risks facing modern enterprises these days:

• Insiders: Many breaches are often caused by insider threats — 57%
  of database breaches involved insider threats within an organization, found the Verizon Insider Threat Report. This usually involves stolen credentials or keys.
• Unknown devices: Nowadays, most people use their own devices to connect to the network. But how can we trust every device and ensure it is up to date and properly managed?
• External malicious apps: These are things outside the corporate firewall and network control. Nefarious actors use them to collect and leverage data.
• Internal malicious apps: These are components within the network. With the rise of supply chain attacks and open-source vulnerabilities, it’s very possible your very own applications are compromised.

In order to mitigate the above threats, Casey proposes a zero-trust architecture. At a high level, this must include policy engines, policy administrators, and policy enforcement over every service. Casey also proposes a fine-grained model, where policy enforcement modules are placed alongside every single component, whether it’s a database, webserver, or API. Thus, systems can be responsible for themselves and not rely on a centralized enforcement engine. Of course, giving components their own policy enforcement points creates a more complicated model. But microgateways and open-source standards like Open Policy Agent can help construct such a system.

Why A Token-Based Architecture Is Great For Zero-Trust

A token-based architecture is ideal for implementing zero trust, says Jonas Iggbom.

Zero trust is more of a philosophy than a particular product or service. As such, many tools and strategies exist to implement a zero-trust architecture. But in general, a zero-trust approach will always verify that an entity requesting access to a record has permission to access it. This must be processed for both users and microservices and will likely involve attribute or policy-based access control systems for each service or workload.

For Jonas Iggbom, zero trust goes hand in hand with identity control. Because when it comes down to it, systems must prove the identity of the user or service, along with their permissions, before granting access to a resource. Without a proper sense of identity, APIs can become prone to broken access control issues.

“You need to understand the identity of who or what is trying to gain access. This aligns extremely well with a token-based architecture.”

Naturally, adopting a zero-trust approach hinges on authentication. Yet, over-prescribing multi-factor authentication over every resource can put a significant damper on user experience. As a result, more user-friendly approaches are becoming popular, such as passwordless authentication, single sign-on, and reduced sign-on. As Iggbom describes, systems could still initiate MFA when suspicious activity occurs. This might include logins outside typical work hours or when geolocation data presents impossible journeys. Future passwordless authentication checks might even monitor a user’s unique keystrokes or mouse movements for irregularities.

The other aspect of affirming identity is authorization. This is where tokens come in. Tokens hold claims that are essentially assertions that allow an application or API to trust certain attributes. The scopes or roles delineated here can be thought of as user privileges. Tokens that are bound to a specific application or API are typically transferred as JSON Web Tokens (JWTs), which are powerful, self-contained tokens that typically hold a good deal of user information. As such, Iggbom advocates using opaque tokens to avoid divulging sensitive information in the authorization process.

The phantom token pattern utilizes a token service external to the application to issue opaque reference tokens, which are random strings. The API gateway calls the token service using the opaque token and gets back a JWT that it sends to an API. By decoupling token generation and management in this way, the system drastically decreases the chance of accidentally exposing personally identifiable information. In addition, Iggbom outlines the need for an entitlement management system. This external system can hold policies and denote access control rules used by the identity access management or token service.

Trust Nothing, Verify Always

By building for zero trust, you can help avoid cyber threats by arming every interaction point. As Casey points out, we must be just as vigilant in granting access to machines and services as we are with external and internal users — especially when programmatic APIs are concerned. Therefore, it’s really moreso a case of trust nothing than trust no one.

Zero trust also helps protect personally identifiable information. Hunkering down access is especially important in areas that carry sensitive data, such as healthcare, financial services, and government.

But zero trust is not easy to implement. Organizations must have a clear understanding of their internal components and their connections to deliver fine-grained policy enforcement. This will require a holistic lens of the entire network, extending beyond the application layer.

In terms of implementation details, Iggbom argues zero trust will require multi-layered authorization, claims-based authorization, and a robust security system that avoids placing PII in public clients. To meet these goals, zero trust appears to fit nicely with a token-based architecture focused on identity. “The identity is the new permitter,” said Iggbom.