By Zack Butcher, Founding Engineer, Tetrate

Anyone who has sat through a bad horror film knows the scene: a hapless and soon-to-be victim answers the phone at their home to hear an otherworldly voice delivering menacing and vaguely lethal threats. And right on cue, the scary music rises as the listener realizes that the danger isn't coming from some far-away caller...  it's coming from inside the house!

Modern IT security has become similarly frightening. More and more, we must contend with bad actors who have already gained access to sensitive information and applications within our networks. Zero trust has emerged as one way to augment perimeter security as a means to thwart risks from those who've already made it through the firewall.

Since 2009 when Google implemented what was arguably the first zero trust architecture called BeyondCorp, the idea of zero trust has steadily gained ground both in interest among highly regulated industries and in terms of the technical choices available to make it happen in production. Zero trust, or "never trust and always verify," is a way to move beyond the limitations of perimeter-based security, where the obviously fatal flaw is that you must assume that bad actors will find a way past the perimeter.

Generally speaking, zero trust is an approach to cybersecurity that denies access by default, granting authenticated users, devices, and applications access only to the data, services, and systems they need to do their jobs. It's focused on controls that we can implement at runtime. To accomplish this, zero trust at my company, Tetrate, maps out five runtime checks-specifically, identity-based segmentation controls-that are made at every hop in your network. If you do this, you can mitigate what an attacker can do even if they're past the perimeter and inside the network. Let's look at each of those five.

1. Encryption in Transit

Encryption in transit provides eavesdropping protection and payload authenticity. It's easy (and popular) to say we want encryption in transit, but why do we want it? We want it so that nobody can eavesdrop on network traffic. More importantly, it provides validation of message authenticity, as a bad actor cannot change the data or instructions being sent.

2. Service Authentication

When two applications are communicating, we want to know what those applications are. Often, we're going to implement this using things like mTLS and SPIFFE for providing cryptographic workload identity. A service mesh, like open source Istio, is a well-known way to accomplish encryption in transit and service authentication at the same time.

3. Service to Service Authorization

It's not just enough to know that a user's mobile phone is connected to the bank's server. We also want to authorize that the action the mobile app is doing is allowed on the bank server.

4. End User Authentication

And, it's similarly not enough to know that the bank app running on the mobile device is allowed to talk to the bank server. We also need to know that the user is properly logged in to the application.

5. Authorize the User at Every Step

Let's say that you exchange an API key for a jot at the front door. In zero trust, you must assert that the jot remains valid and has not been tampered with at every network hop it passes through. You can then use properties of that authenticated user principle to confirm that a user remains logged in, that the banking app is talking to the banking server, that this is allowed, and that you are an authenticated user. At every single hop along the way, we want to check that:

• we have the message that we intended to send, and that we have message authenticity
• the services talking to each other are allowed, authenticated and authorized
• the person in the user session and the actions that they are taking are allowed
  

The Runtime Cost of Enforcement

The computational cost to all this is weighed as a trade off of security versus availability. For example, if you deny a request because the authorization server is offline, you've just made a decision of security over availability. Fundamentally, you are always making that decision in every system that you build. Of course, as the joke goes, "the most secure system is one that's turned off and unplugged." That's why it's a spectrum: you're always making a trade off between security and availability.

Also, you can weigh the business cost of having all your data exfiltrated because of a misconfiguration versus the runtime computational costs of the extra authorization check. If those extra authorization checks can meaningfully reduce your business risk, then it's straightforward to justify the additional costs, especially if yours is a heavily regulated industry or your application space involves highly sensitive information where the cost of a breach is unbearable.

Getting Going With Zero Trust

Perimeter security is well understood and widely adopted. Zero trust is a fundamentally different architectural approach to security. It can be intimidating, and it's understandable that some CISOs have reservations.

In practice, I've seen executives in charge of security and networking sit in amazement at how much simpler a networking topology can be when you adopt zero trust. We worked with an executive at a health services company to deploy zero trust for FedRAMP certification. The architecture we put together was vastly simpler than the models typically found at, for instance, a financial services company. The subtext here is that we replaced a lot of slow and brittle controls with identity based policy-things like the perimeter firewall rules. Instead of going to the spreadsheet that lists all the IP addresses and DIPs and working backwards from that to figure out which applications need connectivity, you can use self-describing policies. You can imagine how much easier and secure it is to approve a policy change in that environment. Bottom line, there are a lot of rigid controls that we can replace with policy.

In general, the litmus test should be this: most of your organization need not hear about zero trust. If you're doing it correctly, it's really something that is focused on the security and operations side of the house, and maybe on your infrastructure platform team. But it shouldn't be something that touches everybody, at least early on. The primary folks that should know about it are going to be the CISO and their organization. After that, you move on to the teams responsible for the infrastructure that runs the business applications.

You can implement those five checks outlined above with a service mesh like Istio. Often, we will work with the platform team and focus on the application infrastructure. Maybe they don't do all five checks from day one, perhaps starting with just encryption in transit. And that's net better than they were yesterday, providing some immediate ROI and credibility before you have to ask a bunch of people to start changing the way they do things. We can accomplish that at the platform layer, so the applications on top of the platform typically benefit without needing to change.

An Update on NIST Zero Trust Standards and FIPs Compliance

I work with NIST on a couple of different sets of special publications around these topics. We're planning a webinar with NIST to provide an update on Thursday, March 30 at 10:00 a.m. PDT. In it, we'll break down a lot of what I'm talking about here, and I'm going to introduce the idea of identity based segmentation. You can find out more about it here. We'll walk through the five checks in greater depth and talk about how we implement them using open source Istio. I'll also introduce two other concepts from the NIST special publication that we did not have time to cover in this article, including the concept of multi-tiered policies.

Tetrate at KubeCon Europe

The Tetrate team will participate in KubeCon + CloudNativeCon Europe 2023, with Istio Day, speaking sessions, after hours, and even a movie premiere on the history of Envoy Proxy. Learn more about how to connect with us on site or stop by Booth #S98.

...

What I want to leave you with is the assurance that implementing zero trust does not have to be a long process. You can get started rather quickly, deploying real improvements quickly that deliver a measurable ROI before adding the other elements. Given the need for security concepts that protect systems and data from attackers that are already in the network, zero trust should be something that every organization in a regulated or data-sensitive industry is taking steps toward embracing, sooner rather than later.

##

To learn more about the transformative nature of cloud native applications and open source software, join us at KubeCon + CloudNativeCon Europe 2023, hosted by the Cloud Native Computing Foundation, which takes place from April 18-21.     

ABOUT THE AUTHOR

Zack Butcher Founding Engineer, Tetrate

Zack Butcher is a Founding Engineer at Tetrate where he works with some of the largest enterprises in the world to adopt Envoy and Istio. Zack was one of the earliest engineers on the Istio project at Google, sat multiple terms on the project's Steering Committee, and co-authored Istio: Up and Running (O'Reilly Media, 2019). He works actively with the National Institute of Standards and Technology (NIST) on Next Generation Access Control and co-authors the series of NIST Special Publications defining the standards for microservice security and zero trust for the US Federal government - including NIST SP 800-204A, NIST SP 800-204B, and NIST SP 800-207A (upcoming). Before Tetrate, Zack worked across Google Cloud Platform on its central resource hierarchy, service management, identity & access management systems, as well as Google's internal mesh that Istio draws from.