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.