“Zero trust” has graduated from buzzword to repeatable architecture pattern, with standards bodies such as NIST putting out guidance and vendors improving the tooling. Add to that the move to provide security during the shifts in work brought
on by the COVID-19 pandemic, and zero trust adoption is accelerating in many organizations. This piece provides an update on zero trust use cases, tooling and effectiveness.
Zero Trust Defined
Zero trust is an evolving set of principles and architectures that favors dynamic trust boundaries over traditional static and long-lived indicators of trust. Zero trust can be summarized by these characteristics from Google BeyondCorp.
- Access to services is granted based on contextual factors from the user and their device.
- Access to services must be authenticated, authorized and encrypted.
These characteristics have been further developed in NIST SP 800-207: Zero Trust Architecture. Fundamentally, trust is established when a service or resource
is accessed.
The principle of least trust is in play here, with zero or little trust being provided before access and when the access request fails to meet the policy requirements. Otherwise, appropriate trust is provided to allow identities to complete their work.
Common Zero Trust Architecture Patterns
To achieve this, zero trust architectures must have a policy decision point (PDP) and policy enforcement point (PEP) between every identity (user and device) and the resource (application). The access is then determined by the observable state at the
PDP/PEP, which includes the context and conditions of the request, behavioral attributes and other signals of trust.
Some combination of the following zero trust architecture patterns is currently being established in large organizations to implement the principle of least trust through dynamic policy:
- Authentication: Using authentication proxy and MFA.
- Connection: Using a front-end access proxy, micro-VPN tunnel or a traditional VPN.
- Network access: Using network access control, software-defined networking, micro-segmentation or traditional segmentation.
DOWNLOAD: Zero Trust: A Step-by-Step Guide
Common Zero Trust Use Cases
Initially, the primary use case for zero trust revolved around securing remote work and enabling hybrid work. This evolved into securing cloud access for SaaS applications for the workforce and enhancing privileged access for IT professionals. Meanwhile,
use cases for applications and equipment continue to be on the roadmaps of many organizations.
More recently, common use cases based on identity for zero trust are detailed in Figure 1 below.
Figure 1: Common Use Cases for Zero Trust |
Identity | Use Case |
People | - Enabling a remote workforce
- Bring your own device
- Securing cloud access
- Enhancing privileged access
|
Applications | - Customer protection
- Reducing customer fraud
- Providing an omnichannel experience
- Digital transformation
- Application modernization
- Cloud migration
|
Equipment | - Deploying new equipment securely
- Securing operations (manufacturing, medical)
- Adopting internet of things devices
|
Source: IANS, 2022 |
Zero Trust Strategy
Organizations effective in zero trust deployments are taking an iterative approach that’s use-case driven. Broadly, this means:
- Identifying all potential use cases and prioritizing efforts on specific ones: The prioritization should be a combination of added business value and reduced security risk. As mentioned above, the primary use case for zero trust in
2020 was securing remote work and enabling hybrid work.
- Within each use case, focusing on expanding coverage for user identities, device identities and resources: For example, initial policy may simply require authenticated identities and then improving identity controls with stronger
factors or passwordless options. For endpoints, it would require first moving to enforce device health, patch status and AV status.
- Expanding from there: Once the zero trust deployment sufficiently covers the use case, the next step is to enhance the policy and expand the signals of trust. For example, the organization could move into more sophisticated policies,
such as behavior analytics, including sign-in frequency, location and access patterns.
It’s best to begin with verifying entities (people, devices, resources) and implementing risk-based authentication. After that, you can focus on deepening the policy enforcement to increase trust signals and risk factors, and then plan for how to
handle in-session trust and data protection.
Organizations that applied zero trust to securing remote work and enabling hybrid work have achieved early successes. These include:
- Strengthening user identity through consolidating identity providers and applying MFA.
- Strengthening device identity with certificate- or agent-based authentication mechanisms.
- Simplifying access to applications by consolidating SSO and access methods (from VPN to micro-VPN or access proxy).
Those early gains also have also proven effective in improving user satisfaction and reducing operational overhead (admin time, licensing, bandwidth, etc.).
Zero Trust Tooling
Zero trust tooling falls into two categories: the policy engine (PEP, PDP) and signals of trust. The policy engine extends or revokes trust when the identity is accessing the resources. This is informed by detective controls. The policy engine piece is
usually performed within one of the following areas:
- Authentication
- Connection
- Network access
Signals of Trust
For signals of trust, the deciding factor is whether it integrates with the policy engine. If it is not integrated, then it may be a strong security control, but it should not be considered part of the zero trust implementation. Signals of trust categories
to consider include:
- Antimalware
- Endpoint identity and management
- CASB
- User and entity behavior analytics
- DLP
- Privileged access management
Zero Trust Threat Mitigations
Attackers take advantage of long-lived indicators of trust and static trust boundaries. A driver for zero trust initiatives is to improve security and breach prevention, while enabling the business to achieve objectives. Depending on the use case and
the extent to which the policy is deployed, zero trust helps mitigate several common threat scenarios. See Figure 2.
Figure 2: Zero Trust Threat Mitigations |
Threat Scenario | Mitigation |
Account takeover through phishing, password spraying or password guessing | MFA |
Business email compromise through phishing, password spraying or password guessing | MFA |
Unknown devices accessing resources or applications | Device identity |
At-risk devices (unpatched, infected, noncompliant) accessing resources or apps | Device posture |
Man-in-the-middle and on-network attacks | Encrypted connections |
Ransomware spread through compromised user session or infected device | - MFA
- Device policy
- Segmentation
|
Insider threat via negligent, malicious or compromised session | - Device policy
- Behavior analytics policy
- Segmentation
|
Network lateral movement | |
Source: IANS, 2022 |
Common Zero Trust Pitfalls
Early zero trust initiatives have also faced some common pitfalls. These include:
- Focusing solely on access: Zero trust implements the principle of least trust for an identity’s access to a resource or application. But once the connection is established, anything that identity does within that resource or
application falls outside the scope of zero trust. Organizations shouldn’t overlook the principle of least privilege within the application as well. Many people have excessive access privileges within organizational resources, and this is
not solved by zero trust alone.
- Vendors claiming to be one-stop zero trust shops: Be wary of sales pitches where the pitched product solves for zero trust and prevents a multitude of threats. Zero trust is an architecture that often requires multiple products. The
stopping power of zero trust is specific to what’s observable and actionable at the policy engine (PEP, PDP). Any action in the threat model that’s after the policy decision or that bypasses the policy engine will not be addressed
by the zero trust product.
- Integration issues: Different products may be deployed for different use cases, and each use case may require multiple detective controls (signals of trust). However, not all security products integrate and share signals. A relatively
mature zero trust implementation requires duplicate work to establish and maintain consistent policy across multiple tools.
READ: Enterprise Security Architecture Best Practices
Establishing Zero Trust Architecture
Establishing a zero trust architecture across an enterprise is a complex undertaking that is iterative and incremental. To improve your chances of success:
- Take a use-case and outcome-driven approach: Prioritize zero trust based on business value and deploy zero trust in an iterative, incremental fashion.
- Focus on threat mitigation: By removing long-lived indicators of trust and static trust boundaries, zero trust can help prevent threat actors’ tactics today and as they evolve.
- Beware of policy sprawl: Integration and orchestration remain a challenge in zero trust implementations. Be sure to factor in enough time and long-term resources.
Overall, it’s important to tie back efforts to first principles—the zero trust tenets and the organization’s reference architecture—to plot a course that’s right for you.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.