1.1 Objective

The subject of this Snapshot document is the specification of the Zero Trust Commandments Standard.

This document is intended to make public the direction and thinking about the path we are taking in the development of the Zero Trust Commandments Standard. We invite your feedback and guidance. To provide feedback on this Snapshot document, please send comments by email to ogspecs-snapshot-feedback@opengroup.org no later than July 31, 2024.

1.2 Overview

This document presents a proposal for a standard that defines Zero Trust and the Zero Trust Commandments, a set of requirements that can be used to support building  Zero Trust frameworks and solutions.

The Zero Trust Commandments in this document are presented together as high-level statements on a single page (see Chapter 3) before being presented as imperative requirements in the form of “shall” statements with supporting and explanatory points beneath each Commandment. These supporting points are all “must” statements.

Critical context for the Zero Trust Commandments is provided in the following sections, including definitions and explanations of “Zero Trust” and “Zero Trust Architecture” as well as the drivers, requirements, and objectives for Zero Trust and foundational content that underpins all the Commandments.

1.3 Conformance

This is a Snapshot document, not an approved standard. Do not specify or claim conformance to it.

1.4 Normative References

None.

1.5 Terminology

For the purposes of this document, the following terminology definitions apply:

Can Describes a possible feature or behavior available to the user or application.

May Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.

Must Describes a feature or behavior that supports “shall” statements.

Shall Describes a feature or behavior that is a requirement. To avoid ambiguity, do not use “must” as an alternative to “shall”.

Shall not Describes a feature or behavior that is an absolute prohibition.

Should Describes a feature or behavior that is recommended but not required.

Will Same meaning as “shall”; “shall” is the preferred term.

1.6 Future Directions

This document is intended to be the foundation for future publications of The Open Group Zero Trust Architecture (ZTA). These future publications include:

• A Zero Trust Reference Model, to describe the core capabilities, architectural building blocks, and governance, risk, and compliance considerations for Zero Trust
• A Practitioners Guide, to provide actionable steps for implementing Zero Trust
• A Business Guide, to provide guidance to senior and C-level executives on Zero Trust
• A Zero Trust Reference Architecture, to define Zero Trust capabilities and implementation and interoperability requirements and allow the contribution of Reference Implementations for different industries

Discussion of how to implement the Zero Trust Commandments by industry in an architecture will occur in future publications.

This document will also be aligned with the forthcoming Security Principles for Architecture Standard, ensuring the documents work together without contradiction or confusion.

For the purposes of this document, the terms and definitions in The Open Group Portfolio of Digital Open Standards – Glossary and Roles (Snapshot) [S222] apply. Merriam-Webster's Collegiate Dictionary[1] should be referenced for all other terms not defined in this section.

2.1 Zero Trust

1. (Noun) An asset-centric information security approach that enables organizations to secure and manage data/information, applications, Application Program Interfaces (APIs), and any data integrations on any network, including the cloud, internal networks, and public or untrusted (Zero Trust) networks.
2. (Adjective) A characteristic of an asset-centric information security approach that enables organizations to secure and manage data/information, applications, APIs, and any data integrations on any network, including the cloud, internal networks, and public or untrusted (Zero Trust) networks.

2.2 Zero Trust Architecture

The architectural implementation of a Zero Trust security strategy that follows well-defined and assured standards, technical patterns, and guidance for organizations.

2.3 Zero Trust Commandment

A requirement that represents a best practice for a Zero Trust Architecture (ZTA) and transformation that provides guardrails for all current and future decisions around implementing Zero Trust.

Table 1 provides summary definitions of the Zero Trust Commandments. The subsequent sections describe each Commandment in detail.

Table 1: Zero Trust Commandments – Summary

Practice Deliberate Security
Secure Assets by Risk	Security controls shall be designed to protect business assets appropriate to required security posture, business value, and associated risk.
Validate Trust Explicitly	Security assurance shall rely on explicitly validating trust decisions using all relevant available information and telemetry.
Support Business Objectives
Enable Modern Work	Security discipline shall enable productivity and manage risk as the organizational capabilities, goals, environment, and infrastructure continuously evolve.
Implement Asset-Centric Controls	Asset-specific security controls shall be implemented whenever available to minimize disruption of productivity, increase precision of security/business visibility, and improve data used to drive security compliance metrics.
Enable Sustainable Security	Security controls shall be sustainable across the full lifecycle of the business asset.
Develop a Security-Centric Culture
Practice Accountability	The entities responsible for accessing and handling assets shall be responsible for their protection and survival throughout their lifetime.
Enable Pervasive Security	Security discipline shall be explicitly included in the culture, norms, and processes throughout the organization.
Utilize Least Privilege	Access to systems and data shall be provided only as required, and access shall be removed when no longer required.
Deploy Simple Security	Security mechanisms shall be as simple as possible while retaining functionality and remaining pervasive, practicable, and scalable.
Deploy Agile and Adaptive Security
Make Informed Decisions	Security teams shall make decisions based on the best available information.
Improve and Evolve Security Controls	Security teams shall continuously evolve and improve to remain successful in an environment that constantly changes.
Utilize Defense in Depth	Security mechanisms and controls shall be layered to enhance resilience and preserve integrity.
Enable Resiliency	Security systems shall ensure the organization can operate normally under adverse conditions.

The subsequent sections in this chapter describe the Zero Trust Commandments in detail, and the following chapters provide supporting details. These Commandments may reflect current best practices and processes at their lower, more specific levels, which are provided with each Commandment, and it is the overall collection of these that results in Zero Trust. The Commandments are grouped according to the broader organizational goal they support.

Implementing these Commandments does not require organizations to “start over” with their practices and policies. Rather, organizations should identify which current practices help them meet their goals while building on and augmenting current practices and moving toward Zero Trust.

3.1 Practice Deliberate Security

3.1.1 Secure Assets by Organizational Risk

Security controls shall be designed to protect business assets appropriate to required security posture, business value, and associated risk.

1. Map Technology to Business – The organization must identify important business assets and translate them into the technical assets that compose them, including consideration of systems with direct administrative control.

2. Classify Information Assets – Organizations should classify mission-critical assets that drive certain business processes (e.g., for insurance companies, a business process can be life insurance, health, savings, retirements, etc.) essential to meeting end-client business objectives. The classification of assets will support arriving at Confidentiality, Integrity, and Availability (CIA) ratings.
3. Increase Security for Sensitive Assets – Security controls must match asset value and sensitivity to ensure the protection of high-value data and applications.
4. Reduce Unneeded Sensitivity – The organization must reduce asset sensitivity where possible to avoid wasting efforts of security and other teams (e.g., retire or replace unneeded sensitive assets, remove sensitive or regulated data with low-value tokens, etc.).
5. Stay Current – The organization must update security assurances for the asset (CIA, safety) as the asset use-cases, threats, and value change over time.

3.1.2 Validate Trust Explicitly

Security assurance shall rely on explicitly validating trust decisions using all relevant available information and telemetry.

1. Verify Access Control – The organization must validate user authentication strength, session context, and device integrity before allowing a user or device to access the organization’s assets (and continuously during each session if available).

2. Verify Application Development – The organization must define and follow secure development lifecycle processes and infrastructure as code [Microsoft® 2021],  and verify that they are followed.
3. Verify Technology Supply Chain – The organization must be able to verify (on-demand) the provenance and integrity (i.e., lack of counterfeiting or tainting) of technology components.
4. Verify Asset Configuration – The organization must be able to verify (on-demand) that operational deployment complies with the security control requirements established per platform.
5. Verify Incident Processes – The organization must be able to verify security and business continuity processes (e.g., ability to detect and respond to incidents, including restoring business operations).

3.2 Support Business Objectives

3.2.1 Enable the Organization’s Mission

Security discipline shall enable productivity and manage risk as the organizational capabilities, goals, environment, and infrastructure continuously evolve.

1. Enable Modern Work – People must be able to work on any network, in any location, with appropriate security assurances and access restrictions. People should have access to all applications required to do their jobs.

2. Align Security to Mission – Security strategy, success metrics, and policies must map directly to the organizational mission and business model or plan.
3. Align Security to Risk Management – The organization must measure and manage risk using its risk management framework and processes (thresholds, prioritization, stakeholders, etc.).
4. Align Security to Compliance Management – The organization must measure and manage compliance using the organization’s compliance assessment processes.

3.2.2 Implement Asset-Centric Controls

Asset-specific security controls shall be implemented whenever available to minimize disruption of productivity, increase precision of security/business visibility, and improve the data used to drive security compliance metrics.

1. Augment or Evolve Existing Infrastructure-Level Security Controls – In the event that there are existing infrastructure-level security controls, asset-specific security controls must embrace and extend them; in the event that infrastructure-level security controls do not exist, they must be created alongside asset-specific security controls.

2. Implement Data-Centric Controls – Data-centric security controls must enable appropriate protection for data in any location and on any network.
3. Implement Application-Centric Controls – Application-centric security controls must help ensure workloads are protected on any location (cloud, on-premises, or otherwise), including when attackers can access the corporate network. This may include controls on the application itself or application-aware infrastructure controls (identity, network, etc.) that focus on the context of the application, its users, and related context (sometimes called micro-segmentation).
4. Determine Trust beyond the Network – Broad network security controls (not application-centric) must be focused on proven use-cases, such as filtering basic Internet traffic, isolating networks with legacy applications or devices (e.g., Operational Technology (OT)), meeting regulatory requirements, and providing high-quality threat detections (e.g., high true positive rate). An asset is not necessarily secured because it is on a particular network, nor does it derive security or trust from that network, though network security controls can help protect an asset.

3.2.3 Enable Sustainable Security

Security controls shall be sustainable across the full lifecycle of the business asset.

1. Secure for the Full Lifecycle – Security programs and strategies must cover the full lifecycle of the business asset; this must include the application of the full security lifecycle (i.e., identify, protect, detect, respond, recover) over the course of the full asset lifecycle (i.e., create, maintain, upgrade, and decommission).

2. Provide End-to-End Data Security – Security governance must sustain security for the full lifecycle of the data, transaction, or relationship, including at rest, in processing, and in transit.
3. Ensure the Architecture is Coherent – Zero Trust security principles must be applied to all aspects of the architecture.
4. Ensure the Ongoing Monitoring of Security Controls – Security controls must be regularly updated, tested, and validated to ensure they remain valid against current threats, business requirements, and technical estate.
5. Continuously Manage All Assets – Systems must be continuously discovered and monitored to find systems that have been orphaned from management and maintenance processes, and to correct for this; the attestation process or function must take this into account.

3.3 Develop a Security-Centric Culture

3.3.1 Practice Accountability

The entities responsible for accessing and handling assets shall be responsible for their protection and survival throughout their lifetime.

1. Assign Asset Ownership – Assets must have clear owners who are responsible for them.

2. Ensure Understanding of Ownership – Asset owners must have a clear understanding of assets under their control, and the implications of failing to adequately protect them.
3. Define Security Impact Correctly – Security risk definitions must consider the systemic and infectious nature of security risk, where any attack can result in organization-wide risk.
4. Assign Security Risk to Organizational Leadership – Security risk represents organizational risk that must be managed, delegated, and accepted like any other risk; the security organization must act as subject matter experts to advise organizational leadership on security risk.
5. Assign Security Risk to Asset Owners – The organization must assign responsibility for mitigating security risk to business asset owners, like all other risks. Security teams must act as subject matter experts to advise asset owners on security risk.

3.3.2 Enable Pervasive Security

Security discipline shall be explicitly included in the culture, norms, and processes throughout the organization.

1. Integrate in Business Environment – The organization must integrate security context into business strategy, planning, operations, acquisition, contracting, and outsourcing.

2. Integrate in Technical Environment – The organization must integrate security controls into workflows, application and solution architectures, migrations to hybrid-cloud and cloud environments, new application development, Artificial Intelligence (AI) and Machine Learning (ML) projects, implementation of Agile practices, and other emerging technologies.
3. Incorporate Security Education and Awareness Training – The organization must regularly provide Zero Trust security education and awareness training for employees as well as partners, contractors, and suppliers as appropriate; the organization must also verify that relevant external personnel have equivalent training as appropriate.
4. Apply Security to the Organization's Ecosystem – The organization's security requirements must apply to the employees and assets of the organization and the full supply chain and value chain of the organization, including other entities (e.g., partners, contractors, suppliers, and sometimes customers). This should be done through all reasonable controls on a regular basis in a verifiable manner; associated non-compliance should be monitored, reported, and addressed appropriately.

3.3.3 Utilize Least Privilege

Access to systems and data shall be provided only as required, and access shall be removed when no longer required.

1. Grant Just Enough Access – The organization must limit access (for a person, in a session, etc.) to only the systems and data required to perform a task.

2. Grant Just-in-Time Access – The organization must provide access on-demand, as needed, and only with appropriate approval and validation.
3. Utilize Adaptive Access – The organization must adjust access permissions over the lifetime of the session in real time (as possible) and the lifetime of the account to prevent accumulation of unneeded privilege and unnecessary risk.

3.3.4 Deploy Simple (User-Friendly) Security

Security mechanisms shall be as simple and user-friendly as possible while retaining functionality and remaining pervasive, practicable, and scalable.

1. Simplify Human Experience – Security controls must minimize manual steps required and workflow disruption for business users and IT personnel, including providing self-service resolution where possible.

2. Simplify Security – The organization must favor automated controls and reporting for (non-)compliance, with security controls to enable security teams to execute at speed commensurate with the organization and to celebrate progress.
3. Provide Clarity – The organization must clearly define and document responsibilities, policy, control requirements, architectures, and aspirational visions to enable consistent security decision-making and implementation.
4. Configure before Customize – The organization must base security controls on accepted best practices implemented (incrementally or fully) within a reasonable time considering available resources – people, process, technology, time. To the degree possible, standardize on organization-wide platforms for IT and security to ensure consistent visibility, management, and control.
5. Enable Scalability – Security mechanisms must scale, from small objects to large objects.
6. Combine Building Blocks – To be both simple and scalable, interoperable security “building blocks” must be capable of being combined to provide the required security mechanisms.

3.4 Deploy Agile and Adaptive Security

3.4.1 Make Informed Decisions

Security teams shall make decisions based on the best available information.

1. Decide with Data – Security teams must use all applicable data to inform security decisions regarding access control, anomaly detection and investigation, risk assessment, planning, design, etc.

2. Constantly Gather Telemetry – Security teams must build and sustain a current and accurate understanding of the technical environment by continuously monitoring all assets (services, apps, identities, data, etc.) for insights and anomalous patterns.
3. Prioritize using Data – The organization must prioritize security investments based on risk analyses informed by current information on active threat actors, technical attack techniques (from the organization, industry peers, and other organizations), and potential organizational loss.
4. Combine Data with Human Wisdom – Security teams must minimize the impact of any decision bias by applying critical thinking and human experience to available data. Consider any differences between actual and expected outputs as learning opportunities to examine further.
5. Constantly Grow your Telemetry – Security teams must continuously seek new information sources as the organization’s business model, technical platforms, threats, and security capabilities emerge and evolve. Security teams must constantly increase visibility into known assets, discovery of expected assets, and discovery of new asset types.
6. Plan for the Future – Security teams must continuously monitor and adjust to current and future threats as they emerge, as well as new best practices, architectures, technologies, etc.

3.4.2 Improve and Evolve Security Controls

Security teams shall continuously evolve and improve to remain successful in an environment that constantly changes.

1. Consider People, Process, and Technology – Security teams must continuously improve all aspects of the security program, tooling, and skills, constantly monitoring and seeking and applying feedback.

2. Consider Business Evolution – Security teams must continuously adapt to evolving business drivers and models, preventing the creation of obstacles for business and/or mission success through either action or inaction.
3. Consider Technical Evolution – Security teams must continuously adapt to feature and product release and adoption cycles of technology.

3.4.3 Utilize Defense in Depth

Security mechanisms and controls shall be layered to enhance resilience and preserve integrity.

1. Ensure Independence – Security layers must be independent of each other.

2. Utilize Different Control Types – Security layers must comprise different types of controls, not multiple layers of the same type of controls.
3. Support Resiliency – Controls must be designed and layered deliberately to ensure that if one of the layers is breached, the others work together to protect the integrity of the system.
4. Ensure Diversity of controls – Security teams must ensure that defense in depth controls blend different control types (preventive, detective, rapid response) and different technologies (network, identity, app, etc.) to better protect against adaptive human attackers.

3.4.4 Enable Resiliency

Security systems shall ensure the organization can operate normally under adverse conditions.

1. Anticipate Attacks – Before a security incident, the organization must implement controls that limit the likelihood and magnitude of security incident impact on business operations.

2. Withstand Attacks – During a security incident, the organization must ensure organizational readiness to rapidly remediate the attack, limit the impact of the attack (i.e., minimize the blast radius), and ensure continuity of critical business operations.
3. Recover from Attacks – Before an attack, the organization must also ensure that data and associated security elements can be restored in case of technical or major failure; after a security incident, the organization must ensure all impacted business capabilities and services are rapidly restored to operational status.
4. Adapt to Adverse Conditions – The organization must ensure that lessons learned are continuously documented and integrated into designs and operations.

The world is transitioning to digital-first business models at an exponential rate. Digital Transformation[2] is a priority for many organizations. Threats and technologies are evolving at an ever-increasing pace, requiring agility and adaptability. This need for organizational agility and adaptability is further enhanced by geopolitical changes, disruptive events like the COVID-19 pandemic, the migration to remote work, ever-changing business models, and rapidly evolving relationships in an ecosystem in flux. For the organization, the new Digital Age is characterized by velocity, complexity, and disruption, with the goal of enabling better user experience through simplicity, speed, and scalability.

Traditional, perimeter-based approaches, built on legacy models of identity, authentication, and authorization, do not meet the security needs of a digital business environment because Threat Agents are constantly learning, and their attacks are becoming increasingly sophisticated. In this modern digital world with ever-evolving threats – such as phishing, social engineering, and particularly insider-threats – organizations must abandon the flawed assumption that networks, both internal and external, are secure. Moreover, the velocity and outside-in nature of a digital-first business model require an Agile approach to securing both partner and customer interactions. Organizations[3] must shift from traditional to modern models; Zero Trust approaches based on asset or data-centric security, policy-driven access controls, modern identity management, and secured zones. These solutions must be simple and cost-effective to develop, implement, transition to, operate, maintain, and evolve.

4.1 What is Zero Trust?

Zero Trust – an asset-centric information security approach that enables organizations to secure and manage data/information, applications, APIs, and any data integrations on any network, including the cloud, internal networks, and public or untrusted (Zero Trust) networks.

Zero Trust is implemented through a comprehensive strategy and provides a security framework based on asset or data-centric security, policy-driven controls, modern identity management, and security zones/domains. Zero Trust provides organizational flexibility, agility, and adaptability in addition to the traditional security assurances of confidentiality, integrity, and availability for business assets.

Zero Trust is achieved by leveraging a combination of existing investments and offering additional new capabilities.

Zero Trust Architecture (ZTA) – the architectural implementation of a Zero Trust security strategy that follows well-defined and assured standards, technical patterns, and guidance for organizations.

4.2 Why Move to Zero Trust?

A Zero Trust approach brings security to the users, data/information, applications, APIs, devices, networks, cloud, etc., wherever they are – instead of forcing them onto a “secure” network. In other words, Zero Trust shifts the perceived role of security restricting business to security enabling business.

Figure 1: Classic versus Zero Trust Approach

Zero Trust enables the continuous journey toward digitization and a digital business model, which will require several intermediate steps before an end state. A Zero Trust security architecture facilitates minimum disruption and greater agility through each intermediate step.

Zero Trust enables the rapid building of meaningful and sustainable security assurances for business assets and business processes in a modern, digitized environment. It secures business workflows from modern information security threats by securing data/information, applications, APIs, and devices regardless of what network they are on.

Fundamentally, Zero Trust enables organizations to grow and operate in the rapidly changing business models, technologies, regulatory mechanisms, and threats that are the hallmark of the digital enterprise.

Zero Trust is not a new silver bullet – many of its underlying concepts (such as de-perimeterization) build on learnings from the Jericho Forum,[4] which have been validated over time. These learnings describe the effective breakdown of the perimeter security model[5] in the 2006-2012 timeframe and the need for new security architectures with a focus on identity and data protection – two key tenets of Zero Trust.

Current technology and business environments have made ZTAs imperative.

4.3 How Significant is this Change?

Implementing Zero Trust will be a long-term, incremental, evolutionary journey that will leverage many existing security investments, building on and augmenting them as possible instead of replacing them (unless necessary). As an over-arching information security paradigm, it will cause cultural, strategic, and philosophical shifts to people, processes, and technology throughout organizations.

Zero Trust represents a change in a fundamental assumption (from a safe network to a hostile data and application environment) and its implementation will require changes throughout current practices for security, productivity, application development, IT operations, and more.

Implementing the Zero Trust Commandments will affect different parts of the organization differently:

• Business units will be able to more effectively operate in a compliant manner (whether internal or external) by removing artificial constraints to operating workflows, while enabling organizational agility and entry into new markets
• Security organizations, in particular, will undergo a substantial cultural and strategic shift, affecting nearly all aspects of their operations – this will be initially challenging, but will result in greater effectiveness, responsiveness, and ability to meet regulatory requirements
• Technology organizations will change the way they architect, build, and operate applications and infrastructure – this will be tied closely to any cloud and DevOps initiatives, which may already be in progress
• Governance, Risk, and Compliance (GRC) teams will need to embrace new standards and guidance to ensure that Zero Trust is integrated into the culture of their organizations

GRC teams will also need to consider existing and new contracts and the way they are written and governed.

Similar to securing physical assets in an unknown or potentially hostile physical environment (e.g., ATMs), Zero Trust ensures acceptable confidentiality, integrity, and availability assurances for intellectual property, data, and applications. Organizations will be able to reduce risk and enable agility by more seamlessly integrating security controls and architectures, thus limiting the impact of Threat Events and leading to greater resiliency and efficiency.

Zero Trust supports modern business scenarios by allowing organizations to move agilely and securely in a modern ecosystem of varying participants (including individuals and organizations), with relations in flux.

A Zero Trust Architecture (ZTA) enables organizations to proactively meet the drivers for the Digital Age. These drivers lead to the requirements and, therefore, the objectives of Zero Trust, as shown in Figure 2, Figure 3, and Figure 4, respectively.

5.1 Zero Trust Key Drivers

Figure 2 depicts the key drivers for Zero Trust, based on the observations and experience of the standard developers. This is not intended as a complete list, for organizations will have their own nuances, and traditional 5-force models [Porter 1979] can be used to determine and focus these drivers. However, in general, the standard developers have observed that most organizations engaged in Digital Evolution^[6] tend to apply one or (typically) more of these drivers to define their roadmaps.

Figure 2: Zero Trust Key Drivers

• Evolving Business Models:

—  Driven by changing business, regulatory, and technical environments

—  Evolution of digital as the single most disruptive element for organizations, and the biggest driver for Zero Trust

—  Outside-in business strategy emphasizing providing value to customers

—    Always-increasing speed of evolution of competition

• Evolving Threat Landscape:

—  Evolution of attackers, criminal business models, and attack techniques that increase the frequency and impact of cybersecurity incidents

• Emerging Partnerships:

—  Emerging partnerships, relationships, customers, supply chains, and organizational ecosystems; e.g., evolving integration of data and applications with partners

• Rapidly Changing Technology:

—  Cloud computing, often hybrid-cloud, and the adoption of Software as a Service (SaaS), serverless computing, edge computing, and microservices

—  Complex communication patterns; e.g., REST, file, streaming, message-oriented, event-driven

—  Artificial Intelligence (AI) and its variants; e.g., Robotic Process Automation (RPA), Machine Learning (ML), Natural Language Processing (NLP), Internet of Things (IoT), Industry 4.0

• Regulatory, Geopolitical, and Cultural Forces:

—  Evolving and often lagging regulatory requirements driven by geopolitical forces, cultural forces, and maturation of the Internet

—  Privacy policies, such as California Consumer Privacy Act (CCPA) and General Data Protection Regulation (GDPR), Chinese privacy laws

—  Impacts to organizations selling in multiple environments or operating across multiple jurisdictions

• Disruptive Events:

—  Events such as 9/11, 2008 Great Recession, or the COVID-19 pandemic

• Supporting Remote Work:

—  Shifting to remote work, driven by organizational intent and laws

—  Enabling mobility so that individuals can work or collaborate wherever they are

—  Support for families and improved employee productivity

5.2 Zero Trust Requirements

Figure 3 depicts what a ZTA needs to support, based on the observations and experience of the standard developers. As the organization works to meet these requirements existing processes and models will be disrupted due to the corresponding changes, which in turn allows defining objectives that must be supported by a modern information security architecture for the Digital Age.

Figure 3: Zero Trust Key Requirements

• Exponentially Increasing Need for Agility:

—  Business models are rapidly evolving and must include strategic and tactical planning

—  People organizations must plan for training and working with employees to adapt to continuous change and new capabilities

—  Both business and technology processes must be Agile and measurable

—  Technology decisions must consider the rapid rate of change and disruption from ever-evolving technologies

—  Risk assessments must be able to adapt to the continuous, rapid rate of change

• Increasing Complexity Requiring Increasing Need to Simplify:

—  New business models

—  Organizational ecosystems

—  Diverse communication patterns

—  Multiple and diverse data sources, with data becoming more critical for new technologies, such as AI

• Support for Remote Work:

—  Bring Your Own X (BYOX); e.g., device, application

—  Source networks of unknown security levels

• Regulatory Requirements:

—  New business and technology models driving new regulations, but often with delays between the new models and the new regulations

—  Rapid and unpredictable geopolitical changes

—  Local cultural or political changes expressed in jurisprudence (e.g., CCPA, GDPR)

• Support for Unpredictability:

—  Unpredictability driven by disruptive events; e.g., 9/11, 2008 Great Recession, Dodd-Frank Act, Basel III, the COVID-19 pandemic

• Real-Time/Near Real-Time Response:

—  Real-time/near real-time response to new and evolving threats

• Measurable Controls and Automated Audit

5.3 Zero Trust Objectives

The Digital Age does not give organizations the luxury of time to meet requirements using traditional network-based solutions, individualized interface, or per client, vendor, or supplier-level integrations; nor can we predict what changes it will bring. Because of the emphasis on automation and real-time information, implementing Zero Trust helps prevent lengthy audits in order to meet organizational needs. Zero Trust provides organizations with a modern information security paradigm able to meet the objectives that can support those requirements. Figure 4 depicts the key objectives of implementing Zero Trust.

Figure 4: Zero Trust Objectives

• Dynamic User Identity:

—  Support for multiple classes of consumers and participants, whose roles and identity may evolve to meet rapidly evolving ecosystems and new environments

—  Ease of maintenance and operation while being Agile and easy-to-modify

—  Reduced complexity of identity management while maintaining identity portability

—  Support of other identity paradigms (e.g., digital identity, sovereign identity)

• Threat Scope Reduction and Risk Avoidance:

—  Reduced scope of threats to support agility and support complexity

—  Increased complexity and number of communication patterns increasing the difficulty of addressing through a data and asset-centric approach

• Context-Specific, Policy-Enforced Data Security:

—  Holistic approach that reduces the risk of exposed data across the full lifecycle by creating and enforcing policies that will slightly vary according to the context of the data

• Separation of Concerns:

—  Ability to support unpredictable consumers by decoupling security from the underlying resource so that clients of APIs and applications can evolve in a changing digitized environment

• Real-Time/Near Real-Time Response:

—  Security Operations Centers (SOCs) with threat and incident response organizations, infrastructure, and processes

• Automated Audit:

—  Support for agility and increased complexity without traditional, lengthy processes

• Policy-Driven Access Control:

—  Support for adaptive identity, evolving and Agile access to resources (e.g., applications, APIs), and unpredictable relationships between consumers and producers

• Secured Zones:

—  Adaptive and easily configured zones for business assets that must be protected, such as fraud, Personally Identifiable Information (PII), and Payment Card Industry (PCI) data

5.4 Advantages of a Zero Trust-Driven Future

There are numerous advantages to a Zero Trust-Driven future. In particular, a successfully implemented ZTA based on the Zero Trust Commandments shall enable the organization to pursue its mission without unnecessary hurdles but with greatly improved security:

• Zero Trust enables mobility and user choice because people can work anywhere on any device they choose, using the applications and data they need – leading to improved organizational productivity, agility, and the ability to proactively support new and evolving capabilities
• Zero Trust improves confidence in the security mechanisms used to protect data and applications, further enabling the business
• Zero Trust provides support for quickly evolving organizational ecosystems, by enabling rapid creation and dissolution of business-to-business relationships

As Figure 5 shows, in this digitized world, remote work is part of the norm. The digitization of organizations introduces complexity and the need for agility driven by, for example:

• Migration to the cloud
• The need to leverage SaaS providers
• Continued leveraging of legacy assets
• Privacy by design
• Data governance
• Rapidly changing national and global regulations
• Ever-changing organizational relationships in an ecosystem in flux

Figure 5: The Digitized World

From a security context, a ZTA enables adapting to the digitized world by simplifying interactions and making them scalable because access is only granted to required resources when it is needed. A ZTA reduces the need for additional security solutions by starting with an assumption of a compromised network environment. This proactive reduction in complexity reduces security risk, by reducing what has to be protected, and letting resources be better focused on protecting high-value assets (the “crown jewels”). By doing this, operating costs can be managed, and threats can be responded to rapidly, in real-time/near real-time.

The needs of the digitized world are encapsulated in the objectives that ZTAs must support, as described earlier in Figure 4.

Figure 6 illustrates what that ZTA might look like.

Figure 6: Zero Trust Components

In Figure 6, assets and data/information are grouped into Digital Ecosystems, which can be as granular as needed. Digital Ecosystems are environments either within an organization or across organizational boundaries, potentially involving multiple “partner” entities. Access to assets, data/information, and/or the Digital Ecosystems may be protected by access control at an API (service) level or directly at the asset or data/information level. Access control is done through security policy enforcement and is policy-driven, enabling protection of assets and data/information using policies based on – but not limited to – business processes, data classification, asset, or data/information (provider), and consumer (user). This allows dynamic and adaptive policy definition and enforcement, providing businesses with the ability to evolve in an Agile manner.

Zero Trust identity models support federated identities, common in many organizations, especially in a world of loosely-coupled Digital Ecosystems, through subject (user)-centric digital identity models. Using adaptive policy-based access and tokenizing data using technologies such as format-preserving encryption reduce risk and the threat surface area; these also limit the friction that new technologies bring, in turn reducing the disruption of building new or re-architected platforms and systems. These approaches allow organizations to protect their high-value assets within highly protected, tiered secured zones.

Another key aspect of Figure 6 is the support of the automated audit, leading to Agile compliance, improved visibility, and governance. This helps reduce/avoid long-running audits and compliance overhead. Incident management and threat management in a Zero Trust world are done through responsive and near real-time threat management and SOC components, which are tied in with incident management, closing the secure DevOps loop.

By creating secured zones to protect high-value assets, using tokenization to reduce the threat surface area, using adaptive, policy-driven access controls to define access control, and tokenizing data, the organization can limit the incident blast radius; in other words, the organization localizes the impact of an incident and improves situational awareness. Risk assessment and compliance are made more Agile and responsive to evolving business need through automated compliance and audit. Finally, the Agile threat management and SOC architectural building blocks enable early, proactive incident detection, response, and avoidance.

Many of these technologies and components exist at varying levels of maturity, though they are rapidly evolving to leverage new tooling and concepts, such as AI. There is a mindset shift, however, in the manner in which they are used to create an Agile ZTA for organizations that brings security to the users, data/information, applications, APIs, devices, networks, cloud, etc., wherever they are.

The imperatives presented in this chapter form the foundation for the Commandments, and drive the full lifecycle thinking key to a Zero Trust transformation. These imperatives shall underpin all the Commandments, and the Commandments lean on them either explicitly or implicitly.

The standard developers acknowledge that some Commandments or their components may at present be aspirational, dependent upon today’s technology – this shall not prevent an organization from attempting to implement and follow as many of the Commandments as is currently possible.

6.1 Assume Failure and Assume Success

Becoming resilient requires simultaneously accepting the reality of both positive and negative outcomes – attacks will inevitably happen, and organizations can manage them (detect, prevent, and/or recover from them). This duality is fundamental in navigating the complex challenges of security.

Figure 7: The Duality of Navigating Simultaneously Positive and Negative Outcomes

The Zero Trust Commandments are based on the dual assumptions “Assume Failure” and “Assume Success” outlined below. The combination of these assumptions promotes resilience by enabling the realistic prioritization of security efforts across the full lifecycle: identify, protect, detect, respond, and recover. These help drive a sense of purpose and optimism, knowing that the organization will face and overcome any security crisis.

Zero Trust means being as prepared as possible to handle failure and be successful.

6.1.1 Assume Failure

The purpose of this assumption is to expand on the concept of “assume breach/compromise”[7] and to ground organizations in the reality of an open environment where security risk will always exist. Organizations must assume that anything could go wrong – users will forget or make mistakes; attackers will succeed in gaining control of data and computer systems (in part or as a whole); and trusted insiders will occasionally go bad. This is the security analog of the “fail safe” engineering practice that assumes failure will happen and ensures the system fails to a safe state (to minimize harm to people, the environment, or other equipment).

Important: This negative assumption represents a fundamental shift from a classic security assumption of perfect security on internal networks or resources. This forces everyone to face the reality that perfect security is impossible for anything (data, other business assets, network, etc.). Security is not a technical problem to be solved once, but an ongoing discipline to be practiced.

6.1.2 Assume Success

The purpose of this assumption is to complement the assumption of failure and keep the focus on preventing and rapidly recovering from incidents. Always assume that the mission and business must and will continue despite any failures that can and will happen: many attacks can be blocked; people will overcome obstacles and learn; systems can be cleaned, restored, or rebuilt – business operations and the mission will continue.

6.2 Advocate for Simplicity

In addition to driving simplicity in security processes (captured in the Commandments), security teams should also act as advocates for understanding and simplifying the technical environment and business processes of the organization. Constraining the complexity of the environment reduces the number of variables, considerations, and exceptions that must be managed by people or by automation (scripts, programs, etc.). Any simplification and/or standardization of the technology environment benefits many aspects of the organization (manageability, agility, etc.), and security teams become more able to provide effective, pervasive, and sustainable assurances.

The standard developers have observed that many organizations deal with multiple generations of platforms, legacy systems, and architectural patterns. These lead to an ever-expanding growth in complexity over time, which is often exacerbated by consumer expectations of businesses to move faster and rapidly adopt new platforms. This complexity growth is even more explosive if governance does not restrain the procurement of duplicative technology solutions, further adding overhead to and difficulty in providing security and other assurances. Instead, the organization should aim for a simple environment in which the same solutions are provided consistently for the same needs (uniformity), reusing patterns, technologies, and business processes that are known to work.

Security teams must advocate for simplicity as a means of reducing business risk while the organization undergoes digital, cloud, and Zero Trust transformations. As part of this, the security teams should clearly and concisely communicate Zero Trust strategy and implementation across the organization.

6.3 View as a Continuous Journey

The transition to a Zero Trust Architecture (ZTA) is a journey, and change does not happen all at once. Any organization undergoing the transition to a ZTA must acknowledge and accept that progress will happen incrementally, and that the organization and its environment must evolve continuously.

The Zero Trust Commandments should be applied to all current and future decisions, which will fundamentally change how an organization functions and connects. All transformations require investment into change, and Zero Trust ultimately represents a change in strategy or perception of security, ensuring continuous enablement of business objectives while managing risk. Zero Trust will require investment into cultural and business process change in order to achieve a reduction in risk and an increase in business agility, and these Commandments enable organizations to address the shifting mindset and culture change required for Zero Trust, linking people, processes, and technology.

As progress occurs, it should be celebrated within the organization. A “fully implemented” ZTA is not needed to benefit from the transition.

The body of the document established an overview of Zero Trust, its key drivers, and the digitally transformed information security world of the future.

This appendix reviews different aspects of Zero Trust for executives and senior leaders, including governance and Business, Security, and IT viewpoints.

When coupled with prior sections, this appendix better equips executives and senior leaders to understand the evolving paradigm of Zero Trust and information security in the era of the digital enterprise.

A.1 Governance, Information Security Management Systems, Digital Transformation, and Zero Trust

Governance in the context of Zero Trust incorporates business, risk, and technical (IT) perspectives, including CIO and CISO organizations (if those are separate), and ensures that organizational leadership is responsible for realization of risk. Governance must address the key characteristics of velocity, complexity, and disruption.

The organization’s enterprise risk management process defines how information security is governed by the organization executive and operated by the information security leader. Information security control requirements change in response to the enterprise risk management process, informed by information technology and organization operations perspectives, embracing the organization's commitment to total quality management.

In a Zero Trust world, governance and information security management must operate in the context of a much higher level of uncertainty than in the past.

Governance must ensure that the implementation and operation of facilities and processes is aligned to the organizational view of risk, including risk tolerance and threshold, while continuing compliance and managing the introduction of new capabilities in a proactive manner.

The information security management system must ensure that the implementation and operation of facilities and processes respond to enterprise risk while monitoring compliance. It includes managing the introduction of new and changed security capabilities. In the Digital Age, the rapid rise in the number of interfaces and interactions driven by new technologies such as the cloud is coupled with the need for extreme agility. However, traditional audits of partners and interfaces and evolving regulatory requirements (which might often lag changes in the organization’s environment) are generally not scalable or able to meet organizational needs for agility and operational efficiency.

To succeed, a Zero Trust governance model must manage or reduce complexity and the dynamic threat surface, allowing organizations to focus on the remaining, smaller threat surface. Zero Trust governance must also establish best practices and guardrails coupled with meeting existing controls, including fiduciary, regulatory, and business controls, and should leverage but not depend on existing controls and organizational risk assessment. A Zero Trust governance model must also provide the guardrails that enforce alignment with the digital enterprise priorities of proactive risk management, agility, and speed. Quantitative risk analysis frameworks, such as the Open FAIR™ Body of Knowledge [C20A; C20B], provide a consistent way to measure, analyze, and discuss risk in a quantified manner, making them especially suited for Zero Trust.

A.2 Compliance and Zero Trust

By beginning with a single compliance capability, the organization can meet industry and regulatory audit requirements. Zero Trust requires regular, timely security assessments to ensure organizations are adequately complying with these requirements. To do this, Zero Trust requires security solutions to be measurable and traceable to security requirements. This necessitates a real-time (or near real-time) capability to assess the compliance to security control requirements of an organization operating in an automated manner.

A.3 Dealing with Data and Breaches

The asset which is compromised in case of a breach is data, and a Zero Trust premise is that the organization must be able to operate and grow in a compromised state. It is also reasonable to assume that laws and jurisprudence will lag the changing environment, but also that they will need to be complied with.

In such an environment, ensuring support for prevailing laws and compliance regimes and developing controls for addressing lagging standards becomes necessary. Security must be shifted as close to the asset (in this case, data) and governance and compliance automated as much as possible. Responses to breaches must be in near real-time. The overall amount of data being exposed must be reduced, thus reducing the loss magnitude and fallout of a breach. Data that must stay sensitive must be treated from a holistic, lifecycle, and access control perspective.

Privacy by Design and Zero Trust

Privacy as a concept and enforced paradigm is rapidly evolving. This rate of change is both jurisdictional and cultural. These controls often evolve and change by decree, leaving organizations very little time to adapt and resulting in huge expenditures. As a result, Zero Trust Architectures (ZTAs) must plan for “privacy by design” and embed it in all aspects of the architecture. This is inherently a cross-cutting[8] capability with a rapid rate of change and high complexity, so it must be incorporated in a manner that is adaptive and business, security, legal, and technology executives must be engaged in determining its implementation.

From the perspective of the business executive, there are numerous drivers (as depicted in Figure 2) to consider, leading to the characteristics addressed by Zero Trust: velocity, complexity, and disruption. This includes both the DevSecOps realm and the increasing and increasingly important connections between IT systems and OT, both within the organization and with business partners.

Given the profusion of security threats as well as security technologies, there is an increased challenge in measuring security risk and determining where there is Return on Security Investment (ROSI) among the myriad security controls in which investment might be made. Cyber risk quantification methods (such as the Open FAIR methodology[9]) allow prioritization among the myriad security controls in which investment might be made.

Collectively, these drivers all impact the thinking of business executives as it relates to traditional or legacy security architectures, and Zero Trust Architectures (ZTAs). From the point of view of business executives, there is increasing interest in ensuring that the organization receives value in terms of reduced risk from security control investments. Additionally, the pace of change drives the need for a focus on ROSI in a timely manner, with a focus on business enablement and operational execution. In short, organizational stakeholders now tend to see investment in terms of the organization being able to support new business models or operate in a changed or evolving business environment. Investment for the sake of meeting compliance controls is no longer the only possible cause for investment in security.

B.1 Enabling Business by Managing Risk

The goal of Zero Trust is to help business stakeholders manage security risk while enabling their objectives, including both creating new capabilities and supporting existing capabilities in an evolving, digitized environment. As such, any guidance offered in a Zero Trust implementation strategy must align with a typical business-driven risk lifecycle approach. The outcome should be the identification of relevant threats and mitigations as well as a set of recommendations on how best to balance risk and business objectives (typically speed to market or cost).

By bringing security to the users, information, applications, and APIs wherever they are, Zero Trust approaches proactively reduce risk wherever possible; this contrasts directly with traditional, perimeter-based approaches that focus more on risk mitigation and responding/reacting to threats after they are identified or have occurred. In essence, Zero Trust implementations proactively reduce the amount of data/assets at risk which, in turn, reduces the effort, cost, and time required to maintain and protect data/assets.

People are more comfortable taking business risks when they feel safe – just as a car with better safety features provides assurances for the owner, ZTA enables an organization to move with greater speed and agility.

In some cases, an organization may not have the necessary Zero Trust competencies to enable business needs. It is the responsibility of technical and business leadership to determine how best to address this gap. It may involve hiring more people, training existing people, using a third party, or accepting the risk and insuring against it. As such, a Zero Trust security strategy must place the technical executive at the same table as business executives with discussion taking place in business terms.

B.2 Enabling Zero Trust Adoption and Digital Transformation

Digital Transformation is aided by agility, and organizations must be able to connect, disconnect, and interconnect many assets, both internal and external to the organization. Organizations are fundamentally changing their business models and entering new lines of business, and institutional knowledge garnered over operating in a particular line of business becomes less relevant or even irrelevant in the new business model, business domain, or technical environment. Organizations are also changing culture, processes, structure, and teams rapidly. In most cases, both business and technology teams are going through this evolution. Information security must adapt to this new environment.

Zero Trust provides a way to undergo Digital Transformation[10] securely and, therefore, must be embedded in the organization throughout the transformation process, which in turn implies that organizations proactively incorporate Zero Trust through the journey. The incremental and transformative nature of Zero Trust strategies requires an approach that supports the duality of operation and growth.

In an Agile world centered on Digital Transformation, Zero Trust provides two fundamental advantages:

• Reduced blast radius of an incident, leveraging improved situational awareness
• Reduced threat surface area to better focus threat mitigation, leveraging asset and data-centric approaches

It does this through:

• Strategic business alignment by using capabilities to align security, the business, and technology
• Alignment of security to operational execution of the business and business processes
• Alignment of security and operating models to determine structural funding and operational decision rights, curating governance frameworks
• Mapping of business strategy and vision, through goals, principles, and policies to actionable security guardrails and governance

NOTE: The text below is presented exactly as it appeared in the Zero Trust Core Principles White Paper [W210], which this document supersedes.

When organizations undertake the journey towards a new, enterprise-wide change, a core set of principles^[11] provides a succinct, easily shared “North Star” to guide and coalesce the organization.

This set of Core Principles acts as a set of fundamental guidelines for organizations to adopt Zero Trust and implement Zero Trust Architectures (ZTAs). They focus on factors specific to Zero Trust – linking people, processes, and technology – and should both be used for all new security initiatives and retroactively applied to old security activities.

The Core Principles are grouped into common themes that address different aspects of Zero Trust:

• Organizational Value and Risk Alignment principles address key goals for business, IT, and security stakeholders to address overall strategic drivers
• Guardrails and Governance principles address compliance, risk, and information security stakeholders to guide the adoption of Zero Trust and ensure sustainability of assurances, addressing:

—  Rapidly evolving compliance and regulatory needs, requiring proactive integration of industry and organizational controls

—  Lagging industry controls and compliance standards, resulting in an expectation to create supplemental organizational controls

—  Increasing complexity and agility requirements that drive the need for rapid, near real-time or real-time audits, requiring automation of data collection, traceability, and processes

• Technology principles address the IT organization, information security, and risk and compliance stakeholders and determine technology decisions that underlie the development of a ZTA, including concerns associated with identity, access, and reduced threat surface area
• Security Controls principles address security and IT architects to ensure strong foundations of confidentiality, integrity, and availability assurances

All of the elements of the Core Principles must fit within the business strategy and organizational culture. Simple axioms are provided below to aid in communicating and remembering the principles. Guardrails and Governance help bind business goals and technical reality, and these principles are depicted to the side in Figure 7 as they should not impede direct connections between the organizational mission and the technology and security that support it.

Figure 8: Summary of Zero trust Core Principles

C.1 Organizational Value and Risk Alignment

1. Modern Work Enablement – Users^[12] in organizational ecosystems must be able to work on any network in any location with the same security assurances, increasing productivity.
2. Goal Alignment – Security must align with and enable organization goals within risk tolerance and threshold.
3. Risk Alignment – Security risk must be managed and measured consistently using the organization’s risk framework and considering organizational risk tolerance and thresholds.

C.2 Guardrails and Governance

1. People Guidance and Inspiration – Organizational governance frameworks must guide people, process, and technology decisions with clear ownership of decisions, policy, and aspirational visions.
2. Risk and Complexity Reduction – Governance must both reduce complexity (i.e., simplify) and reduce threat surface area.
3. Alignment and Automation – Policies and security success metrics must map directly to organizational mission and risk requirements and should favor automated execution and reporting.
4. Security for the Full Lifecycle – Risk analysis and confidentiality, integrity, and availability assurances must be sustained for the lifetime of the data, transaction, or relationship. Asset sensitivity must be reduced where possible (removing sensitive/regulated data, privileges, etc.), and assurances should be provided for the risk of data in use, in-flight, and at rest.

C.3 Technology

1. Asset-Centric Security – Security must be as close to the assets as possible (i.e., data-centric and application-centric approaches instead of network-centric strategies) to provide a tailored approach that minimizes productivity disruption.
2. Least Privilege – Access to systems and data must be granted only as required and removed when no longer required.

C.4 Security Controls

1. Simple and Pervasive – Security mechanisms must be simple, scalable, and easy to implement and manage throughout the organizational ecosystem (whether internal or external).

2. Explicit Trust Validation – Assumptions of integrity and trust level must be explicitly validated against organization risk threshold and tolerance. Assets and/or data systems must be validated before being allowed to interact with anyone/anything else.

Glossary

AI	Artificial Intelligence
API	Application Program Interface
ATM	Automated Teller Machine
BYOX	Bring Your Own X
CCPA	California Consumer Privacy Act
CIA	Confidentiality, Integrity, and Availability
GDPR	General Data Protection Regulation
GRC	Governance, Risk, and Compliance
IoT	Internet of Things
IT	Information Technology
ML	Machine Learning
NLP	Natural Language Processing
O-RA	The Open Group Standard for Risk Analysis
O-RT	The Open Group Standard for Risk Taxonomy
OT	Operational Technology
PCI	Payment Card Industry
PII	Personally Identifiable Information
REST	Representational State Transfer
ROSI	Return on Security Investment
RPA	Robotic Process Automation
SaaS	Software as a Service
SOC	Security Operations Center
ZTA	Zero Trust Architecture

---

Footnotes