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 CTO and CIO 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: (a) The information security steps of the CMS Target Life Cycle (TLC) to incorporate information security and privacy control considerations; (b) The information system architecture defined within the Technical Reference Architecture (TRA); and (c) 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 data, whether called “production,” “test,” “pilot,” “proof-of-concept,” or “other,” must be covered under a CMS ATO (in accordance with the USA PATRIOT Act of 2001 and Homeland Security Presidential Directives). This rule applies to any environment that stores or processes CMS data, to include disaster recovery (DR) sites and archival storage.
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.
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 "Authorizations & Agreements" 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.
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.
Backups also differ from archives, which are performed for Records Management.
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 Risk Management Handbook Chapter 6: Contingency Planning).
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-17-06, Policies for Federal Agency Public Websites and Digital Services (November 8, 2016), 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.