Security & Privacy Planning (PL)

Security & Privacy Planning (PL) 

Introduction  

Security and Privacy Planning (PL) focuses on how the organization must develop, document, periodically update, communicate, and implement plans for the security and privacy protection of its information systems and organizational operations. It also integrates security and privacy into the architecture of each information system by applying CMS-tailored NIST PL controls during the design phase.   

Security and Privacy Planning at CMS 

Every information system at CMS must be Authorized to Operate (ATO). This involves a process of developing system plans and architecture to address the security and privacy requirements of each system and CMS as an organization. This applies to all systems seeking to be a new ATO or reauthorization. 

CMS aligns with:  

• The National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5 
• HHS Information Systems Security and Privacy Protection (IS2P) 
• CMS Acceptable Risk Safeguards (ARS) 
• CMS Information Systems Security and Privacy Policy (IS2P2) 

Key Security and Privacy Measures 

Policy and Procedures 

CMS provides an enterprise-level planning policy within the CMS IS2P2, that can be inherited by CMS organization and systems. When this enterprise policy does not address special requirements that are unique to either the CMS organization or system, a risk-based customization is recommended to address those security and privacy needs. The implemented policy must not be less stringent than the enterprise policy and procedures. 

The CMS CISO manages the development, documentation, and dissemination of the CMS planning policy and procedures; ensures they are reviewed and updated every 365 days or following CMS-defined events, as listed in the ARS.  

System Security and Privacy Plan (SSPP) 

At CMS, the SSPP is a single consolidated document generated and tracked through its Governance, Risk, and Compliance (GRC) tool - CMS Federal Information Security Modernization Act (FISMA) Continuous Tracking System (CFACTS). All CMS information systems must develop and maintain an SSPP compliant with current CMS guidelines and consistent with the CMS Technical Reference Architecture (TRA).  

Each new system must define its security categorization within CFACTS. Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on the Federal Information Processing Standards Publication 199 (FIPS 199). NIST Special Publication 800-60 Revision 1 Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories provides a guideline for mapping types of information and information systems to security categories and was written to work in conjunction with FIPS 199. It should be completed by the ISSO and approved by the Information System Owner. 

At CMS, the Authorizing Official (AO) reviews the package and renders a decision. Since the SSPP is a key component of the ATO package, receipt of an approved ATO also serves as a formal approval of the SSPP. This decision is documented in CFACTS, and an Authorization Memo is signed by the AO and must be uploaded into CFACTS by the Cyber Risk Advisor (CRA). If the ATO for the system leverages or sponsors a FedRAMP Cloud Service Provider (CSP), the CRA must forward the ATO memo to the FedRAMP PMO at info@fedramp.gov. 

CMS plans and coordinates security and privacy related activities affecting the information system with affected internal or external stakeholders, groups, or organizations through plans such as the CMS Cybersecurity and Risk Assessment Program (CSRAP), Continuous Diagnostics and Mitigation (CDM), Security Awareness Training (SAT) Instructors, and auditors before conducting such activities in order to reduce the impact on other CMS entities. 

The CMS IS2P2 and the ARS require Business Owners to review and update the SSPP at least every 365 days per FISMA and IS2P2 requirements. Please refer to the CFACTS User Manual in CFACTS for the current processes for updating the SSPP within the CFACTS tool. 

Rules of Behavior (RoB)  

The Department of Health and Human Services (HHS) releases the  HHS Policy for Rules of Behavior (RoB) for Use of Information and IT Resources  which applies to CMS. It clearly delineates responsibilities and the expected behavior of all individuals with access to CMS information systems. This integration ensures that every system user is held accountable for following specific protocols that protect CMS information throughout its lifecycle.   

The following steps detail the CMS process for ensuring that CMS users review and acknowledge the RoB. 

• The rules of behavior have been incorporated into the annual Information System Security and Privacy Awareness (ISSPA) Training, and all EUA users must take the Computer Based Training (CBT) located at https://www.cms.gov/cbt/login. The training is taken by all EUA users initially prior to account issuance and annually thereafter to maintain an active CMS account.  
• Users receive an annual email reminder to complete the CBT. 
• The CBT database maintains training records, including the user's unique identification (UID) and the completion date. 

Social Media and External Site / Application Usage Restrictions 

The HHS RoB requires CMS to generally restrict the use of social media and external applications to prevent interference with CMS operations, violation of security policies, and unauthorized use of sensitive data.  

Personal use of CMS information technology (IT) resources is permitted only when it is minimal, does not disrupt productivity or mission operations, and adheres to security and privacy policies. Unauthorized storage of sensitive CMS data on third-party applications or personal devices is prohibited. 

To enforce this, CMS incorporates this security requirement into the ISSPA Training and mandates that the RoB must be electronically signed as the last step of the training. Failing to complete the CBT training will result in the user having their credentials revoked.   

Security and Privacy Architecture 

The CMS information security and privacy architecture at the individual information system level is consistent with, and complements the more global, organization-wide information security and privacy architecture. The CMS information security and privacy architecture includes: 

• Architectural Description 
• Placement and Allocation of Security Functionality 
• Allocation of Security Controls 
• Security-related information for external interfaces, information being exchanged across the interfaces 
• Protection mechanisms associated with each interface 

CMS Technical Reference Architecture (TRA) articulates the information security and privacy architecture of the CMS processing environments and assists all agency business partners in developing, transitioning to, and maintaining the CMS processing environments in accordance with CMS’ enterprise technical architecture. 

These five technical objectives enable the agency’s healthcare mission: 

• Secure the CMS operating environment 
• Allow for efficient allocation of CMS workloads across data centers 
• Provide appropriate and sufficient disaster recovery and business continuity capability 
• Facilitate the migration and transition of CMS business owner applications into new processing environments 
• Build an enterprise technical architecture that anticipates and responds to CMS’ mission and business needs 

CMS reviews and updates the information security and privacy architecture every three (3) years, and whenever changes are made to the enterprise architecture. 

Central Management 

CMS centrally manages security and privacy controls, and related processes within the CMS GRC tool – CFACTS. This tool also manages and tracks all the Risk Management Framework (RMF) steps for CMS information systems processing ATO, from planning to monitoring. 

Central management of controls is generally associated with the concept of common (inherited) controls, s such management promotes and facilitates the standardization of control implementations and the judicious use of organizational resources. 

Baseline Selection and Tailoring 

Baseline selection is the initial process of determining the set of security and privacy controls for a system based on its security categorization. CMS determines the control baseline for its information systems in alignment with NIST SP 800-53B and the Risk Management Framework (RMF).  

After selecting the initial baseline, these baseline controls are tailored to the CMS environment, cataloged in the CMS Acceptable Risk Safeguards (ARS), and applied to the security and privacy needs of specific systems, after a risk-based assessment of threats and vulnerabilities in the system’s operating environment. This ensures the success of the mission and business functions of CMS systems and the organization. The RMF step – Select, is managed within the CMS GRC tool – CFACTS.