Zero trust is gaining ground as a go-to strategy to build a more secure environment for breach prevention. In a worldwide survey of 2,767 security professionals and executive leaders published in March 2022, Statista found that 30% have a formal strategy and are actively following a zero-trust policy, and 27% are planning and researching to develop a zero-trust strategy.
A factor has been the expanding embrace of cloud transformation, remote working, and BYOD, which has shifted employees outside of traditionally defined organizational perimeters and shifted the focus to users and identities. But is an identity-centric approach enough to ensure the success of a zero-trust strategy? The answer is an emphatic no. After all, "zero trust" means exactly what it says. As such, the concept of zero trust focuses on securing authentication and authorization mechanisms on a per-transaction basis across devices, networks, applications, and data with cross-cutting capabilities. Transaction-based modalities are what allow a zero-trust organization to enforce least-privilege access.
Architectural Patterns
A zero-trust architecture (ZTA) requires constant analysis to find weaknesses and determine where to reinforce its capabilities. Before we talk about ZTA characteristics, though, we will touch briefly upon the core components that enable zero trust. These are:
- Policy engine (PE): The PE can be considered the brains behind ZTA deployments, deciding whether or not to grant a subject access to a given resource. The PE uses organizational policies/rules and external sources, such as threat feeds, as inputs to arrive at these grant/deny decisions.
- Policy administrator (PA): While the PE acts as decision maker, the PA works as an intermediary in executing the decision. The PA acts as a communication path between the subject and the resource to which the subject is requesting access. Some zero-trust implementations may treat PE and PA as parts of a single service. In these implementations, the PA communicates with the policy enforcement point (PEP; see below) to create the communication path via the control plane.
- PEP: The PEP is responsible for executing the grant/deny decisions—as well as enabling, monitoring, and eventually terminating connections between subjects and resources. The PEP also interacts with the PA to send access requests to the PE and/or receive policy updates.
Each of these represent logical functions, though not necessarily discrete physical components. For example, as mentioned above, the PE and PA can be combined into a single service.
When it comes to reference architectures for zero trust, no one size fits all. Three common reference-architecture approaches for zero trust are:
- Enhanced identity governance
- Micro-segmentation
- Software-defined perimeters
Enhanced Identity Governance
Enhanced identity governance represents the simplest approach to zero trust. It uses the identity of the subjects as the key component in policy creation. Access policies are based upon user identity and device fingerprinting.
Micro-Segmentation
With micro-segmentation, resources are protected by software agents and/or gateway appliances. Implementation is based on individuals or groups of resources on a network segment that is protected by gateway-security components—such as intelligent switches or next-generation firewalls (NGFWs). These gateways act as PEPs to enforce authentication and authorization.
Software-Defined Perimeters
Software-defined perimeters can be implemented either at the network layer or the application layer of an OS stack. In this approach, the PA component acts as a network controller that initially sets up and reconfigures the network based on the rules or policies of the PE. When this approach is implemented at the application layer, the agent-gateway pair act as a PEP to control access between the subject/client and the resource.
Migration and Implementation
Migration to a ZTA is not just the replacement of infrastructure; it is a cultural change in how the organizational assets are inventoried and maintained. This becomes the foundation to the implementation of ZTA. Each business process is evaluated, and zero-trust principles are incrementally implemented until the appropriate risk-tolerance levels are reached. This will involve multiple cross-functional stakeholders—each with their own business needs and risk-tolerance levels.
Be it a greenfield implementation of ZTA or the migration of an existing infrastructure to ZTA, the zero-trust strategy depends on the current security posture of the organization. In both cases, assets, subjects, resources, business processes, data flows, and their respective dependencies must be identified and mapped. This will help in identifying the list of assets and business processes that are potential candidates for ZTA implementation.
Migration Step 1: Discovery
Begin with discovery of network components, core business applications, network traffic, subjects, service accounts, and any other possible physical or virtual assets. A lack of complete details of these assets will lead to business-process failures (such as the slowdown experienced through authentication or authorization requests) due to incomplete information available to the PE.
Migration Step 2: Assessment
Once a detailed inventory of the assets is available, perform a threat-modeling exercise. Assess the PE rules and enforcement policies. Stakeholders should inform the criteria under which a resource access can be granted or denied. Identify the potential candidate for the ZTA and formulate policies for the PEP.
Migration Step 3: Initial Deployment
Choose the architecture that best suits the needs of the organization. Start with system interactions. Implement the logical components (PA, PE, and PEP). Modify the PA and PEP to reflect the new rules and policies. It is preferable to start with low-risk business processes because these will pose minimal risk to the organization as the transition to ZTA begins.
Migration Step 4: Operations Monitoring
The deployment should be continuously monitored to understand the communication patterns and to establish a baseline. Once a baseline activity pattern is established, anomalous activities can be easily identified—and, from there, enforcement policies can be further refined. If a change occurs to the already-implemented business process, such as the creation of new user accounts or the addition of a new device, the zero-trust implementation needs to be re-evaluated.
Migration Step 5: Expand the ZTA footprint
Once enough confidence is achieved in the initial deployment, proceed to implementing the rest of the business processes with logging and monitoring in place.
The design and components of the chosen architecture can be adapted based upon organizational risk tolerances.
In the end, any zero-trust implementation should ensure that:
- Policy enforcement works across hybrid environments, and is applied universally to all assets independently
- The solution is compliant with organizational policies and government/industry standards.
Keep learning
Get up to speed on Zero Trust security with TechBeacon's Guide.
Understand why API security needs access management with this Webinar.
Learn how how privilege and policy management improves your cyber resiliency in this Webinar.
Find out why Zero Trust means rethinking your security approach.
Answer this question: Is your environment adaptive enough for Zero Trust? Get this free white paper.
