Introduction

This chapter of the Risk Management Handbook (RMH) covers the Security Assessment and Authorization family of controls. It describes procedures that help you meet the security and privacy requirements for this control family. Each procedure is labeled with the associated NIST controls using the control number from the CMS ARS.

Security Assessment & Authorization controls 

Security Assessments (CA-2)

CMS must assess security and privacy controls in CMS information systems and the environments in which those systems operate to determine if the controls are implemented appropriately, operating as intended, and producing the desired results.  The output from a security controls assessment provides essential information to the CMS Authorizing Official (AO) needed to make risk-based decisions in support of the security authorization process.  The scope of a security assessment is documented in a Security Assessment Plan (SAP), which identifies the security controls and enhancements under assessment, describes the assessment procedures utilized to determine the security control effectiveness, and outlines the assessment environment, team, and roles and responsibilities.  The result of the security assessment is documented in a Security Assessment Report (SAR), which is provided to the CMS AO.

Some items that would require a security assessment include:

• Significant change that affects the security state of the information system
• Required frequency depending on control and system categorization
• ATO schedule (once every three years)
• Reassessment of selected controls

The table below outlines the CMS Organizationally Defined Parameters (ODPs) for CA-2:

Planning, execution and reporting are the three phases of a security assessment. The following steps outline the process for conducting a security assessment on CMS information systems:

Phase I: Planning

• Step 1:  The ISSO provides a copy of the current System Security and Privacy Plan (SSPP) and any additional information related to the information system boundary (e.g. hardware/software listing, High Level Architecture (HLA) Diagrams, Data Flow Diagrams, etc.) that is not contained in the SSPP to the independent assessor.
• Step 2:  The independent assessor reviews the SSPP and additional information provided by the ISSO and drafts a SAP.  A template for a SAP is provided in Appendix D.  Independent assessors may utilize their own template as long as it captures all of the elements identified in the CMS template. The independent assessor provides a copy of the draft SAP to the ISSO for review and comment.
• Step 3:  The ISSO reviews the draft SAP, briefs/consults the BO as needed, and provides comments to the independent assessor.
• Step 4:  The independent assessor updates the plan to address the comments received from the ISSO and returns the plan to the ISSO for approval.
• Step 5:  The ISSO confirms all required updates to the SAP and presents the SAP to the BO for approval.     
• Step 6:  The BO or BO Representative such as the System Developer Maintainer (SDM) approves the SAP.

Phase II: Execution

• Step 1:  With an approved SAP, the independent assessor conducts a kickoff meeting to brief the assessment stakeholders on the assessment approach, logistics, and schedule.
• Step 2:  The independent assessor executes the assessment procedures contained within the SAP using three methods: interview, examine, and test.
  • Interview – conducted with relevant information system stakeholders to confirm the security control implementations as documented in the SSPP.
  • Examine – documentation and artifacts are provided to the independent assessor demonstrating the implementation of the security controls as documented in the SSPP.
  • Test – manual tests are executed and/or automated tools (e.g. vulnerability scans, penetration tests, DISA STIG outputs, etc) are utilized to evaluate the effectiveness of the implemented security controls.

The ISSO and relevant stakeholders support the assessment activities by responding to the requests of the independent assessor, which may consist of requests for interview, artifacts/documentation, or access to the system for technical testing.

• Step 3:  At the conclusion of the assessment activities, the independent assessor conducts an assessment out-brief with the relevant stakeholder to review the results of the assessment, discuss assessment findings, and present recommendations.

Phase III: Reporting

• Step 1:  Following the assessment out-brief, the independent assessor drafts the Security Assessment Report (SAR) that contains the comprehensive results of the assessment (i.e. controls satisfied or other than satisfied).  A template for the SAR is located in Appendix E. Independent assessors may utilize their own template as long as it captures all of the elements identified in the CMS template. 
• Step 2:  The ISSO reviews and forwards the SAR to all relevant stakeholders requesting feedback. Included in the SAR are findings and the corresponding risk levels (High, Moderate, Low) with recommended actions to mitigate the risks. It is important that the ISSO and relevant stakeholders review and analyze these risks in determining corrective actions and mitigation plans. The ISSO compiles all of the feedback into a single document and submits the comprehensive feedback to the independent assessor.
• Step 3:  The independent assessor updates the SAR to address the feedback received from CMS and provides the updated SAR to the ISSO for acceptance.
• Step 4:  The ISSO confirms the updates to the SAR and briefs the CMS BO. With the acceptance of the BO, the SAR is considered an accepted deliverable. The ISSO uploads the final SAR to the CMS FISMA Controls Tracking System (CFACTS) tool. It is important to remember that the loading of weaknesses into CFACTS shall be done in a timely manner as these weaknesses are considered time sensitive.
• Step 5:  With the approved SAR, the independent assessor creates a CMS Assessment and Audit Tracking (CAAT) spreadsheet that will facilitate the upload of the assessment results into the CFACTS tool.  A template for the CAAT spreadsheet is located in Appendix H.  Once completed, the independent assessor emails the CAAT spreadsheet to the CISO mailbox at CISO@cms.hhs.gov copying the CMS ISSO.

Security Assessments | Independent Assessors (CA-2(1))

Independent assessors or assessment teams are individuals or groups who conduct impartial assessments of organizational information systems.  Impartiality implies that assessors are free from any perceived or actual conflicts of interest with regard to the development, operation, or management of the organizational information systems under assessment or to the determination of security control effectiveness.  To achieve impartiality, assessors should not: (i) create a mutual or conflicting interest with the organizations where the assessments are being conducted; (ii) assess their own work; (iii) act as management or employees of the organizations they are serving; or (iv) place themselves in positions of advocacy for the organizations acquiring their services. Independent assessments can be obtained from elements within organizations or can be contracted to public or private sector entities outside of organizations.  At CMS, the CISO defines the required level of independence of the assessor.   

CMS must also engage independent third-party assessors when conducting security assessments on High Value Assets (HVAs). These assessments must include a Risk and Vulnerability Assessment (RVA) and a Security Assessment Report (SAR).

The table below outlines the CMS ODPs for CA-2(1):

The CISO currently maintains a contract with an independent third party assessor that is available for use by BOs and ISSOs to fulfill the independent security assessment requirement.  The steps below outline the process for utilizing that contract:

• Step 1:  The ISSO notifies the CRA that an assessment is being requested. A tentative date for the assessment to begin should be provided.
• Step 2:  The CRA provides the ISSO with the current pricing for the assessment and instructions for using the Comprehensive Acquisitions Management System (CAMS) and notifies the independent assessor that an assessment needs to be scheduled.
• Step 3:  At least six weeks prior to the assessment kick-off, the ISSO must work with the BO to move funds for the assessment using the CAMS.
• Step 4: The assessment may begin once the funds are verified as available via the CAMS.

Security Assessments | Specialized Assessments (CA-2(2))

In today’s dynamic threat environment, preparation is critical to responding to ever-evolving cyber threats.  One of the ways to prepare for cyber events is to conduct specialized security assessments (e.g. insider threat assessments, malicious user testing, information system monitoring).  These assessments can be utilized to assess the current capabilities of the organization and identify areas for improvement. Special security assessments designed to focus on current threats based on an assessment of risk. 

The table below outlines the CMS ODPs for CA-2(2):

Security Assessments | External Organizations (CA-2(3))

The independent assessment of CMS information systems is critical to achieving impartiality and avoiding conflicts of interest in evaluating the implementation of a security control baseline. Since assessments are conducted on a recurring schedule dependent upon audits and the Assessment & Authorization (A&A) process, utilizing previous assessment results, compliance descriptions, and findings may seem like an efficient way to conduct full security control assessments. However, the benefit of deduction in time and resource consumption with the reused assessment documentation subtracts from the overall quality of the test result write-ups and the accuracy of risk identification. To avoid this risk, the security control enhancement specifies that a high system must contract out assessment related work to an external organization, such as a Third Party Assessment Organization (3PAO).The experience and capability of a 3PAO can vary depending on their past work completed with other organizations. By utilizing a 3PAO to conduct an assessment, the full assessment will rely on an independent and refreshed viewing and testing of implemented security controls.

System Interconnections (CA-3)

This control covers the authorization, documentation, and review of connections between information systems known as system interconnections.  For CMS information systems in different organizations, or external to the federal organization (i.e. private sector), an Interconnection Security Agreement (ISA) must be signed by both parties.  

In addition, system connections between federal and non-federal organizations should include contractual agreements. Interconnections where information systems are within the same organization, or share the same authorizing official, an ISA is not required and instead will document the interface characteristics of the information system within their respective security plans. The type of data agreement needed is dependent on several factors and further guidance on using data agreements is found in Appendix J.

The table below outlines the CMS ODPs for system interconnections:

The following steps detail the CMS specific process for authorizing interconnection between information systems:

• Step 1: System Owner/BO requests interconnection between his/her information system to another information system through use of an Interconnection Security Agreement (ISA), other comparable agreement such as Memorandum of Understanding (MOU)/Memorandum of Agreement (MOA), Service Level Agreement (SLA), or specific contractual clause, as long as the appropriate interconnection details are included. However, the use of an ISA is highly recommended to reduce liability and risk to the organization and to ensure complete compliance with NIST standards. A template for the ISA is provided in Appendix H. A template for the MOU/MOA is provided in Appendix L.
• Step 2: System Owner/BO documents (1) the interface characteristics; (2) the security requirements; and (3) the nature of the information communicated for each interconnection within the applicable SSPP. Internal interconnections are authorized when the ATO memo is signed. If the connection is an external connection, continue to Step 3 and Step 4.
• Step 3: ISAs or other comparable agreement shall be reviewed and updated by the System Owner no less than once per year or when significant changes, affecting the security state of the information system, are implemented that impact that validity of the agreement as an effective enforcement of security requirements. The applicable ISSO shall upload the signed ISA to CFACTS, specifically within the Authorization section under Interconnections.
• Step 4: System Owner shall only activate a system interconnection including, but not limited to, testing when a signed interconnection is signed and enforceable.

System Interconnections | Connections to Public Networks (CA-3(5))

This control covers the connections between information systems and external networks. External networks connections expose the opportunity for intentional and accidental disclosure of sensitive information. This control shall help CMS constrain information system connectivity to external domains and reduce the organization’s exposure to incidents.

The table below outlines the CMS ODPs for connections to public networks:

• Step 1: Within the SSPP, the System Owner defines what information systems are allowed to connect to external information systems and includes a description of the security control employed to mitigate the risk associated with the connection.
• Step 2: If a connection is permitted, the System Owner shall employ a deny-all, allow by exception policy. The System Owner shall determine what exceptions, if any, are acceptable.

Plan of Action and Milestones (CA-5)

The Plan of Action and Milestones (POA&M), prepared for the authorizing official by the information system owner or the common control provider, is one of three key documents in the security authorization package and describes the specific tasks that are planned:

• to correct any weaknesses or deficiencies in the security controls noted during the risk assessment
• to address the residual vulnerabilities in the information system.

The Plan of Action and Milestones identifies:

• the tasks to be accomplished with a recommendation for completion either before or after information system implementation
• the resources required to accomplish the tasks

At CMS, the ISSO is responsible for maintaining the POA&M on behalf of the information system owner by using the CFACTS tool. The table below outlines the ODPs for the POA&M:

At the completion of a security controls assessment, the independent assessor completes a CMS Assessment and Audit Tracking (CAAT) spreadsheet. The CAAT spreadsheet is utilized for all CMS audits, assessments and penetration testing vulnerabilities. The completed CAAT spreadsheet is emailed to the CMS CISO mailbox at CISO@cms.hhs.gov for upload into the CFACTS tool. Once uploaded into CFACTS, the weaknesses are automatically generated for all items with a status of “other than satisfied.”  The following steps detail the CMS-specific process for creating and maintaining the POA&Ms for the identified weaknesses:

Creating a POA&M

The ISSO for the associated information system receives an automated email notification from the CFACTS tool identifying a new weakness. At CMS, a weakness can be identified from any of a number of sources including, but not limited to:

• HHS Office of Inspector General (OIG) Audits
• Government Accountability Office (GAO) Audits
• Chief Financial Officer (CFO) Reviews
• OMB A-123 Internal Control Reviews
• Annual Assessments
• FISMA Audits
• Security Control Assessments
• Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) Section 912
• Audits
• Internal Revenue Service (IRS) Safeguard Reviews
• Department of Homeland Security (DHS) Risk Vulnerability Assessments (RVA)
• DHS Cyber Hygiene
• Penetration Testing
• Vulnerability Scanning

The ISSO has 30 days to create the POA&M within CFACTS.  By associating milestones to each weakness using the following steps, the ISSO will create the POA&M:

• Step 1:  The ISSO or support contractor locates the weaknesses in CFACTS using the subtasks below:
  • Login to CFACTS and select the “Assessment & Authorization (A&A)” tab from the top menu
  • Click on “Authorization Package – Records” under the “Quick Links” column and select the appropriate information system from the list.  You may also find the information system by clicking “Search Records” and specifying search criteria
  • Once the information system has been located click on the system name to open the authorization package for the system
  • Select the “Controls” tab from the top navigation tab of the authorization package
  • Scroll down to the “Allocated Controls” section to locate the hyperlinks for the POA&Ms associated with the controls with a status of “Other Than Satisfied”
  • Click the hyperlink for a POA&M to open that POA&M
• Step 2:  Click the “Edit” button to switch to edit mode allowing new milestones to be added.  Scroll down to the “Milestones” section and click the “Add New” link to add a new milestone.
• Step 3: Enter a milestone name, milestone description, and select a scheduled completion date. Click the “Save” button at the top left corner of the milestones window.

NOTE:  The following remediation timelines apply based on the weakness risk level:

• Critical Risks - must be remediated within 15 days of weekenss creation date
• High Risks – must be remediated within 30 days of the weakness creation date
• Moderate Risks – must be remediated within 90 days of the weakness creation date
• Low Risks – must be remediated within 365 days of the weakness creation date

After 30 days from the weakness creation date the POA&M will automatically be changed to a status of “Ongoing” this will lock the milestones removing the ability to edit them. For this reason, the ISSO must complete the entire POA&M entry as soon as possible, including the recording of all milestones and target dates for completion.

Updating a POA&M

The ISSO is responsible for submitting updates on each POA&M on at least a quarterly basis until resolution. These updates are maintained for each milestone using the CFACTS tool. HVA system POA&Ms must have monthly updates including vulnerability scan reports to HHS. The following steps detail the process for submitting monthly updates for the POA&M milestones:

• Step 1:  The ISSO or support contractor locates the POA&M in CFACTS using the subtasks below:
  • Login to CFACTS and select the “Assessment & Authorization (A&A)” tab from the top menu.
  • Click on “Authorization Package – Records” under the “Quick Links” column and select the appropriate information system from the list.  You may also find the information system by clicking “Search Records” and specifying search criteria.
  • Once the information system has been located click on the system name to open the authorization package for the system.
  • Select the “Controls” tab from the top navigation tab of the authorization package.
  • Scroll down to the “Allocated Controls” section to locate the hyperlinks for the POA&Ms associated with the controls with a status of “Other Than Satisfied”.
  • Click the hyperlink for a POA&M to open that POA&M.  Scroll down to the “Milestone” section, locate the milestone and click “View” to the left of the milestone.
• Step 2:  Click the “Edit” button to switch to edit mode.  Scroll down to the “Milestone Changes” section and add comment indicating the updated status for the milestone. Include the date of comments (e.g. xx/xx/xxxx).  Append to the comments each month so that a complete history of the status of that milestone is maintained.
  • NOTE:  If a milestone is delayed, and the delay will result in the POA&M closure exceeding the schedule completion date then an “Estimated Completion Date” should be entered in the “milestone changes” section.   Provide a justification in the “Milestone Changes” box indicating the reason for the delay.
• Step 3: Click “Save” in the upper left hand corner of the “Milestones” window to save the updates to the milestone.

Closing a POA&M

To close a POA&M, a remediation package containing artifacts demonstrating that the weakness has been mitigated must be submitted and approved by the ISSO using the CFACTS tool. The CRA verifies mitigation for all high risk weaknesses and a sample of moderate and low risk weaknesses. The following steps detail the process for uploading evidence and closing a POA&M:

• Step 1:  The ISSO or support contractor locates the POA&M in CFACTS using the subtasks below:
  • Login to CFACTS and select the “Assessment & Authorization (A&A)” tab from the top menu
  • Click on “Authorization Package – Records” under the “Quick Links” column and select the appropriate information system from the list.  You may also find the information system by clicking “Search Records” and specifying search criteria
  • Once the information system has been located click on the system name to open the authorization package for the system
  • Select the “Controls” tab from the top navigation tab of the authorization package
  • Scroll down to the “Allocated Controls” section to locate the hyperlinks for the POA&Ms associated with the controls with a status of “Other Than Satisfied”
  • Click the hyperlink for a POA&M to open that POA&M
• Step 2:  Scroll down the “Remediation Evidence” section and click “Add New” in the top right hand corner.
• Step 3:  Click the “Select Files” button browse the files containing the remediation evidence and double click them to add them to the “files to upload” box.  Click “Ok” to upload the files.
• Step 4:  Scroll down to the “POA&M Submission” section select a POA&M Owner, change the POA&M status to “Submit for Review” and select a submit date.
• Step 5: The ISSO reviews the evidence package and documents that review in the “Review” section of the associated POA&M in CFACTS. If the ISSO concurs with the evidence package, the status of the POA&M is updated to “Completed” and the POA&M is now closed. If the ISSO does not concur with the evidence package, then they work with the necessary stakeholders to obtain new evidence to support the closure of the POA&M. A “Completed” weakness shall remain on the POA&M report for one year after it is closed.

Risk Acceptance

If the weakness that prompted the creation of a POA&M cannot be mitigated then the risk may be accepted. Risk acceptance is a common and appropriate practice within an organization. When the risk response with the identified risk is within the organization’s risk tolerance and/or the risk has been sufficiently mitigated to an acceptable level, the organization may choose to accept the risk. The accepted risk shall be documented in the system’s ISRA and should include justification as to why the risk cannot be mitigated. Risk deemed to be low, moderate, or high can be accepted depending on particular situations or conditions which are unique to the organization. For example, organizations with data centers residing in the northeastern portion of the United States may opt to accept the risk of earthquakes based on known likelihood of earthquakes and data center vulnerability to damage by earthquakes. Organizations accept the fact that earthquakes are possible, but given the infrequency of major earthquakes in that region of the country, believe it is not cost-effective to address such risk—that is, the organizations have determined that risk associated with earthquakes is low, due to the likelihood of a non-occurrence, and therefore acceptable. Conversely, organizations may accept substantially greater risk (in the moderate/high range) due to compelling mission, business, or operational needs. Organizations typically make determinations regarding the general level of acceptable risk and the types of acceptable risk with consideration of organizational priorities and trade-offs between: (i) near-term mission/business needs and potential for longer-term mission/business impacts; and (ii) organizational interests and the potential impacts on assets such as individuals and information systems. Some scenarios requiring a Risk Acceptance are:

• When the cost of implementing the control is more than the benefit gained
• When implementation of the control results in adverse effects to functionality of the system
• It is technically infeasible to implement the control
• When implementing the control results in disrupting the business process

This list is by no means exhausting and provides some of the most common scenarios for Risk Acceptance.

Security Authorization (CA-6)

Security authorizations are official management decisions that are conveyed through authorization decision documents by senior organizational officials or executives (i.e., authorizing officials) to authorize operation of information systems to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of agreed-upon security controls. The CIO serves as the authorizing official for CMS.  The CIO is responsible for making an overall determination of risk and authorizing CMS information systems for operation, if it is determined that the associated risk are acceptable.  An Authorization to Operate (ATO) memo is signed by the CIO giving the System Owner/BO formal authority to operate a CMS information system.

The CMS Cybersecurity Integration Center (CCIC) must be notified when significant changes occur to architecture, security posture, or other items that could cause degradation or unexpected results in security monitoring, detection, response, and mitigation activities prior to making the changes. Some examples of significant changes that may occur are:

• Discovery of a new vulnerability
• New COTS tool integration
• Installation of a new operating system
• Modifications to system ports, protocols, or services
• Installation of new hardware platform
• Modifications to security controls

Notification of significant changes will be sent via email by the System Owner/BO to the CCIC.

The table below outlines the ODPs for security authorization:

NIST requires three artifacts to support the authorization decision for information systems: System Security Plan (SSPP), Security Assessment Report (SAR), and Plan of Actions and Milestones (POA&M).  At CMS, additional documentation is included and considered as a basis for making an ATO recommendation to the CIO. The following list contains the CMS specific artifacts required for a complete authorization package:

• SSPP
• SAR
• POA&M
• Contingency Plan (CP)
• CP Test Plan
• CP Test After Action Report
• Information System Risk Assessment (ISRA)
• Privacy Impact Assessment (PIA)
• Interconnection Security Agreement (ISA) – if applicable

The following steps detail the CMS specific process for requesting and receiving an ATO for a CMS information system.

• Step 1:  The ISSO completes the CMS System Authorization ATO Request form (see Appendix G) and uploads the completed form to the CFACTS tool using the subtasks below:
  • Login to CFACTS and select the “Assessment & Authorization (A&A)” tab from the top menu
  • Click on “Authorization Package – Records” under the “Quick Links” column and select the appropriate information system from the list.  You may also find the information system by clicking “Search Records” and specifying search criteria
  • Once the information system has been located, click on the system name to open the authorization package for the system.
  • Select the “Authorization” tab from the top navigation tab of the authorization package.
  • Click the “Edit” button at the top of the authorization package window.
  • Click “Add New” and then click “Select File(s)” to navigate the completed CMS System Authorization ATO Request Form. Save form.  Add Authorization ATO Request Form section of the Authorization tab.  After attaching the form, click “OK” to return the authorization package window.
  • Sends an email to their CRA, cc CISO MB notifying them that the CMS System Authorization ATO Request Form uploaded to CFACTS and that the authorization package is ready for review.
  • Set Authorization Package Submission Status to “Submitted”. 
• Step 2:  The CRA requests an ATO package review by their support staff.
• Step 3:  The CRA support staff conducts a review of the ATO package by completing the ATO Gating Review Checklist. If updates to the ATO package are required, the support staff notifies the CRA whom then works with the ISSO to make the necessary updates.
• Step 4:  Once the CRA is satisfied that the authorization package meets the CMS criteria, the CRA sends a request to their supporting contractor to draft the ATO memo and executive summary.
• Step 5: The CRA receives the draft ATO memo and executive summary from the support contractor, updates the executive summary as necessary, and creates a red folder with the following ATO documentation:
  • POA&M Report
  • Executive Summary
  • ATO Memo
• Step 6: The CRA submits the red folder to the assigned privacy lead for review and comment. If updates are identified by the privacy lead, the CRA works with the ISSO to make those changes and updates the red folder package as necessary.
• Step 7: The CRA submits the red folder package to the Director of the Division of Security, Privacy Policy and Governance (DSPPG) and the Director of the Division of Security and Privacy Compliance (DSPC) for sign-off working with the ISSO to update the package as needed based on the feedback from the directors.
• Step 8: The DSPC Director takes the red folder package to the CISO for review and approval.  If updates are identified by the CISO, the CRA works with the ISSO to make those changes and updates the red folder package as necessary.
• Step 9: The CISO presents the ATO memo to the CIO for signature and briefs the CIO on the risks associated with the information system and any associated POA&Ms identified to mitigate those risks.
• Step 10: The CIO signs the ATO memo.  The CIO returns the signed ATO memo to the CRA.
• Step 11: The CRA uploads the signed ATO memo into the CFACTS tool and updates the ATO expiration date, and Date Authorization Memo signed in the system to reflect the newly issued ATO. 

Continuous Monitoring (CA-7)

Information Security Continuous Monitoring (ISCM) programs raise awareness regarding threats, vulnerabilities, and information security in support of organizational risk management decisions. Continuous implies that organizations assess and analyze security controls and information security-related risks at a frequency sufficient to support organizational risk-based decisions. An ISCM program is designed to collect information according to established metrics, utilizing information readily available in part through existing security controls. This program integrates with the Assess, Authorize, and Monitor phases of the Risk Management Framework and enables Ongoing Authorization (OA) of information systems.

CMS, along with other federal agencies, plans to transition from point-in-time authorizations to the more dynamic OA. This process is still based on an initial system authorization (See CA-6) and must have a valid ATO, but systems that enter OA have ATO letters that do not expire. Ongoing Authorization is enabled by having ISCM capabilities in place, but the continuous monitoring capabilities must be mature enough before the transition to ongoing authorizations can occur.

As part of the US Government’s efforts to enhance security of federal information systems, agencies across the government are required to establish an ISCM program. DHS provides the primary guidance for HHS and for the CMS Continuous Monitoring program.

CMS has implemented a continuous monitoring program at the CMS Cybersecurity Integration Center (CCIC). The CCIC ensures oversight of information security and privacy, including Security Information Event Management (SIEM), for each FISMA System operating by or on behalf of CMS. The CCIC delivers various agency-wide security services. These services include Continuous Diagnostics and Mitigation (CDM) as well as security engineering, incident management, forensics and malware analysis, information sharing, cyber threat intelligence, penetration testing, and software assurance. In order for CMS to monitor security information across the enterprise, there must be connectivity between the data sources and CMS to allow for effective continuous monitoring. In addition, the Continuous Monitoring strategy ties in with other stakeholder plans and strategies, including Incident Response.                                                    

The table below outlines the CMS organizationally defined parameters for continuous monitoring:

The Continuous Monitoring strategy guides the implementation through phases of an Information Security Continuous Monitoring (ISCM) program. The CCIC is responsible for the initial focus on Phase 1, which incorporates endpoint protection by conducting an inventory of what is on the network through Hardware Asset Management (HWAM), Software Asset Management (SWAM), Configuration Settings Management (CSM), and Vulnerability Management (VUL).

The requirements for the four phases of the CDM program are directed from DHS; the CCIC will ensure that automated and manual monitoring efforts are in place. Guidance from the CCIC will continue with each update to the program and increased implementation of the phases.

Continuous Monitoring | Independent Assessment (CA-7(1))

CMS conducts Security Control Assessments (SCA) in support of its Continuous Monitoring strategy. To ensure that an impartial assessment is performed on system controls, the CCIC provides independent assessments on thirty (30) published controls. These assessments must be conducted no less frequent than one-third every year ensuring that all systems are assessed during the 3-year cycle.

Penetration Testing (CA-8)

Penetration testing is performed on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Penetration testing is used to validate vulnerabilities or determine the degree of resistance that organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills). This type of testing attempts to duplicate the actions of internal and external adversaries in carrying out hostile cyber-attacks against the organization and allows a more in-depth analysis. Penetration testing can be conducted on the hardware, software, or firmware components of an information system and can exercise both physical and technical security controls.

CMS has the ability to choose internal or external penetration testing teams; penetration testing is one of the services provided by the CCIC. For each penetration test, there must be an agreed upon Rules of Engagement (RoE) before the test can occur. The RoE ensures that a penetration test will be effective and safe for the environment and for those involved in the test itself. CMS utilizes its own RoE for penetration tests that can be found in Appendix I of this document.

Penetration testing is performed on all High Value Assets (HVA) information systems within CMS at a frequency of every three hundred sixty-five (365) days or when there has been a significant change to the system. Information covering significant changes and the systems that will be tested must be updated in the SSPP.

Below are the procedural steps to facilitate a penetration test in the CMS environment:

• Step 1: Through oversight responsibilities, CRAs and / or ISSOs can request a penetration test to be performed by the CCIC.  This test can provide some technical results and assurances on the security of the system.  CRAs can work with system ISSOs to determine if this option is beneficial and informative on a system’s risk posture.
• Step 2: After the decision is made to conduct the test, the CRA should contact the ISSO of the system to be tested and obtain the IP address and/or Uniform Resource Locator (URL) for the system.
• Step 3: The CRA oversees the sending of the IP address and/or URL to the Division of Cyber Threat and Security Operations (DCTSO) Penetration Testing Lead.
• Step 4: DCTSO staff will set-up a kick-off meeting with the stakeholders, ISSO, CRA, BO, and any Contractors, involved with the system(s) to determine the scope of the penetration test. 
  • ISSOs and BOs will ensure that the meeting invite is forwarded to any other personnel, based on the involvement with the application.
  • During the meeting, the penetration test team will relay what type of accounts are needed to perform the test, i.e. user and/or admin accounts, etc.
• Step 5: After determining the scope of the penetration test, DCTSO will add the application to the penetration test schedule and inform the CRA, ISSO, and BO of the date that the penetration testing will begin and its projected duration. 
• Step 6: Upon completion of penetration test, an out-brief between the BO and Penetration Testing team is performed to discuss test results and the discovery of all findings.
• Step 7: The system’s BO has one (1) week to mitigate findings, focusing first on the highest risk findings.
• Step 8: Penetration testers will confirm that the findings are remediated by retesting closed findings within the remediation timeframe.
• Step 9: The final report can be obtained from The Incident Management Team (IMT).  The email address for IMT is IMT@CMS.HHS.GOV
• Step 10: The CRA will work with the ISSO to create the CAAT worksheet, ensuring accuracy and completeness, for any remaining findings after the remediation week concludes.
• Step 11: The CRA, as oversight, ensures that each CAAT worksheet is accurately uploaded into CFACTS within thirty (30) days from the date the finding was discovered.
• Step 12: Any deviations to this process should be reviewed and evaluated for their risk to the security posture of systems.

Internal System Connections (CA-9)

This control applies to connections between organizational information systems and separate constituent system components (i.e., intra-system connections) including, for example, system connections with mobile devices, notebook/desktop computers, printers, copiers, facsimile machines, scanners, sensors, and servers. Instead of authorizing each individual internal connection, organizations can authorize internal connections for a class of components with common characteristics and/or configurations, for example, all digital printers, scanners, and copiers with a specified processing, storage, and transmission capability or all smart phones with a specific baseline configuration.

For CMS, there is a requirement to include privacy standards in connection documents. For example, an Interconnection Security Agreement (ISA) is required for external system connections. In addition, documentation shall be created addressing responsibilities of the receiving information system for how it will protect the Personally Identifiable Information (PII) which transits the system.

The table below outlines the CMS organizationally defined parameters (ODPs) for internal system connections:

• Step 1:  The System Owner shall define information system components or classes of components (found in the applicable SSPP) to be authorized as internal connections to the information system.
• Step 2:  The System Owner shall authorize internal connections of organization-defined information system components or classes of components to the information system when the ATO memo is signed.
• Step 3:  The System Owner shall document the (1) interface characteristics; (2) the security requirements; and (3) the nature of the information communicated for each internal connection within the applicable SSPP.