Introduction

The Risk Management Handbook Chapter 15, System and Services Acquisition, discusses how the organization must:

1. Allocate sufficient resources to protect organizational information systems;
2. Employ system development life cycle processes that incorporate information security and privacy assurance considerations;
3. Employ software usage and installation restrictions; and,
4. Ensure that third- party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization.

Controls discussed in this chapter include System Development Life Cycle (SDLC), Acquisition Process, Information System Documentation, Supply Chain Protection and Trustworthiness. There are also controls addressing developer configuration management, security testing and evaluation, training, security architecture and screening.

System & Services Acquisition controls

This section contains the applicable procedures that facilitate the implementation of the SA family security and privacy controls.

Allocation of Resources (SA-2)

The purpose of this control is to determine information security and privacy requirements for the information system or information system service in mission/business process planning, document and allocate the resources required to protect the information system or information system service as part of its capital planning and investment control process, establish a discrete line item for information security and privacy in programming and budgeting documentation, and include information security requirements in mission/business case planning. CMS uses the financial document called the Major IT Business Case (MITBC)5 to allocate finances to programs/projects. If assistance is needed to submit a budget request, contact the Division of IT Investment Management. This division can communicate through phone or email to give guidance on filling out budgetary paperwork such as the MITBC.

The budget allocated at the beginning of the program/project during the acquisitions phase will assist in obtaining management support for including information security and privacy 

requirements into information systems, system components, and services acquisition. It also creates a process that links information security and privacy to the development of information systems to keep it in focus throughout the lifecycle of the system. The allocated budget of information security and privacy during the early stages of development will ensure IT security and privacy are fully integrated throughout the lifecycle of the project.

The following steps detail the CMS specific process for the implementation of this control:

• Step 1: During the CMS-SDLC Initiation phase, the CMS Portfolio Team, consisting of the Business Owner (BO), Information System Security Officer (ISSO), Cyber Risk Advisor (CRA), and Privacy Advisor, shall determine the information security and privacy requirements for the information system or information system service in the mission/business process planning by following RMH Chapter 12 Security and Privacy Planning, which contains procedures to complete the security categorization for the information system. The categorization is leveraged to select the appropriate baseline of minimum security controls using the procedure in RMH Chapter 12, for security control selection. The ISSO then identifies the list of security and privacy-related activities/assets that will require an IT budget and work with the BO to establish an overall budget for those items. Potential security and privacy-related activities/items might include but are not limited to:
  • Security Controls Assessments (SCA)/Adaptive Capabilities Testing (ACT)
  • Continuous Diagnostics and Mitigation (CDM)
  • Penetration Tests
  • Security and Privacy Training (awareness and role based)
  • Developing adequate documentation (SSPP, contingency plan, SIA, PIA, ISRA, incident response plan, configuration management plan, etc.)
  • Testing (contingency and incident response) Hardware/appliances or licensing for software tools
• Step 2: The BO and ISSO shall determine the resources required, document the resources needed in the appropriate Budget Document (Office of Management and Budget (OMB)-300), and allocate the resources identified to protect the information system or information system service as part of CMS Capital Planning and Investment Control Process (CPIC).
• Step 4: The BO shall establish a discrete line item for information security and privacy in organizational programming and budgeting documentation. The BO shall submit a request for appropriations for the full cost of IT investment acquisitions, including system lifecycle operations costs, to supply the necessary information for budget decisions, then submit the security and privacy line-item requests for IT funding, including all requests for IT training funds, to be reviewed by the Business Architecture and Technology Solutions (BATS) Board. The line item is then submitted for approval by the CMS Information Technology Investment Review Board (ITIRB).
• Step 5: The BO will enter the approved security and privacy line items into the IT Portfolio Summary (ITPS) for the CMS Capital Planning and Investment Control (CPIC) process.

This next step is only required for IT Investments of over $10,000,000 ($10M) since these investments are reported to congress:

• Step 6: The BO and/or the Program Executive (PE) will write the security and privacy requirements as a discrete item in the information system MITBC to request the allocation of resources required for the security and privacy protection of the information system or information system service. The ISSO shall advise and assist the BO and PE on the information system security and privacy requirements and documentation. The following template should be used; Annual Operational Analysis (AOA) Report, approved by the CMS Division of IT Investment Management6, and complete an MITBC as explained in OMB Circular A-117 section 55. OMB will be evaluating all elements of the budget submission and will communicate the results of their evaluations during the active budget process.

System Development Life Cycle (SA-3)

The System Development Life Cycle control is implemented to enforce the integration of security and privacy requirements at the beginning of a system development project. For use in identifying roles, CMS maintains due diligence by naming parties responsible for security and privacy. CMS fulfills this Life Cycle requirement with the CMS-SDLC, currently the Target Life Cycle (TLC). Developers will be expected to follow the CMS-SLDC processes in order to comply with security and privacy requirements. Also, as part of the continued implementation of the SA-3 controls, those systems processing, storing, or transmitting Personally Identifiable Information (PII), must support privacy by automating privacy controls and ensuring that privacy requirements are met throughout the systems life cycle process (AR-7).

Building security and privacy into system development addresses concerns throughout the life of a system. Making enhancements after the system is developed is not cost-effective. In addition, this control reinforces a formal process that will create artifacts. These artifacts can support compliance and auditing for CMS.

The table below outlines the CMS parameters for control SA-3:

Table 1: CMS Defined Parameters - Control SA-3

The following steps detail the CMS specific process for the implementation of control SA-3:

• Step 1: CMS System Developer/Maintainer goes to the webpage for the current CMS-SDLC to get the current guidance to follow the CMS-SDLC
• Step 2: The BO or designee (such as the PE) will include Security and Privacy Artifacts or Tasks and Information in the project plan for the Information System/System Component/Information System Service to ensure that the CMS-SDLC project security deliverables are included in the plan.
• Step 3: The ISSO or BO designee for the system logs into CMS FISMA Controls Tracking System (CFACTS) using the “CFACTS User Manual” which can be found on the CFACTS home page. Within CFACTS, the CMS ISSO must define the security roles as outlined in RMH Chapter 12 Section 3.1.3. This is done during the CMS-SDLC Concept and Planning phases for the Investment Selection Review process.
• Step 4: The CMS-SDLC is a flexible process that takes in feedback and is reviewed periodically. If the Project/Program Manager sees that the CMS-SDLC is not meeting the needs of the project, then a Process Change Request can be completed and submitted to CMS IT Governance Resource Mailbox. The IT Governance team will review and reply to the change requests about the CMS-SDLC process.
• Step 5: The System Developer and Maintainer (SDM) must use the Technical Reference Architecture (TRA) for the development of the information system. 

Acquisition Process (SA-4)

The acquisition process is involved with information technology hardware, software and services purchases. This control incorporates the following types of information security requirements and conditions from CMS into their acquisitions contracts:

• Security functional requirements
• Security strength requirement
• Security assurance requirements
• Security-related documentation requirements
• Requirements for protecting security-related documentation
• Description of the information system development environment and environment in which the system is intended to operate
• Acceptance criteria

Contracts extend the security and privacy of CMS information systems. Therefore, the inclusion of language specific to the purchased information system, system component or information system service, as provided in this control, can help to engage contractor and vendor support of security needs. Also, for systems processing, storing, or transmitting PII, privacy requirements must be included in contracts and other acquisition-related documents. General templates have been developed by HHS and CMS to help develop custom contracts for new acquisitions.

The following steps detail the CMS specific process for the implementation of control SA-4. The program office must evaluate the types of services and personnel that may be involved with the Statement of Work (SOW) to include the appropriate pre-determined standard security language that should be included within the contract using the following steps:

• Step 1: The ISSO, System Owner, and/or Program/Project Manager, shall complete Part A of the Information Security Certification Checklist and have it signed by the CMS CISO or designee.
• Step 2: The Privacy Officer, Data Owner and/or Program/Project Manager, shall complete Part B of the Information Security Certification Checklist and have it signed by the CMS Senior Official for Privacy or designee.
• Step 3: After return of the signed Information Security Certification Checklist, the Contracting Officer Representative (COR) will include the required content contained within CMS’ Security and Privacy Language for Information and Information Technology Procurements into the appropriate places of the SOW.
• Step 4: The COR then removes redundant parts from included sections and replaces applicable general language with contract specific language and numbering in the final version of the document.

Functional Properties of Security Controls (SA-4(1))

The control enhancement, functional properties of security controls, requires documentation of how systems provide security capabilities and the mechanisms that comprise those capabilities. This information is collected through the documentation of the security controls of the system in CFACTS.

CMS implements this control so that developers of CMS information systems, system components, or information system services have a record of how the interfaces are secured. CMS can examine the documentation for what type of security is expected to be in place and render the developers accountable.

The CMS specific process for the implementation of control SA-4(1) is to document security controls in the Systems Security Plan during the CMS-SDLC Planning phase. During this phase, the ISSO must input the security controls into CFACTS as detailed in RMH Chapter 12: Security and Privacy Planning, for documenting security controls.

Design/Implementation Information for Security Controls (SA-4(2))

Design/Implementation for Security Controls looks at the high-level design as well as the security- relevant external interfaces. The design and interface information should provide enough detail to understand what system interfaces are in place, what they are used for, and how they fulfill security control requirements. The system developer(s) will provide the documentation in accordance with the requirements defined in Table 3: CMS Defined Parameters – Control SA-4(2) below.

CMS must develop systems that are well-documented, maintainable, and secure. Requiring documentation for systems high-level design and security-relevant external interfaces provides a reference for maintaining and repairing the system. The documentation of the design allows knowledge to be shared and transferred to those that need to maintain security and the system overall.

The table below outlines the CMS parameters for control enhancement SA-4(2):

Table 2: CMS Defined Parameters - Control SA-4(2)

The following steps detail the CMS specific process for the implementation of control enhancement SA-4(2):

• Step 1: The developer creates this document during the Design phase of the CMS- SDLC, using the template provided on the CMS-SDLC information webpage. The ISSO collects the System Design Document for review in Step 2.
• Step 2: ISSO reviews the System Design Document systems-development artifact, containing the high-level design from the system developers, for enough detail to prove that the security controls are implemented.Checklist 1:
  • High-Level Design
    • Exists in System Design Document
    • Shows proof of security controls implementation
• Step 3: ISSO collects the Interface Control Document systems-development artifact, for review in Step 4, as created by the developer during the CMS-SDLC Design phase.
• Step 4: ISSO reviews the Interface Control Document for sufficient detail to understand the existence, purpose and use of security-relevant external system interfaces.
  • Checklist 2:
    • Security-Relevant External System Interfaces
    • Exists in Interface Control document
    • Outlines all Security-relevant external system interfaces
    • Are explained as to why they are there
    • Shows how they are or plan to be used
• Step 5: ISSO collects the Implementation Plan systems-development artifact as created by the developer during the CMS-SDLC Design phase. The template available on the CMS-SDLC webpage.
• Step 6: ISSO reviews the Implementation Plan for sufficient detail to see the “source code” and the “hardware schematics” in the implementation representation.
  • Checklist 3:
    • Source Code
      • Source code is represented in the implementation plan by at least the level of detail in an information flow diagram.
    • Hardware Schematics
      • Hardware schematics is represented in the implementation plan by at least the level of detail in a system architecture diagram.
• Step 7: The ISSO decides if the plans proceed to the gate review for the Technical Review Board (TRB). If these plans are satisfactory, the plans are reviewed by the TRB during the Design phase of the CMS-SDLC for the Preliminary Design Review, otherwise the plan that requires changes is returned to the developer for updates and review for those suggested changes to be made. The plan is to be returned to the ISSO until determination that the plan can go onto TRB review.

Functions/Ports/Protocols/Services in Use (SA-4(9))

The purpose of this control enhancement is to identify and update the functions, ports, protocols, and services utilized by the information system during the system development life cycle. It requires all developers of information systems, system components, or information system services to identify early in the system development life cycle, the functions, ports, protocols, and services utilized by the information system to transmit, store, or process CMS data. It allows the ISSO to influence the design of the information system, information system component, or information system service to ensure the appropriate security controls are selected and implemented.

Managing risk and implementing the appropriate protection measures during this phase is critical to the confidentiality, integrity, and availability of the information system and resources. This early involvement in the life cycle helps organizations to avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services (or when requiring information system service providers to do so). Early identification of functions, ports, protocols, and services avoids costly retrofitting of security controls after the information system, system component, or information system service have been implemented. The listing also fulfills part of the Technical Reference Architecture (TRA) Volume II Network Services, as documented proof of compliance.

The following steps detail the CMS specific process for the implementation of control enhancement SA-4(9):

• Step 1: The system developer/maintainer working with the ISSO will identify functions, ports, protocols, and services early in the CMS-SDLC in the design, development and requirements analysis phases within the CMS-SDLC Framework by outlining them in CFACTS within the Boundary tab of the system authorization package under the Authorization Boundary Description. Additionally, the information should be input into CFACTS under the Controls tab of the Authorization Package as part of the Shared Implementation Details for the allocated control SA-4(9). These sections include information applicable to the system, such as functions, ports, protocols, and services.
• Step 2: CMS TRB will review these parts of the System Security Plan and specifically the design of the information system, information system component, or information system during the Detailed Design Review during the CMS-SDLC Design phase. TRB will compare them to organizational needs of the TRA and return the developer to Step 1 if the needs are not fulfiled.

Use of Approved PIV Products (SA-4(10))

The purpose of this control enhancement is to ensure the organization employs only information technology products on the FIPS 2018-approved products list for PIV capability implemented within organizational information systems. This is the result of CMS abiding by Homeland Security Presidential Directive 12. The directive calls for an identification standard, which CMS follows using the agreed upon FIPS 201 standard.

To follow the CMS specific process for the implementation of control SA-4(10), the CMS BO should select only information technology products that are compliant with FIPS 201. Pre- approved products are listed here.

Information System Documentation (SA-5)

CMS must protect documentation by distributing documentation to defined personnel or roles as defined in the applicable CMS System Security and Privacy Plan (SSPP). In addition to the security and privacy artifacts required by the CMS-SDLC for system life cycle planning, there are various types of other documentation that CMS must have for each system implementing this control.

The BO or ISSO will then need to evaluate whether additional documentation is essential for the effective implementation or operation of security controls. The other types of documents can be divided into two areas, administrator and user.

The system must have administrator documentation for the information system, system component, or information system service that describes:

• Secure configuration, installation, and operation of the system, component, or service;
• Effective use and maintenance of security functions/mechanisms; and
• Known vulnerabilities regarding configuration and use of administrative (i.e., privileged) functions.

The system must also have user documentation for the information system, system component, or information system service that describes:

• User-accessible security functions/mechanisms and how to effectively use those security functions/mechanisms;
• Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner; and
• User responsibilities in maintaining the security of the system, component, or service.

CMS requires these documents so that it can have a reference for the setup and operation of its own systems. Readily available documentation that lists solutions to common problems may lessen 

system down time. Failure to have system reference material may result in longer system downtimes if troubleshooting processes occur. CMS will make a record for failed attempts to retrieve a document and then review them on a case-by-case basis to determine if the documents should be created. There must also be protections in place so that administration information is kept confidential since the operation of these systems may be sensitive.

The table below outlines the CMS parameter for SA-5 Information System Documentation.

Table 3: CMS Defined Parameters - Control SA-5

The following steps detail the CMS specific process for the implementation of control SA-5:

• Step 1: The ISSO uses the repository in CFACTS for the system under the “General” tab in the “Appendix Documentation” for distribution of the user and administrators’ documents.
• Step 2: The ISSO of the information system, system component, or system service will collect the administrator documentation as described in this control and put it in “Appendix Documentation.”
• Step 3: The ISSO of the information system, system component, or system service will collect the user documentation as described in this control and put it in “Appendix Documentation.”
• Step 4: The ISSO will log in to CFACTS to ensure that the permission levels for accessing the user and administrator documentation reflect the roles and responsibilities assigned to designated personnel as per the system security plan.
• Step 5: The ISSO updates the issues list when a stakeholder tries to access documentation and discovers that it is unavailable with the document name and a comment about its availability.
• Step 6: The issue list must be reviewed to determine if the documentation is needed. The system ISSO can create a Plan of Action and Milestones (POA&M) to retrieve or create the documentation or accept the risk of not having the documentation then update the issue list with the resolution.
• Step 7: ISSO should ensure documentation as required by the SSPP is distributed to defined personnel roles as outlined.

Security Engineering Principles (SA-8)

This control is used to gather artifacts and evidence that security and privacy principles are applied to development practices. Developers at CMS creating systems to process federal information are expected to follow the CMS-SDLC for system development. The CMS-SDLC was created with security and privacy in mind and requires various security and privacy artifacts to be created. The developer follows the CMS-SDLC and uses the built-in security principles that are applied to the engineering practices to develop a CMS information system, system component, or system service. Additionally, the CMS-SDLC covers modifications of CMS systems as well as new system development.

This control is implemented to make sure that CMS developers follow regimented procedures and are mindful of security and privacy throughout the life of a system. CMS builds the security and privacy into the system from the beginning of the system life cycle to save resources. Increased expenditures apply to systems when security must be added later in the development process or to systems in operation.

To follow the CMS specific process for the implementation of control SA-8 the CMS developers will use the CMS-SDLC to incorporate security and privacy principles into the system development process as defined in detail on the CMS-SDLC webpage.

External Information System Services (SA-9)

External Information System Services calls for defining how CMS must have oversight of the service and the roles and responsibilities associated with the service. These services, when purchased by CMS, are expected to comply with related security and privacy controls in the ARS to secure the system for compliance with the CMS IS2P2 and governing regulations. Additionally, if the service processes PHI, HIPAA privacy rules will apply.

CMS will relinquish some information system tasks to external services to lower the cost of an information system. The external nature of these services implies that U.S. Citizen and CMS employee PII or PHI will travel outside of the agency. CMS is bound to minimize the risk of exposure to this data. Lowering the risks are achieved by enacting security and privacy rules and baselines as specified by CMS, overseeing the implementation of those rules by assigning CMS employees to security and privacy roles and responsibilities, and monitoring those external systems continuously.

The table below outlines the CMS parameter for SA-9, External Information System Services:

Table 4: CMS Defined Parameters - Control SA-9

The following steps detail the CMS specific process for the implementation of SA-9 control:

• Step 1: The CMS Contracting Officer (CO) and/or Contracting Office Representative (COR) ensure that the providers of external information system services comply with ARS-selected information security and privacy controls. This is accomplished through CMS’ Contracts, Statements of Work (SOW), Service-level Agreements (SLAs), Interconnection Security Agreements (ISAs), and Memorandum of Understanding/Agreement (MOU/A).
• Step 2: To categorize systems, the system ISSO must assess the external information system service using the security categorization and security control selection procedures from the RMH Chapter 12 Security Privacy and Planning . This will show the ISSO which ARS controls apply to the system. 
• Step 3: The Security Control Assessor can initially audit the selected security reflected in CFACTS and assess using the procedure listed in the ARS under each selected control then record the result using the Security Assessment Report as outlined in the CFACTS User Manual.
• Step 4: The ISSO can reference government oversight and user roles and responsibilities regarding external information system services as documented and defined in the HHS Information Systems Security Policy (IS2P), and in the CMS IS2P2, to correctly assign them to a system.
• Step 5: The ISSO can also define and document user roles and responsibilities further by listing specific personnel in CFACTS per the CFACTS User Manual section on Stakeholders (See also SA-3).
• Step 6: The CRA, or their designee, can document, on an ongoing basis, audit results that demonstrate the system’s compliance with required security and privacy controls within CFACTS. The system security control policies are outlined in the CMS IS2P2, specified in the CMS ARS, and are listed in each SSPP. The CMS Assessment Audit Tracking (CAAT) file is used to document the audit results. The directions to use and upload the CAAT file is in the CFACTS User Manual .

Identification of Functions/Ports/Protocols/Services (SA-9(2))

CMS uses this control enhancement to document identified system functions, ports, protocols and services required to use external information systems services. These can be retrieved by CMS in the form of administrator guides or specification sheets from the provider if the items are clearly identified and input by the system developer and maintainer into the systems security plan.

CMS wants the identification of functions, ports, protocols and services required to use cloud service implementations to be documented and available. This allows for an easier comparison of external information system services and functions before a purchase. The comparison gives CMS a clearer picture of the security implications involved with the implementation of a system or service so that a cost estimate is more accurate. The documentation will detail the ports, protocols and services will be considered for the security of the information system. It will also document functions and services provided by the product/service to demonstrate that it meets CMS guidelines, applicable laws and regulations.

The table below outlines the CMS parameter for SA-9(2) Identification of Functions / Ports / Protocols / Services:

Table 5: CMS Defined Parameters - Control SA-9(2)

The following details the CMS specific process for the implementation of SA-9(2) control:

• Step 1: For external information system service documentation that exists to outline the technical information of the system, the BO will request those that list the functions, ports, protocols, and other services required for the use of external information system services.
• Step 2: The System Developer and Maintainer can record from the provided documents in the applicable CFACTS documentation as outlined in the CFACTS User Manual as part of the boundary description.
• Step 3: For gaps in documentation provided by the provider, the CMS System Developer and Maintainer with the Project/Program Manager and ISSO will document the functions, ports, protocols, and other services required for the use of external information system services in the applicable CFACTS documentation as outlined in the CFACTS User Manual as part of the boundary description.
• Step 4: BO must verify the external information system service meets CMS and HHS security, monitoring, and reporting requirements prior to selecting a service provider. CMS requires that all systems go through an annual assessment, which shall be written into the Authorization Package and the results stored in CFACTS.

​​​​​​​Developer Configuration Management (SA-10)

CMS must consider the quality and completeness of configuration management activities conducted by developers of information systems, system components, or information system services as evidence of implementing effective security safeguards. Safeguards include protection from unauthorized modification or destruction of system hardware, software, and firmware. Maintaining the integrity of changes to the information system, information system component, or information system service requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes.

Configuration Management establishes and maintains the guidelines and methods that govern the procedures and controls necessary to ensure effective change identification, change control, status accounting, and audits of the total environment. The managed environment includes hardware, software, and technical documentation associated with CMS stakeholder and component environments.

Additionally, Change Management enables the understanding of relationships among infrastructure, application, and business process components. It is the foundation of change, incident, problem, availability, and release management. The Change Management processes are tightly integrated with Configuration Management.

Configuration components that are placed within the configuration management process include: the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware source code with previous versions; and test fixtures and documentation.

Depending on the mission/business needs of CMS organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance phases of the life cycle.

The purpose of Developer Configuration Management is to ensure that the CMS requires the developer of the information system, system component, or information system service to:

• Perform configuration management during system, component, or service implementation and operation phases;
• Document, manage, and control the integrity of changes to configuration items under configuration management (as defined by CMS);
• Implement only CMS-approved changes to the system, component, or service;
• Document approved changes to the system, component, or service and the potential security impacts of such changes; and
• Track security flaws and flaw resolution within the system, component, or service and report findings to personnel/roles as designated by CMS.

The table below outlines the CMS parameter for SA-10 Developer Configuration Management:

Table 6: CMS Defined Parameter - Control SA-10

The following steps detail the CMS specific process for the implementation of SA-10 control:

• Step 1: CMS System Developer and Maintainer must perform configuration management9 for the system, component, or service during the development, implementation and operation phases of the CMS-SDLC.
• Step 2: The ISSO will establish security control requirements for identifying and resolving security flaws, manage security impact analyses and flaw remediation and report the findings to the relevant stakeholders, which can be found in the system’s SSPP such as the CMS TRB, ITIRB,10 and System BO.
• Step 3: The PE and system developer/maintainer(s) must adhere to the Change Control and Management processes. Configuration items can only be changed through  submitting change requests such as in the CMS-SDLC Process Change Request form.. The Change Control Process is an integral element of the Change Management process. The process requires a systematic approach to ensure that changes to the operational environment do not impact networks, users, security, or other aspects critical to continuity of operations.

​​​​​​​Developer Security Testing and Evaluation (SA-11)

The Security Controls Assessment (SCA) occurs during the Testing CMS-SDLC phase. An independent third party Evaluator/Assessor needs to plan for assessing security controls by creating the Security Assessment Plan. Furthermore, if the system contains PII, privacy controls must also be addressed by the assessment plan. The developer tests the information system, component or service before it moves to the production environment. When testing for security and privacy control requirements, the Evaluators/Assessors follow their test plan. The test plan should include CMS procedures for assessing security and privacy controls from the ARS, as well as unit, integration, system and regression testing. The Evaluator documents results from all tests in a CMS Assessment/Audit Tracking (CAAT) file. If flaws are discovered through testing in the design of the system, then CMS uses POA&Ms as part of the security testing processes to track and resolve flaws. If there is a rare case where the CRA and the ISSO agree that a risk is not likely to be resolved in a timely fashion or the risk resolution would severely impact business processes, then a Risk Acceptance form can be filed for review, approval/denial and final determination of the risk from the AO. The risk should also be documented in the ISRA template. The risk, the plan for mitigating the risk, and the risk impact will be sent to the AO from CFACTS. The Risk Acceptance will be attached to the POA&M outlining the weakness that it will be addressing.

This testing is built-in to the CMS-SDLC processes to document and illustrate that security controls are built in to the system and are working. CMS requires independent third party Evaluators to create test plans to demonstrate that security controls and possibly privacy controls are considered during testing. The test plan shows the design consideration of security and privacy in systems utilizing PII. Then the CAAT file helps CMS with verification. When the controls are not functioning as intended, Evaluators can document flaws for repair in the CAAT file. Extra protections are enabled for PII systems and CMS includes them in this testing and documentation control to prove and document privacy compliance efforts.

The table below outlines the CMS parameter for SA-11 Developer Security Testing and Evaluation:

Table 7: CMS Defined Parameters - Control SA-11

The following steps detail the CMS specific process for the implementation of SA-11 control:

• Step 1: BO contacts the Information Security and Privacy Group (ISPG) to schedule an assessment. Contact should be made within 6 months in advance of the assessment projected start date, when feasible. The security control assessor will be arranged by ISPG starting from project initiation for shorter term projects, if 6 months is not feasible. It is important to schedule the assessor in a timely manner or risk project scheduling delays.
• Step 2: Evaluator or security control assessor creates and implements a security assessment plan. It outlines the plan for testing controls that are listed and updated in the CFACTS SSPP or Minimum Security Controls under the Controls tab. Additionally, the Software Assurance Misuse Cases started in the CMS-SDLC Design phase can also be added to the planned testing. The plan is created during the CMS-SDLC Test phase. System Teams are encouraged to work with their assessment teams (like the Adaptive Capabilities Testing Team) to manage the security assessments required for your system. 
• Step 3: A security controls assessor must perform unit, integration, system, and/or regression testing/evaluation at the level of depth and coverage specified by the CMS- SDLC Test phase. Thereafter, CMS requires that a percentage of controls governing a CMS system are tested annually.
• Step 4: Security control assessors must produce evidence of the security assessment plan and results of the security test and evaluation in the form of a CAAT Spreadsheet. The appropriate template based on the system security categorization can be downloaded from the CFACTS main page: https://cfacts3.cms.cmsnet.
• Step 5: The security controls assessor sends the completed CAAT spreadsheet to the ISPG for uploading into CFACTS. There should be one CAAT file for each FISMA system or IT Program per security controls assessment engagement. If the CAAT file is the result of an internal audit, then the contractor may upload the file.
• Step 6: ISPG uploads the CAAT files into CFACTS.
• Step 7: ISSO will use POA&Ms to track and document flaws identified during the security test and evaluation prior to entering the operations and maintenance phase of the CMS-SDLC. CFACTS tracks assessment results in accordance with the CFACTS User Manual on Remediation and on POA&Ms. POA&Ms are automatically created when CAAT files include audit results that are “Other than Satisfied”.
• Step 8: The BO, supported by the ISSO, project team, System Developer and Maintainer, security controls assessor, and ISPG develop and implement remedial actions to address the findings that are “Other than Satisfied.” The remedial action can be taken from the audit as the “Recommended Corrective Action”.

The following steps are for systems that contain PII. These are done in addition to the above steps:

• Step 9: The ISSO, with the assistance of the System Developer and Maintainer, adds PII related controls to the assessment plan from Step 1. The PII related controls can be found in CFACTS under the Controls tab or in the ARS labeled with “PII”. CMS policy prohibits the use of sensitive data in non-production environments that have not been assessed and fully authorized. However, circumstances may exist where the use of sensitive data may be required for testing in lower environments (e.g. development/validation). To use sensitive data in a lower environment a risk acceptance is required by the CMS AO. These last steps apply to test environments that contain PII and culminate with the submittal of a risk acceptance to be approved by the CMS AO:
• Step 10: The BO, in coordination with the Senior Official for Privacy (SOP) reviews formal agreements such as Memorandum of Agreement, Memorandum of Understanding, or data exchange agreement between the data owner of the PII and the entity developing/testing. The applicable agreement needs to address how theft, loss or compromise of PII is handled. Interagency agreement templates for the Memoranda and others can be found here on the CMS Intranet: https://agx.cms.gov/Libraries/Library.aspx?LibraryID=54
• Step 11: The Business Owner, in coordination with the SOP, approves the system configuration that minimizes the use of PII to the maximum extent practicable before use in the Test environment.
• Step 12: The Business Owner, in coordination with the SOP, de-identifies or anonymizes PII to the maximum extent practicable before use in the Test environment.
• Step 13: As a final step in this process when utilizing PII in test/development environments, the Business Owner working with the ISSO should request a risk acceptance using the CFACTS tool.

Supply Chain Protection (SA-12)

Implementing protection of the supply chain is one of the methods that CMS uses to ensure the confidentiality, integrity and availability of its information technology resources that are needed to meet the mission goals. CMS is not going to inspect each supplier of components, information systems or services, but rather exercise due care in selecting which information systems, system components, or information system services are acquired. CMS creates methodologies, based on best practices, which are used in formulating contracts and purchasing agreements.

This control ensures that all aspects of its security infrastructure cannot be undermined through the actions of a supplier. It can be easy to accept that the supplier giving CMS an information system or service is reasonably secure. However, a supplier often will get system components from other suppliers as part of the supply chain. CMS shall exercise due diligence by checking suppliers against their best practices and practice due care by rejecting suppliers that do not meet those standards.

CMS is in the early stage of establishing a Supply Chain Risk Managemnet (SCRM) Program in an effort to determine the best method to incorporate security into the agency’s acquisition process. The CMS Division of Physical Security and Strategic Information (DPSSI) is the office of primary responsibility for this effort. Please contact CounterIntelligence@cms.hhs.gov with questions pertaining to existing or new System and Services Acquisition within the agency regarding supply chain vulnerabilities. The table below outlines the CMS parameter for SA-12 Supply Chain Protection:

Table 8: CMS Defined Parameters - Control SA-12

The following steps detail the CMS specific process for the implementation of SA-12 control:

• Step 1: ISSO will document implementation descriptions for applicable security controls selected for the supplier’s product in CFACTS leveraging the procedures documented in RMH Chapter 12: Security and Privacy Planning.
• Step 2: ISSO will ensure, through a properly documented Security Assessment Report (SAR) provided by the supplier, that its organization employs defined security safeguards that ensure an adequate supply of comprehensive, defense-in-breadth information security strategy.
• Step 3: ISSO will ensure, using CMS’s Information Security Penetration Testing team, a thorough test and analysis is performed to validate the readiness of the operational environment.
• Step 4: ISSO will ensure that it validates that the information system or system component received is genuine and has not been altered.
• Step 5: ISSO will ensure, through proper validation with the Office of Support Services and Operations (OSSO), that personnel for the development of CMS systems are cleared for work per the SOW.

​​​​​​​Development Process, Standards, and Tools (SA-15)

Development tools include, for example, programming languages and computer-aided design systems. Reviews of development processes can include, for example, the use of maturity models to determine the potential effectiveness of such processes. Maintaining the integrity of changes to tools and processes enables accurate supply chain risk assessment and mitigation, and requires robust configuration control throughout the life cycle (including design, development, transport, delivery, integration, and maintenance) to track authorized changes and prevent unauthorized changes.

This control requires the developer of the information system, system component, or information system service to follow a documented development process that:

• Explicitly addresses security requirements
• Identifies the standards and tools used in the development process
• Documents the specific tool options and tool configurations used in the development process
• Documents, manages, and ensures the integrity of changes to the process and/or tools used in development

The purpose of this control is to ensure that development process, standards, tools, and tool options/configurations are reviewed within every three (3) years to determine if the process, standards, tools, and tool options/configurations selected and employed can satisfy all applicable System Acquisition (SA) and Configuration Management (CM) security controls.

CMS requires their developers to follow a regimented process. The process involves incorporating security controls, integrating change management, documenting development procedures and identifying standards for development. CMS uses the CMS-SDLC to fulfill this control. System development and its processes are reviewed annually and the CMS-SDLC Steering Committee performs a quarterly review the CMS-SDLC process.

The documentation of standards, tools and processes is a best practice that will enable repeatable processes. This means that once a system development process is defined it can be reviewed on a regular basis and improved. CMS desires repeatable processes to continuously improve upon the activity and formulation of processes in place.

The table below outlines the CMS parameter for SA-15 Development Process, Standards, and Tools:

Table 9: CMS Defined Parameters - Control SA-15

The following steps detail the CMS specific process for the implementation of SA-15 control:

• Step 1: CMS developers will fulfill this control by following the CMS CMS-SDLC as listed on the CMS-SDLC webpage, developers shall obtain the latest approved version of the CMS-SDLC, which is the approved lifecycle for CMS and incorporates security considerations.
• Step 2: The CMS-SDLC Steering Committee will review the CMS-SDLC process for any changes that need to be made for modifications in security controls or increase the efficiency of the overall process.

​​​​​​​Use of Live Data (SA-15(9))

The purpose of this control enhancement is to ensure that CMS approves, documents, and controls the use of live data in development and test environments for the information system, system component, or information system service. Use of live data is specifically disallowed unless approval of the AO is granted before the data is put into use. These implementations need to use appropriate protection measures, as outlined by the NIST 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information section 4 to secure agency information and information systems containing PII and PHI. Notably, the system should utilize the anonymized data substitution outlined in that section. These protections must be as strong as the production environment.

Live data may contain information that is sensitive to exploitation from threats. CMS protects this data with appropriate measures wherever it exists. Protecting the use of live data is part of the due diligence efforts to abide by rules and regulations affecting the kinds of data that CMS collects. As part of this effort, the AO will not accept ‘convenience’ as the sole reason for the developer to utilize live data in development and test environments.

The table below outlines the CMS parameter for SA-15(9) Use of Live Data:

Table 10: CMS Defined Parameters - Control SA-15(9)

To follow the CMS specific process for the implementation of SA-15(9) control enhancement:

• Step 1: The CMS AO must approve uses of live data before implemented in test and/or development environment.
• Step 2: The BO and ISSO conduct a PIA11 initially in the CMS-SDLC Initiation phase, at least annually on the development and test environments of the system and as directed by the CRA.
• Step 3: The Privacy Advisor, CRA, ISSO and BO reviews the PIA form in CFACTS and comments on the answers based on the guidance in the HHS Privacy Impact Assessment (PIA) and Privacy Threshold Analysis (PTA) Writers’ Handbook12. The form is under the “Security Category” tab. The Edit button allows for comments to be entered for individual PIA questions.
• Step 4: If comments are made to reject an answer to a question on the PIA, then the ISSO will address the comments before resubmitting to the reviewers.
• Step 5: The CRA and Privacy Advisor reviews the PIA for completeness and accuracy before submitting the final version to the Senior Official for Privacy (SOP).
• Step 6: The CMS SOP reviews and approves the PIA once submitted and sends the PIA to the HHS Senior Agency Official for Privacy.
• Step 7: The ISSO, consulting the Privacy Advisor, will document security controls of these live data uses within CFACTS during the CMS-SDLC Planning phase such as those listed in the NIST 800-122 Section 4.3, and the ARS controls labeled with “PII”.
• Step 8: The System/Network Administrator, Website Owner/Administrator, ISSO and System Developer and Maintainer configure the system development and test environments, implementing security controls from the SSPP during the CMS-SDLC Development and Test phases.
• Step 9: The ISSO and System Developer and Maintainer anonymize production data, using the guidance of NIST SP 800-122 Section 4.2.4, and substitute it for the live data in the Test and Development environments, if possible.
• Step 10: The ISSO and System Developer and Maintainer will configure the test and development environment using live data with at least the same level of protections as the operational environment using the NIST SP 800-122 as a guidance.
• Step 11: The ISSO submits a request for risk acceptance via the CFACTS tool to be approved by the CMS AO.

​​​​​​​Developer Provided Training (SA-16)

Training options include classroom-style training, web-based/computer-based training, and hands- on training. CMS can also request sufficient training materials from developers to conduct CMS- led training or offer self-study materials to organizational personnel. CMS must determine the type of training necessary and may require different types of training for different security functions, controls, or mechanisms. CMS must protect its systems from risk and cannot do so without knowing how to secure them.

The table below outlines the CMS parameter for SA-16 Developer Provided Training:

Table 2: CMS Defined-Parameters - Control SA-16

To follow the CMS specific process for the implementation of SA-16 control, the CMS ISSO requires the developer of the CMS information system, system component, or information system service provide training (or training materials) on the correct use and operation of the implemented security functions, controls, and/or mechanisms to the affected personnel. CMS requires training on security functions, controls and mechanisms listed in the SSPP before the CMS-SDLC Test phase, when CMS affected personnel may be called upon to use them. Training records for developer security training should also be maintained and submitted to the ISSO and CMS COR.

​​​​​​​Developer Security Architecture and Design (SA-17)

The purpose of this control is to guide the developer of the CMS information systems, system component, or information system service to produce a System Design Document (SDD) based upon a security architecture that is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture. The SDD accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components and expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection. The significance of this control reduces the likelihood of risk introduced by improper implementation of security architecture and minimizes vulnerabilities that may be introduced to an information system.

Subsequently, this control is primarily directed at external developers. In contrast, the Planning Security Control (PL-8) is primarily directed at internal developers to ensure that CMS develops information security architecture, and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when CMS outsources the development of its information systems, information system components, or information system services to external entities; resulting in a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture.

The following steps detail the CMS specific process for the implementation of SA-17 control:

• Step 1: CMS ISSO, working with the System Developer and Maintainer and through the proper documentation within the SSPP, will accurately and completely describe the required security functionality, and the allocation of security controls among physical and logical components and express how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.
• Step 2: CMS ISSO and TRB, through the review of documentation during the CMS- SDLC Detailed Design Review, will check the SDD of the respective system. They will require that the developer of CMS information system, system component, or information system service produce an SDD and SSPP that are consistent with and supportive of the CMS-SDLC and TRA. The SDD template can be accessed on the CMS-SDLC webpage.

The systems that also process PII/PHI information will need to perform this additional step:

• Step 3: The CMS ISSO, working with the System Developer and Maintainer and through the proper documentation within the SSPP, will accurately and completely describe the privacy requirements and the allocation of security and privacy controls among physical and logical components.
• Step 4: Should the system component(s) need to be disposed and/or replaced the next course of action is to create a Service Request (SR) to the appropriate personnel and follow the System Disposition Plan13 for guidance with risk assumed by the AO.

The following steps are only implemented if CMS continues to use the component after it is found to be unsupported:

• Step 5: The Business Owner will provide justification for continued use of unsupported system components required to satisfy mission/business needs by completing a request for risk acceptance using the CFACTS tool. The process is outlined in CFACTS User Manual.
• Step 6: The Authorizing Official will provide official acceptance of the risk by approving the request.