Table of contents

List of figures

List of tables

Overview

1 Introduction

1.1 What is zero trust and zero trust architecture?

• every interaction initiated between a user and a resource is strongly authenticated and authorized

• access control to resources is made as granular as possible

• access control decisions are based on a dynamic evaluation of the trust context for each access request

• Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.

1.2 ZT security approach

• assume that the connections to your network infrastructure and resources are always hostile

• assume that all network traffic and requests to access your resources may be malicious

• assume that an adversarial actor will attempt to eavesdrop on communications and data flow

• implement thorough logging and monitoring of access requests, system management, configuration changes and network traffic to measure the integrity and security posture of all assets

• authenticate and explicitly verify and authorize each request for access to the least privilege and ensure that access that has been granted is time-bound

• make access control decisions based on dynamic risk-based policies

• accept that granting access to sensitive resources will increase your risk of cyber threats

• have an incident response and recovery plan in place that will ensure damage control and business continuity

2 Industry accepted ZT frameworks

• ensure that the GC continues to support a resilient enterprise digital security ecosystem in which government services are delivered safely and securely

• provide a seamless and enhanced user experience for authorized users

• provide a secure platform that ensures protection of systems and data hosted

• (physical and virtual) within the converged GC’s network environment

• offer end-to-end protection of the GC’s information, applications, devices, network, hardware, and physical facilities

• develop, adopt, and enforce mature security processes, governance structure, and standards

• ensure the confidentiality, integrity, and availability of the GC’s information technology (IT) infrastructure and the government’s critical business and customer data

3 Benefits of a ZT security framework

1. Provides greater network and lateral movement protection
• We often hear of attacks that involve a compromised user account or device being used as an entry point to an organization’s network. With most security controls being on the boundary of organizations’ networks, it’s difficult to detect an attacker if they successfully breach that first layer of defence. Once in, the attacker will then progress laterally in the network to gain access to credentials or other sensitive information. With a ZT approach, all applications and services can only communicate once they have been authenticated. ZT reduces the risk of lateral movement because all communication, regardless of its origin is considered untrusted until authenticated and specific access has been granted.
• In a ZT model, every action a user or device takes is subject to some form of policy decision. This allows the organization to verify every attempt to access data or resources, making it challenging for an attacker to break the system.

2. Provides greater visibility and improved monitoring
• The ZT security approach requires organizations to register and maintain compliance on all devices accessing information and resources on the network. It also requires that every user go through a stringent authentication process to gain access to specific resources. This provides visibility on who accesses what resources and for what purpose and can help identify what security measures need to be applied to each resource. ZT requires ongoing monitoring of all activities and communications. This allows organizations to gain full visibility into their network traffic and better detect potential threats and respond to them in a timely manner.

3. Improves incident detection and response
• ZT offers new capabilities for incident response as detailed information is available about all suspicious access requests and which user, device, data, and application were involved. With ZT, when an incident is discovered, it can be linked back to specific entities, applications, and data.

4. Improves access control over cloud
• Access control and loss of visibility are organizations’ greatest worry when moving to the cloud. Although cloud service providers (CSP) offer some security features, the protection of your organization’s assets remains a shared responsibility between you and the CSP. You have limited control inside the cloud.
• ZT requires that all assets on the cloud be classified so that the right protections and access controls can be selected and implemented. With ZT, you can ensure that everything attempting to connect to your organization’s cloud infrastructure is legitimate.

5. Improves data protection
• Traditionally, if your network perimeter (such as a firewall) has been breached the attacker can leverage lateral movement to potentially find and steal sensitive information, customer data or intellectual property. This can damage an organization’s reputation and potentially lead to legal repercussions. By shifting the focus from perimeter defence to securing individual resources, organizations face reduced risks of data breaches and theft.
• Strong authentication and validation of connections under ZT principles makes it possible to ensure data privacy. ZT follows the principle of least privilege, granting only access required by the user to do their work. For each connection request, every entity is assumed to be hostile until both users and devices are authenticated, and permission assessed. The granted access is continually reassessed as the state changes, such as the user's location or the data being accessed.

6. Help support continuous compliance and facilitate auditing
• A ZT architecture also helps support continuous compliance with privacy standards and regulations by evaluating and logging every access request. Tracking the user’s and application’s identity when requesting access, as well as the time and location of when the requests are made, allows for a complete audit trail. As a result, minimal effort is required to comply with audits and to uphold governance.

7. Secures the remote workforce
• One of the biggest challenges organizations face today is the rapid shift to a remote working ecosystem. With users working remotely and data being shared, perimeter defences like firewalls are no longer sufficient. Each remote and hybrid worker expands the attack surface and creates new gateways for attackers. With ZT, segmentation of the network and creation of micro-perimeters with stringent identification and validation policies, control is provided as to which user, device, and application have access to the secured zones.

4 Best practices for implementing a ZTA

1. Authenticate all connections
• Never trust your local network. In traditional architectures, any network connection that originates from inside the perimeter is considered trusted. It’s assumed that the user or activity on the network has already been authenticated and authorized. Instead of implicitly trusting network connections that logically originate from your local network, all connections should be properly authenticated before being allowed to connect. At a minimum, authenticate the user and device requesting access. When more stringent security measures are required, add the geolocation, the date, and the time to the authentication requirements. With ZT, you should build trust into the devices, users, and services operating within your network.

2. Implement ZT policies
• Creating and implementing policies is one of the most important and labour-intensive steps needed to build a strong ZTA. It requires that organizations truly understand all areas that need to be protected and the level of protection that needs to be applied to secure traffic flow.
• When developing and implementing ZT policies, start by answering the following questions:
• Who are the users?
• What do they need to access?
• Why do they need access?
• Where do they need access from?
• Where are the users and endpoints located that are requesting access?
• How is access being granted and approved?

3. Establish a “trust engine”
• A trust engine is used to evaluate trust and subsequently allow or deny access based on the collection and assessment of a wide variety of attributes relevant to the security context of an access request. This can include:
• the security state of the devices involved in the request (software versions, patch levels, physical and logical location, date and time, monitoring status, observed access history, etc.)
• the behavioural attributes of the requester (usage patterns, time-of-day, etc.)
• the enterprise-level attributes that represent the current security context (e.g., heightened security state based on monitoring and event indicators)
• The centrepiece of ZT is a dynamic “trust engine” that has global visibility across all levels of architecture and that incorporates feeds from key components of operational security. This trust engine will take time and effort to develop.

4. Know your assets and network architecture
• When building a ZT architecture, it’s important to know your assets and network architecture. Create an inventory of your data, users, devices, and applications being accessed on your network. Know how you will be controlling and managing the access requests and what potential compromises might occur if access is granted. Understanding the value of your organizational data and the risks associated to any compromise of this data is paramount in implementing any significant changes to your architecture and IT environment.

5. Use multi-factor authentication (MFA)
• With MFA, two or more different authentication factors are needed to unlock a device or sign-in to an account. MFA uses combinations of the following factors to authenticate a user: something you have, something you know, or something you are. These factors can and should be adjusted depending on the sensitivity of the data and resources being accessed. MFA significantly reduces the chance that attackers can use compromised credentials to access your systems and data. It’s an essential prerequisite of ZT.

6. Use encryption for all traffic
• ZT requires the encryption of all traffic to reinforce the ZT tenet that all access to resources must be explicitly granted. This is contrary to the traditional perimeter defence model where access is inherently provided. Encryption helps with data loss prevention as files “leaked” or “stolen” are unusable without the ability to decrypt. For this same reason, encrypting helps protect the information end-to-end and helps with data “sniffing”.

7. Enforce policy-based access
• Organizations need to develop dynamic risk-based policies and make sure they are enforced correctly. These policies are a set of access rules that are assigned to users, data, assets, applications, and services. Resource access permission policies will vary based on the sensitivity of the resource. Least privilege principles should be applied to restrict both visibility and accessibility.
• With ZT, the implied trust based on the network location (IP address) is no longer a condition for authentication. Instead, identity-based authentication is used to establish trust and provide access to specific resources at a given time and from a specific location or device.

8. Use privileged access management (PAM) and secure administrative workstation (SAW)
• PAM should be used to protect all admin accounts that require elevated privileges. When high-level administrative access is required, it should be granted in a manner referred to as “just-in-time” access. This means temporary access is granted and then revoked as soon as the task is done and access is no longer required. Before anyone is allowed a privileged access session, the request for this session should have been reviewed and granted by a different user. This prevents someone from self-granting privileged access without proper approval.
• PAM solutions can automate this approval process as well as record everything that was done during the privileged access session and save that information.
• A SAW, which is a dedicated physical or virtual machine, should be used by administrators strictly to perform administrative tasks. These secured workstations provide added security for IT administrators working with servers and applications to carryout sensitive tasks that pose a higher risk if compromised. The dedicated workstation cannot be used for web browsing, email, and other risky applications.
• The PAM works together with secure administrative workstation solutions. Users must log into the SAW through the PAM to access protected accounts. A PAM platform can be leveraged to secure and control all access to privileged accounts, including individualized access permissions, the assigned access time, and the allowable actions.

9. Implement the principle of least privilege, RBAC and ABAC
• In a ZT environment, it’s important to apply the principle of least privilege in as many areas as possible, especially around privileged access and management of security. ZT is based on the principle that a user should only be given just enough access to allow them to complete a particular task. RBAC can be implemented to enforce least privilege in a codified manner, as it maps user access rights to their role within the organization. Combining RBAC with PAM will further enhance the control of access within your organization.
• With ABAC, attributes, at the granular level, are defined to determine which user can access the data. For ABAC, access control policies are based on rules around the characteristics or properties of each requester and every data point is checked to ensure that the attributes match the requester’s permissions before being released.

10. Monitor and log devices and services access
• Continuously monitor how devices and services are interacting, what is being requested, what activities are performed, and what data is accessed. The continuous collection of log data and the use of security analytics to flag anomalies for investigation will help identify suspicious activity to detect and stop attacks. A properly implemented security information and event management (SIEM) solution will make collecting, correlating, and investigating large amounts of data easier and faster for administrators. SIEM can offer the level of visibility that is needed to ensure that users connected to the network are trustworthy, an essential part of a ZT strategy.

11. Manage all devices
• Verifying your users is necessary but not sufficient. The principles of ZT also extend to endpoint devices. To ensure that only trusted devices are allowed on your network, start by establishing a unique, traceable identity for each. These identities offer visibility on your network and will expose untrusted devices. The identities you create for devices are necessary to authenticate permissions and access, according to the policies you define. The defined policies should cover device certification, configuration, and compliance. Device certificates can help with inventory control as well as authentication. They should be encrypted and password protected so that they cannot be easily used if leaked.
• The operating system and applications that run on the device should be properly configured, securely provisioned, and kept up to date. The access control system should be in place to ensure that all policy controls are in effect before the information/data is accessed. Access should be modified if a security feature is not up to the level required by compliance.
• Organizations should consider the use of a trusted platform module (TPM). A TPM, a secure cryptographic integrated circuit (IC), is a hardware-based approach to authenticate a device. It securely stores artifacts, such as passwords, certificates, and encrypted keys, to manage device and user authentication, network access, and data protection. TPMs are used in modern personal computers (PCs), electronic notebooks, mobile phones, and network equipment.
• BYOD policies and the use of mobile devices for work have become common in today’s modern workforce. With ZT, all devices must be individually authenticated before gaining access to the organization’s resources and data. This offers greater control over BYOD environments. It allows IT administrators to set and enforce granular authorization and authentication policies to determine what is required for a device to be allowed to access its resources.

12. Use network segmentation or micro-segmentation
• Network segmentation is one of the potential approaches that could be used when implementing a ZTA. It’s the practice of creating sub-networks within the overall network to prevent attackers from moving laterally once inside the perimeter. Typically, companies build network segments via virtual local area networks (VLANs) and firewalls, subnets, and security zones.
• Micro-segmentation logically divides the data centres and cloud environments into distinct security segments up to the individual workload level. It relies heavily on the use of managed policy enforcement points throughout the network to dynamically control the communication between components based on policy. This is done to protect sensitive data and services from both internal and external threats. It provides layered security and allows for restricted access to assets on a granular level. This ensures that even if an attacker does enter the network, the amount of damage they can cause is limited.

13. Use software-defined perimeter (SDP)
• SDP can support many of the ZT concepts and principles. This includes fine-grained, least privilege access control for all access requests, encryption of data in transit, micro segmentation, and so on. It offers an alternative to virtual private networks (VPN) and secure remote access to any application, located anywhere. It’s a network boundary that is based on software, not hardware. SDPs are built on an adaptive trust model where access is granted based on user identities and least privilege basis defined by granular ZT policies and principles, not IP addresses. This allows remote users to connect to application without giving them network access which reduces the attack surface.

5 Challenges to organizations

• identify their network’s most critical and valuable data, assets, applications, and services

• know who their users are, which applications and services they are accessing, their geolocation and how they are connecting

• Technicians and administrators across organizations will need to increase their efforts to define and implement detailed attributes of every user and resource to support trust/access decisions.

• Users might become frustrated at having to use multi-factor authentication (MFA) and needing to authenticate themselves more often during their work.

• Devices will require hardware tokens which can be costly and require time to rollout across an organization. There will be an increase in cost for software, hardware, and training.

• Firewalls may be older and not support some of the dynamic functionality required. Phased plans for introducing new equipment must be balanced with cost considerations.

• Technical resources for implementing ZT model may be scarce.

6 Additional zero trust guidelines

6.1 NIST special publication 800-207: Zero Trust Architecture

1. Every data source and computing service is considered a resource
• Any file, data, digital asset, and all types of endpoints that contain company information and communicate with the network must be considered a resource.

2. All communication is secured regardless of the network location
• In ZT, the network is always considered hostile. Appropriate security controls should be implemented to protect the confidentiality, integrity, and availability of data in transit. All access requests from assets must meet the same stringent security requirements for authentication regardless of where the requests originated from. The assets may be located on enterprise-owned network infrastructure or any external network. The same security verifications standards must apply to all. Trust can never be implicit.

3. Access to individual enterprise resources is granted on a per-session basis
• In an ideal ZT architecture, access to a particular resource (file, data, digital asset) is contingent upon authentication and authorization and is time bound. The access granted should be on the principle of least privilege and is given only to a single resource. Attempts to access other resources will require reauthorization using other explicit verification rules. Organization administrators will need to identify how to enforce access policies on individual resources and how the multilayers of authentication will occur for each access request.

4. Access is provided based on a dynamic risk-based policy
• Access to a resource is not a static concept. An authorized user can still be denied access to a particular resource if there is reason to believe that the access request is suspicious and does not meet policy.
• Access to resources is determined by dynamic policy. Those authorized to access the resource must still authenticate themselves and prove they meet the enterprise policy to be granted the session. They must do so by incorporating some combination of:
• state of client identity (including application, service, username, password, etc.)
• asset status (IP address, networks accessed, software version, patch level, geolocation, updates installed)
• other analytics-driven criteria (geolocation, past request patterns)

5. All assets, both internal and external, are continuously monitored and their integrity and security posture are measured
• No asset is inherently trusted, every network and device is always vulnerable to attack. Organizations should have a robust monitoring and reporting system so that they are able to continuously evaluate the security posture of the asset when a specific request is received against that asset. Organizations should implement mitigation techniques and apply patches and fixes when needed.

6. All resource authentication and authorization are dynamic and strictly enforced before granting access
• Your organization should check explicitly every time that a user attempts to access a resource. Scanning and assessing threats, and continually re-evaluating trust must be an ongoing process. An organization must have identity credentials, access management, and asset management in place.
• Implementing MFA along with continuous monitoring is required to ensure that reauthentication and reauthorization occur as defined by security polices.

7. As much information as possible is collected about the current state of assets, network infrastructure, and communications to improve the organization’s security posture
• Organizations should collect as much information as possible about the current state of the network and communications to help improve the security posture of their overall architecture. Insights provided by this information will allow your organization to continuously learn and improve its security settings and policies to reduce risk and enforce proactive protection.

6.2 CISA: Zero Trust Maturity Model

1. Identity: Organizations need to implement technologies that continuously assess identity to then provide or deny access. Identity verification and authentication should be based on the access request and, if access is granted, it should be time bound and limited to the specific resource requested.

2. Device: The term “device” includes any hardware asset that can connect to a network, including Internet of things (IoT) devices, mobile phones, laptops, servers, and others. An inventory of all connected devices should be logged, and continuous compliance monitoring and validation of devices’ security posture should be conducted. It’s critical to not only ensure the integrity of these devices but also that of the users operating them.

3. Network environment: A network environment is an open communication system that ties users together and allows for data sharing. These communication channels, both internal and external, need to be controlled, segmented, and protected based on their unique requirements. Organization’s need to avoid traditional perimeter-defence models, like firewalls, and focus on access control, continuous authentication, encryption, and risk assessment.

4. Application workload: An application workload consists of agency systems, computer programs, and services that are executed both on-premises and in the cloud environment. All applications should undergo rigorous empirical testing during the development and deployment process to ensure threat protection. The principle of least privilege (PoLP) should be enforced throughout the application’s lifecycle.

5. Data: Data across devices, networks, applications, and cloud must be protected against threats. Inventory of this data should be taken continuously with robust tagging, categorizing, and tracking.

• Traditional: Manual configurations and assignment of attributes, static security policies, pillar-level solutions with coarse dependencies on external systems, least-function established at provisioning, proprietary and inflexible pillars of policy enforcement, manual incident response and mitigation deployment.

• Advanced: Some cross-pillar coordination, centralized visibility, centralized identity control, policy enforcement based on cross-pillar inputs and outputs, some incident response to pre-defined mitigations, increased detail in dependencies with external systems, some least-privilege changes based on posture assessments.

• Optimal: Fully automated assigning of attributes to assets and resources, dynamic policies based on automated and observed triggers, assets have self-enumerating dependencies for dynamic least-privilege access (within thresholds), alignment with open standards for cross-pillar interoperability, centralized visibility with historian functionality for point-in-time recollection of state.

Table 1: CISA’s high-level ZT maturity model

6.3 NCSC: Zero trust architecture design principles

1. Know your architecture, including users, devices, services, and data
• The first step in developing a ZT architecture is to identify all your assets and each component of your architecture including your users, devices, and the services and data that they are accessing. This will allow you to identify where your key resources are, where your data is being stored and their level of sensitivity. Knowing this information will help you develop effective and appropriate access policies that will protect your valuable resources.

2. Know your user, service, and device identities
• Identify the identity of all users, services, or devices in your architecture. This is important when deciding who or what will be granted access to data or resources.

3. Assess your user behaviour, devices, and services health
• It’s imperative to continuously monitor the behaviour of services or devices to identify anomalies. This is an important indicator of their security state. Using the appropriate security tools to measure user behaviour, device and service health is key in a ZT architecture. It helps evaluate the confidence in their trustworthiness.

4. Use policies to authorize requests
• Each request for data or services should be authorized against a policy. The power of a ZT architecture comes from the access policies you define.

5. Authenticate and authorize everywhere
• Authentication and authorization decisions should consider multiple signals, such as device location, device health, user identity and status to evaluate the risk associated with the access request. You should always assume the network is hostile and want to ensure all connections that access your data or services are authenticated and authorized.

6. Focus your monitoring on users, devices, and services
• In a ZT architecture, monitoring is focused on users’ behaviour, devices and services and will help you to establish their cyber health. You should know what actions devices, users and services are performing and what data they are accessing. Your monitoring should link back to the policies you have set, verifying they are being enforced as you expect.

7. Don't trust any network, including your own
• Don't trust any network between the device and the service it's accessing, including the local network. Communications over a network, to access data or services, should use a secure transport protocol to gain assurance that your traffic is protected in transit and less susceptible to threats.

8. Choose services designed for ZT
• Services may not support ZT and thus may require additional resources to integrate and increase support overhead. In these scenarios it may be prudent to consider alternative products and services that have been designed with ZT in mind.

7 Summary

8 Supporting content

8.1 List of abbreviations

8.2 Glossary