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.