Preparing for a Zero Trust Initiative-1

Preparing for a Zero Trust Initiative-1

A Zero Trust security model when implemented by an organization reduces external and internal threats to systems and data. Preparing for a Zero Trust initiative is paradigm shifting for organizations that are migrating to the Cloud and/or transforming legacy network based controls for Authentication (AuthN) and Authorization (AuthZ). This course prepares you to be successful by presenting foundational principles, threat scenarios, reference architectures, and a policy governance framework that can be applied to reduce risk.

Introduction

We explore and learn the fundamental concepts of the zero trust security model and how to enable a governance framework that is supported by technical reference architectures. The course consists of three modules:

1. Foundations in Zero Trust Architecture
2. Creating a Zero Trust Strategy
3. Implementing Zero Trust Architectures

Each module progressively imparts knowledge that can be applied to real-world organizational environments. In doing so, we build the skills necessary to be successful at controlling and reducing external and internal threats to organizational systems and data.

By the end of this course, you will be able to do the following:

C1

Relate zero trust architecture (ZTA) principles, concepts, and cases.

C2

Apply knowledge of zero trust architecture (ZTA) principles to the creation of an organizational strategy.

C3

Connect candidate reference architectures and design patterns.

Foundations in Zero Trust Architecture

Module Overview

Relate zero trust architecture (ZTA) principles, concepts, and cases.

In this module, you will gain an understanding of zero trust principles and concepts as they apply to networks and applications. You will learn how to make use of the concepts and extend them in understanding the components of a zero trust architecture. You will also learn the benefits of using a zero trust architecture to cloud digital transformation projects.

L1.1

Define zero trust architecture.

L1.2

Explain the importance of government standards and industry perspectives when preparing for a zero trust initiative.

L1.3

Discover how a zero trust architecture initiative can contribute to overall organizational risk reduction.

Principles

Learning Objective L1.1

Zero trust is a concept that is a response to network trends in which perimeter defenses are changing to allow remote users, work-from-home users, bring your own device (BYOD) users, and hybrid cloud-based assets access to organizational assets. Organizations today are challenged in protecting resources (e.g., device assets, application services, business workflows, networks, and user accounts).

The traditional boundaries of the network perimeter are changing in fact, they are dissolving. The zero trust concept changes how organizations have relied on network access controls. Zero trust centralizes access controls into a new policy-as-code framework that is applied to each data or resource access request. When effectively deployed, an organization’s risk from data breaches, ransomware, and insider threats is lowered.

The foundational principle of zero trust is that trust is not implicit, it must always be granted to a user or a system when accessing organizational resources or data. Often this is expressed as “trust no user or device.” Other defining principles of zero trust are the following:

• Every digital asset is a resource (i.e., hardware, datasets, and applications).
• Access to resources is controlled (i.e., authenticated and authorized) on a per-connection basis.
• Communication channels are secure by default.
• Access to resources is determined by a policy that is dynamic in nature. User identity and/or device hardware fingerprinting are taken into account.
• All resource authentication is dynamic and strictly enforced before access is authorized.
• All hardware connecting to resources is controlled by the organization.

Zero trust assumes that no implicit trust is granted to assets or user accounts based solely on their physical or network location (i.e., the Internet or local area networks) or based on asset ownership (organization or personally owned). When zero trust principles are applied to network architectures and applications, we can effectively control authorization and authentication risks. That design is referred to as a zero trust architecture.

Traditional Network Access Model Versus Zero Trust Architecture

In contrast to a traditional network model, Diagram 1.1 illustrates how zero trust can be applied to a network architecture. The key components, authentication (AuthN) and authorization (AuthZ), both of a user and their device, are discrete functions that are performed before a session is established to an organizational resource.

Adopting a zero trust architecture that is secure by design will control modern and dynamic threats that organizations face, but it requires the following:

• Coordinated and aggressive system monitoring, system management, and defensive operations capabilities.
• Assuming all requests for critical resources and all network traffic may be malicious.
• Assuming all devices and infrastructure may be compromised.
• Accepting that all access approvals to critical resources incur risk, and being prepared to perform rapid damage assessment, control, and recovery operations.

Zero Trust Architecture Components

The IT architecture of most organizations is increasing in complexity, particularly with many organizations hosting a mix of both in-office and remote employees. Because of this complexity, there has been an increase in the use of zero trust. In essence, Zero trust centers on the belief that all network traffic and systems cannot be trusted until someone allows access.

According to NIST, “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.”

There are multiple variations and zero trust architecture approaches, but the basic relationship between the core components and their interactions can be reviewed below.

Digital Transformation

Much like other kinds of digital transformations, implementing zero trust isn’t a plug-and-play solution to fix the shortcomings of current cybersecurity practices. It is a total commitment to a process that alters an organization’s structure, especially when transforming applications and services to be cloud-based.

In any cloud transformation project, there is an opportunity to reduce cybersecurity risk by applying the guiding principles of zero trust:

• Never trust, always verify: Treat every user, device, application, and data flow as untrusted. Authenticate and explicitly authorize each to the least privilege required using dynamic security policies.
• Operate under the assumption of a data breach: Consciously operate and defend resources with the assumption that an adversary already has a presence within an organization. Deny by default. Heavily scrutinize all users, devices, data flows, and requests for access. Log, inspect, and continuously monitor all configuration changes, resource accesses, and network traffic for suspicious activity.
• Verify explicitly: Access to all resources should be conducted in a consistent and secure manner using multiple attributes (dynamic and static) to derive confidence levels for contextual access decisions to resources.

Identify Standards and Requirements

Learning Objective L1.2

Interestingly enough, many of today’s international cybersecurity standards contain requirements that, when taken together as a whole, contribute to supporting the security of a network and enforcing the principle of least privilege.

The United States National Institute of Standards and Technology (NIST) has been the leader in the development of a national standard for zero trust architectures (e.g., see NIST Special Publication (SP) 800-207 Zero Trust Framework). Notably, NIST describes zero trust as a cybersecurity paradigm focused on resource protection and the premise that trust is never granted implicitly but must be continually evaluated.

Additionally, NIST adds, there is a distinction to be drawn between zero trust and zero trust architecture. Zero trust provides a collection of concepts and ideas designed to reduce the uncertainty in enforcing accurate, per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture, on the other hand, is an organization’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. A holistic view of zero trust security is further defined by NIST as the network infrastructure (physical and virtual) and operational policies that are in place for an organization as a product of a zero trust architecture plan.

It’s here that a new paradigm in cybersecurity thinking emerges: zero trust. In essence, a zero trust approach to security assumes that every network is breached, every machine is compromised, and every user is at risk.

As more organizations move toward using a cloud-native architecture (e.g., microservices, containers, orchestration), they come to the realization that their security controls are also changing. They are moving from being perimeter based to also being cloud native. The firewall is dead, and zero trust architecture is here to replace it.

Zero trust is a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgement that threats exist both inside and outside traditional network boundaries. The zero trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information fed from multiple sources to determine access and other system responses. The zero trust security model assumes that a breach is inevitable or has likely already occurred, so it constantly limits access to only what is needed and looks for anomalous or malicious activity.

Zero trust embeds comprehensive security monitoring; granular risk-based access controls; and system security automation in a coordinated manner throughout all aspects of the infrastructure in order to focus on protecting critical assets (data) in real time within a dynamic threat environment. This data-centric security model allows the concept of least-privileged access to be applied for every access decision, allowing or denying access to resources based on the combination of several contextual factors. Systems that are designed using zero trust principles should be better positioned to address existing threats, but transitioning to such a system requires careful planning to avoid weakening the security posture along the way.

Illustrate Design Patterns

When examining the logical components of a zero trust network we can begin to understand what is required to build an architecture and the data that is needed to feed into a policy engine to make access determinations. Notably, existing technologies can be easily adapted into refining and building a variety of zero trust architectures. Some of these design patterns include the following:

• Using a device agent or gateway model
• Using a resource portal for each separate business function (see Diagram 1.3)
• Using application or device sandboxing
• Using micro-segmentation to build a zero trust network
• Using software-defined perimeters and network infrastructure
• Using enclave-based deployment

The diagram below outlines the most common case, the Data Resource Access Model.

Understanding Threats

Learning Objective L1.3

No organization can eliminate cybersecurity risk. However, when complemented with existing: cybersecurity policies; standards; guidelines; identity and access management; and a continuous monitoring program, a properly implemented and maintained zero trust architecture can reduce overall risk and protect against common threats. That said, some threats have unique features when implementing a zero trust architecture.

Subversion of the Zero Trust Architecture Decision Process

In a zero trust architecture, the policy engine and policy administrator are the key components. No communication between organization resources occurs unless it is approved configured by the policy engine (PE) and policy administrator (PA). This means that these components must be properly configured and maintained. Any organization administrator with configuration access to the PE’s rules may be able to perform unapproved changes or make mistakes that can disrupt organizational operations. Likewise, a compromised PA could allow access to resources that would otherwise not be approved (e.g., to a compromised personally owned device). Mitigating associated risks means the PE and PA components must be properly configured and monitored, and any configuration changes must be logged and subject to audit.

Denial-of-Service or Network Disruption

In a zero trust architecture, the policy administrator (PA) is the key component for resource access. Organization resources cannot connect to each other without the PA’s permission and, possibly, configuration action. If an attacker disrupts or denies access to the policy enforcement point (PEP) or the PA using a distributed denial-of-service (DDoS) attack it can adversely impact organizational operations. Organizations can mitigate this threat by having the PEP reside in a micro-segmented network. This mitigates the risk of a DDoS attack, but does not eliminate it. Botnets produce massive DDoS attacks against key Internet service providers and disrupt service to millions of Internet users. It is also possible that an attacker could intercept and block traffic to a PEP or PA from a portion of or the entire set of user accounts within an organization. In such cases, only a portion of the organization’s subjects is affected.

A hosting provider may also accidentally take a cloud-based PE or PA offline. Cloud services have experienced disruptions in the past, both infrastructure as a service (IaaS) and software as a service (SaaS). An operational error could prevent an entire organization from functioning if the PE or PA component becomes inaccessible from the network.

Stolen Credentials / Insider Threat

Properly implemented zero trust policies combined with, resiliency policies reduce the risk of malicious actors gaining broad access via stolen credentials or even against insider abuse. The zero trust principle of “no implicit trust based on network location” means attackers need to compromise an existing account or device to gain a foothold in an organization. A properly developed and implemented zero trust architecture should prevent a compromised account or asset from accessing resources outside its normal access patterns.

Attackers may use phishing, social engineering, or a combination of attacks to obtain credentials of valuable accounts. Valuable may mean different things based on the attacker’s motivation. For instance, organization administrator accounts may be valuable, but attackers interested in financial gain may consider accounts that have access to financial or payment resources of equal value. Implementation of multi-factor authentication for access requests may reduce the risk of information loss from a compromised account; however, an attacker with valid credentials (or a malicious insider) may still be able to access resources for which the account has been granted access.

A zero trust architecture reduces risk and prevents any compromised accounts or assets from moving laterally throughout the network. If the compromised credentials are not authorized to access a particular resource, they will continue to be denied access to that resource. In addition, a contextual trust algorithm is more likely to detect and respond quickly to this attack than an attack occurring in a legacy, perimeter-based network. A contextual trust algorithm can detect access patterns that are out of the normal behavior and deny the compromised account or insider threat access to sensitive resources.

Visibility on the Network

All traffic is inspected and logged on the network and analyzed to identify and react to potential attacks against the organization; however, it’s possible that the majority of the traffic on the organization’s network may not be visible to network analysis tools. This is because network traffic may originate from non-organizational-owned assets (e.g., contracted services that use the organization’s infrastructure to access the Internet) or applications or services that are resistant to passive monitoring.

Organizations that cannot perform deep packet inspection or examine the encrypted traffic must use other methods to assess a possible attacker on the network. This situation does not mean that the organization is unable to analyze encrypted traffic that it sees on the network. The organization can collect metadata (e.g., source and destination addresses) about the encrypted traffic and use that to detect an active attacker or possible malware communicating on the network. Machine learning techniques can be used to analyze traffic that cannot be decrypted and examined. Employing this type of machine learning would allow the organization to categorize traffic as valid or possibly malicious and subject to remediation.

Defining Architectural Components

The core components of a zero trust architecture start with defining the data control plane and the data plane for an organization’s network. NIST calls the model a “conceptual ideal,” but it’s worth remembering that all of the elements illustrated are necessary for a zero trust architecture to be effective at controlling risk by making access decisions in real time.

To better understand how an ideal zero trust network works, it can be helpful to break it down into how the core elements work together. As illustrated in Diagram 1.4, starting with the policy enforcement point (PEP) at the center, we can observe that the policy engine (PE) supplies the PEP with accurate up-to-date dynamic rules to apply when traffic requests are made to or from the Internet and business partners. Traffic can either be granted or denied to organizational resources based upon the rules.

As we have learned previously, the PE can use external system data sources to influence access determinations that then get programmatically applied as security policies - these are effectively policy rules in code. Notably, the complex process of feeding the policy administrator data sources happens in near real time allowing for the PE to update rules that are applied by PEPs.

Analyzing Access Control Policies

Here we begin to explore the policy constructs and strategy shifts needed for the successful implementation of zero trust within an organization. For an organization with a zero trust architecture deployment, the PE can be thought of as the brain and the PE’s trust algorithm as its primary thought process. The PE, we learned, takes input from multiple sources to make access decisions on users and devices. The trust algorithm ultimately grants or denies access to a data resource or business asset.

Let's now focus on the policy engine internals and how it takes input from various data sources in the access decision rules creation. These inputs can be broken into categories based on what they provide to the trust algorithm.

Threat intelligence

This is an information feed about cyber threats and active malware operating on the Internet. This could also include specific information about communication seen from the device that may be suspect (such as queries for possible malware command and control nodes).

Known system defects

An asset and vulnerability database contains the known status of each organizationally owned and any non-organizationally owned asset that requests access to resources. Depending on the asset state compared with this database, access to other resources may be restricted or denied.

PKI and identity and access management user database

This is the “who” that is requesting access to an organizational resource. The “who” can be a set of users (commonly referred to as “subjects), which could be either human or system processes.

Asset database (and observable status)

This is the database that contains the known status of each enterprise-owned asset (and possibly known, non-enterprise/BYOD asset), asset (both physical and virtual, to some extent). Depending on the asset state compared with this database, access to other assets resources might be restricted or denied.

Resource requirements

This set of policies complements the user ID and attributes database and defines the minimal requirements for access to a resource. Requirements may include multi-factor authentication, network location, and requests for configuration updates.

Subjects and attributes form the basis of policies for resource access. The identities can include a mix of logical identity and results of authentication checks performed by policy enforcement points. Attributes of identity that can be factored into deriving the confidence level include time and geolocation. A collection of privileges given to multiple subjects could be thought of as a role, but privileges should be assigned to a subject on an independent basis and not simply because they may fit into a particular role in the organization. The identity and access management system should also maintain a log of subjects' behavior for input into the PE trust algorithm.

Creating a Zero Trust Strategy

Module Overview

Course Objective C2
Apply knowledge of zero trust architecture principles to the creation of an organizational strategy.

In this module, we dive deeper into zero trust principles by illustrating how organizational risk and attack vectors inform the creation of strategy, policy, and architecture. We illustrate several threat scenarios where a zero trust architecture effectively stops malicious Internet actors and insider threats. We explore what is needed to inform the policy engine and the policy enforcement points and finally, develop a list of requirements that can be used when evaluating zero trust software providers.

Learning Objectives

L2.1

Apply zero trust architecture principles to reducing an organization’s attack surface.

L2.2

Integrate zero trust requirements and practices when creating organizational policies and standards.

L2.3

Analyze the effectiveness of zero trust architecture policy and design patterns.

Perimeter Risk Management

Learning Objective L2.1

Managing the risks associated with a zero trust perimeter security model is multi-dimensional. We need to control how users, devices, systems, and processes interact with business data, and then effectively manage the associated risks.

The zero trust decision engine examines the users, devices, and access requests and then compares that to the security policy for the data or resource being requested. It then makes a risk-informed decision on whether to allow access and sends a log entry of that access request and decision to be part of future suspicious-activity analytics. This process is conducted for every individual access request to each sensitive resource and can be repeated periodically during extended access to a resource.

Zero Trust Architecture Case Studies in Threat Management

Risk of User and Device Access

No organization can eliminate cybersecurity risk. When complemented with existing cybersecurity policies and guidance, identity and access management, and continuous monitoring, however, a properly implemented and maintained zero trust architecture can reduce overall cyber risk and protect against common threats. A zero trust architecture deployment involves developing access policies around acceptable risk to the designated mission or business process. Often that risk can be visualized as network traffic, which can be set to always deny by default. Another way to think about a zero trust architecture is the formulation and implementation of firewall rules, both for IPv4 and IPv6, as control points at each resource. Still another analogy is to think of a zero trust agent listening and acting as a proxy on each resource, and always communicating back to the policy engine.

Zero Trust From a User Perspective

User provisioning is a key component of zero trust architectures; however, nothing obvious occurs in a zero trust architecture that would make it feel any different to existing security mechanisms. The security model is intentionally made transparent. The policy engine determines if data requests or connections are authorized for every organizational resource that is protected in the architecture. Access decisions are based upon intelligence sources to inform a policy administrator, who then creates rules that are implemented in the policy engine to make a security decision. These decisions can be to grant access, block it, or revoke access.

Zero Trust — The Human Risk Element

The core components of a zero trust architecture (i.e., the policy engine, policy administrator, and policy enforcement point systems) rely heavily upon humans to specify and control the inputs that make access decisions. It is this reliance upon “administrators” that presents a significant risk to zero trust deployments.. Minimizing human interaction through automation, system-to-system APIs, and privileged credential management will minimize the risk.

Diagram 2.1: Zero Trust Risk Maturity Model

Capability Maturity Model Integration (CMMI) Maturity Levels

Building a Governance Framework

Learning Objective L2.2

A zero trust architecture makes use of the concept of “enhanced identity governance.” This approach uses the identity of users as the key component of policy creation. If it were not for users requesting access to enterprise resources, there would be no need to create access policies. For this approach, enterprise resource access policies are based on identity and assigned attributes.

Defining Policy Requirements

The primary requirement for resource access is based on the access privileges granted to the given user—often users are also referred to as “subjects.” Other factors such as device used, asset status, and environmental factors may alter the final confidence level calculation (and ultimate access authorization) or tailor the result in some way, such as granting only partial access to a given data source based on network location. Individual resources or policy enforcement point components protecting the resource must have a way to forward requests to a policy engine service or to authenticate the subject and approve the request before granting access.

Enhanced identity governance-based approaches for enterprises are often found using an open network model or an enterprise network with visitor access or frequent non-enterprise devices on the network. Network access is initially granted to all assets with access to resources that are restricted to identities with the appropriate access privileges. The identity-driven approach works well with the resource portal model since device identity and status provide secondary support data to access decisions. Other models work as well, depending on policies in place.

A policy administrator will be responsible for defining the following as inputs into the policy engine:

• Role-Based Access Controls (Least Privilege) Enforcement Rules
• Information Access and Sharing Rules
• Identity (user/device) Registration Rules
• Identity Provider Single Sign-on Rules
• Identity Federation Rules (when applicable)
• Device Configuration Management Rules
• Asset Inventory Rules
• Endpoint Security Rules
• Network Segmentation Rules (both macro and micro)
• Privileged Access Management Rules
• Third-Party Data Sharing Rules
• Audit Rules
• Threat Management Rules

Zero Trust Vendor Selection Considerations

When selecting vendors to provide either technical services or software, the following technical considerations should be made.

First, identify the key drivers for the initiative:

• Regulatory/Industry compliance (e.g., PCI DSS, GDPR, CCPA).
• Reduction of insider threats.
• Breach prevention.
• Security or data protection.
• Reduction of endpoint and security threats.
• Response to audit or security incident.

Second, prioritize your mission goals:

• Have trust earned through device verification.
• Facilitate least-privilege access.
• Have continuous authentication and authorization.
• Have a centralized, granular access policy.
• Segregate applications and resources.
• Have end-to-end access visibility and auditing.
• Promote data protection (e.g., secure transmission and storage).

Effectiveness of Zero Trust Architecture Policy and Design Patterns

Learning Objective L2.3

Thinking about the effectiveness of a zero trust architecture, we can distill the elements down to a list where we can measure their effectiveness. This is valuable when an organization’s internal audit functions need to review the performance of a zero trust architecture against a policy standard.

Component	Zero Trust Capability
Authentication System	The explicit ability to verify the identity of a process or device.
Authorization System	The ability to grant or deny device access to data, assets, applications, or services by a policy enforcement point.
Privileged Access Management	The ability to secure, control, and manage privileged access to critical assets and applications.
Software-Defined Perimeter or Networking	The ability to provision and control network components using code.
Device Compliance	The ability to validate that policy engine decisions are enforced on device endpoints.
Network Segmentation	Network traffic can be segmented at either the macro or micro level depending upon the organization’s application and data resources.
Data Loss Prevention Systems	The ability to inspect network traffic and application-based traffic and apply rules to allow or deny it. This capability works in tandem with the policy engine.
Security Information and Event Management Systems	A security information and event management system provides network and application traffic visibility and supports the notion of continuous monitoring and reporting on the success and failure of the enforcement of policy engine rules.

Table 1.0: Zero Trust Security Objectives

Zero Trust Architectural Components Checklist

Here is a checklist for evaluating the effectiveness of zero trust architecture components.

Zero Trust Architecture Components Checklist

• Implemented data loss prevention systems.
• Improved identity and access management.
• Enabled mobile device management.
• Enhanced wide-area network security functions.
• Improved vulnerability remediation.
• Simplified secure access delivery.
• SSL deep packet inspection.
• Improved mobile/desktop/application device threat protection.