NIST – the Zero Trust architecture that can get us to Zero Day
This article is designed to review the NIST Zero Trust architecture and see how it is possible to create true Zero Day capability, given that NIST (SP 800 207) does not explicitly refer to the term ‘Zero Day’. Therefore, we should see that the NIST model does cut the mustard as we move towards a containment / guarding approach alongside the established detection methodologies
The NIST model (SP 800-207) can be accessed as a PDF at this location
What is the Trust Zone
In simple terms the NIST model proposes that a subject (threat actor, good actor) requests access to an enterprise resource, as in the diagram below.
If we pare it back, the ultimate aim of threat actors is to target data stored on PCs and/or servers as pictured above. To do this they undertake a series of actions (hoping to remain undiscovered) moving closer to the ‘Implicit Trust Zone’, where they hope they have done enough to ‘fool’ the system into giving them access.
The NIST model says that we should consider TRUST at any of the ACTION points in the journey, from the edge of the network to the target resource. If the conclusion at the TRUST ‘check point’ is ‘not trusted’, the ACTION will be prevented without further consideration.
One might argue that, ultimately, the critical and final TRUST check point is in front of the core data. If we could 100% guarantee this, then reliance on all other security measures is diminished, though not negated. It is best that we aim to check TRUST / NOT TRUST at all points where a Resource is targeted.
The RESOURCE (System, Data, Application) is any target inside the computing environment. Therefore it can be a file, an active program and its memory, or a folder. The ACTIONs requested towards any of these resources will be a Read, a Write, or a Launch.
NIST SP 800-207 does say, ‘Note that this is an ideal model showing logical components and their interactions’. Semantically the use of the word ideal, might imply that it may not be a deliverable model. Crossing the Rubicon between ideal and achievable is the purpose of this article.
This is where the question of ‘cutting the mustard’ arises. If we can take the NIST model and overlay it with a different approach, then we should be able to create Zero Trust at any point where a RESOURCE is targeted (resource intersection), with the attainment of true Day Zero handling being the ultimate goal.
Who is Trusted
The answer is that TRUST is always checked and not pre-emptively given. Each action a user asks a computer to undertake should be checked for Trust/Not Trust. This is the premise of NIST. It does however create the potential for large overheads in managing the context of each TRUST point for each and every ACTION. At this point let’s categorise requesters of ACTION by actor type:
Actor types
Threat Actors –however they got in, we want to stop them
Good Actors – Legitimate actors using the system/resources in the expected manner
Naïve Actors – those that are unknowingly blundering around; what damage are they doing?
NB: We will move away from this categorisation a little later
In essence, the majority of security systems attempt to assess the type of Actor activity they are seeing inside the network. They are assessing behavioural patterns and (to a degree) matching them against known shapes of activity (sometimes defined as signatures) for a match, or a near match.
The weakness of this method is that the outcomes can only be assessed after an ACTION is underway.
In actor terms it is trying to correlate one thing:
Is there a match or near match for previously known Threat Actor workflows?
The detection-based model needs to assess whether it has a positive or negative value against the already known activities / workflows, and then attempt to filter out events so as not to overload the human interface with false positives (time wasters) or, more dangerously, false negatives.
Another fly in the ointment is the constantly changing landscape of all software and its vulnerabilities that create opportunities for Threat actors to navigate closer to their target RESOURCE unnoticed.
As we can see, Trust can be a tricky thing to manage. Vendors of detection tools are constantly outpaced and their AI attempts will always be outgunned by a smarter, well-funded, AI enabled criminal fraternity.
Effective Trust Policing
Moving away from a reliance on detection-based models, we need to understand how Trust Policing with containment / guarding provides a more robust approach with unambiguity.
NIST codifies this with the statement below.
The key word is policies delivered by policing. In the view of the author this is not just the starting point, it is the end point. We need to police the final frontier, the door to the data resource, which we will come to when we review Actor/Threat/Action as our NIST overlay.
If we could make an instantaneous and consistent call on TRUST / NOT TRUST when a RESOURCE is being requested, we are creating our ideal model that moves us towards Zero Trust with a Zero Day capability.
Zero Trust at the resource interface should really be asking the following.
· What are you trying to do?
· Where are you trying to do it from?
· And if we let you proceed, what are you doing next?
The Airport Security Analogy
This is something most, if not all, have experienced. We are policed without favour in a consistent and objective manner, using clear and simple policies that the airlines and authorities impose.
When we turn up at the airport, at some point, we are scanned (possibly frisked) but checked out for what we are carrying.
Most airports have rules that state
· No knives in hand luggage
· No liquids over a certain volume in hand luggage
· No guns in hand luggage
These rules say no matter how nice you may be NO PASSENGER is TRUSTED with such items in hand luggage. The security guard has a simple and repeatable and 100% objective role to undertake.
This is security that is quick, consistent and not open to interpretation. No algorithms or AI required here.
The passenger (whether they look friendly or criminal like) while on the plane has been denied a path of ACTION.
Recommended by LinkedIn
Possible attack halted. Lest we forget the passenger who accidently / innocently had left their pen knife in their hand luggage (so they could peel their apple on the plane) is also rapidly dis-armed. Better to be safe than sorry, better not to trust.
I posit here that this is Zero Day because no matter how nice or threating a person looks, no matter the shape of the knife, gun, bottle: the potential for a threat action is stifled well ahead of boarding the aircraft.
The NIST model suggests if we can operate something like airport security then we are better aligned to Zero Trust capability.
Because SP 800-207 does not mention Zero Day, the market has used some of its guile to craft (or should it be graft) Zero Day onto the Zero Trust tenets. I see this as a potential veil that stops the cyber world from understanding how containment / guarding is the paradigm shift.
If we continue to pursue detection models only then the following comment from Fintech Times is a little scary.
This comment highlights the challenge where Zero Day seems to be measured in numbers of days way greater than zero. A clear argument for pre-action policing and containment / guarding rather than post action detection; this is the paradigm shift.
We need to assess the NIST model to see if it is fit for a containment / guarding approach.
The NIST Architecture (as per SP 800-207)
The NIST model applies Trust to its architecture at various layers using relevant approaches to meet Compliance expectations, or Log acquisition, or ID management etc.
Threat intelligence such as that provided by Mitre@TTack has a valid and important part to play in fulfilling this architecture, as does the utilisation of XDR/EDR/SIEM et. al. This is all valid grist to the SecOps mill, but let’s stop and suggest that while this may all be necessary, it does not appear to be sufficient.
To helps us move away from our reliance on detection to a containment / guarding approach, let’s re-frame the above view of the architecture with an overlay using the 3 labels below
Who is the Actor
What is the Target
What is the Action
If we can then police this effectively without recourse to vastly complex systems and large processing overhead, we should be nearer to our digital holy grail.
SP 800-207 (re-labelled)
Actors
We need to reframe into the two types below
User Actors – that is you and me asking Windows to open up a program called Excel, Word, Sage, etc.
System Actors – this is the Operating System undertaking tasks on behalf of the user wanting to print a word document or save it to some file store etc.
Actions
Actions are when any process tries to
Targets
Can be defined as
All a computer is doing is running applications that interoperate with other applications to make it all look seamless for all legitimate, ostensibly Trusted, activities which a User is generating as a result of, say, a mouse click to send an email half way around the planet.
How is this complexity handled in a Trust or Not-Trust way?
The purpose of this document is not to deep dive into the technical underpinnings of guarding / containment. However as a paradigm shift in thinking we need to understand the simple policy process that underpins this excellent overlay to the NIST architecture. In doing so the delivery of lightweight Trust policing with a Zero Day capability is getting us to our Holy Grail.
Policy 1. We know what the Operating System should be trusted to do if it obeys the unwritten (best practice) rules of Windows or Linux; anything that the OS is doing that is outside of this SYSTEM Policing Definition is to be explicitly NOT TRUSTED.
Policy 2. We know what Users can do and where they cannot (really should not) roam in terms of file store or memory access so anything outside of this USER Policing Definition is to be explicitly NOT TRUSTED.
What the two above Policies do is ensure that every TARGET (File /Folder/Memory) with an ACTION (read, write, launch) request is Policed (just like the airport security). No matter the Actor (OS, User) invoking the ACTION, anything outside of a clearly defined policy is explicitly NOT TRUSTED, and therefore halted via containment / guarding.
This methodology disables hackers from exploiting vulnerabilities buried in the OS and any other applications because the Containment happens if the ACTION is NOT TRUSTED. Using vulnerabilities to circumnavigate the above two policies consistently fails. This is Zero Trust in Zero Day (possibly Zero Time) in action.
At no point do we let an action take place and then try to ascertain, ‘Why did that App do what it did?’ We say that App cannot do what it requests, STOP.
One could then argue that Application Containment / Guarding might stop legitimate processes doing what they need to do, if they happen to occasionally violate policy.
The key here is assessing whether a legitimate process is doing something illegitimate because the code is not as pure as it should be (in other words, it contains inbuilt vulnerabilities). We do need to be able to allow a trust path that says: ‘We do not really like this because some underlying code is badly structured. But we must trust it so long as we understand the risk this presents in terms of softening our trust security carapace and evaluate if some other Trust/Not Trust point will provide secure equivalence’.
Trust has to be policed explicitly, with no context (algorithm free) and without favour until a softening of our policy has been truly assessed. We have to assess the risk of the Cabin Crew going rogue with the scalpel knife in the aircrafts first aid kit and manage that ahead of them boarding the plane, but we do wish to allow the first aid scalpel past the TRUST / NO TRUST gate, hence softening the policy is required.
So does NIST ‘cut the mustard’?
I would say as an established architecture it is fit for purpose. It details a comprehensive approach to Zero Trust and with a judicious overlay of containment / guarding underpins Zero Day delivery.
One major benefit of Zero Trust & (true) Zero Day is the reduction in event noise inside the necessary detection systems, while ensuring we negate the time delay baked into assessing ‘what was that threat that might have just sneaked past us all?’
One final thought to ponder is that a containment and guarding approach does not need to be cognisant of behaviour, patterns of viral attack, good or threat actors. It has no concept of a virus, so protects against viral behaviour not yet dreamed up. We can now deliver a necessary and sufficient wrap aligned to the NIST architecture.