Zero-trust security has gotten a lot of ink from the first, but like anything that gets good PR, it’s also been washed, to an excess in many cases. What we’re seeing now is that the contamination of the term is hurting enterprises by leading them to believe that the current usage offers them the same protection as the original idea.
What is that original idea, though? The primary goal can be summarized with the NIST approach documented three years ago. It says that zero trust “is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.” In other words, it protects assets and not network segments, the paper continues. “A zero trust architecture (ZTA) is an enterprise cybersecurity architecture that is based on zero trust principles and designed to prevent data breaches and limit internal lateral movement.” The whole NIST definition is:
“Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.”
From NIST Zero-Trust Document
You can see from this that the NIST document is (by its own admission) an abstract vision. If you dig into the details, the document seems to define two basic principles. First, you need to validate the state of all the users and resources to establish their trust level. Second, you need to validate the access rights of each element relative to the others. Identity trust, interaction trust, in short.
Implementation of this has often focused on the first point, identity. The most-recognized strategies presume that entities that access resources are separate from the mechanism whereby they make the connection. Think of it as a role-relationship approach. My job assigns me a role, and that role permits me to establish a set of relationships with other users and with resources. If I’m a device instead of a human, the same thing is true, and both are true no matter where I might be.
The practical challenge of zero trust lies in the question of how you establish the trust that you’re not able to start with (because otherwise it wouldn’t be “zero” trust!) Identity trust requires an exploration of whether a given entity is actually what it’s supposed to be. Presumptively this means that there might be an intruder that either lives autonomously within the valid entity (a parasite) or the entity might have been spoofed or taken over (a doppelganger or zombie). But how do you know? As they say, “some snarks are boojums” and inspection to determine which are which demand a standard of snark-ness too apply and a way to apply it.
And it isn’t worth it, at least not by itself. Knowing who someone is, what something is, doesn’t mean that you control what they can do, or what can be done with/to it. Access rights are related to identity but they’re more than identity, they’re a reflection of what work must flow to or from an entity. An entity that can be identified can be assigned a right to participate in information flows. That added step only makes the question of establishing trust more complicated, requiring greater efforts and introducing more cost and risk of error.
When you talk with enterprises about zero trust, this is their biggest complaint. Over five of every six enterprises say that establishing entity trust is too burdensome, and that they had been unable to consistently update the policies associated with identity to conform to changes in work practices and application usage. The problem is that it’s clearly impossible to support access security in any form without knowing who/what everything is. Or is it?
Three years or so ago, I blogged on what I believed was a critical element in security, compliance, and performance management for networks, which I called “session awareness”. A session is an information relationship established between two entities and enduring for some period of information exchange. My theory was that if you were aware of, and able to manage, sessions, you could gain control of information flows and information security. There is still a question of identity, but if you could identify all valid sessions as pairwise relationships between specific entities, you could directly address the issue of access rights and trust. I think session awareness refines the notion of zero trust.
The idea that a network might want to know what a “session” was isn’t new. Ipsilon (remember them?) brought the notion to ATM (remember that?) networks for the purposes of enhancing performance for IP-over-ATM. When an Ipsilon switch encountered what it called a “persistent flow” (just another name for a session), it would establish a virtual circuit from source to destination and bypass other handling. There were also similar concepts in frame relay and in the IETF Address Resolution Protocol, RFC 1735. What I’m wondering is whether the approach could be applied to zero-trust security, and improve it.
The theory here is that hacking and malware act through establishing a session. How can you contaminate a server or access a database without information flowing? Thus, if you were to specify what sessions were valid, anything not on that list would be untrustworthy. A pure identity approach really doesn’t do that because pure identity only establishes who everyone is, not whether they have a reason to communicate. A session identifies a flow, and a flow is really the essential, recognizable, piece of an attack.
It would be possible to recognize valid sessions as “vectors”, which would identify all relationships you’d want to afford explicit trust to. When a network recognizes a session, it could check to set if its vector is on the list, and if so afford it trust. If an endpoint is determined to be compromised, you could spin through the of vectors and “poison” the ones that involve the endpoint. All this doesn’t prevent you from having to establish who/what an endpoint is, of course, but it does create a trust model that makes sense.
I did my original work on this for SD-WAN, and shortly after 128 Technology announced a product that provided this capability. Juniper acquired them, and called it a “Session Smart Router”. It’s still one of only three implementations of session awareness I’ve been told about (others may exist and just never come to my notice, or the notice of users I’ve been in touch with), and it’s the only implementation that’s part of a major vendor’s product line. Juniper sells the solution as SD-WAN, and they link to it in the “Security” tab of their website, but still as “SD-WAN”.
Almost three-quarters of enterprises think that security vendors limit their product evolution to ensure they don’t lose revenue or risk displacement. Almost all enterprises think that their security strategy has too many layers and has grown in cost and complexity over time. They say that major changes in a security product line would “likely” mean they’d reassess their security vendor, and they’re split pretty evenly between those who say that they’d jump on a better (and in particular, more comprehensive and future-proof) strategy and those who say they’d look for another vendor who didn’t expose them to a big jump in costs.
Only 7 of over a hundred enterprises who commented on security indicated that they understood the concept of session awareness and how it could help. The majority of customers of the three vendors who offered session awareness in SD-WAN didn’t cite it as a security feature when they talked about security. I wonder whether this is because the vendor didn’t push it, or because the users found administration of a zero-trust framework burdensome.
What I wonder is whether session awareness doesn’t provide a complete, and better, strategy for zero-trust than traditional access-limiting approaches. An attempt to communicate is validated, and if an invalid attempt is recognized, it poisons trust in the entity that tries it. That’s a big step in security, but of course it still doesn’t address the users’ complaints about the difficulty associated with maintaining it.
What we need here is something that can learn validity. Give a session-aware tool access to a given endpoint, and let it identify all the sessions the endpoint attempts, over some reasonable period of time. Let operations review each session to determine if it’s valid, and if it is, then save the vector in the database. Let another tool then parse that database regularly looking for patterns, cases where several endpoints with type=user are connecting to the same partner, type=resource. From that, it should be possible to identify groups of users who share access patterns, and define “roles”. A hierarchy of structure for both user and resource endpoints can be established like this.
We’re almost there. Juniper’s Session Smart Router supports hierarchies, though as far as both users and I am aware, it doesn’t include automatic classification tools. You could accomplish the same thing, though, with the current management tools and a little time spent defining a review and assign practice to do the classification. I think that without this sort of thing, we’re not really addressing the problem.
Even with it, we may not be. The problem with any identity or session-aware trust management process is that it can’t handle situations where malware can mimic a trusted relationship by contaminating the user endpoint. That, in fact, is a hole in any of the zero-trust systems we have today. Security, then, really needs to have two pieces, one of which is session-based trust management and the other endpoint protection to fend off parasitic malware that can ride on what appear to be trusted sessions. I think a discussion of this sort of thing is lacking, and 82% of enterprises admit that they haven’t looked at security that way. Maybe they should.
