An Introduction To Zero Trust Architecture
Lately I've been diving into the Executive Order on Improving the Nation's Cybersecurity (EO 14028) to figure out the implications for platforms and software development.
The executive order, as stated in the title, is focused on improving cybersecurity. This is outlined in ten different sections that deal with various topics across information sharing, incident response and remediation and modernizing digital systems to be more secure in the first place.
One of the prominent concepts in the order is Zero Trust Architecture (ZTA). This is featured throughout Section 3 "Modernizing Federal Government Cybersecurity". Zero Trust has a big impact on how we build and operate systems but what, exactly, is it?
The basic idea of Zero Trust is that digital systems should assume a hostile environment. Users, the network, devices, even other services may all be compromised. In this model any action taken by a given party must be validated without making assumptions about who it is, where they are coming from or any other implicit trust factors.
Who are you and what do you want?
The first step in handling this level of distrust is to know much more about who or what is attempting to do something to your system. This validation must also be dynamic and context sensitive. For instance, if you assume that a user could be compromised then you can't just depend on a simple username/password challenge and role check to protect a resource. You need to take a deeper look at what they are requesting, when they are requesting it, where they are requesting it from, etc.
One way of thinking about this approach vs traditional systems is as a series of statements or facts about an actor and what action they are attempting with system. We can use a system of subject, predicate, object to describe these statements.
In traditional systems, we would protect elements of the system by role through a couple of statements:
<user> isAuthenticated True<user> hasRole Administrator
This kind of check would allow the user to take certain actions based on being a member of a role, something that might be checked once a year during access validation processes.
This is called Role Based Access Control (RBAC), a system that has been around for a while which does provide some protection against unauthorized activities beyond just basic authentication.
RBAC is not really prepared for a world where the environment is hostile, though. We don't have much information other than an attribute that might not get checked very often but could grant sweeping access.
In order to deal with a hostile world, we need to know more and make no assumptions. For instance, when a user wants to take an action, we could have the following available:
<user> authenticationType MFA<user> <action> <resource URN><user> physicalLocation <geographic area><user> timeOfRequest <timestamp>
This approach is call Attribute Based Access Control (ABAC). ABAC can represent RBAC within it, but doesn't limit the context available to make security decisions.
With this kind of information about the user request, we can make a much more informed judgement about whether to allow the request or deny it based on more extensive rules as well as dynamic threat models updated by real-time data.
I don't care who let you in, why are you here?
A big departure with ZTA is that you do not trust the perimeter.
It might be convenient to think that if you have enhanced your access controls with all kinds of fancy anomaly detection you can cut the user off at the access point and be done with it.
Remember that our posture is to assume a hostile environment. Depending on a perimeter is just not compatible with that.
In ZTA each part of the system distrusts whatever is talking to it unless they've proven that they have a right to speak. This means that applications can't make assumptions about who is talking to them and simply offload the concern to infrastructure.
In the end, we are trying to protect enterprise resources that are a combination of applications or data. These destination systems must be vigilant about any activities within their scope. This requires a level of paranoia at the application that we used to reserve for the boundaries of the system.
Does this mean you should just get rid of all perimeter boundaries? No. There is an ancient security concept called "defense in depth" (ever played a tower defense game?). At any given moment, parts of your system may have weaknesses of one kind or another. Having multiple layers in your defensive strategy reduces the likelihood of compromise if any one layer fails.
Implications For Platforms
There are many more details to implementing ZTA than the introductory material above. In order to build and operate a system with this level of resilience there are many changes to make across people, process and technology.
With this amount of change, a natural response will be to "shift left" and pile up security responsibility on developers and other engineers involved in the process of delivering software. This will lead to a huge amount of cognitive load, reducing the overall ability of teams to deliver.
This is where platforms can ease the transition. Rather than "shift left", "shift down". Take implementation details for ZTA and put them in underlying platforms. Expose only what is necessary for engineering teams to remain accountable for security their part of the system: the application.
Finding out more about Zero Trust Architecture
A good introduction to the subject is Google's BeyondCorp. While the term was coined by John Kindervag at Forrester, Google introduced the idea to a much larger audience by documenting how they were eliminating VPNs.
While Google took the idea mainstream, the Executive Order is pushing wider implementation. The definition of Zero Trust as far as the government is concerned comes from NIST Special Publication 800-207 but a more digestible overview can be found in the CISA Zero Trust Maturity Model. The maturity model breaks out the ZTA into easier to understand pillars and gives a good idea of the scope of details that need to be addressed to achieve a given level of maturity.
In Closing
The CISA Maturity Model has a very important quote within it:
The path to zero trust is an incremental process that may take years to implement.
There are many, many, details to accomplish the full breadth of Zero Trust Architecture.
The term incremental is absolutely essential here. Our digital systems are under constant threat. We cannot leave ourselves vulnerable while creating the perfect system. Make smaller changes, improve resilience and don't get overwhelmed.
