In this chapter, you will learn about the following:
Zero trust and functional pillars
Elements of zero trust policy
Tools and technologies for zero trust deployment
Greenfield versus brownfield zero trust network deployment
In today’s risky and uncertain times, organizations need to build a solid foundation for reliable and adaptable security operations. This could be achieved by building zero trust in their IT systems. The zero trust framework operates on the principle of “never trust, always verify.” Unlike traditional security approaches that rely on a strong perimeter (like firewalls) to protect a trusted internal network, zero trust assumes that threats can originate both inside and outside the organization. Therefore, every request, user, or device must be authenticated and authorized, regardless of its location within or outside the network. It is important to understand the functional pillars of zero trust before any organization starts deploying it. You will need a variety of tools and platforms to deploy zero trust in your organization. Your zero trust approach must be able to perform the following four functions:
Establish Trust: Ensure the system can verify each user and device connecting to the network.
Enforce Trust-Based Access: The system should be able to enforce policies and grant access to the users and devices based on the trust level. The policies should be applied based on the principle of least privilege. The access mechanism should protect all network resources, including applications and data, on-premises and in the cloud.
Verify Trust: The system should be able to continuously verify the trust and dynamically adjust the access to the network. It should not be a time check and then access is allowed for a longer duration or to multiple applications.
Enforce Policies and Monitor: The system should be able to react to changes in trust by analyzing and coordinating responses to potential incidents while gaining better visibility into suspicious activities related to trust levels. A continuous refinement of trust policies is required.
An organization needs to protect all its assets irrespective of their location. Some assets could be mobile-like users and devices, and others like applications, and stationary databases could either be on-premises or hosted in the cloud. The zero trust approach should consider various factors, such as user type, location, device type, data requested, and application accessed, to create robust dynamic policy-based access controls. Some of the common assets you want to protect in your organization include (but are not limited to)
Users
Devices
Network
Cloud
Applications
Data
A common question arises: Where to start, and how can you define the steps toward a zero trust framework adoption?
In the rest of this chapter, you will learn the iterative approach that could be adopted for securing trusted access for users and devices based on the four primary functional requirements of zero trust as covered in this section. We will first look at the key decision points to establish the overall zero trust strategy that includes establishing trust for users and devices, application access, and policy enforcement. Next, we will look at the common tools and technologies to help you deploy zero trust, and finally, we will look at the approach for zero trust adoption in greenfield and brownfield scenarios.
Elements of Zero Trust Strategy Definitions
In this section, we will look at the key considerations that you will need to formulate the zero trust deployment policy. These considerations include
Establishing user trust
Establishing device trust
Defining application access policies
Enforcing policies
Establishing Trust
A trust level represents the degree of confidence you have that a user or device is who or what they claim to be and that they are authorized to access specific resources. Unlike older models, where access is granted based on location (inside vs. outside the network), trust levels in zero trust are dynamic and can change based on several factors. Trust levels can be assigned to users and devices.
User Trust Level: Based on the identity of the person accessing the network
Device Trust Level: Based on the security status of the device accessing the network
The first functional requirement of zero trust is to establish trust for users and devices. This requirement could be divided into two categories: users and devices. Let’s look at both of them in detail.
User Trust Definition
The purpose of defining user trust is to verify the user’s trust and enforce the principle of least privilege. You need to start evaluating what mechanisms and processes are there in your organization to authenticate and authorize the users before they can access the resources. But wait, which users? There could be different types of users having different privilege access. To start, do the following:
Identify the user types and roles (employees, including contractors, temporary users, and guests).
Associate the risk with each user type, based on their function and type of data they need to access.
Identify the assets that need to be accessed by these user groups.
Identify the location of assets each group needs to access—on-premises, cloud, DMZ, and so on.
Following these steps, you will get a matrix that shows the user group and their need to access, which type of information, and where that information is stored. As a next step, you need to define the trust level for each user type based on the authentication and authorization system in place or planned. You can start evaluating as follows:
How does an employee need to be authenticated and authorized?
How does a partner need to be authenticated and authorized?
Can you deploy multifactor authentication (MFA)? If yes, which applications are critical?
Is biometric-based passwordless authentication required?
How often is the MFA required, and what reauthentication triggers need to be deployed?
Do you have a secure identity database for the full type or contract employees?
Once you have evaluated the responses to the questions, you will then need to devise a policy, plan, and then deploy the solution that allows strong authentication and authorization of the users before they can access any information. User trust can be verified using different methods and actions such as:
Multifactor Authentication (MFA): Ensure users verify their identity through multiple factors (something they know, have, or are)—for instance, a password combined with a mobile authentication app or biometric verification.
Role-Based Access Control (RBAC): Grant users access only based on their roles, ensuring they can access the minimum necessary resources.
Contextual Authentication: Authenticate based on context (time of access, location, device type) to provide a more secure, tailored approach.
Just-in-Time Access: Ensure that users get access only when they need it and that it’s revoked immediately after their session ends, minimizing the risk of lingering access.
User Behavior Analytics (UBA): Monitor user activity in real time, including access patterns and application usage. Anomalies (e.g., accessing data from an unusual location or time) trigger additional authentication steps or even block access.
Dynamic Risk Scoring: Assign risk scores to users based on behavior, device posture, and external factors (e.g., suspicious login attempts). Trust levels adjust dynamically based on these scores.
For a greenfield scenario (described more fully later in this chapter), it is easy to plan, design, and implement first. Users are then onboarded to a well-defined and secure environment. But in a brownfield environment, you might face challenges such as users being hesitant to adopt new methods of authentication. Some workflows might need to be interrupted to adopt a new user identity verification system. To overcome some of these challenges, you must do the following:
Prepare clear communication and messaging for the need for change.
To avoid any hiccups due to technical glitches, ensure that all systems are tested. You can start the pilot with a small group and data set as identified in the matrix.
Device Trust Definition
Defining device trust means ensuring that a device is safe and authorized to access the network. You must never assume that any device is safe because it is inside the network or is company-owned. Especially with BYOD policies, employees are now allowed to bring their own devices to work. Such devices need to be secured and segmented properly. Ensuring devices accessing your network are in a healthy state is a critical step for zero trust deployment. You can start by doing the following:
Evaluate the type of the company’s own assets, such as model, make, and operating systems.
Rank devices based on the risk and data sensitivity.
Create a list of technologies that can be used for device trust such as virtual private network (VPN), mobile device management (MDM), and certificates.
Create a strategy based on supported devices and their capabilities such that each device can be continuously authenticated.
It is important to understand the difference between a company-owned asset and company-managed asset. A company-owned asset is owned, managed, and fully controlled by the organization, whereas a company-managed-only device typically includes BYOD devices that an employee can purchase but are managed by the company. This is typically done by enrolling devices in an MDM system that defines the security policy and configuration for the device such as certificate requirements or password lengths. You can even wipe an entire device remotely if an employee reports it as stolen. Access to further applications and resources could be constrained for such devices. Because managed devices are tracked, enrolled in configuration and patch management programs, and continuously monitored for security incidents, the trust level for such devices is always higher than for unmanaged personal devices. As such, your zero trust policy usually allows Internet-only access for unmanaged personal devices. We have discussed managed and unmanaged devices, but how do you bring a device under management? You can use a combination of solutions such as
Certificate-Based Trust: In zero trust, every device must prove itself before accessing any resource. Using certificate-based trust, a device proves its identity by showing its digital certificate. Even if the device is already inside the network, it must keep proving its trustworthiness every time it tries to access new resources or data.
Device Health: It is important to ensure that a device is healthy before it can be allowed on the company’s network. Even a company-managed device with a certificate installed can get infected. It is important to use device posture as one of the device trust points. Validating if the endpoint security agent is installed to protect against the threats helps in establishing trust.
Device trust further strengthens the security because now an attacker needs not only a valid user credential but also a trusted device to launch any attack. A combination of trusted users with trusted devices is commonly used as part of the zero trust policy definition to provide different levels of access. Typical components you will require for device trust include
PKI Infrastructure: PKI (Public Key Infrastructure) is a framework that manages digital certificates and encryption keys to enable secure communication and authentication over networks. In zero trust PKI is used to issue device certificates. These issued certificates will be used for identifying all company-managed assets, including company-owned or BYOD assets.
Security Agents: A variety of tools can be installed on company-owned assets, such as endpoint agents, VPN, VPNless remote access, and device posture agents. For BYOD, an MDM solution could be used.
Central Inventory: It is important to have a central inventory of all devices in your network with proper asset tags, owners, type of access required, and so on.
One common challenge with device trust is the hesitation of users to install any agent or certificate on their devices due to privacy concerns. This requires careful validation based on the local laws, so the organization must use a solution to verify the trust without violating privacy. As an example, monitoring the website that a user visits on a BYOD could be considered a privacy issue, while suggesting a stronger login password with a specific key length could be considered a genuine safety measure.
With user and device trust policies established, you now know who can access the network using which types of devices. We have covered a high-level approach, but you need to go multiple levels down to establish detailed policies, tools, procedures, and ways to track the user and device trust. Once you have done this, the next step is to enable access to the application by framing policies that a combination of users and devices can access.
Trust Score Calculation
Trust levels can be represented as scores or risk levels based on multiple factors. Here’s a simple breakdown of how they might be calculated.
Each factor gets a score, and the total score determines the user/device trust level:
Base Trust for User Credentials (e.g., MFA or SSO): 50 points
Device Security (e.g., fully patched, antivirus running): 30 points
Geolocation (known/unknown location): 10 points
Time of Access (normal/abnormal): 10 points
If all conditions are met, the trust score would be 100. A lower score (below a set threshold, e.g., 70) might trigger additional security actions, like reauthentication or restricted access.
Instead of adding points, you can subtract trust based on risk indicators. For instance:
Base Trust: Start at 70.
Subtract 40 if the user uses only a password (no MFA).
Subtract 20 if the device is missing recent patches.
Subtract 10 for unrecognized geolocation.
Once a trust score or risk level is assigned, the system decides how much access to grant and whether any additional actions are needed:
High Trust Score (90–100): Full access to the system, no extra verification needed.
Medium Trust Score (70–89): Limited access, or additional verification required like MFA.
Low Trust Score (Below 70): Deny access or allow access only to less-sensitive resources.
Defining Application Access Policies
The entire idea of establishing trust for users and devices is to allow them access to business applications in a secure way. This ensures that even after the user and device are verified, they get access only to specific applications they need. One of the important considerations you need to make is where the application and data are hosted, such as public or private cloud, on-premises, or SaaS applications. You will need to devise the policies for different data sets and applications based on how often they are accessed, keeping in mind the user experience you want to provide. Following are some of the decision points for creating policy around application access:
A comprehensive list of applications used in the organization, both internal and external, should include cloud-based, on-premises, and hybrid applications.
It is also important to identify the application dependencies like interactions with databases, other services, and APIs. This information will come in handy while building the microsegmentation.
What user types need to access the application? We covered this step from a user authentication perspective earlier in the user trust definition, but now you need to map the application in detail, along with the frequency at which different user groups typically access any applications, and rank the risk of the applications.
Policies also need to consider device type and location of user groups concerning the application accessed. Do you want to reauthorize or have stricter controls when users try to access the service from a location that is different from their regular location? If your entire workforce is mobile, then your strategy needs to include the fact that random location is normal behavior. In such a case, frequent location-based reauthorization may result in poor user experience. You may want to club the common application sets and allow access based on single sign-on (SSO).
The SSO-based approach is essential because users often forget passwords for multiple applications. When many applications are involved, users may resort to using the same password for all. Here, SSO provides a centralized enforcement point, allowing the establishment of policies on password length and change frequency. It is advisable to implement multifactor authentication with biometrics alongside SSO.
Access policies should align with user and device trust levels. Trust depends on contextual factors like location, time, and behavior, necessitating continuous monitoring even for authorized access. For example, if a terminated employee quickly downloads multiple files, this could indicate potential malicious intent. Such behavior should trigger alerts or adjust access per established protocols. This strict approach reflects a zero trust framework, which emphasizes that no one is inherently trusted. Ongoing supervision and adaptive policies are vital to enforce zero trust principles.
Macro- and microsegmentation form the basis of the zero trust network access, as you will learn later in this book. From an application perspective, it is also critical that segmentation considers the following constructs:
Application-Level Segmentation: Isolate applications from one another so that a compromise in one doesn’t lead to a breach in others. This involves defining granular policies for inter-application communication and blocking unnecessary pathways.
Data and API Segmentation: Segregate databases, APIs, and other backend services from applications and users that don’t require direct access.
Environment Segmentation: Separate development, testing, and production environments to ensure that an issue or breach in one environment doesn’t spread to others.
It is also important to think about securing the data in motion. When the authorized user groups access specific applications, it must be secure. Following are some of the approaches you may consider:
Transport Layer Security (TLS): Ensure that all traffic between users and applications is encrypted using TLS, preventing interception by attackers.
End-to-End Encryption: For sensitive applications, ensure that data is encrypted at rest and in transit, especially when communicating with external services or across untrusted networks.
API Security: Use API gateways and API security tools to secure communications between applications, especially in cloud environments where APIs are frequently exposed.
Enforcing Policies
With the details gathered so far, now you have a clear understanding of the users, devices, and applications in your environment. It is time to think about how to enforce these policies, monitor the users, and continuously refine them. Because there is a complex matrix of users, devices, and applications, it is important to set a baseline and expand from there. This means a base trust with the users and devices is based on certain factors like
If the user is seen for the first time
Which factors are used to authenticate and authorize the users
If there are signs of malicious activities
If the device is managed; if yes, company-owned or BYOD?
Device posture details
If these basic checks pass, you can assign the base trust-level policies that allow access to the common and less risky applications. You can then add further levels of trust confirmation for the highly sensitive user and application combination. This means that with base trust users can access common applications such as email and Microsoft Office. For example, if the user login happens at the usual time, using the known devices with an attempt to access the regular applications, the decision engine could assign a high trust level with no additional authorization steps required. This will also help you define trust tolerance, as explained later in this chapter.
Granular policies and secondary trust verification are required to access critical assets, including code or financial information. At this point, you also need to decide what actions or changes will result in a loss of trust—for example, a change in hardware. A real-time decision engine is typically used for adaptive access.
Contextual information from the users needs to be collected, stored, and then analyzed to continuously evolve the policies. Advanced AI/ML-based analysis engines could be deployed for this behavior analysis. The information base must have information from events, as described in the following subsections.
Contextual Data
User roles and devices change over time. Employees might change their role for various reasons, such as changing teams or getting a promotion. As a result, the location to access the information also changes. Device type, operating system, and applications used might also change. It is important to collect all this information.
Connection Metadata
It is important to collect user role information and device details at the time of login. User roles could easily be collected from the active directory group memberships, and device details can be collected during posture assessment. Operating system version, installation of mandatory endpoint solutions, device status (e.g., if jailbroken)—all must be collected and stored for further analysis. This also allows you to have a central inventory of all the devices in one place with their security state. This information, when combined with the user information, provides insights into the compliance status of teams and individuals. Necessary actions can be taken if noncompliance is related to a specific group or team.
Logging Suspicious Actions
As you established the baseline trust earlier, it is also important to create the baseline behavior of the users within that trust level. Any deviation from the baseline needs to be recorded and analyzed, and immediate action should be taken. Continuous failed attempts at authorization, use of unsupported platforms to access resources (like jailbroken devices), and attempts to access resources with different user credentials from the same device must all trigger alerts, and immediate action needs to be taken based on company security policies. Additional authorization using MFA, device quarantines, and reduced trust level with each event like this are some of the many actions you can take in these cases. Detailed analysis will help you identify the repeat offenders (intentional or unintentional). AI-based predictive analysis could be used once sufficient data points are available, to help prevent the attacks, reduce the attack surface, and create a self-healing network. Details on self-healing and maturity levels are covered in the later chapters.
Trust Tolerance
Trust tolerance is the degree of flexibility in the zero trust model. While the fundamental principle is “never trust, always verify,” trust tolerance allows for different levels of stringency depending on various factors like the sensitivity of the resource, user context, or current security posture of the device. It answers the question: “How much risk are we willing to accept for this specific access?”
High Sensitivity (Low Trust Tolerance): When a user is accessing critical systems (e.g., financial records, confidential data), there is minimal tolerance for risk. Trust levels must be high, and any small deviation (like accessing from a new location or using a noncompliant device) should trigger additional security measures or block access.
Low Sensitivity (Higher Trust Tolerance): When a user is accessing less critical resources (e.g., internal HR portals or general information), the system can tolerate more variations in trust. For instance, accessing from an unfamiliar device might still be allowed, but with more monitoring.
In zero trust, you will create a dynamic trust tolerance, which adjusts based on the current risk environment. A user trust value could be very high at the time of initial login and authentication. However, as the user tries to access different applications, the trust level can erode based on that user’s behavior. Every organization needs to devise policies that reflect its trust tolerance. Threshold-based dynamic access policies need to be defined. If the trust level of a user is maintained, the sessions and access levels could be extended by a predefined time. In that case of trust falling below a certain threshold, the user needs to be reauthorized before access to the existing or new applications can be granted.
Several tools can help organizations manage trust tolerance within a zero trust architecture:
Identity and access management (IAM) tools like Okta or Microsoft Azure Active Directory allow for context-based access policies that adjust trust levels dynamically.
Security information and event management (SIEM) solutions like Cisco Splunk or Elastic Stack help monitor security events and adjust trust tolerance based on real-time risk factors.
Endpoint detection and response (EDR) solutions like Cisco Secure Endpoint or CrowdStrike provide continuous monitoring of device security, adjusting trust tolerance based on device posture.
By this point, you must have a clear understanding of the overall approach and key decision points to develop a zero trust policy by defining clear objectives around user and device trust, application access, and policy definition requirements. In the next section, we will explore various tools and technologies that help you achieve these outcomes.