CMS Technical Reference Architecture

The CMS Technical Reference Architecture (TRA) provides CMS-approved technical standards and architecture guidance for designing, integrating, modernizing, and maintaining information systems across all CMS processing environments, ensuring consistency, interoperab

Last Reviewed: 7/7/2026

Contact: jacob Wilson | CISO@cms.hhs.gov

FOUNDATION

Introduction to the TRA

The CMS Technical Reference Architecture (hereafter referred to as the “CMS TRA”) articulates the technical architecture of all Centers for Medicare & Medicaid Services (CMS) processing environments (hereafter simply the “CMS Processing Environments”). A CMS Processing Environment is defined as:

Any computing environment (e.g., CMS data center, virtual computing environment, or cloud computing including Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS)) that creates, consumes, and/or stores CMS-related data. CMS data includes sensitive, non-sensitive, and security information and event management-related information used to provide CMS services to the public and internal CMS users.

The CMS TRA represents the Agency’s policy guidance to all Agency business partners wishing to develop, transition, and maintain information systems that interact with the CMS Processing Environments. The CMS TRA is approved and authorized by the CMS Chief Information Officer (CIO) and Chief Enterprise Architect (CEA).

Adherence to the CMS TRA supports the Agency’s healthcare mission by providing:

A secure CMS Processing Environment that protects sensitive information, including CMS, beneficiary, provider, and partner information
Appropriate disaster recovery and business continuity capabilities
Timely and economic transition of CMS applications into new processing environments
An enterprise computing solution that responds to CMS’s evolving mission and business needs

Toward these ends, the CMS TRA defines a common set of terms and definitions to support CMS’s architecture approach and ensure an effective operating environment. It conveys required design considerations, including security policies and controls (for confidentiality, integrity, and availability), reusability, scalability, and sustainability. The common framework of the CMS TRA supports future application designs as well as architecting and engineering CMS applications. It encourages the use and creation of enterprise shared services and presents clear guidance on their appropriate use and interaction among CMS data centers. By promoting a technical reference standard for future CMS task orders and acquisitions, the CMS TRA clarifies the decision-making process and target technical environments, which helps Agency contractors develop sound and acceptable transition approaches.

Purpose

This topic introduces the CMS TRA and is the keystone of CMS TRA guidance, as shown in Essential Guidance for the Entire CMS TRA. It articulates the CMS Architectural Vision and provides guidance relevant to all stakeholders. It establishes the guiding principles of the CMS architecture that informs all guidance in subsequent topics and presents overviews of CMS Services Framework and Multi-Zone Architectures.

Essential Guidance for the Entire CMS TRA

This topic also summarizes how to request a change to the CMS TRA through the Architecture Change Request (ACR) process.

Stakeholders interested in specific architectural topics can find detailed guidance organized in topics as follows:

Network Services – focuses on network infrastructure including security-related appliances that monitor network traffic
Infrastructure Services – focuses on physical or virtual infrastructure supporting CMS applications
Application Development – focuses on application-level concepts and methodology
Data Management – focuses on data management and data lakes

The guidance in each CMS TRA topic includes narrative providing context; Business Rules (BR), which are requirements for TRA compliance; and Recommended Practices (RP), which are strongly encouraged for use within the CMS Processing Environments but not required.

Intended Audience

The CMS TRA is intended to guide system architects, business owners, system maintainers, and security auditors in working with CMS’s technical environment. A publicly available version is located at CMS TRA. CMS restricts access to the complete CMS TRA to the following authorized users:

CMS staff
CMS Processing Environment contractors
Operator of the CMS Alliance to Modernize Healthcare Federally Funded Research and Development Center (the Health FFRDC)

CMS executive or management approval is required to provide this document to other entities pursuant to business need.

Complementary Documents

The CMS TRA complements CMS standards documentation. The CMS TRA supersedes and takes precedence over other existing CMS standards documentation, with the following exceptions:

CMS Information Security (IS) Acceptable Risk Safeguards (ARS, hereafter simply the “CMS ARS”)
All volumes of the CMS Risk Management Handbook (RMH)
CMS Information System Security and Privacy Policy (IS2P2)
CMS Section 508 Policy

The CMS ARS is located at: CMS Acceptable Risk Safeguards (ARS) on the CMS CyberGeek website.

CMS provides an orientation briefing for CMS TRA Document Development (MS PowerPoint) and the ACR Form (PDF) for initiating an Architecture Change Request.

A mailing list entitled “CIO Resource Library Communications” is available to notify subscribers when new or revised information technology (IT)-related policies, technical or TRA standards, directives, or guidelines are available. To subscribe to the new list, please select the following URL and enter your email address:

https://public.govdelivery.com/accounts/USCMS/subscriber/new?topic_id=USCMS_12066

Please direct all questions, comments, suggestions, or requests for further information to the CMS CIO Policy Officer at IT_Policy@cms.hhs.gov.

Guiding Principles

The CMS TRA informs the development of the Agency’s Common Enterprise Infrastructure (CEI) and is the foundation for the design and implementation of processing components and computing environments across the CMS Enterprise. Ensuring the secure operation of all CMS Processing Environments (as defined in CMS Processing Environments) is a primary architectural consideration. Adhering to the CMS TRA improves interoperability of services across the enterprise, supporting the goal of providing high-value services at lower cost, with higher availability, reduced implementation times, and improved maintainability.

The CMS TRA describes the technical baseline for all CMS Processing Environments. The CMS TRA cites proven, effective, and tested common controls that meet legislatively mandated mission, security, and privacy requirements. The Agency updates the CMS TRA as required to respond to CMS’s changing needs and direction and to reflect current technical standards.

As CMS’s repository of technical reference standards, the CMS TRA plays a critical role in all contracts. Contracting Officers refer to the CMS TRA topics in task orders and solicitations to ensure that contractors understand and apply technical consistency across data centers and contract efforts.

The TRA focuses on services, outcomes, and effects instead of physical structures, specific products, or system components. Unless explicitly stated, references to specific products and/or vendors within the CMS TRA provide information about the existing technical environment rather than express an Agency preference. The CMS TRA supports the Department of Health and Human Services (HHS) Enterprise Architecture principles and satisfies the CMS ARS security control, CM-2, Baseline Configuration.

CMS relies on the following guiding principles for the CMS TRA:

Defense-in-Depth
Least privilege
Vendor agnostic, amenable to new technologies
Reuse
Service-Oriented Architecture (SOA) and Microservices
Enterprise Services
Common Platform Services
Cloud First
Use of Open Source Software
Automation
Sustainability

Defense-in-Depth

Defense-in-Depth employs multiple, coordinated security countermeasures to protect against security issues throughout the infrastructure.

A Services Framework architecture separates services by their function and encapsulates them with their own layers of protection/defense providing adaptable layers of depth.

A multi-zone architecture, which is a type of Services Framework architecture, places multiple layers of protection/defense on each zone by segregating networks and controlling inter-zone communications.

Least Privilege

The CMS TRA adheres to the security concept of least privilege, the security objective of granting users only those accesses they need to perform their official duties. When a user is permitted to “self-elevate” temporarily (e.g., Linux sudo command), this action is logged.

Vendor Agnostic

Unless explicitly stated, the CMS TRA does not advocate a preferred vendor or suite of products. One notable exception to this rule is shared services (including security services), where a specific technology has been selected and is mandated for use of or integration with this shared service. CMS encourages innovation of supportable solutions within the parameters of the CMS TRA.

When selecting software, business owners should evaluate competing product licenses and leverage existing agency purchasing sources before approving new contractor purchases. The focus should be on minimizing costs and promoting consistency across CMS applications and environments. Business owners are required to utilize Inter-Agency Agreements (IAA), CMS Enterprise License Agreements (ELA), and Government Furnished Software (GFS) to the greatest extent possible. These actions will support CIO Directive 25-02 Use of CMS Enterprise License Agreements, issued July 1, 2025.

CMS maintains enterprise licensing information at: Enterprise Software Licensing

For more information on IAA, ELA, or GFS agreements, please contact the Software Asset Management Program Management Office (SAM PMO) at SoftwareLicensesCMS@cms.hhs.gov.

Reuse

CMS encourages reuse and sharing wherever practicable to avoid creating redundant services/applications. There can be multiple cloud and physical data centers in the CMS environment. Any application can reside in any combination of CMS data centers (including CMS Clouds) and use software services—for example, Identity Management (IDM) and Enterprise Portal—of the other data centers. Application software in one data center may leverage services in another data center.

The benefits of reuse include:

Reduced implementation times
Lower project risk
Reduced costs
Minimized redundancy
Improved security
Improved interoperability

CMS employs several strategies for reuse: adoption of a Service-Oriented Architecture, use of Microservices, and the implementation and use of Strategic and Preferred Solutions.

Service-Oriented Architecture and Microservices

SOA defines a set of principles for developing software as interoperable, reusable, distributed services to fulfill business functions. For example, the Medicaid Information Technology Architecture (MITA) is a SOA framework that allows CMS and state Medicaid organizations to create, deploy, execute, and manage reusable, modular, and interoperable business, data, and technology services. The Application Development section addresses SOA extensively.

Microservices (MS) are a modern interpretation of SOAs for building distributed software systems. Each component/ module of an application is developed and deployed separately. This contrasts with a traditional, “monolithic” application in which all components are developed and deployed as one piece. Microservices are well suited to DevOps methods and tools. The Application Development section addresses Microservices, with additional detail in the TRB Research Spotlight, “Microservice Architecture,” published April 11, 2023.

Strategic and Preferred Solutions

CMS strongly encourages the use of Strategic and Preferred Solutions. These are solutions which have been designed, tested, and approved for broad use within CMS. Utilizing these existing solutions, which include formally designated Enterprise Shared Services (ESS), shortens the Time-to-Delivery (TTD), facilitates efficient infrastructure use, reduces redundant capabilities, improves access, and leads to more consistent cybersecurity posture. The Office of Management and Budget (OMB) Memorandum M-19-16, Centralized Mission Support Capabilities for the Federal Government, April 26 2019, defines federal IT shared services and policy. (Also see Solutions to Improve Agency Management Efficiency (ussm.gsa.gov) and cio.gov/policies-and-priorities/shared-services)

Details and guidance for the use of these services are described in the following section, CMS Strategic Guidance and Preferred Solutions.

Common Platform Services

Common platform services are technology services provided in support of all hosted applications. The CMS ecosystem now supports platform services across both cloud and on-premises environments. These capabilities are designed to standardize and simplify support and management.

Common platform services may include (but are not limited to):

Network capabilities such as load balancing, domain name services (DNS), dynamic host control protocol (DHCP)
Event logging (Syslog, SIEM)
Database Administration
Operating System (OS) Administration

Application developers should use enterprise shared services and common platform services where possible rather than implementing specialized or single-use software.

Cloud First

The CMS TRA supports the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kundra, February 14, 2011) Cloud First Policy. For details, please refer to the Network Services and Infrastructure Services sections.

Pursuant to this objective, CMS is closing its on-premises data centers and is migrating all on-premise applications to cloud environments. Any residual on-premises functionality is migrating to cloud-connected collocation facilities. This strategy is aligned with OMB M-19-19 regarding the Data Center Optimization Initiative. “Agencies may not budget any funds or resources toward initiating a new agency-owned data center or significantly expanding an existing agency-owned data center without approval from OMB.” See the full OMB M-19-19 directive for more information. The objective is to drive meaningful improvement to IT infrastructure, achieve cost savings through optimizations and closures, and foster IT modernization.

CMS has a robust set of recommended cloud services and capabilities available to enable rapid migration to and deployment within the cloud. See the CMS Strategic Guidance and Preferred Solutions section for further detail.

Use of Supportable Open Source Software

The CMS TRA permits the use of supportable Open Source software in CMS Processing Environments. For details, please refer to the chapter on Open Source Software in the Application Services Section. Unsupported software in any capacity cannot be patched in a timely manner; accordingly, any Open Source software without a dedicated support matrix violates the CMS ARS.

Development Methodology Agnostic

The CMS TRA applies to all CMS Processing Environments regardless of the approach used to develop and maintain CMS Federal Information Security Modernization Act (FISMA) applications (e.g., using Waterfall, Prototyping, Incremental, Spiral, Rapid Application Development, and Agile).

Automation

The CMS TRA encourages the appropriate use of automation to reduce variability and increase speed. In code development and deployment process, continuous integration automation (code checkout/build, static code analysis, dependency check, unit testing), continuous deployment release orchestration, Infrastructure as code can be used to avoid manual errors and manage complexity. In production, operational monitoring can be automated by vulnerability scanning, system health, alerts, etc.

Sustainability

The CMS TRA encourages projects to consider sustainability as a critical element of architectural solutions. Projects should apply appropriate attention to future scale, cost, security, operational efficiency, technology, and vendor support. The long-term viability of applications and data products must be considered when integrating any solution into the CMS Processing Environments. Risk and mitigation planning for sustainability should address personnel (technical expertise), operational processes (automation), adherence to Service Level Agreements, and total cost of ownership.

In cloud environment the sustainability for cost, scalability, service level agreements can be achieved by adoption of cloud native features like dynamic scaling up/down of resources based on usage, use of shared instances vs reserved instance and optimal sizing of resources.

Accessibility and Section 508 Compliance

Inaccessible technology interferes with an individual’s ability to obtain and use information quickly and easily. Section 508 of the Rehabilitation Act of 1973 was enacted to eliminate barriers in IT, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. CMS operates many programs that are critically important to people with disabilities. IT is often the vehicle for delivering these programs. The most effective and least costly approach to technology accessibility is for CMS to incorporate accessibility into its IT governance, development, and procurement processes.

Under Section 508, federal agencies must give federal employees and members of the public with disabilities access to Information Communication Technology (ICT) and information that is comparable to the access available to individuals without disabilities. For CMS Processing Environments and applications, adherence to the Agency’s Section 508 policies include:

External and internal user interfaces
Hardware and software products, including Commercial Off-the-Shelf (COTS) and custom products
Development and maintenance tools
External and internal reports or other artifacts created by CMS applications or tools
Electronic documentation
Support services

CMS Guidance

CMS provides resources for Section 508 compliance, including policies, validation procedures, and a list of CMS Section 508 Clearance Officers, at: Section 508 and CMS.

PREFERRED: Additional CMS guidance and resources are found in Application Development, Web-based UI Services, as well as in the CMS Design System.

The CMS Section 508 Policy provides a clear rationale and compliance road map for CMS Processing Environments and applications and takes precedence over the CMS TRA. The following paragraphs summarize the basis for these requirements, which is explained further in the CMS Section 508 Policy.

In 1986, Congress added Section 508 to the Rehabilitation Act of 1973. Section 508 established non-binding guidelines for IT accessibility. On August 7, 1998, the president signed into law the Workforce Investment Act of 1998, which included amendments to the Rehabilitation Act. These amendments significantly expanded and strengthened the IT accessibility requirements in Section 508 and made them binding on federal agencies.

Section 508 applies to Information Communication Technology, previously referred to as Electronic and Information Technology (EIT). Section 508, as amended, specifically requires that, when federal agencies develop, procure, maintain, or use ICT:

Individuals with disabilities who are federal employees shall have access to and use of information and data that is comparable to the access to and use of the information and data by federal employees who are not individuals with disabilities; and
Individuals with disabilities who are members of the public seeking information or services from a federal department or agency shall have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities (FAR 39.201 and 36 CFR 1194.1).

Section 501 of the Act requires CMS to be a model employer of people with disabilities. Section 504 requires CMS to ensure equally effective access to its programs and services. CMS can reach both objectives only if it adheres to the requirements of Section 508.

Relevant Section 508 Standards for CMS IT

The CMS Section 508 policy is based on the standards described in the following subtopics.

U.S. Access Board 508 Standards for Information Communication Technology

The U.S. Access Board’s Information and Communication Technology Revised 508 Standards and 255 Guidelines apply to a wide range of products and services, including but not limited to, the following:

Computers
Telecommunications equipment
Multifunction office machines (e.g., copiers/printers, software, websites, information kiosks, and transaction machines)
Electronic documents

The final rule jointly updates requirements for information and communications technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Telecommunications Act. The Section 508 Standards apply to electronic and information technology procured by the federal government. The Section 255 Guidelines address access to telecommunications products and services and apply to manufacturers of telecommunication equipment.

Web Content Accessibility Guidelines 2.1

Web Content Accessibility Guidelines (WCAG) 2.1 define how to make web content more accessible to people with disabilities. WCAG 2.0 is developed through the World Wide Web Consortium (W3C) process in cooperation with individuals and organizations around the world. The goal is to provide a shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally. WCAG 2.0 is designed to apply broadly to different web technologies now and in the future, and to be testable with a combination of automated testing and human evaluation. WCAG 2.0 has three conformance levels, including A (lowest), AA, and AAA (highest). CMS requires that the WCAG 2.0 standards be met at both the Level A and Level AA conformance level.

Web accessibility depends on accessible content as well as accessible web browsers and other user agents. Authoring tools also have an important role in web accessibility. For an overview of how these components of web development and interaction work together, please refer to the following links:

PDF / UA

The Portable Document Format/Universal Accessibility (PDF/UA-2) standard, defined by ISO 14289-2:2024, describes technical requirements for universally accessible PDF documents by identifying a set of relevant PDF functions (including text content, images, form fields, comments, bookmarks, and metadata) based on ISO 32000-2:2020 (PDF 2.0) and specifies how they should be used in PDF/UA-compliant documents. Successful access to content within PDFs depends both on compliant documents and compliant PDF programs and assistive technology. PDF/UA therefore also specifies requirements for compliant assistive technology.

For assistive technologies to work properly with PDF/UA, they must meet the following requirements:

They must be able to recognize all structural elements, attributes, and key values used in the specification and output them for the user of a PDF document.
They must allow the user to navigate through the document by page number, through the structure tree, or by using bookmarks.
They must allow the user to easily set and change the magnification of a PDF document at any time.

Document Accessibility at CMS and HHS Section 508 Compliance Checklist

For information about designing accessible documents that adhere to HHS’s requirements, please refer to the HHS Section 508 Accessibility Conformance Checklists.

HHS Guidance

HHS Web Standards apply to all HHS Office of the Secretary (OS) websites—including all Operating Divisions (OPDIVs) / Staff Divisions (STAFFDIVs) and Secretarial Priority websites, whether aimed at internal or external audiences. These standards are required for the design and development of all HHS/OS websites and may be adopted by OPDIVs.

The Framework covers all HHS web sites, internal or external, that are owned, managed, or funded by Operating and Staff Divisions, including CMS, whether developed by staff or acquired through contracts, cooperative agreements, grants, and/or formally established partnerships with other government entities and/or the private sector. The Framework covers traditional web content, including all attached or linked HHS files, and all news and social media, including videos, podcasts, blogs, Wikis, and associated applications on all HHS web sites.

CMS Testing for 508 Compliance

CMS uses the following tools and methods to test IT products and artifacts for Section 508 compliance:

Manual code review
Review of system development test plans
JAWS screen reading software
Dragon translation software speech-to-text
Zoom Text screen magnification software

CMS Strategic Guidance and Preferred Solutions

Introduction

The architectural guidelines described by the CMS TRA are designed to provide flexibility to development teams in choosing a technical approach, and yet there are cases where CMS has a strongly preferred approach or solution option. This section provides information about such Strategic Guidance and Preferred Solutions.

CMS systems and data must be protected from a constantly evolving threat and vulnerability landscape. Aligning to strategic guidance and utilizing preferred solutions strengthens CMS security posture through extending the use of thoroughly validated and tested security controls and procedures. Maintaining CMS data within the CMS security boundary facilitates CMS stewardship of the data.

The use of preferred solutions also shortens time-to-delivery, reduces redundant development, facilitates efficient use of infrastructure, and leverages CMS strategic investments and economies of scale. This aligns to the TRA Guiding Principle of Reuse as well as broader federal IT policy (see Office of Management and Budget (OMB) Memorandum M-19-16, Centralized Mission Support Capabilities for the Federal Government, April 26 2019, and Federal Shared Services).

The goal is to speed secure system deployment by utilizing existing solutions that may provide built-in automation, approved security configurations, and pre-authorized infrastructure. Use of these solutions is strongly encouraged unless there is a more compelling business case for an alternative.

CMS encourages its organizations to maximize the benefits of utilizing the Microsoft 365 Government Community Cloud (GCC) capabilities through the CMS tenant. All CMS email accounts include G5 subscriptions that provide access to Office 365 applications, storage, and other advanced security and data management features. CMS has completed transition from Zoom to Microsoft Teams for all CMS-hosted meetings and is migrating from the on-premises SharePoint 2019 environment to SharePoint Online.

The CMS TRA will provide high-level information about preferred solutions. Detailed information including their setup and use will be found through the supplementary sources/ links to additional information.

Note that hyperlinks in this section may refer to CMS internal information sources; a CMS EUA ID and access to the CMS intranet may be required for access.

Additionally, links to Strategic Guidance and Preferred Services will be included throughout the TRA, aligned to associated TRA guidance.

PREFERRED - CMS strategic guidance and preferred solution information throughout the CMS TRA will appear like this.

Enterprise Services

The preferred solutions in this section are CMS “enterprise services”, based on an expanded definition of the term. The updated CMS definition of enterprise services reflects that these capabilities may be developed and provided by any CMS Center or Office or by a vetted partnership of Centers/Offices. This includes but extends well beyond centrally provided “shared services”. In the new model, enterprise services can be leveraged as a shared capability or provide a pattern for a new implementation if required.

A CMS enterprise service may be leveraged without onboarding with an established support organization or a central enterprise instance. CMS encourages the use of the most appropriate deployment model depending on business requirements. A project might, for example, choose to deploy a parallel instance but still use the standards and processes of the enterprise instance, potentially enabling them to utilize existing support staff. An existing, validated solution can be used as an architectural pattern, with any refinements shared back with the original.

The overall group of enterprise services form a federated set of capabilities which development teams can tap into, avoiding duplication and aligning with CMS standards.

Data Stewardship and Governance

Sound data stewardship practices are essential to the protection of CMS data. The risk of data compromise is exacerbated when CMS data is moved or copied outside of the CMS security boundary. With the shift to flexible cloud computing environments, CMS now has the capability and capacity to provide for very large and complex data storage and analytics requirements. Keeping CMS data and associated data processing and analysis within the CMS security boundary enables CMS to maintain provenance and proper stewardship of CMS data.

As such, CMS policy is that all CMS data remain within CMS authorization boundaries, except for public data released by CMS. Business requirements to do otherwise will be reviewed on an exception basis to ensure appropriate controls (which may include a Data Use Agreement) are in place. A new TRA section, Data Sharing and Governance provides additional information on this topic. It also introduces Business Rule BR-DG-1, which reinforces the imperative to keep CMS data inside CMS boundaries, while Recommended Process RP-DG-2 suggests some ways to accomplish this.

CMS Cloud is the preferred environment for CMS data storage and analytics.

Preferred Solutions

CMS Preferred Solutions are presented here in the following categories:

CMS Hybrid Cloud
CMS Enterprise Data
CMS DevSecOps Support
CMS Collaboration Capabilities

Note that the list of Preferred Solutions will evolve over time. Additional sections and solutions will be added in future TRA releases.

CMS Hybrid Cloud and CACHE

The CMS TRA supports the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kundra, February 14, 2011) Cloud First Policy as well as the Federal Cloud Computing Strategy’s (OMB/Federal CIO Kent, June 24, 2019), Cloud Smart Policy.

CMS Hybrid Cloud is the strongly preferred hosting platform for all CMS developed applications. It provides the most operationally integrated and cost-effective platform solutions. In addition to “self-service” cloud computing with guardrails, CMS Cloud features managed Infrastructure-as-a-Service (IaaS) environments for both Amazon Web Services (AWS) and Microsoft Azure Government (MAG), as well as for CMS on-premises data centers.

The CMS TRA chapters on Cloud Infrastructure and Virtualization, among others, address CMS Hybrid Cloud services.

CACHE and DRaaS-CACHE

The Continuously Available CMS Hosting Environment (CACHE) service offerings provide the primary on-premise infrastructure hosting platform, with seamless integration with the overall CMS hybrid enterprise environment. These include:

Geo-diverse data center and hosting within the DRaaS-CACHE FISMA boundary
Full Infrastructure-as-a-Service (Iaas) virtualized environment
Application Workload hosting across multiple computing platforms, including Mainframe, Open Systems (x86), and hybrid cloud, as well as multiple storage platforms, including disk, tape, and file-level
Comprehensive Disaster Recovery as a Service (DRaaS) with next-gen replication capabilities across multiple technology platforms
Enterprise Services that include robust Application and Network Load Balancing, Domain Name Service (DNS), Directory Services (LDAP), and Time Services (NTP)

Critical applications that support CMS programs and operations should, if managed by CMS, rely on DRaaS-CACHE to protect both their system availability and their data.

CMS Enterprise Data

CMS maintains several preferred solutions for accessing and managing CMS program data:

The Integrated Data Repository (IDR) Cloud is a high-volume cloud data platform integrating Medicare claims with beneficiary and provider data sources, as well as such ancillary data. This robust, integrated data supports mission-essential analytics in CMS and in other government agencies. It also helps to prevent the proliferation of replicated data sources that perpetuate data inefficiency, duplication, inconsistency, inferior quality, and increased costs for associated infrastructure.
The IDR Enterprise Data Product (EDP) now supports the data mesh functions of the previous Enterprise Data Mesh (EDM), which was decommissioned in 2024. Based on the IDR’s Snowflake implementation, the EDP maintains a central point where systems and individual users can find, locate, access, and use CMS enterprise information with “data in place.” This enables data owners and curators to focus on data and data quality while also enabling consumers to bring their own preferred compute resources, analytics, and APIs. Additionally, the EDP enables a wide spectrum of programs and consumers to leverage program data sets with close to zero provisioning time with their choice of tools and technologies optimal for their use case.
CMCS DataConnect is an all-in-one cloud analytics platform for the Center for Medicaid & CHIP Services (CMCS) data. DataConnect provides a range of capabilities to streamline Medicaid and CHIP program analysis, monitoring, and oversight. It includes dashboards, tools, and datasets to enable CMCS staff, researchers, and other data experts to produce meaningful insights from complex data.
CMMI Analysis and Management System (AMS) holds key information about CMMI models and demonstrations. AMS helps stakeholders access information about, and collected by CMMI models.
CMS Master Data Management (MDM) has provided a single point of access to a singular, synchronized, comprehensive and ID-resolved authoritative source of Provider and other data for use by CMS and other external organizations. MDM provided support across multiple CMS business units with a focus on eliminating redundancy, inconsistency, and fragmentation of CMS data. IDR, IDR Enterprise Data Product, and CMCS DataConnect have all relied on this authoritative data.

MDM is scheduled to be retired in February 2027. Support of this data management functionality is migrating to the CMMI Analysis and Management System (AMS), Integrated Data Repository (IDR) Cloud, IDR Enterprise Data Product (EDP), and CMCS DataConnect. ID Resolution will be performed as needed within these systems, as well as by the Center for Clinical Standards & Quality (CCSQ) and the Center for Program Integrity (CPI).

CMS Research Data Assistance Center (ResDAC) provides technical assistance to researchers interested in CMS Medicare and Medicaid data. Various data sets are available; however, access is restricted to approved research requests. Public use data files (which contain no protected information) are available via data.CMS.gov

CMS DevSecOps Support

A key goal of the CMS TRA is to support sound and secure software development practices. The DevSecOps tooling landscape is vast, and it can be challenging to determine which solutions are the best match for project requirements. CMS has preferred platform and tool options available which can help development teams manage and secure development pipelines.

Enterprise Services are preferred over other project specific services as they offer potential operational and/or cost benefits. Existing systems are encouraged to utilize enterprise services wherever possible.

CMS DevOps Tools
- GitHub is a common repository platform, used to distribute open-source software and other content. Thus, it is both a DevOps and a collaboration tool. Premium Enterprise GitHub provides advanced management and security features. CMS has implemented GitHub Copilot, an AI coding assistant (see TRA recommended practices for AI-Assisted Coding).
  - SaaS GitHub instances include OC Tools-supported CMSgov and theCMCS | MACBIS organization that collaborates with states and other Medicaid and CHIP partners.
  - CMS Hybrid Cloud supports SaaS-based OIT Enterprise GitHub, which provides enterprise-grade collaboration, security, and administration.
  - OC GitHub Enterprise is supported by the Web Help Service Desk. It is primarily for support of public-facing medicare.gov, healthcare.gov, cms.gov, and their related applications and ADOs. During the first half of 2026, the OC Web and Emerging Technologies Group (WETG) is migrating these repositories from this internal GitHub to CMSGov.
  - CCSQ manages an additional GitHub Enterprise instance.
  - The Open Source Program Office provides an additional GitHub repository containing additional tools, templates, and other information about using and share open source software.
- CloudBees CI is a continuous integration, deployment, and delivery (CI/CD) server solution
- JFrog Platform is comprised of Artifactory, a binary repository manager and XRay, an add-on to the Artifactory product used to enhance the security posture
CMS Testing
CMS provides Testing as a Service (TaaS), a CMS Cloud offering that provides a suite of products support application teams with test case management, functional and regression test execution, and performance test execution. This includes:
CMS Security Scanning and Analysis
These CMS Cloud inspection and analysis tools support application security and vulnerability management for both developers and the security team:
- SonarQube, which provides static code analysis. Static code analysis attempts to highlight possible vulnerabilities within ‘static’ (non-running) source code by using analytic techniques.
- Snyk (“sneak”), a SaaS-based system composition analysis (SCA) tool that enables applications to be developed and built securely. SCA identifies the open-source software in the codebase. This analysis is performed to evaluate security, license compliance, and code quality. It proactively finds and fixes vulnerabilities in codes, open-source dependencies, container images and Infrastructure as Code (IaC) configurations, and offers context, prioritization, and remediation.

CMS Collaboration Capabilities

A number of enterprise collaboration tools are available within the CMS environment to facilitate data sharing and team communications, supported by OIT and the Office of Communications (OC). These include:

Jira and Confluence:
- Atlassian Jira is an application lifecycle management solution that helps teams plan, manage, and report on their work. It is used for bug tracking, issue tracking and project management.
- Atlassian Confluence is a team workspace providing teams a place to create, capture, and collaborate on project information including text, tables, images, and other content.

The CMS Cloud Agile Tools Team supports Enterprise Confluence and Enterprise Jira, with integrated TestRail. The Office of Communications provides OC Jira and OC Confluence, primarily for support of public-facing medicare.gov, healthcare.gov, cms.gov and their related applications.

SharePoint is an application platform that allows organizations to store and organize any content and information. That includes documents, images, videos, news, links, lists of data, web pages, and tasks. The CMS Enterprise SharePoint Support (ESS) team supports the SharePoint Online (SPO) environment.
- CMS SharePoint Online (SPO) is the new home of CMS-wide enterprise information. In addition to new sites being created for all CMS Centers and Offices, the entire contents of the decommissioned On-Premise SharePoint have been migrated to cmsgovonline.sharepoint.com. These include:
  - share.cms.gov
  - capms.cms.gov
  - cmsintranet.share.cms.gov
  - mysite.share.cms.gov
  - pbrs.cms.gov
- SharePoint Online is part of the CMS Microsoft 365 SaaS enclave.
Slack is a workplace messaging tool through which CMS employees and contractors send messages and files, defining and using specialized and general channels that contain message threads. Some chat and meeting functions will migrate to Microsoft Teams.
Microsoft Teams is also part of the CMS Microsoft 365 Government subscription. Microsoft Teams is a collaboration tool designed to enhance productivity by integrating with other Microsoft products and providing a centralized space for communication, file sharing, chat, and meetings. Preliminary guidance is available. Transition to Teams from Zoom Workplace took place during 2025. Partial transition from Slack is also planned.
Another feature of Microsoft 365 is OneDrive. OneDrive provides backing cloud storage for M365 tools such as Word, Excel, PowerPoint, Teams, and SharePoint. Note that CMS Enterprise SharePoint Online is managed separately from SharePoint sites for Teams and Channels. CMS is migrating CMS Box users to OneDrive, primarily for secure sharing within CMS. Box remains available, primarily for external sharing.

Please also see CISO Memorandum 25-01: Updated Best Practices and Guidance for the Use of Approved CMS Collaboration Tools.

Artificial Intelligence Guidance

Introduction

Artificial Intelligence (AI) tools and technology are rapidly evolving with the promise of enabling increased efficiency, insight, and analysis across a broad range of use cases. CMS is embracing AI to improve health care administration and delivery. At the same time, policies, processes, and mechanisms are being established to ensure that AI-enabled systems at CMS are developed, deployed, and used responsibly and ethically, mitigating risks and protecting sensitive information while also maximizing benefits for CMS and beneficiaries.

Aligned to federal guidelines (see ai.cms.gov), this section provides current AI-related policies and recommended practices at CMS. Given the dynamic nature of the AI domain, frequent updates and changes are expected. It is not intended as a primer on AI technologies or approaches. Additional information on those topics can be found within the CMS AI Playbook and Technical Application Resources.

More policy guidance can be found in the HHS Intranet: “Reminder of Existing HHS IT User Policies Relevant for Third-Party Generative AI Tools,” “HHS Policy for Securing Artificial Intelligence (AI) Technology,” and “HHS Policy for Rules of Behavior for Use of Information and IT Resources.”

Additional Considerations

Accountability and Oversight

All individuals and teams employing AI or Machine Learning (ML) at CMS are responsible for the system's output, regardless of the model or tools used. The “owner(s)” of this output are also required to use the appropriate mandated security controls for “sensitive” and especially “privacy data” assets. Continuous human oversight is required to ensure CMS and federal guidelines are met.

Risk Management and Security

AI Model Supply Chain and Provenance

In the modern information security landscape, AI-driven supply chain attacks are a concern. These can introduce malicious code through compromised AI models, data, or code repositories. Teams deploying AI models should ensure the provenance and integrity of AI components used in production.

Example: The “Model Namespace Reuse” attack, demonstrated against Google and Microsoft products, highlights the risk of trusting a model based on its name alone. This form of attack can enable a threat actor to gain code execution permissions and gain access to underlying infrastructure.

Recommendation: Implement System Composition Analysis to verify the origin and integrity of AI dependencies.

Embracing a Zero-Trust Architecture for AI

Using AI technology that can perform outbound internet requests can introduce risk to CMS environments, including sensitive code and data that could be transmitted outside the network.

Recommendation: Teams should perform threat-modeling and risk assessments to ensure proper network segmentation and limit an AI tool’s access to only the necessary resources to contain the blast radius of any potential breach. Implement Data Minimization principles to ensure AI tools access only the information strictly necessary for their function. See The TRA section Zero Trust Architecture.

Monitoring, Versioning and Observability for AI and Production Operations

System maintainers must implement observability to understand how their AI systems are behaving over time. This requirement supports debugging, security, and continuous improvement, and ensures alignment with OMB M-25-21 and M-25-22.

Recommendation: Track traces, evaluations (EVALs), prompt management or versioning, and key metrics for production systems using AI.

Recommendation: Prompts — AI system prompts used for production at CMS systems should be versioned (See BR-SCM-1). Store prompts (or reusable “recipes”) and review them and measure their performance over time.

Data Handling, Data Retention and Privacy

Privacy-Preserving Techniques

When developing and testing AI models that handle sensitive data, teams should adopt privacy-preserving techniques like federated learning and homomorphic encryption. These methods allow for model training and inference on encrypted or decentralized data without direct sensitive data exposure.

Use of Synthetic Data for AI Initiatives

The use of synthetic data is highly recommended to avoid the use of sensitive Personally Identifiable Information (PII) or Protected Health Information (PHI) in development and lower environments entirely. This mitigates the risk of exposure and simplifies compliance.

Examples: AI techniques like Generative AI, GANs and VAEs, and initiatives like SyntheticMass and Synthea™ [can also be used to avoid the use of sensitive PII or PHI from development and lower environments entirely at CMS.

Review Data Rights, Retention Policies prior to the use of External AI Tools and Services

The use of AI tools, services or infrastructure external to CMS may introduce risks, including companies that train or fine-tune AI models using CMS non-public code, data or metadata.

Recommendation: Application teams, CMS system owner or business owners introducing new AI technology into their systems should ensure compliance with CMS security and privacy requirements, and that appropriate data use agreements are in place before incorporating external AI systems that can access non-public CMS data . Teams should be especially careful with Terms of Use and Agreements that enable the training, share or selling of CMS data. For inquiries, consult with the CMS Privacy Office.

AI Services and Data Retention: Content generated by your AI system may be subject to Data Retention policies and FOIA. For inquiries, consult with Records_Retention@cms.hhs.gov. .

Overall AI Business Rules

BR-AI-1: AI Tools and Services Must Meet Federal AI, Cybersecurity and Privacy Standards in the Handling of Sensitive Data

Sensitive data, including Protected Health Information (PHI), Sensitive Personally Identifiable Information (SPII), classified, export controlled, trade secret and other confidential information may only be used with AI tools and services that meet HHS and CMS Cybersecurity Standards.

To ensure compliance and protect privacy, consult with the CMS Privacy Office in relation to AI tools and Services that could handle sensitive data.

Rationale:

All HHS and CMS policies regarding AI use, Personally Identifiable Information (PII) protection, and data security (including storage, transmission, and sharing) must be adhered to in order to ensure proper implementation of AI risk management practices per the HHS AI Strategy and HHS Compliance Plan for OMB Memorandum M-25-21.

Also see in the TRA: BR-F-5: Any System That Processes CMS Data Must Be Covered by a CMS ATO; BR-SQ-6: De-Identification of Production Data Is Required in Non-Production Environments; NIST SP 800-122, “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII);”NIST SP 800-18, ”De-Identifying Government Datasets: Techniques and Governance.”

BR-AI-2: High-Impact AI Use Cases Must Meet Minimum Risk Management Practices

A high-impact use case, as defined in the Office of Management and Budget (OMB) Memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, is one where the AI’s output serves as a principal basis for decisions or actions that have a legal, material, binding, or significant effect on specific critical areas.

A CMS AI Governance risk assessment will determine if an AI use case is high-impact. All CMS high-impact use cases must apply minimum risk management practices in accordance with M-25-21.

Contact CMS IT_Governance for an AI Governance Risk Assessment.

Rationale:

Non-approved AI tools may retain or use submitted information in ways that could expose CMS sensitive data. Attackers may be able to steal sensitive data by manipulating prompts or exploiting vulnerabilities in AI systems. Non-approved AI tools may not be compliant with evolving federal regulations regarding data protection, records retention, consumer rights, and algorithmic transparency. Additionally, these tools may lack the security controls and oversight mechanisms required for handling federal government data within established security boundaries.

BR-AI-3: Foreign Entity AI Tools May Only Be Used if Deployed on CMS Infrastructure

With the rapid introduction of new AI capabilities into the market, it can be difficult to determine which are aligned to federal government requirements. AI technology from foreign entities can be used if it’s deployed on CMS infrastructure and does not send data to the internet. This aligns with the principle of CMS data staying within the United States (see BR-SAAS-8: CMS Data Must Always Reside in the U.S.). Such deployments must utilize normal CMS and AI governance processes, including the CMS Risk Management Framework and the NIST AI Risk Management Framework.

Rationale:

The use of unapproved or foreign AI tools and models could compromise CMS information. Foreign AI models, especially those from countries with broad government access to data, could be used for surveillance and the collection of sensitive personal information. Third-party AI models may lack sufficient security controls, potentially exposing the systems to data breaches.

BR-AI-4: Human Review Must Follow Use of AI Tools to Write CMS Policies

Individual CMS employees are accountable for official CMS policies. AI tools are only to be used in support of and not as a substitute for human decisions and oversight of CMS strategic or compliance-related activities. Humans must be in the loop.

Rationale:

AI tools lack the capacity for human judgment and critical thinking, which is crucial for interpreting complex situations, considering ethical implications, and crafting policies that fully align with CMS’ values and objectives. AI tools may generate false or misleading information as factual and may reflect biases present in their training data.

BR-AI-5: Do Not Rely on AI for Final Decisions for “High Impact” Cases

AI should provide advice or recommendations; final decisions must be made by qualified staff with documented oversight. AI use cases for these purposes are considered potentially “High-Impact AI,” and actions they support may risk compliance with privacy and civil rights requirements.

Rationale:

OMB memorandum M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust defines “High-Impact AI” as “AI with an output that serves as a principal basis for decisions or actions with legal, material, binding, or significant effect on:

“an individual or entity’s civil rights, civil liberties, or privacy; or
“an individual or entity’s access to education, housing, insurance, credit, employment, and other programs;
“an individual or entity’s access to critical government resources or services;
“human health and safety;
“critical infrastructure or public safety; or
“strategic assets or resources, including high-value property and information marked as sensitive or classified by the Federal Government.”

AI tools lack the capacity for human judgment and the nuanced perspective necessary to make complicated decisions. High-Impact AI risks need to be managed.

BR-AI-6: AI-Supported Official Actions Are Subject to Records Retention Requirements

When AI provides work products in support of official CMS actions that would be subject to records retention, those work products become part of the record and must be retained according to the applicable records retention schedule. Those AI-created work products must include the AI model version and the prompt(s) used.

Rationale:

“Adequate and proper documentation” (per 44 U.S.C. Chapter 31 §3101) supporting official CMS actions are part of the action. This supports transparency of AI use. For more information, consult with the OSORA Issuances, Records & Information Systems Group.

AI-Assisted Coding Guidance

Recommended practices regarding AI-assisted coding are available within the TRA Application Development section on AI-Assisted Coding.

Threat Modeling for AI Systems

See TRA Recommended Practice AD-SS-8: Perform Threat Modeling During the Design Phase to Identify Potential System Threats. Additional recommended practices regarding performing Threat Modeling for AI systems can be found in A Practical Understanding of Threat Modeling for AI Systems

AI Recommended Practices

This section provides Recommended Practices information for AI overall and for specific AI concepts.

RP-AI-1: Release and Maintain AI Code as Shareable Open Source Software

CMS projects must prioritize sharing AI code, models, and data government-wide, consistent with the Open, Public, Electronic and Necessary (OPEN) Government Data Act. Custom-developed AI code is also covered by the SHARE-IT Act and OMB M-25-21. More information is found in the TRA Application Development section on Open Source Software.

AI Prompt Crafting

Prompt Crafting is the practice of writing clear and helpful directions that a large language model (LLM) can use to generate more accurate, relevant, and useful outputs for a given task or question. This is like providing a person the right level of contextual detail and specific instructions to complete a task in the manner it is to be completed. For the best results using LLMs, it is important to build instructions and relevant details in a similar manner- by providing the task to accomplish, the role that the AI is taking on to complete it, any relevant reference materials as context, and the desired response format.

Prompt Crafting is the bridge between human intent and LLM capability. It is the heart of what determines the quality and usefulness of AI-generated responses from LLMs. In the context of CMS Chat, effective prompting enables users to interact with documents, synthesize information across sources, and generate new content effectively.

For CMS, effective Prompt Crafting matters because it:

Improves the accuracy and reliability of AI-generated outputs
Increases consistency in AI interactions across the organization
Reduces the likelihood of AI hallucinations or incorrect responses
Enhances the user experience of staff using CMS Chat
Increases the efficiency of the AI and reduces time and compute costs

The following best practices can be applied to effectively use chatbots like CMS Chat to enhance the user experience and ensure more accurate and useful AI interactions

RP-AI-2: Clearly define the context of the prompt

Be specific about which aspects the AI is to focus on and what type of analysis is needed. Provide relevant background information, specify limitations, include domain-specific terminology, and define the scope of the response

Example: “Within the context of the 2024 Medicare Physician Fee Schedule final rule, focusing specifically on telehealth provisions, analyze the requirements for audio-only services.”

RP-AI-3: Clearly define the role the AI should adopt

This approach provides clear context for the AI’s responses, helps maintain consistent tone and expertise level, and enables more targeted and relevant outputs.

Example: Instead of “Tell me about Medicare Part B coverage,” use “Within the context of the 2024 Medicare Physician Fee Schedule final rule, focusing specifically on telehealth provisions, analyze the requirements for audio-only services.”

It is also possible to provide roles that the AI can use to tailor the generated output.

Example: “Act as an experienced Medicare benefits counselor with 15 years of experience explaining coverage to beneficiaries. Explain Medicare Part B coverage in simple terms.”

RP-AI-4: Break down complex requests into clear, sequential steps

This approach helps AI systems provide more organized and concise responses. When analyzing documents or synthesizing information, structure prompts to guide the AI through the process.

Example: “First, analyze the key points of this policy document. Then, identify any changes from the previous version. Finally, summarize the potential operational impacts for the policy team.”

Sometimes, it’s best to break these steps into separate prompts for each step. AI have a maximum amount of response length they can provide, so allowing them to focus on one step at a time, with a full response at each stage, may provide better end results. This is also true when you have large documents. The AI can be asked to review the first chunk of text, then the next, and so on until the needed details are derived from the entire document.

Example:

Prompt 1: “Analyze the key points of this policy document.”
Prompt 2: “Review the key points provided and identify any changes from the previous version.”
Prompt 3: “Based on the output in the previous response, summarize the potential operational impacts for the policy team.”

RP-AI-5: Provide Guidelines

Outline any scoping, rules, writing styles, or specify any specific format requirements for the response, such as using headers, bullet points, or specific citation formats. Clearly communicate how the information should be presented.

Example: “Present your findings in a structured format using headers to break up the text, followed by a few sentences that explain the header, and then bullet points to breakdown the main points.”

Sometimes, more complex guidelines and response formats are necessary. It’s possible to instruct many AIs to respond in structured formats while also demanding it utilize a specific approach, style, or scope.

Example: “Present your findings in a structured table format. I’d like columns A, B, C, and in A, please create categories for the text, followed by a brief description of each in B, then bullet points to breakdown the main points in C. Write in the style of a CMS Policy Expert but be concise and clear. Avoid jargon or complex topics. Instead, focus on clarity and simplicity.”

RP-AI-6: Create New Chats or Sessions When Switching Topics

It is best to create a new chat or discussion session when switching topics. The context of conversations in generative AI prompting sessions is typically stored and available throughout a single chat. Unless the context of the entire chat is needed for the next query, it is recommended to create a new conversation, so the AI does not hallucinate or conflate topics. For example, if the AI was asked in one chat to clean up a project presentation, then instead of asking how to write a policy document in the same chat, start a new one with the right level of context provided to ensure the AI has no distractions from the desired intent.

RP-AI-7: Use Structured Prompts

The best prompts are structured with all the details covered in the previous best practices in mind. A recommended structure template to get the best results is:

[Task] + [Role] + [Guidelines] + [Reference Context (Reference Materials)]

Each are further defined below:

[Task] – The action(s) you wish the AI to take based on the [Role], [Guidelines], [Format Requirements], and [Reference Context (Reference Materials)]
[Role] – The role that the AI is to take on to complete the [Task]
[Guidelines] – Rules or guidance for the AI to ensure it accomplishes the task as expected. This may include the expected output structure/format or instructions on how to write (perspective, style, etc.), and other guidance for the AI
[Reference Context (Reference Materials)] – Relevant attachments, details, documentation, resource materials, etc. that can act as the source of truth for the AI to accomplish its [Task]

Example:

Task: “Please create a categorized list of Medicare Part B rules relevant to a retiree from Tennessee.”

Role: Act as an experienced Medicare benefits counselor with 15 years of experience explaining coverage to beneficiaries. Explain Medicare Part B coverage in simple terms. You complete TASKS based on the GUIDELINES and REFERENCE CONTEXT and respond as outlined by the FORMAT REQUIREMENTS

Guidelines: Please respond in a bulleted or tabular format. Responses should be concise, but fully explained in a style most suitable to the intended audience. Note if any relevant details may be missed and what additional actions should be taken to ensure the [Task] can be completed.

Reference Context: *Attached Document* “OR [Copy/Paste text from the appropriate documentation]”

RP-AI-8: Use Iterative Refinement

Prompt Crafting is not a one-time process but rather an iterative approach that involves starting with a basic prompt, evaluating the response, refining the prompt based on the output, and then testing and validating any improvements. It is also a creative process — one that benefits from continuous experimentation and adjustment to ensure the AI’s responses align with evolving requirements and user needs. By reviewing each new output, identifying gaps or inaccuracies, and incorporating feedback into the next version of the prompt, steady improvements will be achieved in both the clarity and effectiveness of AI interactions.

RP-AI-9: Recommended AI-Assisted Development Methodologies

Recommended Workflow Steps:

Specify: Create a formal, human-readable specification that defines the goals in accordance with best-practices.
Plan: Use AI to generate a technical plan based on the spec and enterprise standards.
Implement: Use AI to break down the plan into small, testable tasks and generate code.
Review and Verify: A developer reviews each code change for accuracy, security, and quality. Automated testing and security checks run in CI/CD.
Iterate: If issues are found, refine the specification or prompts and re-run the cycle.

CMS Processing Environments

A CMS Processing Environment is defined as any computing environment that creates, consumes, and/or stores CMS data, as defined in the CMS Data and CMS Sensitive Information definitions. The CMS TRA applies to all CMS Processing Environments that CMS controls. This includes all production environments having a CMS Authorization To Operate (ATO) and any development or testing environments residing in data centers that host CMS workloads.

The CMS TRA refers to production environments as ATO(ed) environments. CMS TRA guidance for production environments also applies to any non-production environment with an active CMS ATO, as such environments must be managed and secured like a production environment to maintain its ATO.

By convention, there are three types of processing environments: Development Environments, Validation Environments (sometimes known as Implementation), and Production Environments (also known as Operational environments). These environments provide a set of high-level stages corresponding to a software promotion model, which follows the baseline progression as follows:

Development environments support multiple business application baselines, including the execution of functional testing, unit testing, application integration testing, and regression testing. When there is a significant defect in a baseline in one of the other environments, the baseline returns to the Development environment for repairs and other corrective actions.
Validation environments provide a staging area for production releases and evaluation of the final release versions of production code, database, and related packages for business applications. Many non-functional requirements (security, privacy, performance, and various “ilities” such as scalability and reliability) are tested here. CMS intends the Implementation environment for performance and stress testing, system and user acceptance testing, final integration testing, and security assessment. The Validation environment should be comparable to the production environment to promote CMS business owner confidence in the performance and functionality of the system.
Production environments provide stability and security for the final release versions of production code, database, and related packages. All production environments are required to have a CMS ATO.

Projects may select different naming conventions for their lower environments. CMS recommends, however, using Development and Validation because of their frequent use in CMS IT. Projects may choose to create additional lower environments as required to facilitate testing (e.g. Test environment; Integration environment). Projects may choose to perform activities such as Independent Validation and Verification (IV&V) or User Acceptance Testing (UAT) in whichever environment makes the most sense for the project.

Each environment should emulate the production environment; accordingly, the infrastructure must mirror production in versions, patch levels, configurations, and network. Development and testing services may be provided, such as performance testing, functional compatibility testing, and performance monitoring.

Business application code and database changes, including break-fix, must be tested successfully in a development or test environment before promotion to the next higher environment. Related changes to infrastructure services (such as firewalls and switches) must be tested in a development or test environment before deployment to the implementation environment.

Non-ATO(ed) environments may not contain sensitive information. As described in Business Rule (BR) BR-F-5, CMS prescribes the removal or replacement of personal identifiers, other personalizing information, and other CMS sensitive information to render information anonymous before it may be loaded into an environment not covered under an ATO. Redaction of sensitive data must occur in an environment covered under an ATO. Existence of Personally Identifiable Information (PII), Protected Health Information (PHI), or other CMS sensitive information in any environment causes that environment to require production-level security, privacy controls, and coverage by ATO, regardless of its name.

Development Environments

A development environment supports business application baselines during code and database development, and for development testing functions. The data center may support multiple instances of a development environment to accommodate development of multiple variants of a business application.

Validation Environments

The validation environment provides a secure, locked-down staging area for production baselines and for evaluating the final release versions of the production code, database, and related packages for the business applications. It is used to perform implementation testing and to complete business application testing before release into the production environment. This includes validating system performance, events, alerts, and notifications. CMS may provide support from this environment for end-user training on system usage and functionality as well as for access to training data.

There may be multiple instances of a validation environment to support the testing of a business application (or multiple versions) and its preparation for promotion to the production environment. The validation environment must maintain an image of the last successfully tested version of a business application code and database.

The validation database should be approximately the same size as the production database (for realistic performance testing) and, if it has been issued an ATO, may contain sensitive information. If it contains sensitive information, the implementation database must be protected to the same standards as the production database (please refer to BR-F-5.)

All changes to the validation environment must be subject to CMS change management. Additional requirements and constraints include, but are not limited to:

Scheduling of operations in the implementation environment must include adequate time to roll back any changes, for example, changes to business application code and databases, and any infrastructure changes.
Troubleshooting of business application code and database errors will be limited to Root Cause Analysis (RCA) only.
Business application code and database changes, including break-fix changes, must be tested successfully before their promotion from the implementation environment to the production environment.
Changes related to infrastructure services must be tested successfully in the implementation environment before promotion to the production environment.

CMS ATO(ed) and Production Environments

CMS production environments are required to be ATO(ed) environments. CMS TRA guidance for production environments also applies to any non-production environment with an active CMS ATO, because such an environment must be managed and secured like a production environment to maintain its ATO.

An ATO(ed) environment provides a stable, secure, locked-down operational environment to complete the business application production baseline. This environment is inaccessible except to authorized operations and security personnel. Access to business applications will be provided via approved user interfaces only. Only the Administrator role will be granted server-level access to the CMS business applications in the ATO(ed) environment. (and must follow a Software Development Life Cycle (SDLC) driven promotion process).

All changes to the ATO(ed) environment must be subject to CMS change management. Additional requirements and constraints include, but are not limited to:

All production environments are required to have a CMS ATO.
All business application code and database changes, including break-fix, must be tested successfully in the implementation environment before promotion into a CMS production environment.
All related changes to infrastructure services must be tested successfully in the implementation environment before deployment to the CMS production environment.
Production-readiness testing is required for all initial deployment of business applications. Troubleshooting of business application errors will be limited to RCA only.
Monitoring & Reliability Testing is required for all initial deployment of business applications. New business application code, databases, and infrastructure migrated into the ATO(ed) environment will become part of the production baseline.

The quality of CMS’s production environments reflects on the organization’s reputation and public trust. Although the production environment may be used for quality assurance and testing, the CMS TRA generally discourages such use, suggesting instead that the validation environment be used for such tasks. This is true if the code or data tested could lead to incorrect or misleading results or behavior. The production environment may also be used for community verification of quality assurance of data.

Non-CMS Processing Environments

The CMS Processing Environments may interact with non-CMS processing environments.

Third-Party Websites and Applications

The HHS Office of the Chief Information Officer (OCIO) Policy for Social Media Technologies, March 07, 2012, Policy 2010-0003.1 includes managing the use of Third-Party Websites and Applications (TPWA) and establishes requirements for Department access to web-based technologies that are not exclusively operated or controlled by HHS. This policy is consistent with federal guidelines and regulations.

HHS-OCIO directs that TPWAs must be addressed in a Privacy Impact Assessment (PIA) and may require a Security Impact Analysis (SIA).

OMB Memorandum M-10-23, Guidance for Agency Use of Third-Party Websites and Applications, states:

The term “third-party websites or applications” refers to web-based technologies that are not exclusively operated or controlled by a government entity, or web-based technologies that involve significant participation of a nongovernment entity. Often these technologies are located on a “.com” website or other location that is not part of an official government domain. However, third-party applications can also be embedded or incorporated on an agency’s official website.

Social Media

The use of social media at CMS is governed by the Guidelines for Secure Use of Social Media issued by the CIO Council, and by HHS-OCIO Policy for Social Media Technologies. Also, see HHS Social Media Policies.

Services Framework Architecture

Services Framework - Concept

The CMS Services Framework provides a standardized template for implementing systems at CMS. This template or pattern details security and interoperability requirements. The goal of the framework is to maintain the integrity of CMS applications and data.

CMS Services Framework - Principles

CMS utilizes a Defense-in-Depth (DID) and a least privilege strategy to protect its assets. Defense-in-depth is a security strategy that uses a series of layered, redundant defensive measures to protect sensitive data, personally identifiable information (PII) and information technology assets. If one security control fails, the next security layer thwarts the potential cyber attack. Least privilege is the concept of restricting access rights of users to only those resources that are required for performing their legitimate functions. CMS’ services framework provides a structure for implementing security challenges to ensure CMS resources are protected.

The goal is to protect CMS assets and reputation. CMS data must be protected from unauthorized access. To minimize the impact of any breach, the egress of data from CMS must also be protected. Too many security implementations concentrate on protecting from unauthorized access but do very little in protecting the egress of data if a breach was to occur. The implementor must address the complete security picture, prohibiting unauthorized access to the data, as well as minimizing the ability to obtain (download) data when a breach has occurred. Security implementations are always a trade-off between risk and cost. The implementor should work with their ISSO (Information System Security Officer) to validate appropriateness of security controls for any implementation.

A key guidance to protect CMS data is to ensure that the overall architectural design is consistently putting CMS’ valuable data at least three independent legitimacy tests away from the open Internet. A legitimacy test is defined as the challenge, filtering or transformation of the data to obfuscate the technical details regarding the sensitive data. For more information regarding challenges, see the information on Mediation Principles. Within the CMS network, services may interface with any other available service, given that the proper authorization is in place.

The following topics will define the CMS services framework from a services perspective to detail the zoned architecture and the security obligations required to protect CMS assets. The TRA Multi-Zone architecture will be depicted as a services framework defined by requirements and risks rather than network routers, and will consider the role of each service, its interfaces, its parent services, and its dependent services in supporting TRA compliance.

Services Framework Architecture

CMS Services Framework

The architecture will be described by the set of services within the architecture, detailing the functions these services provide and the objectives for protecting these services. The following section of the TRA will discuss how these services can be applied.

The services framework is centered around core data, application, and edge services, integrated with management and security services. See the Elements of the Services Framework diagram below. Management and security services both enable administrative access to the system. Security services assist in cybersecurity threat detection and protection, as well as the compliance with CMS security policies. The management and security services are housed in different subnets, accessible only through a virtual private network (VPN).

Elements of the Services Framework

Core Services

Core services include data, application, and edge services. These services are detailed below.

Data Services

Data services are fundamental and the most basic component protecting the data. They are the components of the architecture that reside in front of and provide access to the data.

Services Framework Data Services

The data services must:

Restrict access to the data
Validate the caller (service consumer) has the appropriate access rights to the data services (producer)
Obfuscate implementation details from the consumer, not exposing data formats, credentials, etc. to the consumer.
CMS expects non-data services to front CMS data services. Data services are not directly accessible from outside a CMS data center.

Application Services

Application services are the components of the architecture that are generally responsible for housing the business logic. They are the consumer of data services and the producer of edge services.

Services Framework Application Services

The application services must:

Validate the caller (service consumer) has the appropriate access rights to the application services (producer)
Provide access to data services
Act as the mid layer between data and edge services, obfuscating the access details of the data from services which are accessing that data

Edge Services

Edge services interface with external components from non-CMS systems.

Services Framework Edge Services

The edge services:

Must restrict access to the application services
May, depending on architecture, provide authentication services.

Mediation Principles

Mediation principles are implemented as part of the data, application, and edge services to enhance the security by obfuscating the access details to the data. As the request proceeds through the services framework, the request must pass legitimacy tests and be filtered or transformed to provide the necessary obfuscation of critical system components and data. An inbound data request, in most use cases, passes through edge, application and data services. Therefore, at each level, validations and transformations are performed to protect the underlying service. Some systems need to support outbound connections, and these must also follow the path out through the edge services. As outbound calls provide a ‘bad actor’ with a pathway for extracting data from a CMS data center, this pathway is restricted out to only those specific components which are required to be traversed. The outbound calls to a specific destination are also limited.

When implementing the data, application and edge services, the system designer should consider the following mediation principles:

Challenges -– Using rules to allow authorized access or the routing of messages and network packets.

Filtering -– Using criteria and rules to select data, permit a request, or check the validity of data, messages, or network packets.

Transforming -– Changing a structured request, query, result, or response, into a different structure or syntax. Changing only the headers and routing envelopes of messages or network packets does NOT qualify as transforming.

Management Services

Management services assist the system administrators in maintaining the system. The tools required are placed in a management zone, accessible only through the VPN, which provides two factor authentication.

The tools included within the management zone vary by application, but typically include the tools necessary for software releases and patching.

Security Services

The security zone houses any security tools for the application. CMS has enterprise logging and monitoring tools that are available to the system maintainers, so not all applications require a separate security zone.

CMS Services Framework - Summary

In summary, the CMS Services Framework enables applications to be orchestrated and/or composed of a service-fabric that integrates a set of services which enable access to and provide protection of CMS data. The architecture should implement a service as the authorized channel to access the application data. Users from external networks, CMSNet, or the CMS LAN must be authenticated to access the service fronting the data. Additionally, the file storage service must be configured to deny access to all unauthenticated users and all unauthorized users. Furthermore, users from external networks, CMSNet, or the CMS LAN must not have direct access to the CMS files persisted by the storage services.

Services Framework Architecture

CMS Multi-Zone Architecture

Introduction

The CMS TRA specifies a zone architecture that provides defense against security attacks and implements layers of challenges to ensure only authorized access to CMS resources. The services framework details the functions provided by each of the service types, and these services are represented by zones in the CMS multi-zone architecture. In general, the service names match the zone terminology (e.g., Data Services and Data Zone) except for Edge services which corresponds to the Presentation Zone. As the use of cloud platforms and cloud services (such as content delivery networks) have become more prevalent within CMS, the term “Edge Services” has been adopted to represent the services that front and protect CMS internet-facing resources.

The multi-zone architecture is focused on protecting CMS assets via security challenges and enforcing defense-in-depth principles. Zones are a way of grouping and sharing resources based upon a shared security posture. Distinct zones generally exist in legacy data centers but are not as prevalent in cloud implementations where virtual resources, such as network, compute, and storage are usually project based implementations and there is tight integration with other cloud service provider (CSP) provided services. CMS does not require distinct zones for protecting assets, but it does require that data is protected by at least three security challenges. This is a minimum requirement, as additional security measures may be helpful in reducing the risk of a security breach. In addition, the security measures should not be housed on the same resource. This is done to ensure that if one resource is compromised, other security measures are in place to thwart an attack.

The following subtopic will diagram and discuss the multi-zone architecture, detailing the relationship between the zones and the services framework. Note that the depiction is reminiscent of the CMS three-zone architecture as the three-zone model is one instance of the CMS multi-zone architecture. This is a result of the physical nature of the three-zone architecture and its implementation with CMS data centers. The services framework and multi-zone architecture is applicable to cloud environments, where the delineation of the zones is not as obvious. Cloud implementations that utilize a combination of CSP services and CMS services obscure specific zones implemented by the system developer. The specific zone is not as significant to the design as the need to implement challenges to protect CMS assets.

After the discussion of the multi-zone architecture, examples of typical use cases are provided that demonstrate how the function could be implemented in the three-zone architecture as well as the cloud. These examples will support the reader's understanding of the architecture and security requirements. Please note, since system requirements and design vary greatly, these examples are to demonstrate the principle of protecting system assets, but the specific example may not apply to every system design. It must be stressed that the system developers should work with their ISSO in developing and implementing protections to CMS assets.

Zone Architecture

CMS defines a zone as “a portion of the network isolated by firewalls that serves a specific business function”. These firewalls may be physical or virtual, or implemented by other means (e.g. Security Groups in AWS, Network Security Groups in Microsoft Azure, etc).

CMS data centers have typically utilized a three-zone architecture design. While CMS does not dictate the actual number of zones, in CMS data centers the common practice was the implementation of three zones based around data, application and edge services. As a result of the hierarchical nature of the implementation, using specific zones allowed for ‘like’ services to communicate (e.g., application to application service) in and between data centers as long as the CMS network was utilized. In addition, this implementation method also allowed for services to communicate with other services one layer below their own (e.g., edge services to application). Therefore, data services are not directly accessible from outside a CMS data center. Services on the same level are assumed to have passed through the same levels of security and may be accessed directly, although common practice is to restrict consumers of a service to just those components that require the use of the service. Systems implemented in the cloud do not generally have this distinct segmentation and assumptions about the security posture do not exist.

In today’s more dynamic, elastic, and transient cloud environments, the multi-zone architecture is still relevant, but the security challenges may be implemented within Cloud Service Provider (CSP) services or within resources implemented by the CMS development organization. Clouds, microservices, software defined networks, and other emerging technologies present new paradigms for application architecture and often favor new design patterns for performance, security, and cost avoidance. Also, applications may resemble a fabric of services running on a dynamically changing cloud of virtual resources connected through networks often more defined by permissions than wires. These newer cloud environments and implementations rely upon CSP’s services which leads to a collaboration between the CSP and system implementor for implementing security.

CMS Processing Environments are composed of one or more of the following zones to provide Defense-in-Depth, as depicted in the CMS TRA Multi-Zone Architecture figure below:

Presentation Zones (PZ) – Edge services that support the presentation of content. Presentation Zones are accessible to external networks via firewalls through a Trusted Internet Connection (TIC).
Application Zones (AZ) – Application services which support business logic for applications and creating dynamic user presentations.
Data Zones (DZ) – Data services that contain data and data services used by applications.
Management Zone – To support specialized services, such as Public Key Infrastructure (PKI), Domain Name System (DNS) services, and system management services.
Security Zone – A shared mediation service to support security services.

As the CMS TRA Multi-Zone Architecture diagram shows, the Presentation Zone controls the ingress and egress of all external communications into the CMS Processing Environment. The Application and Data Zones may communicate with corresponding Application Zones and Data Zones in other CMS data centers only. CMS has the capability of communicating from a zone in a CMS data center to a CMS cloud environment. Application and Data Zones would be allowed to communicate to equivalent zones in the cloud. These equivalent zones would be part of a CMS private subnet within the CMS enclave at the service provider.

In the CMS vernacular, a Management or Security Zone is a network segment whose primary function is in support of security or infrastructure, and typically provides services to all the other zones. These Zones generally follow the same rules as other zones though there are a few additional rules. A data center may choose to group infrastructure functions into more zones than those listed here. Note: CMS TRA Multi-Zone Architecture represents the conceptual connections between zones and does not depict network implementation such as Trusted Internet Connections (TIC) integration and Virtual Routing and Forwarding (VRF), which are covered in more detail in TRA Network Services.

CMS TRA Multi-Zone Architecture

Transactions within a zone are permitted without restriction unless the traffic is firewalled between data centers. Transactions traversing the zones are controlled and protected via firewalls and other security mechanisms. This multi-zone architecture allows CMS to monitor and control business application transactions within and between zones. The Transport and Management Zones provide infrastructure and supervisory services to manage the core zones.

Presentation Zone

The Presentation Zone contains the front-end components of applications. The Presentation Zone receives requests from external sources, performs data validation, and proxies the requests to the Application Zone for processing. No business logic or database processing is performed on Presentation Zone servers. The Presentation Zone function is to proxy communication requests to the Application Zone (i.e., application-related connections must originate in the Presentation Zone). It is also the zone where business applications first receive data from external sources and is therefore the first zone to challenge requests for validation, authorization, and malicious content.

For outbound communications, the Presentation Zone is the last zone traversed before reaching the Internet.

Application Zone

The Application Zone contains the business logic components of an application. It receives requests from the Presentation Zone and requests necessary data from Data Zone components. The Application Zone can host proxy services to the Data Zone.

Data Zone

The Data Zone contains all data sources, including data stores supporting directory services, authentication functions, data lakes and meshes as well as the applications’ operational databases. All interactions between the Application Zone and the Data Zone must use mediation and data access services. CMS permits the use of database-stored procedures that may reside on database servers in the Data Zone.

Management Zone

The Management Zone provides services to all zones and includes such functions as:

DNS servers
Backup servers
Logs
Remote Access Services
System monitoring applications
Asset/vulnerability management
Application deployment functions
System configuration management function

The specific services provided by the Management Zone will vary from data center to data center. Projects are encouraged to discuss specifics with their data center provider. The Management Zone is the appropriate zone for hosting development and operations automation, such as DevOps deployment components.

Security Zone

The Security Zone provides services to all zones and includes such security functions as:

Security monitoring and response
Network and Host Intrusion Detection Systems (NIDS/HIDS)
Intrusion Protection Service (IPS)
Asset/vulnerability management
Recording and monitoring of system, security, and audit logs
Antivirus monitoring and analysis of server based anti-malware agent
Enterprise-level security monitoring by integrating with the CMS Cybersecurity Integration Center (CCIC)

Applying Zoned Architecture

As described above, CMS implements defense-in-depth principles in a multi-zoned architecture. In the subtopic above, we talked about defense-in-depth and how each zone within the architecture contributes to protecting CMS resources.

In the cloud, the definitive lines between zones are not as clearly defined, and utilizing services from the cloud providers further obscures the responsibility for implementing defense-in-depth. Firewalls may not be implemented, but the team may use security groups (in AWS environments) or their equivalent within their respective cloud for controlling access and flow through the system. CMS requires at least three challenges before allowing access to sensitive data. In the cloud environment, these challenges may not be as clearly separated into zones as CMS data centers would support. The reader should take ‘three’ challenges as a minimum to implement security needs. As such, the implementor should strive to deliver the most secure implementation, limiting risk, that resources can support.

We will detail some common implementations within the cloud environment below and discuss how defense-in-depth can be implemented. Remember these examples are to demonstrate possible implementations and the implementor should work with their ISSO to validate the security adequacy of the design. Note that the current practice is for CMS cloud engineers to provide the implementor with a private and public subnet. The implementor creates the zones or the defense-in- depth using this model. For example, the application zone and data zone could be implemented within the private subnet, controlling flow and access using security groups.

Example 1 – API Implementation

In this example, the implementor desires to implement an API to access CMS sensitive data for users external to CMS. The API endpoint should be protected by a Web Application Firewall (WAF) which may implement one or more of the security challenges and mediation principles (e.g. Geo fencing). A typical implementation would include:

Multi-factor authentication prior to accessing the APIs that front sensitive data
Authorization that the user has adequate permissions/roles to access the API. This could be accomplished using a directory.
The API endpoint should obfuscate (see Mediation Principles) the data access details to avoid providing the end user with any type of information regarding the type of database, location, etc.

The diagrams below depict the zonal mapping of the API example to a CMS data center implementation and a cloud model where the implementation is supported with cloud services. Amazon Web Services (AWS) is used in the example, but the example holds for any CMS approved cloud. Please note that in the cloud example, we do not explicitly name the presentation and application zones. In this example, the implementation utilizes services provided by the cloud service provider (CSP). While not explicitly named, the reader can infer the web application firewall is analogous to the presentation zone and the API gateway to the application zone.

Example 1 - API Implementation

Additional security challenges/features, such as data masking, may be applied to further protect CMS sensitive data. The implementation should also prohibit the egress of data using the API or the resources that house the API.

Example 2 – Business Intelligence Tool Implementation

In this example, the implementor intends to utilize a cloud service that will use a virtual desktop/BI tool to access CMS data. In this example, due to the nature of the data, multi-factor authentication must be used.

A typical implementation would utilize multi-factor authentication, either through a CSP or CMS service to validate the user.
Once authenticated, the user’s authorization must be validated to ensure that access to the data is appropriate. This could be achieved through a sign-in or verification check within the database or CMS directory for roles/permissions.
The virtual desktop/BI tool should also be restricted to access only the targeted CMS data source, such as for example the CMS Enterprise Data Mesh (EDM). This could be accomplished by using security groups, or locking down the IP/ports that the cloud-based virtual desktop/BI tool is permitted to access within the CMS enclave.

The diagrams below depict the zonal mapping of the Business Intelligence Tool example to a CMS data center implementation and in the cloud where the implementation is supported with cloud services. AWS is used in the example, but the example holds for any CMS approved cloud.

Example 2 - Business Intelligence Tool Implementation

Additional security challenges/features may be implemented depending on the risk posture of the system. For example, data masking can provide additional security as well as configuring the desktop/tool to limit the ability of the user to download or obtain the data.

Sharing Components and Capabilities

The following definitions are critical to understanding the components of the CMS Processing Environments. These definitions apply to all virtual and physical components of information processing systems:

Dedicated components – are those physical resources provided exclusively for CMS Environments.
Shared component – means the physical or virtual component is shared among multiple tenants in a data center, in a virtualization hosting system, or in a community or public cloud environment. Details of CMS cloud shared services are available at CMS Cloud Services.
Independently managed component – means the physical or virtual component is independently usable and managed by CMS, in isolation from other tenants.
Third-Party Websites and Applications – are web-based technologies (covered within the CMS ARS) that are not exclusively operated or controlled by HHS. The CMS TRA covers TPWAs linked to or accessed by CMS applications.
Single-purpose component – means the physical or virtual component is a standalone custom or commercial device or appliance product (including hardware, firmware, software, and/or operating system) designed for a specific purpose, and not to perform general purpose processing. An example would be a firewall appliance that consists of firewall software running on a virtual machine (VM) with a highly customized operating system that is designed to run only the firewall application.

Network Connectivity and Trust Boundaries

CMS data centers and the CMSNet connections between them are within the CMS security perimeter and currently operate with an elevated level of trust. The movement towards newer security models such as zero trust will continue to reduce the inherent trust at the network connectivity level, and best practice is to authenticate all network connections. Although individual data centers may connect to the untrusted Internet, connections between CMS data centers should preferably traverse CMSNet. Connections to external entities must be covered by an Interconnection Security Agreement (ISA) approved by the CMS Authorizing Official.

CMS Data and CMS Sensitive Information

The CMS TRA uses the term “Sensitive Information” as defined in the NIST Glossary and the Guide to Cyber Threat Information Sharing, SP 800-150 and referenced in Executive Order 13556 -- Controlled Unclassified Information, with guidance in the NARA CUI Registry. It is the responsibility of the business owner, in consultation with their Group Director (GD), Information Systems Officer (ISO), Information Systems Security Officer (ISSO), Cyber Risk Advisor (CRA), Chief Information Security Officer (CISO), Administrative Officer (AO), Data Guardian, and Privacy subject matter expert to determine what data are sensitive. This includes all data that require protection due to the risk and magnitude of loss or harm, such as PII, PHI, and Federal Tax Information (FTI).

There are some system data elements in ATO(ed) environments that should always be considered sensitive:

Passwords and private keys, including application programming interface (API) keys and other keys used to access or configure sensitive CMS data, services, or IT resources
Final release of code, executables, and configuration files that will be or are deployed in ATO(ed) environments
Configuration “Reference Data” such as configuration files or metadata used for configuring virtual resources and services in ATO(ed) environments
Internal network addresses, and unique addressable device identifiers—such as Media access control (MAC) addresses, Virtual Machine identities (ID), etc. in ATO(ed) environments

The Privacy Impact Assessment (PIA) is a critical tool for spotting privacy risks and compliance with federal regulations or laws, tracking implementation of privacy controls, identifying instances where CMS collects or handles Personally Identifiable Information (PII) and/or Protected Health Information (PHI) and for identifying CMS systems subject to the Privacy Act of 1974.  PIAs must be conducted as part of the ATO process for CMS IT systems, and must be reviewed at least every three years and/or upon a major change to the IT system or electronic information collection. For additional information, reference the CMS Privacy Impact Assessment (PIA) Standard Operating Procedures and ARS SC-7(24) - Personally Identifiable Information.

Designating High Value Assets

A High Value Asset (HVA) is an asset used as a mission-critical information resource supporting infrastructure providers and suppliers or partnering organizations. The unauthorized disclosure, modification, destruction, or disruption of access to this information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

The business owner of a CMS information system must categorize the system in accordance with Federal Information Processing Standards (FIPS) 199, and document the system attributes used to identify PII, PHI, and HVAs. The CIO determines whether a system is an HVA. If the CMS CIO identifies a system as a High Value Asset, an HVA Designation Letter must be on file. Please refer to TRA Network Services, Cyber Security Operations / Risk Management for more information.

Zero Trust

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:

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

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

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

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

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

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.

All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
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:

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

CMS Cloud Zero Trust documentation
CyberGeek Zero Trust

External

OMB

Executive Order 14028, “Improving the Nation’s Cybersecurity”,
OMB Memorandum M-22-09, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles”
Cyber.gov, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

NIST

Special Publication 800-207, Zero Trust Architecture
Special Publication 1800-35(A-E), Implementing a Zero Trust Architecture, (2nd Preliminary Draft)

CISA

Zero Trust Maturity Model (Version 2.0)
Cloud Security Technical Reference Architecture

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.

Zero Trust

Zero Trust Maturity Identity Pillar

Introduction

This section covers the capabilities needed for the Zero Trust Maturity Identity Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

The identity pillar considers how accounts are created and how users log into systems. The ability to identify every user and entity requesting system access is foundational to the concept of zero trust.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Identity Pillar. This includes:

How to store identities of users as well as authenticate them
Consideration of identity for the developers and admins creating the system and the end users of the system like providers or the public
Consideration of non-person entities such as devices, service accounts, and APIs

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Authentication capabilities
Traditional	Initial	Advanced	Optimal
Agency authenticates identity using either passwords or multi-factor authentication (MFA) with static access for entity identity.	Agency authenticates identity using MFA, which may include passwords as one factor and requires validation of multiple entity attributes (e.g., locale or activity).	Agency begins to authenticate all identity using phishing-resistant MFA and attributes, including initial implementation of passwordless MFA.	Agency continuously validates identity with phishing-resistant MFA, not just when access is initially granted.

BR-ACID-2: Known Identity Required to Access CMS Information Systems
BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory
BR-SA-2: Integrate with the CMS Identity Management Services
BR-UI-12: Authentication
BR-WS-11: Use Certificate-Based Mutual Authentication for Machine-to-Machine Web Services

Zero Trust Identity Stores capabilities
Traditional	Initial	Advanced	Optimal
Agency only uses self-managed, on-premises (i.e., planned, deployed, and maintained by agency) identity stores.	Agency has a combination of self-managed identity stores and hosted identity store(s) (e.g., cloud or other agency) with minimal integration between the store(s) (e.g., Single Sign-on.).	Agency begins to securely consolidate and integrate some self-managed and hosted identity stores.	Agency securely integrates their identity stores across all partners and environments as appropriate.

BR-BI-3: Authentication, Auditing, and Logging of All BI User Accounts Must Be Managed from the CMS Enterprise LDAP Directory and Enterprise User Administration
BR-ACID-3: Single Identity Record for Each Individual Accessing CMS Systems
BR-ACID-4: User Identities Must Be Vetted and Managed Using a Common Framework
BR-ACID-10: EUA Manages UserIDs of CMS Employees and Contractors
BR-SA-2: Integrate with the CMS Identity Management Services
RP-SAAS-4: Integrate SaaS with CMS Identity Management Systems

Zero Trust Risk Assessment capabilities
Traditional	Initial	Advanced	Optimal
Agency makes limited determinations for identity risk (i.e., likelihood that an identity is compromised).	Agency determines identity risk using manual methods and static rules to support visibility.	Agency determines identity risk with some automated analysis and dynamic rules to inform access decisions and response activities.	Agency determines identity risk in real time based on continuous analysis and dynamic rules to deliver ongoing protection.

BR-SEC-Gen-22: All Information Systems Must Have a System Risk Assessment in CFACTS
BR-CCIC-02: Assessment of Information Security and Privacy Risks

Zero Trust Access Management capabilities
Traditional	Initial	Advanced	Optimal
Agency authorizes permanent access with periodic review for both privileged and unprivileged accounts	Agency authorizes access, including for privileged access requests, that expires with automated review.	Agency authorizes need-based and session-based access, including for privileged access request, that is tailored to actions and resources.	Agency uses automation to authorize just-in-time and just-enough access tailored to individual actions and individual resource needs.

BR-ACID-1: Valid Purpose Required to Access CMS Information Systems
BR-ACID-11: CMS Business Owners Provide Privilege Administration
BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory

Zero Trust

Zero Trust Maturity Devices Pillar

Introduction

This section covers the capabilities needed for the Zero Trust Maturity Devices Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

The devices pillar highlights the importance of consistently tracking and monitoring devices to understand their security posture prior to granting access to systems. For applications, this will include physical servers as well as digital assets such as virtual machines and containers.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Device Pillar. This includes:

How to maintain a complete inventory of every device a system operates through the CDM program
Managing supply chain risks for both devices and the software it runs
Preventing and detecting incidents on those devices

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Policy Enforcement & Compliance Monitoring Capabilities

Traditional

Initial

Advanced

Optimal

Agency has limited, if any, visibility (i.e., ability to inspect device behavior) into device compliance with few methods of enforcing policies or managing software, configurations, or vulnerabilities.

Agency receives self-reported device characteristics (e.g., keys, tokens, users, etc., on the device) but has limited enforcement mechanisms.

Agency has a preliminary, basic process in place to approve software use and push updates and configuration changes to devices.

Agency has verified insights (i.e., an administrator can inspect and verify the data on device) on initial access to device and enforces compliance for most devices and virtual assets.

Agency uses automated methods to manage devices and virtual assets, approve software, and identify vulnerabilities and install patches.

Agency continuously verifies insights and enforces compliance throughout the lifetime of devices and virtual assets.

Agency integrates device, software, configuration, and vulnerability management across all agency environments, including for virtual assets.

BR-SEC-Gen-2: Software and Hardware Components Must Adhere to a Secure Baseline Configuration
BR-SEC-Gen-3: Disable All Unnecessary Features and Capabilities
BR-SEC-Gen-11: Periodic and Continuous Configuration Compliance Scanning Is Required
BR-CCIC-14: Hardware Asset Management Capability
BR-CCIC-16: Configuration Settings Management Capability
BR-SV-12: Perform Asset Management of Virtual Instances
RP-SV-14: Use VM Configuration Templates
BR-IoT-1: CMS IoT Platforms Must Comply with CMS Requirements for CMS Processing Environments

Zero Trust Asset & Supply Chain Risk Management Capabilities
Traditional	Initial	Advanced	Optimal
Agency does not track physical or virtual assets in an enterprise-wide or cross-vendor manner and manages its own supply chain acquisition of devices and services in ad hoc fashion with a limited view of enterprise risks.	Agency tracks all physical and some virtual assets and manages supply chain risks by establishing policies and control baselines according to federal recommendations using a robust framework, (e.g., NIST SCRM.)	Agency begins to develop a comprehensive enterprise view of physical and virtual assets via automated processes that can function across multiple vendors to verify acquisitions, track development cycles, and provide third-party assessments.	Agency has a comprehensive, at-or near-real-time view of all assets across vendors and service providers, automates its supply chain risk management as applicable, builds operations that tolerate supply chain failures, and incorporates best practices.

BR-CI-4: Obtain TRB Approval for CMS-Owned Equipment
BR-CI-5: Acquisition of New IaaS or PaaS Cloud Service Providers
BR-F-6: Mainframes Must Be Dedicated to CMS
BR-IoT-1: CMS IoT Platforms Must Comply with CMS Requirements for CMS Processing Environments
RP-IoT-1: CMS-Managed IoT Devices Should Comply with NIST SP 1800-15 and the Latest MUD Specifications
BR-SEC-FW-11: Utilize Firewalls from Two or More Different Vendors

Zero Trust Resource Access (Formerly Data Access) Capabilities
Traditional	Initial	Advanced	Optimal
Agency does not require visibility into devices or virtual assets used to access resources.	Agency requires some devices or virtual assets to report characteristics then use this information to approve resource access.	Agency’s initial resource access considers verified device or virtual asset insights.	Agency’s resource access considers real-time risk analytics within devices and virtual assets.

Zero Trust Device Threat Protection Capabilities
Traditional	Initial	Advanced	Optimal
Agency manually deploys threat protection capabilities to some devices.	Agency has some automated processes for deploying and updating threat protection capabilities to devices and to virtual assets with limited policy enforcement and compliance monitoring integration.	Agency begins to consolidate threat protection capabilities to centralized solutions for devices and virtual assets and integrates most of these capabilities with policy enforcement and compliance monitoring.	Agency has a centralized threat protection security solution(s) deployed with advanced capabilities for all devices and virtual assets and a unified approach for device threat protection, policy enforcement, and compliance monitoring.

BR-PMM-3: Monitor Production Environments
BR-SEC-Gen-11: Periodic and Continuous Configuration Compliance Scanning Is Required
BR-SEC-Gen-12: Host Intrusion Detection Capabilities on All IT Components
BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone
BR-CCIC-09: Local Information Sharing and Cyber Threat Intelligence Support
BR-CCIC-25: Insider Threat Detection

Zero Trust

Zero Trust Maturity Networks Pillar

Introduction

This section covers the capabilities needed for the Zero Trust Maturity Networks Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

A network refers to an open communications medium including typical channels such as agency internal networks, wireless networks, and the Internet as well as other potential channels such as cellular and application-level channels used to transport messages.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Network Pillar. This includes:

Encrypting traffic that leaves the CMS boundary, as well as encrypting internal traffic
Focusing on network resilience from both normal use and adversaries
The need to begin executing a plan to break down the perimeters into isolated environments

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Network Segmentation Capabilities

Traditional

Initial

Advanced

Optimal

Agency defines their network architecture using large perimeter/macro-segmentation with minimal restrictions on reachability within network segments.

Agency may also rely on multi-service interconnections (e.g., bulk traffic VPN tunnels).

Agency begins to deploy network architecture with the isolation of critical workloads, constraining connectivity to least function principles, and a transition toward service-specific interconnections.

Agency expands deployment of endpoint and application profile isolation mechanisms to more of their network architecture with ingress/egress micro-perimeters and service-specific interconnections.

Agency network architecture consists of fully distributed ingress/egress micro-perimeters and extensive micro-segmentation based around application profiles with dynamic just-in-time and just-enough connectivity for service-specific interconnections.

BR-F-3: The CMS TRA Defines a Zoned Architecture
BR-F-4: Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone
BR-SEC-FW-1: Separate Network Interfaces for Each Network Segment and Zone
BR-WAN-S-3: Communication between CMS Data Centers Is Only Permitted between Like Zones
BR-WAN-S-12: Management of CMSNet Is Via a Dedicated Logical Network

Zero Trust Network Traffic Management Capabilities

Traditional

Initial

Advanced

Optimal

Agency manually implements static network rules and configurations to manage traffic at service provisioning, with limited monitoring capabilities (e.g., application performance monitoring or anomaly detection) and manual audits and reviews of profile changes for mission critical applications.

Agency establishes application profiles with distinct traffic management features and begins to map all applications to these profiles.

Agency expands application of static rules to all applications and performs periodic manual audits of application profile assessments.

Agency implements dynamic network rules and configurations for resource optimization that are periodically adapted based upon automated risk-aware and risk-responsive application profile assessments and monitoring.

Agency implements dynamic network rules and configurations that continuously evolve to meet application profile needs and reprioritize applications based on mission criticality, risk, etc.

BR-CCIC-07: Local Security Information and Event Management Capability
BR-CCIC-12: CyberScope Data Feeds
BR-CCIC-18: Perimeter Monitoring Prerequisites
BR-PMM-3: Monitor Production Environments
BR-SAAS-7: Integrate with CMS CCIC
RP-SAAS-3: Continuous Monitoring
BR-SA-9: Systems Must Define Metrics for IT Health Monitoring

Zero Trust Traffic Encryption Capabilities
Traditional	Initial	Advanced	Optimal
Agency encrypts minimal traffic and relies on manual or ad hoc processes to manage and secure encryption keys.	Agency begins to encrypt all traffic to internal applications, to prefer encryption for traffic to external applications, to formalize key management policies, and to secure server/service encryption keys.	Agency ensures encryption for all applicable internal and external traffic protocols, manages issuance and rotation of keys and certificates, and begins to incorporate best practices for cryptographic agility.	Agency continues to encrypt traffic as appropriate, enforces least privilege principles for secure key management enterprise-wide, and incorporates best practices for cryptographic agility as widely as possible.

BR-SA-6: Network Communications Must Meet the TRA Rules for Encryption
BR-SEC-Int-3: HTTPS on CMS Public-Facing Websites and Services on the Internet
BR-CCIC-24: FIPS 140-2 or FIPS 140-3 Validated Encryption Use
BR-WAN-S-0: Use Mutual Authentication and Encrypted Tunnels between Data Centers
BR-WAN-S-1: The WAN Must Implement FIPS 140-2 or FIPS 140-3 Compliant Encryption

Zero Trust Network Resilience Capabilities
Traditional	Initial	Advanced	Optimal
Agency configures network capabilities on a case-by-case basis to only match individual application availability demands with limited resilience mechanisms for workloads not deemed mission critical.	Agency begins to configure network capabilities to manage availability demands for additional applications and expand resilience mechanisms for workloads not deemed mission critical.	Agency has configured network capabilities to dynamically manage the availability demands and resilience mechanisms for the majority of their applications.	Agency integrates holistic delivery and awareness in adapting to changes in availability demands for all workloads and provides proportionate resilience.

BR-CCIC-12: CyberScope Data Feeds
BR-DR-1: Annual Review of Disaster Recovery Plans
BR-DR-2: Disaster Recovery Tier Selection
BR-DR-3: All CMS FISMA systems must have a plan for DR
BR-DR-4: Required Risk Analysis, System BIA, and ISCP

Zero Trust

Zero Trust Maturity Applications & Workloads

Introduction

This section covers the capabilities needed for the Zero Trust Maturity Applications and Workloads Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

Applications and workloads include systems, computer programs, and services that execute in on-premises and cloud environments. In mature zero trust deployments, users strongly authenticate into applications, not into the underlying networks.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Zero Trust Maturity for AWS for CMS Cloud. This includes:

Application-specific threat protections
Application security testing at all stages of development and deployment
Enabling access to applications based on additional user attributes beyond mere presence on specific networks

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Application Access Capabilities
Traditional	Initial	Advanced	Optimal
Agency authorizes access to applications primarily based on local authorization and static attributes.	Agency begins to implement authorizing access capabilities to applications that incorporate contextual information (e.g., identity, device compliance, and/or other attributes) per request with expiration.	Agency automates application access decisions with expanded contextual information and enforced expiration conditions that adhere to least privilege principles.	Agency continuously authorizes application access, incorporating real-time risk analytics and factors such as behavior or usage patterns.

BR-P-5: Each Portlet Must Control Access to Content / Functionality Based on User and Role Information via the Portal
BR-BI-5: Role-Based Authorization Must Be Used to Manage Access to BI Applications, Queries, Reports, Analytic Functions, Tables, Views, and Stored Procedures
BR-ACID-1: Valid Purpose Required to Access CMS Information Systems
BR-WAN-S-2: CMS Business Partners Only Access the Presentation Zone
BR-WAN-S-4: Business Partner Access Restrictions
BR-F-12: Role-Based Security AAA Must Be Used for Management and User Roles
BR-URL-3: Logs Must Identify the Users Who Access a CMS File Referenced by a URL from the External Networks or CMSNet
BR-URL-4: Logs Must Identify the Users Who Upload a File to a CMS Location Referenced by a URL from the External Networks or CMSNet

Zero Trust Application Threat Protections Capabilities
Traditional	Initial	Advanced	Optimal
Agency threat protections have minimal integration with application workflows, applying general purpose protections for known threats	Agency integrates threat protections into mission critical application workflows, applying protections against known threats and some application-specific threats.	Agency integrates threat protections into all application workflows, protecting against some application-specific and targeted threats.	Agency integrates advanced threat protections into all application workflows, offering real-time visibility and content-aware protections against sophisticated attacks tailored to applications.

BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone
BR-SEC-Gen-15: Logs Must Be Securely Collected, Aggregated, and Analyzed
BR-SCM-2: All Code Must Be Baselined Prior to Release into Implementation, Validation, and ATO(ed) Production Environments
BR-SBI-1: All Builds Must Occur in Controlled Environments
BR-SBI-2: All Production-Deployed Custom Code Must Be Built and Installed from Version-Controlled Source Code
BR-OSS-5: Use OSS Built from a Controlled Source
BR-OSS-6: Binary Package Management Is Mandatory
BR-OSS-10: CMS OSS Code Released as CMS-Managed Code Requires a Governance and Support Model
RP-CA-10: Validate All Third-Party Containerized Applications before Implementation
BR-OR-5: Libraries of Containers Must Be Maintained in CMS-Only Stores
BR-SEC-Gen-17: Software Assurance Measures
BR-SEC-Gen-18: Malicious Code Protection in CMS Processing Environments
BR-SAAS-1: SaaS Clouds Are Defined by NIST SP-800-145

Zero Trust Accessible Applications Capabilities
Traditional	Initial	Advanced	Optimal
Agency makes some mission critical applications available only over private networks and protected public network connections (e.g., VPN) with monitoring.	Agency makes some of their applicable mission critical applications available over open public networks to authorized users with need via brokered connections.	Agency makes most of their applicable mission critical applications available over open public network connections to authorized users as needed.	Agency makes all applicable applications available over open public networks to authorized users and devices, where appropriate, as needed.

Zero Trust Secure Application Development and Deployment Workflow Capabilities
Traditional	Initial	Advanced	Optimal
Agency has ad hoc development, testing, and production environments with non-robust code deployment mechanisms.	Agency provides infrastructure for development, testing, and production environments (including automation) with formal code deployment mechanisms through CI/CD pipelines and requisite access controls in support of least privilege principles.	Agency uses distinct and coordinated teams for development, security, and operations while removing developer access to production environment for code deployment.	Agency leverages immutable workloads where feasible, only allowing changes to take effect through redeployment, and removes administrator access to deployment environments in favor of automated processes for code deployment.

Zero Trust Application Security Testing Capabilities
Traditional	Initial	Advanced	Optimal
Agency performs application security testing prior to deployment, primarily via manual testing methods.	Agency begins to use static and dynamic (i.e., application is executing) testing methods to perform security testing, including manual expert analysis, prior to application deployment.	Agency integrates application security testing into the application development and deployment process, including the use of periodic dynamic testing methods.	Agency integrates application security testing throughout the software development lifecycle across the enterprise with routine automated testing of deployed applications.

BR-SS-4: Check for Common Security Vulnerabilities
BR-SS-5: Use Static Analysis Tools to Catch Common Security Weaknesses
RP-SS-6: Use Profiling to Perform Dynamic Code Analysis
BR-SS-7: Error Handling Must Not Reveal Information That Could Lead to an Exploit
BR-SEC-Gen-21: Malware and Malicious Code Scanning Results Must Be Sent to the Security Zone

Zero Trust

Zero Trust Maturity Data Pillar

Introduction

This section covers the capabilities needed for the Zero Trust Maturity Data Pillar. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

Data includes all structured and unstructured files and fragments that reside or have resided in federal systems, devices, networks, applications, databases, infrastructure, and backups (including on-premises and virtual environments) as well as the associated metadata.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Data Pillar. This includes:

How data should be protected on devices, in applications, and on networks
How data should be inventoried, categorized, and labeled, as well as protected at rest and in transit
The advantage of cloud security services for monitor access to sensitive data and the preferred practice of implementing enterprise-wide logging and information sharing

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Data Inventory Management Capabilities
Traditional	Initial	Advanced	Optimal
Agency manually identifies and inventories some agency data (e.g., mission critical data).	Agency begins to automate data inventory processes for both on-premises and in cloud environments, covering most agency data, and begins to incorporate protections against data loss.	Agency automates data inventory and tracking enterprise-wide, covering all applicable agency data, with data loss prevention strategies based upon static attributes and/or labels.	Agency continuously inventories all applicable agency data and employs robust data loss prevention strategies that dynamically block suspected data exfiltration.

Zero Trust Data Categorization Capabilities
Traditional	Initial	Advanced	Optimal
Agency employs limited and ad hoc data categorization capabilities.	Agency begins to implement a data categorization strategy with defined labels and manual enforcement mechanisms.	Agency automates some data categorization and labeling processes in a consistent, tiered, targeted manner with simple, structured formats and regular review.	Agency automates data categorization and labeling enterprise-wide with robust techniques; granular, structured formats; and mechanisms to address all data types.

Zero Trust Data Availability Capabilities
Traditional	Initial	Advanced	Optimal
Agency primarily makes data available from on-premises data stores with some off-site backups.	Agency makes some data available from redundant, highly available data stores (e.g., cloud) and maintains off-site backups for on-premises data.	Agency primarily makes data available from redundant, highly available data stores and ensures access to historical data.	Agency uses dynamic methods to optimize data availability, including historical data, according to user and entity need.

Zero Trust Data Access Capabilities
Traditional	Initial	Advanced	Optimal
Agency governs user and entity access (e.g., permissions to read, write, copy, grant others access, etc.) to data through static access controls.	Agency begins to deploy automated data access controls that incorporate elements of least privilege across the enterprise.	Agency automates data access controls that consider various attributes such as identity, device risk, application, data category, etc., and are time limited where applicable.	Agency automates dynamic just-in-time and just-enough data access controls enterprise-wide with continuous review of permissions.

BR-DM-6: Data sets remain within the data owner’s security boundary
BR-DM-9: The data owner determines the users, groups, roles, and policies that govern data access
BR-AWS-5: Users Must Be Authenticated by AWS S3 Using a CMS-Managed IAM UserID When Accessing Data in CMS S3 Buckets
RP-AWS-1: Use Amazon AWS Security / Access Features for S3

Zero Trust Data Encryption Capabilities
Traditional	Initial	Advanced	Optimal
Agency encrypts minimal agency data at rest and in transit and relies on manual or ad hoc processes to manage and secure encryption keys.	Agency encrypts all data in transit and, where feasible, data at rest (e.g., mission critical data and data stored in external environments) and begins to formalize key management policies and secure encryption keys.	Agency encrypts all data at rest and in transit across the enterprise to the maximum extent possible, begins to incorporate cryptographic agility, and protects encryption keys (i.e., secrets are not hard coded and are rotated on a regular basis).	Agency encrypts data in use where appropriate, enforces least privilege principles for secure key management enterprise-wide, and applies encryption using up-to-date standards and cryptographic agility to the extent possible.

Zero Trust

Zero Trust Maturity Cross-Cutting Capabilities

Introduction

This section covers the cross-cutting capabilities needed for the Zero Trust Maturity Foundation. It illustrates how existing TRA Business Rules and Recommended Practices align with these capabilities.

CMS Guidance

Each pillar also implements three cross-cutting capabilities. Visibility and Analytics refers to how we monitor systems. Automation and Orchestration is the process of creating reusable processes that can be automated within our systems. And Governance is the policies we set for the systems as well as how we track how we enforce those policies.

The CMS Zero Trust Workgroup is developing guidelines for CMS ADOs. Specific guidance can be found in CMS Cloud documentation: Zero Trust Maturity for AWS for CMS Cloud. This includes:

Using existing logging, monitoring, and alerting infrastructure where possible
Centralizing the implementation of the cross-cutting capabilities over all five of the other pillars
Documenting policies and procedures so they can be automated

Capabilities

The business rules shown beneath each capability aren’t comprehensive — Other requirements are defined in the ARS and RMH.

Zero Trust Visibility and Analytics Capabilities
Traditional	Initial	Advanced	Optimal
Agency manually collects limited logs across their enterprise with low fidelity and minimal analysis.	Agency begins to automate the collection and analysis of logs and events for mission critical functions and regularly assesses processes for gaps in visibility.	Agency expands the automated collection of logs and events enterprise-wide (including virtual environments) for centralized analysis that correlates across multiple sources.	Agency maintains comprehensive visibility enterprise-wide via centralized dynamic monitoring and advanced analysis of logs and events.

Zero Trust Automation and Orchestration Capabilities
Traditional	Initial	Advanced	Optimal
Agency relies on static and manual processes to orchestrate operations and response activities with limited automation.	Agency begins automating orchestration and response activities in support of critical mission functions.	Agency automates orchestration and response activities enterprise-wide, leveraging contextual information from multiple sources to inform decisions.	Agency orchestration and response activities dynamically respond to enterprise-wide changing requirements and environmental changes.

Zero Trust Governance Capabilities
Traditional	Initial	Advanced	Optimal
Agency implements policies in an ad hoc manner across the enterprise, with policies enforced via manual processes or static technical mechanisms.	Agency defines and begins implementing policies for enterprise-wide enforcement with minimal automation and manual updates.	Agency implements tiered, tailored policies enterprise-wide and leverages automation where possible to support enforcement. Access policy decisions incorporate contextual information from multiple sources.	Agency implements and fully automates enterprise-wide policies that enable tailored local controls with continuous enforcement and dynamic updates.

BR-F-10: Annual Review and Exercise of Data Center Disaster Recovery Plans
BR-F-11: Annual Review and Exercise of Contingency Plans
BR-CI-4: Obtain TRB Approval for CMS-Owned Equipment
BR-CI-5: Acquisition of New IaaS or PaaS Cloud Service Providers
BR-SAAS-3: Ensure CMS Security May Perform Periodic Security Assessments
BR-SEC-Gen-22: All Information Systems Must Have a System Risk Assessment in CFACTS
BR-CCIC-01: Security Authorization of Systems
BR-CCIC-02: Assessment of Information Security and Privacy Risks
BR-WAN-CM-2: CMSNet Services Must Be Certified Annually
BR-ACID-11: CMS Business Owners Provide Privilege Administration
BR-ACID-13: OIT Is Responsible for Identity Management of Users with Credentials Provisioned in the CMS Enterprise Directory
BR-DNS-13: All DNS Changes Must Be Subject to CMS’s Change Management Procedures
BR-ADM-1: Use of the CMS Life Cycle Is Mandatory
BR-SA-7: Substantive Changes to the Architecture, Products, or Technology of an Existing Application Must Be Documented and Reviewed by the CMS TRB
BR-SQ-5: Manual Code and Design Reviews Are Mandatory
BR-CM-3: Significant Changes to Configuration Items of a System or Component Managed by a CCB Requires the Approval of That CCB
BR-CM-5: Projects Must Conduct Periodic Audits of CM Activities and Products

CMS TRA Business Rules

Guidance in the CMS TRA includes business rules, which are requirements for TRA compliance, and recommended practices, which are strongly encouraged but not required. The format for BRs and RPs is similar. The business rules consist of a brief, binding requirement and a rationale that provides context on the intent of the rule. Where applicable, the rationale also contains references to relevant policies, standards, and specific CMS ARS controls. The following BRs for this topic (i.e., rule numbers beginning with BR-F) provide high-level guidance applicable to all TRA stakeholders. Other topics contain additional business rules relevant to their respective sections.

BR-F-1: Any Deviations from the CMS TRA Must Be Requested and Approved

All projects and applications are required to adhere to the CMS TRA unless covered by a Technology Review Board (TRB)-approved exception. The CMS CEA and CIO has have joint approval authority for the CMS TRA. Only the TRB can approve deviations from the CMS TRA.

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration and CA-6 - Authorization.

Rationale:

ARS control CM-2 requires “Baseline configurations of information systems reflect the current enterprise architecture.” The CMS TRA is the CMS Enterprise Architecture standard. In some cases, applications identify circumstances where the benefits of deviating from the CMS TRA may outweigh the risks. The risk/benefit of any deviation from the CMS TRA must be assessed and approved by the TRB before the CIO can determine if the risk is acceptable and the system should be granted an ATO.

BR-F-2: The CMS TRA Applies to All CMS Processing Environments

The CMS TRA provides the standard technical reference for all CMS Processing Environments. This includes both physical and virtual server and end-user (e.g., Virtual Desktop Infrastructure) environments, cloud-based environments, and hybrid environments. These standards are effective on publication. A CMS Processing Environment is defined as any computing environment (e.g., CMS data center, virtual computing environment, or cloud computing) that creates, consumes, and/or stores CMS-related data. CMS data includes sensitive and non-sensitive information, security information, and event management-related information used to provide CMS services to the public and internal CMS users. For existing systems, compliance with CMS TRA updates is required within twenty-four (24) months of publication. When certain changes require immediate compliance, CMS will communicate these changes outside the TRA process via CIO directive.

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration and SA-8 - Security and Privacy Engineering Principles, Implementation Standard 1:

The information system must follow system security and privacy engineering principles consistent with:

The information security steps of the CMS Target Life Cycle (TLC) to incorporate information security and privacy control considerations;
The information system architecture defined within the Technical Reference Architecture (TRA); and
The Technical Review Board (TRB) processes defined by CMS.

Rationale:

Updates to the CMS TRA require corresponding changes to all CMS information systems. A 24-month compliance window provides sufficient time for data center operators and application maintainers to plan for and execute required CMS TRA changes to bring systems into compliance.

BR-F-3: The CMS TRA Defines a Zoned Architecture

At its most fundamental level, the CMS TRA defines a zoned architecture, a type of services framework architecture (see BR-F-22), where each service type provides different functions and has different responsibilities. There are three application zones and two infrastructure zones. The three business application zones are the Presentation/Edge, Application, and Data Zones. The two infrastructure zones are the Management Zone and the Security Zone. See additional information in the CMS Services Framework.

In the multi-zone architecture, and specifically in the cloud environment, CMS does not specify the number of zones, but does require that access to CMS data resources be protected by at least three security challenges (e.g. multi-factor authentication, security certificates, etc. See Mediation Principles). This ensures that a user or other resource that requires access CMS sensitive data has been properly vetted prior to gaining access to the sensitive resources. This leads to a hierarchy, where zones have bi-directional adjacency. The Presentation/Edge Zone is adjacent to the Application Zone. (Please note, there are restrictions on the storage of data within the Presentation/Edge Zone. See BR-SA-3 for additional information.) The Application Zone is adjacent to both the Presentation/Edge Zone and the Data Zone. The Management and Security Zones are adjacent to all zones. The following rules govern the zoned architecture:

No other adjacency relationships are permitted.
Firewalls (virtual or physical) separate adjacent zones.
The three business application zones (the Presentation, Application, and Data Zones) extend across all CMS Processing Environments.
There are no other zones.

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, PL-8 - Security and Privacy Architectures, RA-9 - Criticality Analysis, SA-8 - Security and Privacy Engineering Principles, SC-2 - Separation of System and User Functionality, and SC-32 - Information System Partitioning.

Rationale:

The CMS TRA follows a Defense-in-Depth strategy implemented in part by a multi-zone architecture. Access to the most valuable parts of the architecture (typically the data) requires crossing multiple zones, including multiple firewalls and servers (which may be physical, virtual, or configured via cloud-based services). The CMS Multi-Zone Architecture defines a consistent architecture used across the enterprise. In addition to Defense-in-Depth for each application, this architecture allows inter-application communication while maintaining a secure environment.

Appendix I, section 4 of Office of Management and Budget (OMB) Circular No. A-130, Managing Information as a Strategic Resource, revised July 28,2016, directs, in pertinent part, under sub-paragraph i (4) that federal agencies shall:

Isolate sensitive or critical information resources (e.g., information systems, system components, applications, databases, and information) into separate security domains with appropriate levels of protection based on the sensitivity or criticality of those resources;

BR-F-4: Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone

Network communication must flow only between adjacent zones (as described in BR-F-3). Direct communication between non-adjacent zones is prohibited.

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, SC-32 - Information System Partitioning, and SC-7 - Boundary Protections.

Rationale:

Communication limited to zone adjacency implements the CMS TRA Defense-in-Depth strategy. Network Services provides details.

BR-F-5: Any System That Processes CMS Data Must Be Covered by a CMS ATO

A CMS processing system is any environment dedicated to CMS FISMA applications or services (in whole or part) that process and/or store CMS data. A CMS processing system must be covered under a CMS Authorization to Operate (ATO). Additional guidance regarding CMS data is provided in CMS Data and Sensitive Information.

All systems that process CMS enterprise data, whether called “production,” “test,” “pilot,” “proof-of-concept,” or “other,” must be covered under a CMS ATO in compliance with the Federal Information Security Modernization Act (FISMA)). This rule applies to any environment that stores or processes CMS data, to include disaster recovery (DR) sites and archival storage. Lower environments that contain only test data might not require an ATO.

See the CMS ATO website for additional information regarding the CMS ATO process and the different types of compliance authorizations provided by CMS to manage agency-wide risk. For further information about test data and “synthetic data generation,” see NIST SP 800-188, “De-Identifying Government Datasets: Techniques and Governance.”

Related CMS ARS Security Controls include: CA-6 - Authorization, CM-2 - Baseline Configuration, AC-21 - Information Sharing, SC-32 - Information System Partitioning, RA-2 - Security Categorization, andSA-3(2) - Use of Live Operational Data.

Rationale:

The “Types of authorizations” section of the CMS ATO website states:

“Every system that is integrated at CMS — either built in-house or contracted — must get a compliance authorization to operate and access government data. This ensures that the agency is aware of all components interacting with its data, and that each system can be monitored for compliance and risk mitigation. This helps safeguard sensitive personal information, manage the risk to critical infrastructure, and address cybersecurity issues when they arise.

“If you are introducing a new system at CMS, you must go through the security and compliance process.”

The emphasis on CMS ATO is important to shared environments such as clouds, which may be covered under the Federal Risk and Authorization Management Program (FedRAMP) or another agency’s ATOs. While other agencies may have different ATO requirements, the compliance with such an ATO or FedRAMP does not ensure that all CMS-prescribed controls have been addressed.

BR-F-6: Mainframes Must Be Dedicated to CMS

CMS must be the sole user of the mainframe resources, when those resources are operated with an ATO and access CMS data, as detailed in the following paragraphs.

For Processing Resources: CMS’s IBM Mainframe Logical Partitions (LPAR) may be used on the same machine as other data center tenants (including the data center operator), provided the LPARs processors are dedicated to CMS use only when processing CMS data.
For Storage Resources: If storage is secured via the LPAR, dedicated storage is not required. Storage allocation on the hardware must be dedicated to the CMS LPAR. Thus, storage media may not be shared between CMS and other tenants. Note that this rule applies to online, nearline, and offline storage.

For all resources, an appropriate Authorization, Auditing and Authentication tool (AAA) for access control must be used to protect both CMS data and processing capability.

Rationale:

CMS has two broad concerns with sharing mainframes. The first concern is protecting CMS data. CMS wants to ensure that CMS data is protected and separated from other user workloads. As a result, CMS considers it essential to isolate CMS processing resources from other tenants (including the hosting provider). For example, although storage hardware such as tape silos may be shared with other tenants, the storage medium such as tapes may not be.

The second concern is sharing infrastructure among non-CMS tenants. Shared infrastructure, including the mainframe that hosts the LPARs and any related networking or other components shared by the LPARs, constitutes both performance and security risks. The performance risk is that shared infrastructure may be unable to meet CMS performance needs. The security risk of shared infrastructure includes, for example, potential for data leakage and lessened availability due to misconfiguration or lack of coordination or oversubscription.

In addition, CMS needs assurance that it is not subsidizing other tenant workloads on CMS-funded environments.

Mainframe LPAR processors need not be dedicated to CMS when used for development or test purposes, so long as no CMS data is processed.

Note that this business rule also applies to CMS mainframe resources used for Disaster Recovery.

BR-F-7: Cost-Effective Reuse of Data Centers with Established TIC, CMSNet, and CCIC Integration

Projects must reuse data centers with established TIC, CMSNet, and CCIC integration.

Related CMS ARS Security Controls include: SA-2 - Allocation of Resources.

Rationale:

This rule supports cost savings related to OMB-mandated physical data center consolidation (Update to Data Center Consolidation Initiative (DCOI), OMB/Federal CIO Kent, June 25, 2019) and more efficient use of security monitoring services. As stated in the OMB memorandum, data center consolidation will promote the use of Green IT by reducing the overall energy and real estate footprint of government data centers; reduce the cost of data center hardware, software, and operations; increase the overall IT security posture of the government; and shift IT investments to more efficient computing platforms and technologies.

BR-F-8: Backup CMS Data

All CMS data must be backed up regularly, on a documented schedule, regardless of hosting implementation (i.e., physical data center, Cloud, etc.).

ARS Security Control CP-9 provides specific requirements for backup. Note that Cloud Service Providers have additional requirements under this control. All backups must be secured from unauthorized access and disclosure.

Related CMS ARS Security Controls include: CP-6 - Alternate Storage Site, AU-2 - Event Logging, CP-9 - System Backup, and CP-9(8) - Cryptographic Protection.

Rationale:

Disaster Recovery and Fault Tolerance (FT) is sometimes confused with data backup. Data backup is an essential part of any CMS Processing Environment because it offers the ability to restore data to the most recent copy as well as one of several older copies. This backup capability facilitates comparative analysis and recovery from data corruption, neither of which can be handled by DR or FT.

The OIT Backups Policy provides details about implementation. The basic requirement is to meet the “return to service” requirements per the system’s ATO. AWS Backups for AWS and Azure Backups for Microsoft Azure for Government (MAG) cloud are preferred, replacing the Cloud Protection Manager (CPM).

Backups also differ from archives, which are performed for Records Management.

PREFERRED - The CMS recommended backup tools are AWS Backups and Azure Backups in Microsoft Azure for Government (MAG).

BR-F-9: Test CMS Backups on a Documented Schedule

CMS backups and associated procedures must be tested for corruption and completeness on a regular basis to ensure that restoration can occur, if need be.

Rationale:

Improper testing of backups is a frequent cause of operational issues. Restoring backups and comparing against a master copy is one way to test backups. System maintainers are encouraged to explore alternatives to select the most appropriate method for their projects.

Related CMS ARS Controls include: CP-9(1) - Testing for Reliability/Integrity and CM-4(1) - Separate Test Environments.

BR-F-10: Annual Review and Exercise of Data Center Disaster Recovery Plans

Disaster recovery plans and their supporting documents must be reviewed and re-evaluated annually or on a significant change to the operating environment. In addition, DR plans must be exercised to ensure that the plans are complete and accurate and to make certain that authorized personnel can execute their training.

Rationale:

The review and exercise of DR plans assures that the plans are accurate and up to date and that all parties understand their roles in the event of a disaster.

Related CMS ARS Controls include: CP-8 - Telecommunications Services and CP-10 - System Recovery and Reconstitution.

BR-F-11: Annual Review and Exercise of Contingency Plans

Contingency Plans (CP) and any supporting documents must be reviewed and re-evaluated annually or on a significant change to the operating environment. In addition, the CPs must be exercised to ensure that the plans are complete and accurate and to ensure that personnel can execute their training (see CMS Information System Contingency Plan (ISCP) Handbook).

Rationale:

The review and exercise of CPs assures that the plans are accurate and up to date and that all parties understand their roles in the event of a disaster.

Related CMS ARS Controls include: CP-10 - System Recovery and Reconstitution and CP-4 - Contingency Plan Testing.

BR-F-12: Role-Based Security AAA Must Be Used for Management and User Roles

Use Role-based Security Authentication, Authorization, and Accounting (AAA) functions provided by a shared AAA server within the data center to ensure that management and user roles are common throughout a zone.

Related CMS ARS Controls include: AC-3 - Access Control, AC-5 - Separation of Duties, and AC-6 - Least Privilege.

Rationale:

This rule prevents accidental or unauthorized access.

BR-F-13: Consistent Security Categorization within ARS Security Boundary

All applications or systems within the same security control assessment boundary must implement security controls that meet the requirements for the highest Federal Information Processing Standards (FIPS)-199 security categorization level rating of any of the applications or systems.

Related CMS ARS Security Controls include: RA-2 - Security Categorization, CA-6 - Authorization, and SC-32 - Information System Partitioning.

Rationale:

Security is only as good as the weakest link. All systems within the same Security Control Assessment (SCA) Boundary must be hardened adequate to prevent compromise of the most sensitive system or data. A compromised system may be used to attack other systems within the boundary.

BR-F-14: Applications with Disparate FIPS-199 Security Categorization Levels Must Not Be Hosted on the Same Server

BR-F-13 also establishes requirements related to this recommended practice.

Related CMS ARS Security Controls include: RA-2 - Security Categorization, CA-6 - Authorization, and SC-32 - Information System Partitioning.

Rationale:

Co-locating systems with disparate ratings is not a normal practice because providing additional security controls to bring FIPS Low-rated applications to the FIPS Moderate or a higher grade, as required by BR-F-13, will increase the complexity and costs of the process.

BR-F-15: Ensure Timely Version, Patch, and Configuration Management Practices

All organizations responsible for operations and maintenance (O&M) of CMS Processing Environments must develop and employ timely version, patch, and configuration management practices to protect CMS component hardware, software, and data against threats to confidentiality, integrity, and availability while minimizing negative impacts to business operations. These practices must include coordination with other related CMS Processing Environment operators and affected application owners.

Related CMS ARS Security Controls include: CM-1 - Policies and Procedures, CM-3 - Configuration Change Control, and PL-2 - System Security and Privacy Plan.

Rationale:

Delaying deployment of new security features and patches leaves CMS IT assets vulnerable. Untimely and uncoordinated deployment of new security features and patches can also interfere with business operations, disrupt the normal operation of IT systems, or introduce unexpected issues affecting the interoperability, performance, or access to CMS IT systems. Therefore, having effective and efficient version, patch, and configuration management practices are essential to the operations of CMS Processing Environments.

BR-F-16: All Hosts Must Share a Common, Authenticated Time Server

Rationale:

This rule ensures that audit logs can be correlated between systems. Originally, this rule was non-production only, but it applies to all OS instances (such as VM, physical, cloud compute and containers that run their own Network Time Protocol Daemon) as well as networking equipment.

BR-F-17: The CMS TRA Applies to Custom-Produced as well as COTS Products and Services

Rationale:

The CMS TRA is an integrated approach to system and security engineering. Commercial Off-the-Shelf (COTS) products as well as custom-developed software must comply with the CMS TRA to ensure interoperability within and integration into the CMS Processing Environments. This compliance must be validated prior to acquisition. The TRB may allow an exception for COTS products that cannot be made to comply; however, these deviations must be documented, reviewed, and approved by the TRB.

BR-F-18: Use .Gov Domain Names for All CMS Internet Traffic

All CMS Internet traffic for Agency business, including all web traffic and email, must use domain names ending in “.gov”. Requests for the use of second-level domain names not previously used for CMS Agency business must be approved by the CMS Office of Communications.

Rationale:

Both the OMB and HHS have policies prohibiting the use of most top-level domains for agency business.

The OMB Memorandum M-23-22, Delivering a Digital-First Public Experience, September 22, 2023, stipulates each agency must use only an approved .gov or .mil domain for its official public-facing websites. The requirement to use only approved government domains does not apply in circumstances where the agency is a user or a customer of a third-party website or service that resides on a non-governmental domain.

The HHS Internet Domain Names Policy regulates the usage, approval, acquisition, and registration of HHS Internet domain names. The CMS Office of Communications coordinates waiver requests for second-level .Gov domain names, such as healthcare.gov, medicare.gov, and CMS.gov.

BR-F-19: Communication Initiated to Internet-Based Services from ATO’d Environments Must Be Allowlisted

Communications initiated to Internet-based services must be allowlisted, either by IP address or by domain name, by a CMS-controlled security service.

Exception: An application may be granted broader access capabilities if it uses an authenticated security service that keeps detailed usage logs. To obtain such an exception, consult with the TRB before adopting such an architecture.

Related CMS ARS Security Controls include: AC-3(09) - Supplemental: Controlled Release, AC-4 - Information Flow Enforcement, AC-4(08) - Supplemental: Security and Privacy Policy Filters, and AC-6 - Least Privilege.

Rationale:

Environments covered under an ATO typically contain CMS data (not test data) and are targets for attack. To reduce the likelihood of unauthorized or unintended disclosure and exfiltration as well as limit the impact of malware, Internet endpoints for CMS applications must appear in a security service allowlist.

An associated CMS TRA business rule, BR-SEC-FW-2, defines how interzone communications are restricted (by default).

BR-F-20: Untrusted Services and Code from Third-Party Websites and Applications

CMS applications should only use services from Third-Party Websites and Applications (TPWA) where the terms of service are acceptable with regard to CMS business needs, including security and privacy, data use, and service levels.

Likewise, CMS applications should only reference or initiate the download and execution of code from TPWA providers where the terms of service are acceptable with regard to CMS business needs, including security, privacy, and data use. Examples of TPWA-provided code include, but are not limited to, scripts that run in a browser, apps that install on desktop or mobile devices, or executable software.

Related CMS ARS Security Controls include: AC-20, Use of External Systems.

Rationale:

Using untrusted code or services from a TPWA may lead to potential data leakage and privacy violations. Referencing services or downloading or code from a TPWA is inviting an external source to operate in concert with applications from CMS. This is a dangerous practice because the TPWA provider may change their code at any time and without notice. This may result in malware execution because a TPWA domain name expired, the link was changed, or the code was changed without notice to CMS.

Some TPWA providers may also embed in their code or content links to additional TPWA providers who may distribute unwanted content or malware. TPWA providers may also share collected data with additional unidentified providers who may not be bound by the TPWA’s terms of service.

RP-F-21: Limit Data in the Application and Presentation Zones

While application services (Application Zone) may temporarily store data for processing as described in BR-SA-5 , the data should be limited to only what is needed to complete the processing task. Avoid having full copies of data sets (i.e., files, query datasets, etc.) in the Application and Presentation Zones.

BR-F-22: The CMS TRA Defines a Services Framework Architecture

The Services Framework Architecture defines services based upon function, edge services, application services and data services. Mediation services are required to be applied to each service to provide compliance and security.

The Services Framework is a service-fabric that integrates services as required with two key requirements - data should be at least three independent challenges away from the open Internet and a service should front access to the application data.

To comply with the defense-in-depth principles, the architecture should implement a service as the authorized channel to access the application data. Users from external networks, CMSNet, or the CMS LAN must be authenticated to access the service fronting the data. Additionally, the file storage service must be configured to deny access to all unauthenticated users and all unauthorized users.

Related CMS ARS Security Controls include: CM-2 - Baseline Configuration, PL-8 - Information Security Architecture, SA-8 - Security Engineering Principles, SC-2 - Application Partitioning, and SC-32 - Information System Partitioning.

Rationale:

The evolution of cloud and modern technologies has created more dynamic environments. As a result, the Service Framework Architecture, has been developed to align Defense-in-Depth principles with new cloud architectures.

CMS Technical Review Board

This topic is based on the TRB Research Spotlight CMS TRB Engagement Guidance, Updated June 7, 2024.

The Technical Review Board (TRB) is the CMS governing body that oversees and provides guidance on CMS’s IT investments to ensure they are consistent with the Agency’s IT strategy and architecture. The TRB provides intellectual continuity of high-level architectural decisions and direction, and promotes IT reuse, information sharing, and systems integration across the Agency.

The TRB engages with project teams by request at key decision points throughout the CMS IT project life cycle in accordance with the project’s demonstrated compliance with

The CMS Target Life Cycle (TLC)
Agency enterprise architecture principles
CMS policies, procedures, standards, and guidelines

The TRB encourages developers, especially developers using the newer, iterative development methodologies (e.g., Agile and Lean), to review and plan their project implementation to minimize the impact of changes resulting from TRB guidance received during the development process. For more information about engaging with the TRB, please visit the CMS TRB SharePoint site.

The Technical Review Board offers different engagement types reviews of any proposed system . Project teams can engage with the TRB for various purposes, facilitating project progress and adherence to CMS standards. The TRB provides technical consults on CMS projects related to Infrastructure, Software, Interface, Security, Performance, and Technology at various stages of the system lifecycle. These consultations may occur on an ad-hoc basis or follow a regular cadence, allowing for discussions with the TRB to benefit from their expertise without impeding project timelines.

TRB Services

The CMS Technical Review Board (TRB) is a technical assistance resource for project teams across the agency at all stages of their system’s life cycle. It offers consultations and reviews on an ongoing or one-off basis, allowing project teams to consult with a cross-functional team of technical advisors. It also guides project teams on adhering to CMS technical standards and leveraging existing technologies.

Teams can consult regarding:

ask for help with a technical problem
review potential solutions or ideas with the TRB and other Subject Matter Experts (SMEs)
schedule an ongoing cadence of technical consultations
consult with SMEs from across the agency
consult with the TRB about CMS guidelines and standards
request research or information about a particular technical topic

Requesting TRB Services

The project team can request TRB services at any point in the life cycle of the project. The TRB CaaS and TRB Consults can all be requested by submitting a Technical Assistance request in EASi system at easi.cms.gov/trb or by reaching out via email to the TRB mailbox at CMS-TRB@cms.hhs.gov. Such requests must be initiated by a CMS Employee, preferably the business owner, project manager, or technical lead.

Preparing for TRB Sessions and TRB CaaS Engagement

To help facilitate the TRB Consults, TRB requires the project teams to fill in the EASi intake form with a clear business context, any relevant technical diagrams, and the areas where help is sought and upload any relevant artifacts before the scheduled meeting.

The TRB Consults and TRB CaaS engagements are informal and do not have any prescribed templates for the presentation. The project teams are recommended to provide a document explaining the system and the changes/questions that the team is seeking guidance on, along with a background and brief description of the system and the system diagrams. Most of the technical discussion centers around the system architecture/design diagrams, and the project team should prepare system architecture/design diagrams that depict the current and proposed changes with all the system components. Clear and complete diagrams will lead to a more meaningful engagement.

The TRB-published review templates are located on the CMS Enterprise website at:
TRB Architectural Diagrams Sample and Diagram Requirements - Instructions

What Project Materials are required for the TRB Engagements?

To help facilitate the TRB Design and Operational Readiness Session engagements, TRB requires the project teams to fill in the TRB Templates noted above and send them to the TRB mailbox in advance of the scheduled meeting.

TRB Consults and TRB CaaS engagements being informal, do not have any prescribed templates for the presentation. The project teams are recommended to provide a document that explains the system and the changes/questions that the team is seeking guidance on, along with a background and brief description of the system and the system diagrams. A majority of the technical discussion centers around the system architecture/design diagrams and the project team should prepare system architecture/design diagrams that depict the current and proposed changes with all the system components. Clear and complete diagrams will lead to a more meaningful engagement.

Who Should Attend the TRB Engagements?

The following members should attend:

A CMS employee with oversight of the project, such as CMS’ Contracting Officer Representative (COR) and/or Government Task Lead (GTL)/ CMS Project Manager, must be present at the sessions. (Note: The TRB cannot meet without one of these individuals).
CMS Business Owner Representative.
Information Systems Security Officer (ISSO).
Contractor Project Manager (PM) responsible for the overall effort
Lead Business Analyst who can address the business purpose, context, and process.
Lead Technical or Solution Architect who can address the architecture and design.
Development lead who can address the development process, DevSecOps, and overall testing.

What do I need to do on the day of my Scheduled TRB Session?

TRB Session meetings are conducted at CMS’ Central Office, and zoom sessions are always available. In the case when the CMS Central Office is closed, TRB Session meetings will be held entirely virtually. To attend the meeting virtually, please click on the TRB Meeting link that is sent in the meeting invite.

We recommend that you login a few minutes early to ensure that you can share your screen and display your presentation properly.

Please make sure to input your full name when logging into Zoom for the TRB Meeting. Due to the sensitive nature of the presentations, we require that all participants identify themselves on Zoom. Unidentified participants will be removed from the call.

What to expect after the TRB Session?

The project teams will receive a TRB Advice Letter within five business days for any Design/Operational Readiness/Consults. TRB Consult as a Service engagement meetings run by the TRB will be provided with a response in the form of meeting notes within a couple of days of the engagement. For continuous ongoing TRB CaaS engagement, the TRB notes might be sent out based on a need-by-need basis as determined by the TRB.

References

TRA Architecture Change Request (ACR) Process

The ACR Process establishes the standard CMS process for request, review, approval, and publication of changes to the CMS TRA. The ACR Process consists of the major activities as shown in Architecture Change Request Process and below. The CMS TRA is accessible via the TRA websites. The complete version of the TRA is provided via an internal TRA website tra.cloud.cms.gov that is accessible to CMS employees and contractors with CMS network access. A public version is available to anyone at cms.gov/tra. The public version has CMS sensitive information redacted. Information about the CMS Target Life Cycle (TLC), often referenced in conjunction with the CMS TRA, is accessible on the cms.gov public site.The OIT ISPG site CyberGeek is also available to the public.

TRA Release Process

Request for Change

Architecture Change Requests are now integrated with the overall TRA Release Process. Users may submit change requests through the TRA website, using the Topic Feedback feature, or optionally the Review site’s Annotator Feature. In either case, this request will create a Jira ticket to track it. The process below remains available.

CMS employees submit requests for changes to the CMS TRA using an Architecture Change Request (ACR) Form that is delivered to the Division of IT Investment Management and Policy (DIIMP) via an email to the CMS IT_Governance@cms.hhs.gov mailbox. CMS Contractor partners and/or other employees who identify the need for an Architectural Change should request their Government Task Lead or other CMS employee submit a change request on the contractor’s behalf.

Review and Prioritization

The CEA and TRB reviews submitted ACRs to determine how they will be addressed and either closes the request or schedules the change request for processing.

Reasons for closing a change request at this point include, but are not limited to:

Duplicate requests
Out-of-scope activities (e.g., production implementation steps)
Lack of information to support any actions taken on behalf of the request

Proposed Updates to the TRA

Based on input from the CEA, the TRA Release Coordinator works with subject matter experts (SME) to identify changes to the CMS TRA to incorporate into an upcoming release. The TRA Release Coordinator ensures that all selected ACRs are addressed with the stakeholders and SMEs and coordinates the appropriate changes across all impacted parts of the CMS TRA.

TRA Release Review – Initial TRB Consult

When the proposed updates are completed, the TRA Release Coordinator submits the revised TRA to the TRB for initial review and schedules a TRB consult to discuss the proposed changes. The TRA Release Coordinator then updates the release based on TRB Consult comments and feedback received during the review period. Some comments may be addressed by creating a new ACR to be assigned to a future release.

TRA Release Review – Group Review

The TRA Release Coordinator submits the release for review by CMS Group Directors, CMS Business Units, and CMS data center operators for review and comment. The TRA Release Coordinator then updates the release based on comments and feedback received during the review period. Some comments may be addressed by creating a new ACR to be assigned to a future release.

CIO / CEA Review and Signature

After the TRB and Group reviews are completed and all comments are addressed, the TRA Release Coordinator submits the release to the CIO and CEA for review, approval, and signature. If the CIO or CEA have any comments, the TRA Release Coordinator addresses the comments and resubmits the release for final review and approval. After all CIO / CEA comments have been addressed, the CIO and CEA sign the release.

Release Publication

After the CIO and CEA sign the release, the TRA Release Coordinator publishes the updated CMS TRA. As prescribed in BR-F-2, The CMS TRA Applies to All CMS Processing Environments, the latest published CMS TRA applies immediately for new systems; for existing systems, compliance with CMS TRA updates is required within twenty-four (24) months of publication.