Zero Trust Journey Takeaways#
Based on our experience building example implementations in the lab, we recommend that an organization that wants to deploy and implement zero trust embark on a journey that includes the steps listed as subsection headings below.
Discover and inventory the existing environment#
The first step any organization should take on its zero trust journey is to identify all of its assets by determining what resources it has in its existing environment (hardware, software, applications, data, and services). This may involve deploying tools that monitor traffic to discover what resources are active and being accessed and used. It is necessary to have a complete understanding and inventory of the organization’s resources because these are the entities that the zero trust architecture will be designed to protect. If resources are overlooked, it’s likely that they won’t be appropriately protected by the ZTA. They could be vulnerable to exfiltration, modification, deletion, denial-of-service, or other types of attack. It is imperative that all of the organization’s resources, whether on-premises or cloud-based, be identified and inventoried.
Discovery tools that are used to identify organization resources may do so, for example, by monitoring transaction flows and communication patterns. These tools may also be useful in helping the organization identify the business and access rules that are currently being enforced, and in identifying access patterns that business operations require. Understanding how resources are accessed, by whom, and in what context will help the organization formulate its access policies. In addition, once the organization has begun deploying a ZTA, continuing to use the discovery tools to observe the environment can be helpful to the organization as it audits and validates the ZTA on an ongoing basis.
Formulate access policy to support the mission and business use cases#
Once the organization has identified all the resources that it needs to protect and where they are, it may formulate the policies that the ZTA will enforce to specify who is allowed to access each resource and under what conditions. The access policies should be designed to ensure that permissions and authorizations to access each resource conform with the principles of least privilege and separation of duties. Typically, access to each resource will be denied by default, and access policies should be formulated to authorize subjects with the least privileges required in order to perform their assigned task on a resource that they are permitted to access. This requires understanding the types of users that will be accessing resources, their access requirements, work locations, employment arrangements, device types, and ownership models (e.g., BYOD and corporate-owned) because these will all influence policy creation. Access authorizations may be constrained according to the location of the individual requesting access, time of day, or other parameters that can further limit access without interfering with organizational operations. All access policies should be informed by the criticality of the resource being protected.
Initially, an organization may not have a clear sense of what resources each employee needs to access. They may not be aware of which employees are accessing which resources or whether or not such access conforms to the principles of least privilege and separation of duties. Information provided by the tools that were used to discover resources can be useful in this regard. They can monitor access patterns and produce a list of access flows and patterns that are observed. For the remote access example, an organization transitioning from a full device VPN to per-app tunneling could first set up a full device tunnel and observe traffic, then begin enabling only the traffic that is required for the user profile. The organization’s security team can then examine this list to determine which access flows should be permitted and then formulate access rules that permit them. Any observed access flows that should not be permitted may be denied by default or explicitly prohibited in the access policy. By basing access policy on observed access patterns, an organization reduces the chances that it will create overly restrictive policies that interfere with its ability to conduct normal operations. By taking into consideration the criticality of the data being protected when formulating the access policy, an organization can help ensure that the protections being provided to a resource are commensurate with its value.
One challenge that organizations may have when formulating policy is that their ZTA may consist of numerous components that each perform policy engine and policy administration roles. As a result, access policy may not be centralized; rules may be distributed across numerous products, i.e., with some rules configured in an endpoint protection component; some configured in identity, credential, and access management components; other rules configured in a network security component; and still other rules configured in a data security or other components. The lack of a single location where all policy rules can be centralized may make it challenging for an organization to maintain an organized, complete, consistent understanding of its access policy. To help organizations manage their access policies, they should explicitly keep track of not only what their access rules are, but where each of the rules is configured.
Identify existing security capabilities and technology#
If an organization is planning to install a ZTA into a greenfield environment, meaning that it will not have any existing IT equipment or security capabilities that it will want to use or accommodate, this step would not be needed. Most organizations embarking on a zero trust journey, however, will not be starting from scratch. Instead, they will have an existing infrastructure and technology systems that already perform security functions. Organizations will typically have at least network firewalls and intrusion detection systems to help provide perimeter security, and identity and credential access management systems that enable them to authenticate users and enforce authorized access based on identity and role. They may have endpoint security systems protecting their laptops and/or mobile devices to provide firewall protections and ensure that they are running required antivirus or other security software. They may have tools for vulnerability and configuration management, log management, and, and other security-related functions. They also likely have some sort of security operations center.
An organization should identify and inventory its existing security technology components and capabilities to understand what protections they already provide, then determine whether these components should continue to provide these protections as part of the deployed ZTA or should be repurposed. To save money, an organization will want to continue to use or repurpose as much of its existing technology as possible without sacrificing security. Continuing to use existing technology will require the organization to understand what potential zero trust components and products its existing security technology will integrate with. Any additional components that are purchased specifically for deployment in the ZTA should, ideally, integrate with the security technology components that the organization already has and plans to continue to use.
Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based Approach Based on the Value of Data#
Once an organization has inventories of the resources it needs to protect and the security capabilities it already has, the organization is ready to begin planning its access protection topology, in terms of whether and where its infrastructure will be segmented and at what level of granularity each resource will be protected. The access topology should be designed using a risk-based approach, isolating critical resources in their own trust zones protected by a PEP but permitting multiple lower-value resources to share a trust zone. In designing its access protection topology, the organization will identify which PEP is responsible for protecting each resource as well as what supporting technologies will be involved in providing input to resource access decisions. Initially, the organization’s network may not be well segmented. In fact, before zero trust is implemented, when the organization is still relying on perimeter-based protections, such a topology can be thought of as the organization protecting all of its resources behind a single PEP, i.e., the perimeter firewall. As the organization implements ZTA, it should segment its infrastructure into smaller parts. Such segmentation will enable it to limit the potential impact of a breach or attack and make it easier to monitor network traffic. In designing its access protection topology, the organization should apply access control enforcement at multiple levels: application, host, and network.
Implement ZTA components (people, process, and technology) and incrementally leverage deployed security solutions#
Once an organization has: 1) a good understanding of its current environment in terms of the resources it needs to protect and the security capabilities that it already has deployed; 2) formulated the access policies that are appropriate to support its mission and business use cases; and 3) designed its access protection topology to identify the granularity at which access to various resources will be protected and the supporting technologies that will provide input to the PDP, the organization is ready to begin incrementally implementing ZTA. Given the importance of discovery to the successful implementation of a ZTA, the organization may begin by deploying tools to continuously monitor the environment, if it has not done so already. The organization can use these observations to audit and validate the ZTA on an ongoing basis.
In addition to discovery tools, the organization should ensure that any other baseline security tools such as SIEMs, vulnerability scanning and assessment tools, and security validation tools are operational and configured to log, scan, assess, and validate the ZTA components that will be deployed. Having security baseline tools in place before the organization begins deploying new ZTA components helps ensure that the ZTA rollout will be well-monitored, enabling the organization to proceed with high confidence that it will understand the security ramifications of the incremental deployment as it proceeds.
Identity, authentication, and authorization are critical to making resource access decisions. Given that making and enforcing access decisions are the two main responsibilities of a ZTA, the organization will want to use its existing or a new ICAM solution as a foundational building block of its initial ZTA implementation. The organization should strongly consider implementing MFA in a risk-based manner for its users. An endpoint protection or similar solution that can assess device health and that integrates with the ICAM solution may also be another foundational component of an initial ZTA deployment. An initial ZTA based on these two main components will be able to use the identity and authorizations of subjects and the health and compliance of requesting endpoints as the basis for making access decisions. Additional supporting components and features can then be deployed to address an increasing number of ZTA requirements. Which types of components are deployed and in what order will depend on the organization’s mission and business use cases. If data security is essential, then data security components will be prioritized; if behavior-based anomaly detection is essential, then monitoring and AI-based analytics may be installed. The ZTA can be built incrementally, adding and integrating more supporting components, features, and capabilities to gradually evolve to a more comprehensive ZTA.
Verify the implementation to support zero trust outcomes#
The organization should continue to monitor all network traffic in real time for suspicious activity, both to look for known attack signatures and patterns and to apply behavioral analytics to try to detect anomalies or other activity that may be attack indicators. The organization should use deployed discovery and other baseline security tools to audit and validate the access enforcement decision of the ZTA it has provisioned, correlating known data with information reported by the tools. The organization should perform ongoing verification that the policies that are being enforced, as revealed by the observed network flows, are in fact the policies that the organization has defined. Periodic testing should be performed across a variety of use case scenarios, including those in which the resource is located on-premises and in the cloud, the requesting endpoint is located on-premises and on the internet, the requesting subject is and is not authorized to access the requested resource, the requesting endpoint is and is not managed, and the requesting resource is and is not compliant. In addition, service-to-service requests, both authorized and unauthorized, should also be tested. The use cases selected for testing should reflect those which most closely mirror how the organization’s users access the organization’s resources on a day-to-day basis. Ideally, the organization can create a suite of tests that it can use to validate the ZTA not only before deploying each new ZTA capability in the incremental rollout process, but also on a periodic basis once the ZTA rollout is considered complete.
Continuously improve and evolve due to changes in threat landscape, mission, technology, and regulations#
Once rolled out, the ZTA must continue to adapt to changing conditions. If technology components used in the ZTA are upgraded or obsoleted by their manufacturer, they should be replaced. If innovative new technologies become available, the organization should consider whether they could be integrated into the existing ZTA to take advantage of new defensive tactics, techniques, and procedures that might improve the organization’s security posture. If the organization’s security goals change, either as a result of a shifting mission or changes in regulations, the ZTA’s policies and the ZTA itself may need to evolve to best address these new goals.
In addition, the ZTA may need to adapt to a changing threat landscape. As new types of adversary attacks become known and prevalent, the ZTA will need to add the threat signatures for these attacks to the list of things it monitors for. Ideally the ZTA will also perform behavior-based monitoring that enables it to detect anomalies that may signal zero-day attacks for which threat signatures are not yet know. Behavior-based monitoring tools provide the ZTA with some degree of agility and readiness with respect to its ability to detect attacks by adversaries who are constantly changing their tactics and techniques. In any case, as the threat landscape changes, the organization’s CISO and security team need to continually assess the ZTA’s topology, components, and policies to ensure that they are best designed to address newly emerging threats. If the value of one or more of an organization’s resources increases substantially, the organization may want to change how that resource is protected by the ZTA, as well as what its access policies are.
As input to this ongoing process of validation and improvement, organizations should continuously monitor their network and other infrastructure and update policies, technologies, and network segmentation topologies to ensure that they remain effective. Creating a ZTA is not a one-time project but an ongoing process. The organization’s CISO or other security team members should perform ongoing validation of their ZTA access policies to ensure that they continue to be defined in a manner that supports the organization’s mission and business use cases while conforming with the principles of least privilege and separation of duties.