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, authentication within a zone(s), whether by users, applications, or other resources. In addition, the model redefines the architecture of a trusted network inside a defined perimeter. This can be on-premise or in the cloud. This is relevant today since technologies and processes like the cloud, DevOps, edge computing, and IoT have either blurred, or dissolved altogether, the idea of a traditional perimeter. Therefore, the concept of a trust zone is important to manage any resources operating and communicating together.
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 reevaluation of trust for further access to prevent any unauthorized lateral movement.
While zero trust has become a trendy catchword in IT, in practice, this model is very specific about how things should be designed and operated and may not work for everyone. In practice, it is best suited for new deployments that can be designed from the ground up. The conversion of legacy deployments and network architectures in accordance with zero trust is generally impractical and unrealistic.
Success with a Zero Trust Model
- 1.Identify Your Sensitive Data at Rest and in Motion:
- a.
Perform data discovery and classification. Ensure sensitive data is properly classified.
- b.
Segment and zone the network based on data classification.
- a.
- 2.Map the Acceptable Routes for Sensitive Data Access and Egress:
- a.
Classify all resources involved in the electronic exchange of sensitive data. Ensure they are compliant for security best practices like end of life and patch management.
- b.
Evaluate the workflow of data and redesign, if necessary, who and what has access to sensitive data.
- c.
Verify that existing workflows (like PCI architectures) for data are not only governed by the network but also who and what has network access via authorized routes.
- a.
- 3.Architect Zero Trust Microperimeters:
- a.
Define microperimeters , zones, and segmentation around sensitive data. Attempt to make them as small and self-contained as possible.
- b.
Enforce segmentation using physical and virtual security controls.
- c.
Establish access based on these controls and the microperimeter designs.
- d.
Automate rule and access policy baselines and consider just-in-time access for all account types.
- e.
Audit and log all access and change control.
- a.
- 4.Monitor the Zero Trust Environment, in Detail, with Security Analytics:
- a.
Leverage and identify security analytics solutions already existing within the organization.
- b.
Determine the logical architecture and best placement for your security analytics tools.
- c.
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.
- a.
- 5.Embrace Security Automation and Adaptive Response:
- a.
Translate business processes into technology automation and remember not everything should be automated.
- b.
Document, assess, and test security operation center policies and procedures for effectiveness and response.
- c.
Correlate policies and procedures with security analytics automation and determine what can be lifted from manual processes.
- d.
Verify the security and implementation of automation within your environment and current solutions.
- a.
NIST Enhanced Core Zero Trust Architecture
The Policy Engine is responsible for the decision to grant access to a resource. It uses as much data as it can based on roles, attributes, and threat intelligence to determine if access should be granted.
The Policy Administrator is responsible for establishing the connection between a client and a resource. It provides the negotiation between the resources to “state” that the connection is allowed.
The Policy Enforcement Point is responsible for enabling, monitoring, and terminating the connection between the untrusted resource (user or application) and trusted enterprise resource.
The Policy Engine can be found in the management capabilities of an enterprise password manager, the rules and policies governing least privilege within endpoint privilege management solutions, and the role- and attribute-based access models found in a secure remote access solution.
The Policy Administrator can be found in the session management capabilities of an enterprise password manager and a secure remote access solution.
The Policy Enforcement Point can be found in enterprise password managers that have session management and privileged monitoring capabilities, and in secure remote access solutions.
And, all of this is dependent on secure credentials that follow the model of least privilege, just-in-time access, and single-use authentication. If your applications can be designed to match this model for user and application access regardless of the network, you can achieve a true zero trust architecture. Any partial implementation of this is a great step in secure computing, but represents only a hybrid approach. This is something most organizations have implemented since a pure approach is not always technically feasible.
Obstacles for Zero Trust
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 the authentication and connection models in the specification, nor are coded to operate in small groups as specified by NIST. Therefore, depending on the architecture of your custom application, it will dictate whether or not you can adopt zero trust for those processes and potentially determine the effort and cost required if they are not compatible. This is especially true in instances when applications are not microperimeter-compatible, use large quantities of resources that are network-dependent, or where they lack application programming-level interfaces to support the required automation.
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 enveloping all resources regardless of their location with the concepts of zero trust. This defeats the premise of zero trust because you have just created a bubble with even more resources that need to be managed than the original implementation you are trying to protect. You cannot necessarily monitor the behavior within a noncompatible application as well because it has now been shielded from what was traditionally normal interaction. You can, however, screen scrape, keystroke log, and monitor logs and network traffic to look for potentially malicious behavior, but your reaction is limited to this new bubble. 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.
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 a risk of 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 for IoT, 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.
Digital Transformation: Even for organizations that are in a position to build a new data center, 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 multiuser 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. Lift and shift does not equal zero trust; it must be designed in from the beginning to take advantage of privileged access management.
Considering Zero Trust?
Realistically, the only successful zero trust implementations that have gone from marketing to reality are ones that have had zero trust designed in from day one. Typically, this is not something everyone can do unless they are embarking on a brand new initiative. To put it simply, if your organization has not yet embraced the concepts of password management, least privilege, and secure privileged remote access, or still maintains shared accounts for access, zero trust is a distant goal and not something you can embrace first. It is a matter of privileged access management maturity along your journey. Finally, 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, but rather a product that fits a niche in the model. This is a “buyer beware” problem.