By Morey Haber
By definition, a zero trust security model advocates the creation of zones and segmentation to control sensitive IT resources. This also entails the deployment of technology to monitor and manage data between zones, and more importantly, user interactions within a zone(s).
A zero trust security model redefines the architecture of a trusted network inside a defined corporate perimeter. This is relevant today since technologies and processes like the cloud, DevOps, and IoT have either blurred, or dissolved altogether, the idea of a traditional perimeter.
Zones in and of themselves can be delegated using micro-segmentation down to the host or data layer to enforce a zero trust model. This implies that a resource, like a server, or even a database, can have multiple zones to support the data collection and monitoring needed to achieve zero trust.
Zero trust essentially establishes a model of trust, verification, and continuous evaluation of trust for further access and lateral movement.
While zero trust has become a trendy catchword in IT, in practice, this model is generally impractical, or unrealistic to implement.
In this blog, I will review the practical shortcomings and limitations of a zero trust model, and explain a better path forward.
Success in a Zero Trust Model
Forrester has outlined a roadmap for a successful zero trust implementation. Here is Forrester’s five step model, paraphrased:
- Identify your sensitive data at rest and in motion
- Perform data discovery and classification
- Segment and zone the network based on data classification
- Map the acceptable routes for sensitive data access and egress
- Classify all resources involved in the electronic exchange of sensitive data
- Evaluate the workflow of data and redesign, if necessary
- Verify the existing workflows, like PCI architectures, and verify designs
- Architect zero trust microperimeters
- Define microperimeters, zones, and segmentation around sensitive data
- Enforce segmentation using physical and virtual security controls
- Establish access based on these controls and the microperimeter designs
- Automate rule and access policy baselines
- Audit and log all access and change control
- Monitor the zero trust environment, in detail, with security analytics
- Leverage and identify existing security analytics solutions already existing within the organization
- Determine the logical architecture and best placement for your security analytics tools
- If a new solution is needed, identify a vendor that is moving in the same security direction as your organization and that can provide analytics for your other security solutions
- Embrace security automation and adaptive response
- Translate business process into technology automation
- Document, assess, and test security operation center policies and procedures for effectiveness and response
- Correlate policies and procedures with security analytics automation and determine what can be lifted from manual processes.
- Verify the security and implementation of automation within your environment and current solutions
4 Obstacles to Achieving Zero Trust
While many of the recommended approaches have merit and seem logical, many are unrealistic to achieve in practice due to the following issues facing almost every organization:
1. Technical Debt
If your organization develops its own software for consumption, and the applications are more than a few years old, you have technical debt.
Redesigning, recoding, and redeploying internal applications can be costly and potentially disruptive. There needs to be a serious business need to undertake these types of initiatives. Adding security parameters to existing applications to make them zero trust-aware is not always feasible. Odds are your existing applications have no facilities today to accommodate zero trust.
Therefore, depending on how reliant you are on custom applications, this will dictate whether or not you can adopt zero trust to those processes, and potentially determine the effort and cost required. This is especially true in instances when applications are not microperimeter-compatible, or where they lack application programming level interfaces to support the required automation.
2. Legacy Systems
Legacy applications, infrastructure, and operating systems are most certainly not zero trust-aware. They have no concept of least privilege or lateral movement, and they do not possess authentication models that dynamically allow for modifications based on contextual usage.
Any zero trust implementation requires a layered—or wrapper—approach to enable these systems. However, a layered approach entails wrapping the external access to the resource and rarely can interact with the system itself. This defeats the premise of zero trust. You can not necessarily monitor the behavior within a non-compatible application. You can screen scrape, keystroke log, and monitor logs and network traffic to look for potentially malicious behavior, but your reaction is limited. You can only limit the external interaction of the legacy application to the user or other resources—but not the runtime itself. This limits the coverage of zero trust, and based on the characteristics of the legacy application, organizations may find that even monitoring network traffic is infeasible due to heavy encryption requirements, including TLS 1.3.
3. Peer-to-Peer Technologies
If you think your organization does not use peer-to-peer (P2P) networking technology, you are probably unaware of the default settings in Windows 10.
Starting in 2015, Windows 10 enabled a peer-to-peer technology to share Windows Updates among peer systems to save Internet bandwidth. While some organizations turn this off, others are not even aware it exists. This represents privileged lateral movement between systems that is fundamentally uncontrolled. While no vulnerabilities and exploits have materialized for this feature, it does present communications that violate the zero trust model. There should be no unauthorized lateral movement—even within a specified microperimeter.
In addition, if you use protocols like ZigBee or other mesh network technology, you will find that they operate completely counter to zero trust. They require peer-to-peer communications to operate, and the trust model is based strictly on keys or passwords, with no dynamic models for authentication modifications.
Therefore, if you decide to embrace zero trust, please investigate if your organization has P2P or mesh network technologies, even for wireless networks. These present a huge stumbling block to embracing the access and microperimeter controls required for zero trust.
4. Digital Transformation
Even for organizations that are in a position to build a new datacenter, implement a role-based access model, and embrace zero trust 100%, the digital transformation considerations can make the theory difficult to embrace.
The digital transformation driven by Cloud, DevOps, and IoT does not inherently support the zero trust model as it requires additional technology to segment and enforce the concept. For large deployments, this can be cost-prohibitive, and may even impact the ability for the solutions to interact correctly with multi user-access. If you doubt this, consider simply the storage requirements and license costs to log every event for dynamic access on all resources within the scope of the project.
While some may disagree that the Cloud does embrace segmentation and zero trust models, it all depends on how you use the Cloud. A straight migration of your raised floor to the cloud does not embrace zero trust. If you develop a new application in the cloud as a service, then it certainly can embrace zero trust.
However, just moving to the Cloud alone as a part of your digital transformation does not mean you inherently get the prescribed zero trust model benefits. And if you decide to embrace zero trust and bake it into your plan, it most certainly will not work well after the fact as a layered approached for all the reasons discussed earlier in this article.
What to Think about if you are Considering Zero Trust
The only successful zero trust implementations that have gone from marketing to reality are ones that baked zero trust in from day one. Typically, this is not something everyone can do unless they are embarking on a brand new initiative.
- Privileged Access Management (PAM)
- Remote Access
- Vulnerability Management
To put it simply, if your organization has not yet embraced the concepts of privileged access and least privilege, and/or still maintains shared accounts for access, zero trust is not going to work.
While some PAM vendors market “zero trust” solutions, they are really selling a solution to begin the journey of zero trust. They are not actually offering a self-contained zero trust solution to solve the entire problem—which is a massive undertaking that generally requires building the right IT architecture with zero trust as the driving security principle from the outset.
However, to be fair, the first step in embracing zero trust is embracing PAM.
Removing administrative rights, managing accounts and passwords, eliminating shared accounts, incorporating session recording, enforcing network communications, etc., are the primary features of PAM. Extending that to zero trust only succeeds when implemented correctly and the rest of the organization embraces zero trust for automation, microperimeter access control, data discovery, and security analytics.
Not all privileged access occurs within the traditional corporate perimeter. Zero trust requires strict control of the resources to enforce the microperimeter model.
Regardless of whether the organization is a fledgling startup or a well-established enterprise, zero trust to privileged resources cannot manage what is not in scope. Zero trust demands full control of everything that requests access, but when it’s outside of the perimeter, it falters. User (remote employees, contractors, etc.) and application access requires privileged remote access to establish a secure connection and manage the threats that can come from a non-managed system.
Remember, the zero trust model has very limited, if any, accommodations for securing remote access for personnel and contractors outside of a microperimeter. Please consider any and all access to a microperimeter based on the source of the connection and its overall security from credentials, context, and privileges.
Zero trust is focused on user access, role-based access, lateral movement, microperimeters, and user analytics and behavior. For a mature company, zero trust is a layer above, and below, existing security procedures and ignores a fundamental hygiene process; vulnerability and patch management.
Controlling the user is pointless if the resources they are accessing are vulnerable to other types of cybersecurity risks and exploits. Why would you ever give a vulnerable application administrative rights?
Lateral movement and privilege exploitation can only occur from two attack vectors:
- Privileged attack vectors (due to poor account and password management)
- Vulnerability and exploit combinations
For zero trust to be effective, it needs to consider not only the user, but the risks of the resources themselves. It does not. You would never grant access in a zero trust model if the assets have remotely exploitable critical flaws. Zero trust ignores the resources risk, while focusing inordinately on access controls.
The zero trust model is not new. Regulatory standards like PCI have embraced the concepts, minus analytics and automation, for years. The basics make common sense, but without considering the existing technology within your stack, your strategic direction, and the technologies used for remote access and vulnerability management, it is just a theoretical approach used for architecting good cybersecurity hygiene from the ground up, not a pre-packaged solution that can be bought to retrofit over your existing systems.