Zero Trust Maturity Introduction

Introduction

The Federal Government has directed agencies to modernize their approach to cybersecurity. Executive Order 14028, “Improving the Nation’s Cybersecurity”, and OMB Memorandum M-22-09, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” direct Federal Civilian Executive Branch (FCEB) agencies to base their enterprise security architecture on Zero Trust principles. While HHS and CMS have not published new policies regarding Zero Trust, the CMS Zero Trust Workgroup is working to evolve the Zero Trust Maturity of all CMS environments through incremental change, with “Advanced” or “Optimal” maturity being the objective for systems, based on their sensitivity (the results of a recent data call for Zero Trust Maturity for AWS for CMS Cloud suggests an overall maturity level of "Advanced" for CMS Cloud).

CMS is in the midst of defining its Zero Trust strategy, policies, and approach. As such, this TRA section does not introduce any new business rules. However, to assist CMS in preparing for and aligning with Zero Trust objectives, the following topics illustrate how existing TRA business rules and recommended practices align with Zero Trust Maturity capabilities. This information can aid development teams in understanding which areas may need additional focus along the Zero Trust Journey. This is not per se a Zero Trust primer. See below for additional resources.

Overview

The Federal Zero Trust Architecture (ZTA) strategy involves migration from existing perimeter-based defenses to a “Zero Trust” approach. Zero Trust is not a single architecture, but a set of guiding principles that can improve the security posture of agency applications and environments. These seven tenets outlined in NIST SP 800-207 guide its implementation:

  1. All data sources and computing services are considered resources. Including:

    • Multiple classes of devices
    • Small footprint devices
    • Personally owned devices (BYOD)

  2. All communication is secured regardless of network location.

    • Both enterprise-owned network infrastructure and any other non-enterprise-owned network
    • In the most secure manner available
    • Access requests from inside must meet same requirements as from outside the enterprise

  3. Access to individual enterprise resources is granted on a per-session basis.

    • Trust in the requester is evaluated before the access is granted
    • Access is granted with the least privileges needed to complete the task
    • Authentication and authorization to one resource will not automatically grant access to a different resource

  4. Access to resources is determined by dynamic policy, including:

    • The observable state of client identity, application/service, and the requesting asset
    • May include other behavioral and environmental attributes, such as security posture
    • Rules and attributes are based on the needs of the business and acceptable level of risk
    • Least privilege principles restrict both visibility and accessibility

  5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

    • No asset is inherently trusted.
    • Evaluates the security posture of the asset when evaluating a resource request.
    • Continuous diagnostics and mitigation (CDM) systems monitor the state of devices and others.

  6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.

  7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

CMS-specific guidance for ISSOs and ADOs can be found at The 7 Tenets of Zero Trust for ISSOs and ADOs. Zero Trust Maturity is the degree to which ZTA principles have been implemented across the agency. CMS assesses this using the CISA Zero Trust Maturity Model, which is organized around a structure that is shown with five pillars:

The five pillars are identity, devices, networks, applications, and workloads, and data. The three steps are governance, automation and orchestration, visibility, and analytics.
Figure 1: Zero Trust Maturity Model Pillars
  • Identity: Federal staff, as well as partners and end users, use enterprise-managed accounts to access everything they need to do their job, protected from phishing and other attacks.
  • Devices: The devices that Federal staff use are consistently tracked and monitored, with those devices’ security postures used to grant access.
  • Networks: Agency systems are isolated, with encrypted network traffic flowing between and within them.
  • Applications and Workloads: Enterprise applications can be made available to staff securely over the internet.
  • Data: Federal security teams and data teams develop data categories and security rules to automatically detect and ultimately block unauthorized access.

Below the pillars are three steps:

  • Visibility and Analytics: Collecting information about the systems to identity how things in the Pillar are working.
  • Automation and Orchestration: Methods for automatically creating and maintaining the different entities and assets in a Pillar. Manual configurations can introduce errors over time, and automation helps prevent that.
  • Governance: The set of policies that tell how you control and direct different assets and entities in your environment. This can include how teams create new users, decide on data classifications, and manage servers.

High-level Summary

Below are the characteristics of the maturity levels assessed for CMS environments.

Zero Trust Maturity Capabilities Summary
Pillar Traditional Initial Advanced Optimal
Identity
  • Passwords or MFA
  • On-premises identity stores
  • Limited identity risk assessments
  • Permanent access with periodic review
  • MFA with passwords
  • Self-managed and hosted identity stores
  • Manual identity risk assessments
  • Access expires with automated review
  • Phishing-resistant MFA
  • Consolidation and secure integration of identity stores
  • Automated identity risk assessments
  • Need/session-based access
  • Continuous validation and risk analysis
  • Enterprise-wide identity integration
  • Tailored, as needed automated access
Devices
  • Manually tracking device inventory
  • Limited compliance visibility
  • No device criteria for resource access
  • Manual deployment of threat protections to some devices
  • All physical assets tracked
  • Limited device-based access control and compliance enforcement
  • Some protections delivered via automation
  • Most physical and virtual assets are tracked
  • Enforced compliance implemented with integrated threat protections
  • Initial resource access depends on device posture
  • Continuous physical and virtual asset analysis including automated supply chain risk management and integrated threat protections
  • Resource access depends on real-time device risk analytics
Networks
  • Large perimeter / macro-segmentation
  • Limited resilience and manually managed rulesets and configurations
  • Minimal traffic encryption with ad hoc management
  • Initial isolation of critical workloads
  • Network capabilities manage availability demands for more applications
  • Dynamic configurations for some portions of the network
  • Encrypt more traffic and formalize key management policies
  • Expanded isolation and resilience mechanisms
  • Configurations adapt based on automated risk-aware application profile assessments
  • Encrypts applicable network traffic and manages issuance and rotation of keys
  • Distributed micro-perimeters with just-in-time and just-enough access controls and proportionate resilience
  • Configurations evolve to meet application profile needs
  • Integrates best practices for cryptographic agility
Applications and Workloads
  • Mission critical applications accessible via private networks
  • Protections have minimal workflow integration
  • Ad hoc development, testing, and production environments
  • Some mission critical workflows have integrated protections and are accessible over public networks to authorized users
  • Formal code deployment mechanisms through CI/CD pipelines
  • Static and dynamic security testing prior to deployment
  • Most mission critical applications available over public networks to authorized users
  • Protections integrated in all application workflows with context-based access controls
  • Coordinated teams for development, security, and operations
  • Applications available over public networks with continuously authorized access
  • Protections against sophisticated attacks in all workflows
  • Immutable workloads with security testing integrated throughout lifecycle
Data
  • Manually inventory and categorize data
  • On-prem data stores
  • Static access controls
  • Minimal encryption of data at rest and in transit with ad hoc key management
  • Limited automation to inventory data and control access
  • Begin to implement a strategy for data categorization
  • Some highly available data stores
  • Encrypts data in transit
  • Initial centralized key management policies
  • Automated data inventory with tracking
  • Consistent, tiered, targeted categorization and labeling
  • Redundant, highly available data stores
  • Static DLP
  • Automated context-based access
  • Encrypts data at rest
  • Continuous data inventorying
  • Automated data categorization and labeling enterprise-wide
  • Optimized data availability DLP exfil blocking
  • Dynamic access controls
  • Encrypts data in use

Resources and References

Find more information about Zero Trust within CMS OIT and the Federal Government at large. Some are out of the scope of the CMS migration.

Internal

External

OMB

NIST

CISA

 

Zero Trust Maturity Model Pillars

The sections that follow show ways in which the CMS TRA aligns with capabilities required for Zero Trust Maturity. The CMS objective is to implement these capabilities at the Advanced or Optimal maturity level.