22. Zero Trust – Privileged Attack Vectors: Building Effective Cyber-Defense Strategies to Protect Organizations

© Morey J. Haber 2020
M. J. HaberPrivileged Attack Vectorshttps://doi.org/10.1007/978-1-4842-5914-6_22

22. Zero Trust

Morey J. Haber1 
Heathrow, FL, USA

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

The analyst firm, Forrester,1 has outlined a road map for a successful zero trust implementation. In summary, it can be summarized in five steps with some adaption to make each step achievable in a real-world environment:
  1. 1.
    Identify Your Sensitive Data at Rest and in Motion:
    1. a.

      Perform data discovery and classification. Ensure sensitive data is properly classified.

    2. b.

      Segment and zone the network based on data classification.

  2. 2.
    Map the Acceptable Routes for Sensitive Data Access and Egress:
    1. 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.

    2. b.

      Evaluate the workflow of data and redesign, if necessary, who and what has access to sensitive data.

    3. 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.

  3. 3.
    Architect Zero Trust Microperimeters:
    1. a.

      Define microperimeters , zones, and segmentation around sensitive data. Attempt to make them as small and self-contained as possible.

    2. b.

      Enforce segmentation using physical and virtual security controls.

    3. c.

      Establish access based on these controls and the microperimeter designs.

    4. d.

      Automate rule and access policy baselines and consider just-in-time access for all account types.

    5. e.

      Audit and log all access and change control.

  4. 4.
    Monitor the Zero Trust Environment, in Detail, with Security Analytics:
    1. a.

      Leverage and identify security analytics solutions already existing within the organization.

    2. b.

      Determine the logical architecture and best placement for your security analytics tools.

    3. 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.

  5. 5.
    Embrace Security Automation and Adaptive Response:
    1. a.

      Translate business processes into technology automation and remember not everything should be automated.

    2. b.

      Document, assess, and test security operation center policies and procedures for effectiveness and response.

    3. c.

      Correlate policies and procedures with security analytics automation and determine what can be lifted from manual processes.

    4. d.

      Verify the security and implementation of automation within your environment and current solutions.

Next, consider the zero trust architectural model defined by NIST 800-207.2 It clearly states that the goal of zero trust is to focus security on a small group of resources (zones) in lieu of wide network perimeters or environments with large quantities of resources interacting “freely.” It is a strategy where there is no implicit trust granted to systems based on their physical or network location (local area network, wide area networks, and the cloud), but rather access is granted by a trusted source for either a user or application. That is where privileged access management comes in. Consider the enhanced NIST core zero trust architecture presented in Figure 22-1.
Figure 22-1

NIST Enhanced Core Zero Trust Architecture

The key components of the control plane and data plane are typically found in privileged access management solutions:
  • 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.

If we map this to PAM, we find:
  • 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

Zero trust has been developed in response to industry trends that include remote users and cloud-based assets that are not located within a traditional enterprise perimeter. It focuses on protecting resources, not logical network segments, as network segmentation is no longer seen as the prime component to the security posture of the resource. This, in itself, begins the discussion of why zero trust may not be for everyone and may not be compatible with existing systems leveraging PAM. Many times, a hybrid approach is needed that borrows some characteristics from zero trust, but which does not constitute a true zero trust architecture. Therefore, the following obstacles are the most common considering Forrester’s and NIST’s models:
  • 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.