For Zero Trust to be widely and successfully adopted, organizations must understand it.
That seems an obvious statement, but right now, Zero Trust is not well understood—and it’s seriously harming the way many organizations are approaching the concept.
We believe there are several reasons for this.
Zero Trust Barriers to Entry
Right now, we see three major reasons why organizations struggle to understand what Zero Trust is, and what it really means for them.
1. A lack of common and agreed terms, components, and meaningsWe’ve already noted the relatively vague Zero Trust definitions provided by leading analysts and regulators. When combined with an overload of unhelpful and often contradictory marketing messages from cybersecurity vendors, this has created a general air of confusion. Kathleen Moriarty, CTO at the Center for Internet Security, explains:
“There’s a big misconception, probably caused by vendors misusing the term, that Zero Trust is just a marketing buzzword. Zero Trust is a crucial concept for organizations to adopt, and I’m concerned that its overuse and misuse in a marketing context could get in the way of its adoption.”
Most concerningly, while NIST SP 800-207 does an excellent job of outlining the core tenets of Zero Trust, it doesn’t explicitly list the underlying capabilities required to deliver Zero Trust in practice. There are some arguments in favor of this approach. However, it has left the floor open for some cybersecurity vendors to claim Zero Trust benefits for unrelated solutions, creating further confusion.
2. A lack of individual vendors that can “deliver” Zero TrustIn the past, many cybersecurity “wins” have been achievable by implementing a single solution. For example, Multi-Factor Authentication (MFA) is a substantial improvement on traditional password authentication—and can be implemented with relative ease by purchasing a single solution.
Zero Trust does not fall into this category. NIST SP 800-207 goes so far as to state: “[...] no one vendor offers a single solution that will provide zero trust. Furthermore, it might not be desirable to use a single-vendor solution to achieve zero trust and thereby risk vendor lock-in.”
While this isn’t a “fault” with Zero Trust, it makes it more challenging, resource-intensive, and time-consuming for organizations to implement.
3. An over-focus on access and authorizationOne of the top misconceptions about Zero Trust is that it’s purely about access and authorization. NIST SP 800-207 may be partly to blame for this misconception, as it directly states:
“The initial focus should be on restricting resources to those with a need to access and grant only the minimum privileges [...] needed to perform the mission.”
The publication goes on to highlight other components of Zero Trust—and it is evident from reviewing the prescribed tenets that there is more to Zero Trust. However, the heavy focus on access and authorization throughout the document may well have influenced broader industry messaging that frequently leaves out vital capabilities.
A Zero Trust Architecture should eliminate assumed trust throughout an IT environment. This requires enforcing dynamic cybersecurity policies across four layers:
- Identity
- Device/Workload
- Access
- Transaction
Most discussion of Zero Trust covers the Identity and Access layers at length and the Device layer in passing. However, the Workload or Transaction layers are rarely mentioned. This is a problem—only by enforcing policies at all four layers can an organization achieve the full Zero Trust value proposition.
For every request or action within an IT environment, several queries must be answered with a high degree of confidence. These include:
|
Query |
Layer |
|
Is the subject (user, application, service) expected, legitimate, and allowed to access a resource? |
Identity |
|
Are the subject’s recent behaviors in line with expectations and historic records? |
Identity |
|
What is the least privilege the subject can be granted that will allow it to fulfill its function |
Access |
|
Is the device or infrastructure the request originates from in the expected, securely configured state AND free from compromise? |
Device/ Workload |
|
Are device/infrastructure’s behaviors in line with expectations and historic records? |
Device/ Workload |
|
Are the changes being made by the subject or device allowable within the environment? |
Transaction |
If the answer to any of these queries is negative OR there is insufficient confidence in the data, the request or action should be blocked. This is regardless of whether it’s a request for access to a resource or an attempt to change a resource in an unauthorized manner following successful authentication.
The Missing Components of Zero Trust
Our new report, ‘The Missing Components of Zero Trust,’ explains what Zero Trust really is, examines some significant gaps in existing guidance, and details the most important concepts and capabilities required for an effective Zero Trust Architecture.
Download the report to learn:
- The Core Principles and 7 Tenets of Zero Trust.
- How the Zero Trust strategy and architecture eliminate implicit trust.
- How to elevate your security posture and avoid making the most common Zero Trust mistakes.
- The answer to the question, "Does Zero Trust actually work?"
Download your free copy today:
