System and Information Integrity (SI)

What is System and Information Integrity (SI)  

An information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information. The integrity of an information system means the data within the information system is complete, trustworthy and has not been modified or accidentally altered by an unauthorized user. As the integrity of data can be compromised unintentionally by errors in entering data, a system malfunction or forgetting to maintain an up-to-date backup.    

Therefore, a multilevel-secure trusted computing base ensures a system’s integrity because it has the ability to protect itself against an unauthorized user access and an unauthorized program. Unauthorized changes to the trusted computing base could compromise the integrity of a system. Therefore, the installation procedures must ensure that only authorized programs are added to the trusted computing base which maintains the same controls, or equivalent measures to protect the trusted computing base from unauthorized access and same applies for installation-written authorized codes.  

Unauthorized access is when a person gains logical or physical access to a network, system, application, data or other resource without permission, and an authorized program allows the installation to identify system or user programs that can use sensitive system functions to maintain system security and integrity, including which libraries contain special functions or programs. A program must be authorized before it can access restricted functions such as supervisor calls.  

How SI works at CMS  

An overview of some of the CMS services and practices that relates to the System and Information Integrity (SI) security requirements outlined in the CMS Acceptable Risk Safeguards (ARS) minimum control standards and ensures that CMS has an SI management service and practice in place to meet its policy requirements.  

This section provides guideline, procedures and security considerations for implementing the SI control towards the mission and business requirements of CMS, its operational environments and the assessments of organizational and system risks.  

In addition, to facilitate and ensure the compliance of SI, CMS provides additional SI policy within the Information Systems Security and Privacy Policy (IS2P2) and implementation details on the CMS ARS where the minimum controls standards are defined that can be tailored to meet system specific needs.  

Flaw Remediation 

Flaw remediation is the process of identifying, reporting, and correcting of information and information system flaws in a timely manner to minimize the risk of security breaches. It is required for all types of hardware, software and firmware as vulnerabilities can exist in any component of a system. To effectively identify, report and correct system flaws, the following must be applied: 

• Test hardware, software and firmware updates related to flaw remediation for effectiveness and potential side effects before any installation.
• Install security-relevant software and firmware updates within timeframe established in the system patch management plan and CMS-defined time of the release of the updates.
• Incorporate flaw remediation into the CMS configuration management process which helps to ease the tracking and verification of remediation actions.    

The CMS Technical Reference Architecture (TRA) provides guidance on configuration management processes for both Configuration Identification and Configuration Control / Change Management. Project teams can request Technical Review Board (TRB) services at any point in the life cycle of the project by sending an email to the TRB mailbox at CMS-TRB@CMS.HHS.GOV.  

The CMS ARS requires the identification, reporting and correcting of CMS Information and information system flaws in a timely manner, including flaws discovered during assessments, continuous monitoring, incident response activities and system error handling as defined within the ARS. As an effort for CMS to stay in compliance with NIST SP 800-137 standards for Information security continuous monitoring (ISCM) for federal information systems and organizations. 

 To satisfy this security requirement, CMS information systems and the CMS Cybersecurity Integration Center (CCIC) team through its Penetration Testing team and the Red Team Engagement work comprehensively and proactively to counter any threats that can put the CMS security posture at risk. Including, the CMS Cyber Risk Management (CRM) team who is responsible for risk management and reporting within CMS to help identify and mitigate security and privacy risks for all CMS FISMA systems.  

The CMS Continuous Diagnosis and Mitigation (CDM) maintains an automated authorized hardware and software inventory including FISMA tagging, mapping and asset discovery as part of its Hardware Asset Management (HWAM) and Software Asset Management (SWAM).  

Automated Flaw Remediation Status  

Requires CMS applications to employ automated mechanisms to determine the state of its information system components regarding flaw remediation. Automated mechanisms, scans for security flaws on a continuous and/or periodic basis, while providing tracking and status updates for existing flaws within the system component.  

As systems are scanned for flaws, the results from continuous scans can be leveraged to schedule patch update or configuration changes required to strengthen the security posture of the information system. Operating without an automated mechanism installed can leave the system components vulnerable to the exploits presented by undetected software flaws.  

To meet this security requirement and to comply with OMB M-14-03 for Enhancing the Security of Federal Information and Information systems, CMS requires its systems to determine and identify system components that have applicable security-relevant software and firmware updates installed using automated mechanisms no less often than once every seventy-two hours. 

Each CMS FISMA system is within the scope of the CMS CDM program that ties into the CMS CCIC to provide automated flaw remediation status as part of its monitoring function using Tenable Nessus. The tool does not only detect vulnerabilities, but analyzes the severity ratings and other information regarding the vulnerabilities, as well, and reports significant vulnerabilities to data centers for remediation and determines if vulnerabilities have been remediated and systems behind on patch level. This allows CMS system administrators to have a full picture of the current security posture for that CMS information system. 

Malicious Code Protection 

Malicious Code is any Software or firmware intended to execute an unauthorized process that will have adverse impacts on the Confidentiality, Integrity or Availability (CIA) of a system.  The various classifications of malicious code include viruses, worms and trojan horses.  

Systems are required to employ malicious code protection mechanisms, utilizing a combination of signature-based and non-signature-based detection methods like anti-virus signatures, reputation-based technologies and comprehensive software integrity controls to effectively prevent unauthorized code execution at system entry and exit points, detecting and removing malicious code.  

Implementing a malicious code mechanism requires automatic updates for new releases or changes in accordance with the  CMS Configuration Management Policy and Procedures such that it is configured to block and/or quarantine malicious code, and send alerts to system stakeholders. While addressing any false positive findings, including live scans of files from external sources at endpoint, and/or network entry/exit points as the files are downloaded, opened or executed in accordance with CMS policy.  

The CMS CCIC Content Creation and Management Team provides subject-matter expertise in the areas of producing alert signatures with help from Splunk. Security Operation Center (SOC), content developers create signatures, look for known threats and generate new alerts based on new indicators of compromise. 

At CMS, malicious code must be reported to the ISPG SOC and to the CMS CCIC as part of an incident management plan. CMS must be prepared to take immediate or automated action to mitigate the damage from malicious code when it is detected, as well as comply with CMS requirements and incident management procedures. 

Malicious code protection mechanisms must be updated whenever new releases are available in accordance CMS Configuration Management procedures.  

System Monitoring 

System Monitoring refers to the ongoing observation of an information system to detect changes or threats. System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the information system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the information system. System monitoring ties in with NIST SP 800-137 Information Security Continuous Monitoring (ISCM) guidance which also refers to the maintaining of ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.  

System monitoring is required for establishing a baseline for system health, for detecting underlying problems before they negatively impact the system and its users, to detect unauthorized local, network and remote connections. It also enables organizations to manage, operate, and monitor their IT systems in a centralized manner which can be done both internally (monitoring that runs inside your server, and it focuses primarily on system resources) and externally (monitoring events focused on the customer or end user perspective and at system boundary).  

OMB M-14-03 requires organizations to monitor the security controls in Federal information systems and the environments in which those systems operate on an ongoing basis.  

The Department of Homeland security (DHS) provides the primary guidance for HHS and for the CMS Continuous Monitoring program. CMS has implemented a continuous monitoring program at the CMS CCIC in accordance with NIST SP 800-137 to improve situational awareness and provide near real-time risk management solutions, by performing periodic manual or automated audits, scans, reviews or other inspections of CMS processing environments. This ensures oversight of information security and privacy, including Security Information and Event Management (SIEM), for each FISMA System operating by or on behalf of CMS. 

The CMS Information Security and Privacy Group (ISPG) SOC offers 24/7, 365 continuous monitoring activities for FISMA systems throughout CMS. 

The CMS FISMA Controls Tracking System (CFACTS) is the FISMA Governance Risk Compliance (GRC) tool that keeps tracks of security artifacts produced as a result of ISCM or CDM scans that produce outputs for systems and a central repository that organizes FISMA reportable federal information systems. Documenting their security artifacts during the Authority-To-Operate (ATO)Authority-To-Operate (ATO) life-cycle, into manageable Information System domains, that offsets risk with security controls, and that documents the implementation and testing of the effectiveness of the controls.  

CMS CCIC Vulnerability Assessment Team (VAT) utilizes tools such as Splunk, Tenable, NetSparker and Forescout for monitoring and reporting as another core function other than providing vulnerability assessment. CMS also provides monitoring objectives within the CMS Incident Response Procedure which corresponds with the guidance provided within the CMS IS2P2 and ARS.  

For additional guidance on system monitoring please see NIST SP-800-53Rev5 Security and Privacy Controls for Information Systems and Organizations- Section 3.19 SI-04: System Monitoring. 

System-Wide Intrusion Detection System  

This security requirement ensures the connection and configuration of individual intrusion detection tools into a system-wide intrusion detection system.   

To meet this security requirement and to comply with OMB M 24-04 reporting requirements for Federal Information Security and Privacy Management Requirements. CMS systems intrusion detection tools are connected and configured to communicate with each other and the CMS CCIC team through the data they share widely across CMS, creating awareness for other systems and users.  

The CMS CCIC team provides the list of compliant formats for all systems to follow as the information must be made available in a format, and within a timeframe, to be agreed-upon with the CCIC team and consistent with all other safeguards required by the CMS ARS.    

CMS System Teams can find many of the resources, services and tools offered by the CCIC in the ServiceNOW catalog (VPN required).  

CMS systems are configured to have a centrally managed Intrusion detection system/intrusion protection system (IDS/IPS) capability implemented to monitor system and network communications on all networks and subnets of CMS network. This helps to strengthen CMS systems security posture and can improve the functionality and capabilities of the detection tools.  

The System Developer and Maintainer (SDM) must collect IDS/IPS logs according to the following requirements:  

• IDS / IPS logging/alerting data must be provided and include (at a minimum): The rule that triggered the alert (by reference identifier or the full rule itself). The category of the rule and any associated risk rating / scoring data.
• IDS / IPS implementations must (at a minimum): Allow for implementation of customized signatures in response to notifications and/or alerts from various security entities. Should provide the option to automatically save an associated Packet Captured File (PCAP) for triggered alerts that ISPG requests in support of incident response activities or for limited retention durations upon CMS request. Should provide read-only access to configuration data upon CMS request or the configuration files themselves via a centralized network management facility. 

Automated Tools and Mechanisms for Real-Time Analysis  

Ensures that Organizations information systems must employ automated tools and mechanisms to support near real-time analysis of events. NIST SP-800-53Rev5 Security and Privacy Controls for Information Systems and Organizations- Section 3.19 SI-04(02) discusses examples of automated tools and mechanisms including SIEM technologies that provide real-time analysis of alerts and notifications generated by organizational systems.  

CMS FISMA systems are integrated with the CMS CCIC which provides CDM capabilities that proactively scan CMS’s networks and hosted applications to proactively identify and fix vulnerabilities before an outside attacker can exploit them and gain access to the network.  

The CMS CCIC VAT team relies on Tenable Nessus as their primary vulnerability scanning tool that allows them to obtain real-time visibility into the vulnerabilities throughout the CMS environment. The CMS CCIC Vulnerability Analysis Team provides compliance and vulnerability scans for FISMA Systems across CMS using external-facing tool sets like DB Protect and Invicty, the team initiates system scans every seventy-two (72) hours to assess the overall security posture of each system.  

CMS CCIC also utilizes the CounterACT toolset to obtain real-time visibility into the hardware on the network within the CMS enterprise.   

Inbound and Outbound Communications Traffic  

Requires organizations to properly determine the source and frequency of communication on their network. The CMS CCIC team maintains logs in a unified format that it is consistent (with CMS requirements and applicable federal laws) and searchable within the CCIC designated Splunk cluster by deploying a network intrusion detection/prevention system that collects network traffic flow logs. 

All CMS inbound and outbound traffic to each zone routes through highly available switches and firewalls to reduce the possibility of compromising the entire network and is protected by highly available IDSs. This helps CMS determine the criteria for unusual or unauthorized activities that patterns to traffic that originates from outside the network (inbound) and for traffic that originates from inside/within the network (outbound). Monitoring inbound traffic can assist with alerting and possibly preventing malware and denial-of-service attacks. It can also help identify unexpected traffic on specific ports, as well as help administrators understand who may be misusing the network.  

CMS is also required to monitor its inbound and outbound communications traffic at a defined frequency as defined in the applicable System Security and Privacy Plan (SSPP) for unusual or unauthorized activities or conditions. 

System-Generated Alerts  

Requires that systems have automated alert capabilities for alerts that can be generated from different sources and can be transmitted to Organization personnel on the alert notification list.  

The CMS CCIC VAT uses a series of alerts that focus on Tenable compliance to inform the VAT when scanners fall outside of the recommended guidelines. The alerts are generated to track the indications that a compromise or potential compromise occurred from specific events with the raw event information available in an unaltered format to the CMS CCIC in real-time.  

This does not only establish a proper chain of custody ensuring that logs processed by the CMS CCIC have not been manipulated in any way but also establishes a reliable baseline that is able to identify abnormal behavior within the CMS information system. 

Visibility of Encrypted Communications 

Visibility of Encrypted Communications requires organizations to have a mechanism in place to monitor the traffic for encrypted communications.  

CMS systems are configured to report to the VAT Splunk dashboard that monitors the compliance of Tenable Nessus scanner configurations and scan policies at different CMS data centers as part of Compliance Monitoring. It also provides reports on expired and non-compliant SSL certificates to show which applications need an update, any unwanted Transport Layer Security (TLS) versions that contain vulnerabilities and the strength of the encryption.  

The CMS TRA Network Services   Security Services section provides a comprehensive framework for securing CMS networks and data. It emphasizes a layered security approach, adherence to security best practices, and compliance with CMS security policies to ensure the confidentiality, integrity and availability of CMS information that CMS Network Communications must adhere. The CMS Email Encryption requirements also provides step-by-step instructions for encrypting your email/communications within CMS.  

For additional information on email encryption at CMS please refer to the CMS Enterprise Data Encryption (CEDE) or contact the CISO@cms.hhs.gov.  

Analyze Communications Traffic Anomalies 

This requires CMS to monitor communication traffic for all CMS High Value Asset (HVA) FISMA systems to analyze any anomalies. To satisfy this security requirement, CMS SOC monitors CMS systems and network traffic, investigates suspicious traffic and events on the network and plays key role in incident handling as it coordinates with VAT to conduct targeted vulnerability scans of data center environments. 

Automated Organization- Generated Alerts 

Automated Organization-Generate Alerts ensures organizations have security alerts in place that can be transmitted automatically to the various organization personnel on the system alert notification list alerts go off when there are various types of triggers and these triggers vary amongst organizations in CMS, and the organizations are responsible for defining its activities that trigger alerts.  

The CMS CCIC through its content creation and management service provides subject-matter expertise in the areas of producing alert signatures, establishing dashboards and developing reports for data sets which helps to distribute the generated alerts to CMS personnel's with the “need- to- know”.   

Analyze Traffic and Event Patterns 

This security requirement requires organization to stay compliant with NIST 800-137 for continuous monitoring. As organizations are encouraged to have control over common communication traffic and event patterns on its network as a method of monitoring. This allows organizations to identify and understand any suspicious or anomalous traffic and events, which can also enhance organization respond, and handling of incidents efficiently and effectively as required by NIST 800-61 Rev 2.  

To meet this security requirement, CMS uses the Gigamon appliance and the CounterACT appliance which are the two major components of the Forescout CounterACT solution. The two devices work together to provide a comprehensive view of the monitored networks. Specifically, the Gigamon appliance functions as an aggregator for data passing through network switches throughout the CMS enterprise. It strips out unnecessary data found within network traffic and sends the essential data to CounterACT to create a real-time inventory of the devices found within the network. 

Wireless Intrusion Detection 

Wireless Intrusion Detection requires organizations to implement a wireless intrusion detection system to identify rogue wireless devices and to detect attack attempts and potential compromises or breaches to the system.  CMS monitors for unauthorized wireless access and prohibits the installation of wireless access points (WAP) in its systems.  

The Infrastructure and User Services Group (IUSG) oversee managing wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS information systems and prohibits the installation of WAP to systems unless explicitly authorized, in writing, by the CMS Authorizing Official (AO), which is the CMS CIO or the designated representative.  

CMS uses the wireless intrusion prevention system (WIPS) to detect rogue wireless devices, that are unauthorized WAPs, that are connected to the CMS network.  Such that any unauthorized WAP connected to the CMS internal network will be detected and locked out at the switch level (performing a port lock action on the switch IP address connection point) and then followed up as a potential security incident using the CMS Incident Response Process. For usage restrictions and configuration/connection requirements of wireless intrusion detection you must adhere to CMS Policy for Wireless Client Access and the HHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN).  

For more information on IUSG Wireless Intrusion Detection please visit CMS Wireless Support and/or CMS Wireless Network Connection Guide. 

Correlate Monitoring Information 

The purpose of this security requirement is to ensure the correlation of information from all CMS monitoring tools and mechanisms including those operating in isolation. The CMS Division of Implementation and Reporting (DIR) establishes an integrated security monitoring & reporting ecosystem that encompasses all FISMA systems across the CMS enterprise.  

It leverages the tools/processes that measure security compliance, to identify and prioritize cybersecurity risks/defects on a near real-time basis. While enhancing data analytics and process automation, to facilitate risk-based management by providing actionable information to leadership and risk managers at the agency, department and DHS level, thus, improving CMS's cybersecurity and privacy risk posture and alignment with federal requirements.  

For additional information please visit the CMS Reporting and Data Integration Collaboration Area. 

Analyze Traffic and Covert Exfiltration 

CMS data centers host the CMSNet, Extranet and Internet gateways that serve as secure entry and exit points for all transactions and communications between the stakeholders. CMS uses TLS cryptographic protocol at the highest available level to encrypt all traffic via the CMS-Extranet. 

All communication traffic within CMS is analyzed through CMS-dedicated firewalls, network and host-based IDS/IDPs where the firewalls and IDS/IDPs provide a concentration of security services that include packet and protocol filtering, packet inspection, information hiding and audit logging consistent with CCIC requirements. 

Privileged Users 

Requires organizations to include an additional monitoring step, such as audit records and network monitoring software, for users with access to more sensitive information or users with administrative level access commonly referred to as “keys to the kingdom” level access.  

CMS privileged users will include but not limited to Database Administrators, System Administrators, Network Administrators, Web Server Administrators, System Developers and Maintainers and any additional roles as documented in the SSPP. The HHS Rules of Behavior (RoB) requires that all Privileged Users shall read, acknowledge and adhere to the HHS/OpDiv Privileged User RoB prior to obtaining a privileged user account and at least annually thereafter.  

CMS CDM has Trustwave DB Protect security capabilities to audit privileged users. Also, CMS conducts a periodic review of all privileged users to determine if the reason for assigning such privileges remains valid, which can help identify any malicious activity in a timely manner. 

Unauthorized Network Services 

This security requirement ensures that the network infrastructure of CMS Processing Environments must impede, or challenge, any network traffic attempting to traverse (i.e., pass through) a zone unless explicitly approved by CMS.  

The CMS TRA Multi-Zone Architecture is designed to separate the components of an application in a “defense-in-depth” strategy, thus creating multiple points in which network-based transactions may be inspected, challenged and monitored. Impeding attempts to traverse network zones helps to discourage or defeat simple network attacks, and to detect misconfigured network devices or unauthorized network scanning. It also helps to defeat or detect malicious code outbound exfiltration attempts. 

Host-Based Devices 

Host-Based Devices requires CMS to implement a Host-based monitoring capability that collects information about the host/system it resides in and typically applies to all CMS HVA systems.  

The  CMS TRA offers Host-based firewalls that run locally on and protect only the hosting computer or device. Host-based firewall can provide endpoint protection that can improve the standing of CMS’s defense-in-depth and may be deployed as a mechanism to address certain CMS ARS controls. 

Security Alerts, Advisories, and Directives 

Security Alerts, Advisories and Directives ensures organizations have mechanisms in place to receive, generate, disseminate and implement system security alerts, advisories and directives including those from external organizations as defined within the SSPP on an ongoing basis or as needed.  

All CMS FISMA systems are required to report any system information security and privacy incidents and breaches to CMS Computer Security Incident Response Team (CSIRT) or CMS SOC  as required by federal law, regulations, mandates and directives.  

The CCIC Information Sharing and Cyber Threat Intelligence (IS&CTI) service improves the effectiveness of CMS information security and privacy by identifying CMS-specific threat indicators, actors, attack vectors and breach scenarios. To enhance situational awareness, incident detection, response and coordination operations throughout CMS.  

The CMS CCIC uses various communication channels, such as SLACK, email broadcasts to distribution lists and forums to maximize communication to stakeholders. As an overall incident response effort, the CMS SDMs are required to assist with reporting activities, respond to advisories, requests or directives issued by the CCIC.  

Automated Alerts and Advisories  

Automated Alerts and Advisories requires organizations to deploy an automated system wide notification service that can broadcast security alerts and advisories information throughout the CMS enterprise. 

CMS Application Administrators and Developers ensure automated information security and privacy capabilities are integrated and deployed. This enables CMS to disseminate security-related information to a variety of organizational entities that have a direct interest in the success of CMS mission and business functions. When disseminating the message, it is important for the sender to select the method(s) that will most effectively reach the desired audience in a timely manner. 

The AlertCMS program provides a variety of communications platforms that CMS uses to provide emergency information to staff in all CMS facilities such as the CMS Broadcast, Global Email (Agency-wide), Web-based mass notification system (capable of sending emails and phones calls to specific groups, including on-site and off-site) and Mass notification system (pre-scripted building specific messages, and manual messaging). 

The CMS Office of Communications (OC) is the organization that helps CMS create, coordinate and deliver cohesive, timely and strategic communications. 

Security and Privacy Function Verification 

Security and Privacy Function Verification ensures that CMS is verifying the security and privacy function of systems as defined within the system SSPP. Through a verification test at least once a month and has a system alert in place to notify system administrators when a test fails to verify the security and privacy function of a system. 

It also ensures that the following actions can be carried out upon discovery of any system anomalies, system restart, shutdown or be able to perform other security related activities as defined with the system SSPP. Some example of Security functions includes establishing system accounts and configuring access authorizations.  

CMS’ developers and personnel responsible for employing well-defined security policy models, structured, disciplined, rigorous hardware and software development techniques and sound system/security engineering principles. The implementation of these functions increases CMS’ assurance in security functions.  

CMS implements its information security programs and privacy programs to meet current and future information management needs in accordance with OMB Circular NO. A-130 

Software, Firmware and Information Integrity 

Software, Firmware and Information integrity requires organization to deploy integrity verification tools to detect any unauthorized changes to the system software, firmware or the information that the organization stores, process or transmits. Including having a process in place to address any unauthorized changes. 

Unauthorized changes to software, firmware, and information can occur due to errors or malicious activity. Software includes operating systems (with key internal components such as kernels, drivers), middleware and applications. Firmware includes the Basic Input/Output System (BIOS).  

Information includes personally identifiable information (PII) and metadata containing security and privacy attributes associated with information. Integrity-checking mechanisms, including parity checks, cyclical redundancy checks, cryptographic hashes and associated tools can automatically monitor the integrity of systems and hosted applications. Implementing any of these methodologies provides a critical integrity check against the target to make a determination that no unauthorized changes have occurred.  

CMS' CDM Program HWAM and SWAM helps CMS manage the enterprise associated risk by closely examining every device on the CMS enterprise network that processes, stores, or transmits CMS data. All devices are discovered by the HWAM tool and then verified which may include ingesting current HWAM data from third-party applications.  

The CDM VUL capability identifies vulnerabilities/weaknesses in software that can directly be used by an attacker to gain access to a system or network. All CMS applications and devices must adhere to the HHS Minimum Security Configuration Standard Guidance  and the CMS baseline configuration standards based on hardening scripts to provide protection against unauthorized access and malicious cyber activity or attacks, and to permit security services and authorized security personnel to perform auditing and monitoring of communications.  

Integrity Checks 

Integrity Checks requires that the information system performs a quarterly integrity check of software/firmware/information within systems at startup, during transitional states or when a security-relevant event occurs as discussed in NIST SP-800-53Rev5 Security and Privacy Controls for Information Systems and Organizations- Section 3.19 SI-7. 

All CMS configurable software and hardware components must adhere to HHS Minimum Security Configuration Standards Guidance authorized to operate by the CMS CIO and documented within the applicable host environment SSPP. Including all Operating Systems (OS), network devices, databases, middleware or other equipment and software must be configured in accordance with CMS Configuration Management settings and the CMS ARS.  

The CMS BO and SDM are responsible for actively managing system configurations and configurations must be validated periodically using the tools hosted in the Security Band, such as Security Content Automation Protocol (SCAP) testing tools and Defense Information Systems Agency (DISA) scripts (STIGs). 

Automated Notifications of Integrity Violations 

Automated Notification of Integrity Violations ensures organizations have automated mechanisms to notify personnel with a need-to-know as defined within the system SSPP when there are any discrepancies during the integrity verification process.  

CMS’ CDM program offers automated capabilities that ties in with the CMS CCIC and NIST defined SCAP which includes formats for asset management (Common Platform Enumeration [CPE]), vulnerability management (Common Vulnerabilities and Exposures [CVE]) and configuration management (Common Configuration Enumeration [CCE]). CMS also requires automated scanning and feeds that report the status of asset management, vulnerability management and configuration management across all assets in an unfiltered manner.  

For additional information please contact the CMS CDM team for CDM program capabilities and onboarding process via CDMPMO@cms.hhs.gov . 

Automated Response to Integrity Violations 

Automated Response to Integrity Violations requires organizations to have automatic mechanisms to deploy either one of the following actions: Shut the information system down, restart the information system or implement appropriate security and/or privacy controls as defined in the System SSPP when integrity violations are discovered.  

The CMS IRT receives alerts and response to security or privacy incident that affects CMS IT system while coordinating with the CMS CCIC IMT. The CMS CDM also receive alerts and offers responses that are as planned for both routine and unexpected events that can compromise CMS security to maintain functionality and security.  

The CMS vulnerability management team through its vulnerability monitoring plan offers prepared alert actions as a prerequisite for CMS’s ability to continuously monitor vulnerabilities and respond quickly to alerts.  

The CMS CCIC IMT, serves as the main authority responsible for the coordination of information security and privacy incident. For additional information please contact IncidentManagement@cms.hhs.gov.  

 Integration of Detection and Response 

This requires documenting alerts and actions taken when an incident occurs which is also necessary for determining impacts, determining if additional steps are needed and supporting further analysis. 

The CMS enterprise-wide vulnerability management and monitoring capability infrastructure allows the continuous collection of all vulnerability data at a single location within CMS for centralized analysis and reporting.  Including maintaining historical records to be able to identify and discern adversary actions over an extended time period and for possible legal actions. 

All CMS FISMA system IRT reports to the CMS CCIC IMT, which is responsible for CMS-wide incident management. It is the goal of the CMS Enterprise Vulnerability Program to maintain the capability to collect such data on all CMS IT assets.  

Code Authentication 

Requires organizations to implement cryptographic authentication and key management solutions that are in accordance with FIPS 140-3 and all other applicable federal laws, directives, policies, regulations and standards.  

The CMS ARS requires using appropriate approved cryptographic mechanisms (such as digital signatures and cryptographic hashes) to protect the integrity of data while in transit to prevent unauthorized disclosure of information and to detect changes to information during transmission. This allows CMS information systems to use encryption products that have been validated under the Cryptographic Module Validation Program. Such that when cryptographic mechanism is required and used within any CMS information system, CMS establishes and manages the cryptographic keys for the required cryptography employed within the information system. 

CMS also encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements. 

For additional information on cryptographic authentication and key management at CMS please see the CMS Key Management handbook or contact the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov for assistance.  

Spam Protection  

Requires organizations to protect themselves from targeted email attacks that can be costly and disruptive by employing a spam protection mechanism that can recognize and stop messages containing malicious links, attachments and other social engineering techniques commonly used to trick users. 

At CMS, system information communications and processing connections are controlled through an integrated system of firewalls, routers, switches and through the CMS IDS equipment. Thus, CMS offers spam protection through its boundary protection strategy which utilizes firewall perimeter routers and IDS, configured to provide a defense-in-depth.  

To further protect CMS information systems against spam CMS enforces phishing exercises such that suspicious email must be reported to spam@cms.hhs.gov or using the 'Report Spam' icon on the CMS Microsoft Outlook interface.  

Automatic Updates 

Ensures organizations spam protection mechanism has automated capabilities to push out updates when new releases are available and on a regular basis that is in accordance with the organizations configuration management procedures and as defined within the SSPP. 

The CMS IDS offers automated capabilities to CMS System entry and exit points that include firewalls, servers, workstations and mobile devices for real-time analysis. CMS also employs continuous Anti-Virus and Anti-Malware scanning services with automatic capabilities to identify all major types of malwares and to prevent or contain any malware incidents.  

Information Input Validation 

Ensures organizations are validating the input provided to a program or an algorithm to enforce software application security against remote code executions that can lead to a security breach.  

NIST recommends a manual override capability for certain situation such as disruptive events or as defined within the system contingency plan and SSPP such that it is restricted to authorized personnel only and can be audited. 

The CMS TRA requires that business applications validate received data from external sources and CMS websites must validate all user input at a minimum on the server side, although validating on both the client and server side is recommended.  

The CMS development team ensures that they are pulling the vetted components from a trusted location, as opposed to untrusted, public repositories. The development team is also responsible to have sufficient viable options and threat protection-related settings available for each application as part of the application acceptance process.  

At CMS, before applying any operational function to the contents of a submitted file, it must be scanned for malware. Including the contents of newly submitted files must be scanned in the Presentation or Application Zone before it can be transferred to the Data Zone.  

CMS also implements a servlet filter to validate Content-Type and throw away requests with suspicious values not matching multipart/form data. This helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks. 

Error Handling 

Ensures organization information systems are generating error messages that provide necessary information for corrective actions without revealing exploitable information, and only revealing these messages to authorized personnel or roles as defined within the SSPP. Some web-based systems have default, development-mode configurations that reveal information about the processing to help developers easily identify problems. Unfortunately, these settings also provide information valuable to attackers.  

Overall, Error Handling carries a “high impact” consideration and should be prioritized during development and remediation. CMS recommends using static analysis tools to check the bulk of files created by programmers. Good tool candidates include code quality analysis, coding standards, security vulnerability and Section 508 analyses.  

Accessible error handling ensures assistive technology users are made aware of needed corrections so that successful completion of a task is possible. 

Information Management and Retention 

Information Management and Retention ensures CMS systems are managing and retaining information within the system and its output in accordance with all applicable laws, EO, directives, regulations, policies, standards, guidelines and operational requirements.  

CMS is required to comply with OMB A-130, Appendix II the implementation of Government paperwork Elimination Act. Most of the information processed within CMS information systems can be seen as a federal record which is an information resource that is created in the course of business, received for action or needed to document CMS activities.  

Both the Privacy Act and the Federal Records Act require records to be maintained and disposed of in accordance with a published records schedule. Disposal and destruction of PII must be done securely so that it may not be reconstructed. 

AT CMS Office of Strategic Operations and Regulations Affairs (OSORA) is responsible for the planning, development and coordination of CMS’s records and information management program in accordance with Federal regulations.  

CMS provides annual records and information management training to all staffs that must be completed by the established completion date in accordance with 36 CFR 1220.34(f) which includes all contractors who have access to HHS Federal Information or a Federal information system or Personally Identifiable Information (PII) shall complete the CMS provided records management training required by HHS.  

The National Archives and Records Administration (NARA) provides retention schedules that govern the disposition of federal records. Program officials and business owners coordinate with records officers, Cyber Risk Advisor and with NARA to identify appropriate retention periods and disposal methods. NARA may require organizations to retain PII longer than is operationally needed. In those situations, organizations describe such requirements in the notice. 

 CMS retains the collection of PII for the time specific by the NARA approved records schedule in consultation with the Records Management Officer to fulfil the purpose identified in the notice or as required by law.  

CMS uses FIPS validated techniques or methods to ensure secure deletion or destruction of PII (including originals, copies, and archived records). The CMS retention schedule consists of nine records subject categories referred to as “buckets”. The retention of all CMS records falls under one of the buckets according to the type of record. The records schedule will identify the authorized retention period for that specific bucket. 

For additional information please contact the CMS OSORA OSORA_Regulations_Records@cms.hhs.gov.  

Limit Personally Identifiable Information (PII) Elements 

Limit the use of PII elements throughout the information life cycle. PII elements include name, Social Security Number (SSN), date and place of birth, mother’s median name or biometric records and any other information that is linked or linkable to an individual, such as medical, educational or financial information. Thus, limiting PII to the minimum required to accomplish the legally authorized purpose of collection and retaining PII for the minimum necessary period reduces the risk of PII breaches. 

CMS minimizes the retention and usage of PII elements in its operations to those that are relevant and necessary to accomplish the legally authorized purpose of collection for example, CMS identity life-cycle management only retain the PII needed for performance of identity life-cycle management functions after issuance of credentials, such as credential maintenance, account maintenance, authorization or periodic certification. CMS will collect, retain, use or disclose PII elements identified for the purposes described and for which the individual has provided consent only when necessary and where no practical alternative exists in accordance with NIST 800-53; PT-2 control and the CMS Cybersecurity and Privacy Training Handbook.    

The following documents CMS best practices to limit PII which includes but not limited to: 

• CMS Business Owner (BO) and System Owner/Maintainer (SO/M) must identify the minimum PII elements that are relevant and necessary to accomplish the purpose of collection (and where a collection of certain PII requires legal authorization, HHS/CMS must ensure that such collection is legally authorized).
• CMS BO must limit the collection and retention of PII to the minimum elements identified in the notice and, when the collection of PII is made directly from the subject individual, limits its purposes to those for which the individual has provided consent to the extent permitted by law.
• CMS BO and System Owner/Maintainer must conduct an initial evaluation of PII holdings and establishes and follows a schedule for regularly reviewing those holdings, no less often than once every three hundred sixty-five (365) days, to ensure that only PII identified in the notice is collected and retained, and that the PII continues to be necessary to accomplish the legally authorized purpose. 

Minimize Personally Identifiable Information in Testing, Training and Research 

Organizations are required to develop and document policies and procedures including implementing security controls to protect PII and address the use of PII in internal testing, training, and research in order to limit, or minimize, the level of privacy risk that the system creates.  

CMS consults with its Senior Official for Privacy (SOP) to ensure and/or authorize that the use of PII for internal testing, training and research is compatible with the original purpose for which the information was collected.  

CMS, where feasible, uses techniques to minimize the risk to privacy of using PII for testing, training and research which includes the privacy artifacts required in the CMS Target Life Cycle (TLC) and highlighted in the Privacy-Enhanced System Design and Development section of the Privacy handbook.  

Safeguarding Protected Health Information PHI/PII is among CMS’ highest priorities. Therefore, CMS enters into a valid Data Use Agreement (DUA), whenever appropriate, to protect the limited data sets (LDS) that will be used and/or disclosed for purposes of research, public health or health care operations. The CMS Office of Acquisition and Grants Management (OAGM) is responsible for ensuring that all contracts involving the collection, us, or disclosure of PII/ PHI include the Business Associate Agreement (BAA). 

For additional information please contact the CMS privacy team Privacy@cms.hhs.gov  and for CMS OAGM please contact OAGMGrants@cms.hhsgov 

Information Disposal 

Information Disposal ensures organizations are timely and correctly disposing information when it is no longer needed. It applies to originals as well as copies and archived records, including system logs that may contain PII. The methods of disposal may include recycling, shredding, pulping, physical destruction of electronic media (e.g., hammering, smashing), demagnetization and secure deletion of electronic records (i.e., overwriting data several times using specialized software). 

CMS record schedules authorize destruction of temporary records when their retention period expires provided no specific preservation obligations apply such as a litigation hold. Temporary records with restrictions, such as those containing personal or confidential business information (CBI), must be shredded or otherwise definitively destroyed when their retention period expires. 

If those records are destroyed by outside contractors, a federal employee or, if authorized by CMS, contractor must witness the destruction. Executive Order (EO) 12356 governs the destruction of security-classified documents. Specific laws and regulations, including the Privacy Act of 1974 and NARA regulations (36 CFR § 1226.24), governs the destruction of other restricted records.  

CMS must ensure that there are no records freezes, or litigation holds on all records that are scheduled for destruction. 

For additional information please contact the CMS records retention Records_Retention@cms.hhs.gov.    

Memory Protection 

Memory Protection ensures organizations implement data execution prevention controls and all applicable security safeguards as defined in the SSPP to prevent the execution of codes in a non-executable region of the system memory or in prohibited memory locations.  

System memory protection helps to prevent unauthorized processes from accessing memory that has not been allocated to it. NIST provides examples of memory protection controls such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) that provides additional protection by performing checks on memory to help prevent malicious code from running and guards against buffer-overflow attacks by randomizing the location where system executables are loaded into memory respectively.  

CMS system developers and implementers include the isolation of memory space and libraries as part of the overall implementation of CMS defined security policy models and rigorous hardware and software development techniques and sound system/security engineering principles. 

Personally Identifiable Information (PII) Quality Operations 

Requires organizations to develop and document policies and procedures to confirm that the PII information they collect, use, process, store, maintain, disseminate, disclose and dispose continues to be accurate, of relevant, timeliness and completeness throughout the information life cycle. Including having a process to correct or delete inaccurate or outdated PII that can help reduce the risk of the organization making decisions based on inaccurate PII. 

To meet this security requirement, CMS conducts an initial evaluation of PII holdings and establishes and follows a schedule for regularly reviewing those holdings no less often than once every 365 days to ensure that only PII identified in the notice is collected and retained, and that the PII continues to be necessary to accomplish the legally authorized purpose.  

CMS issues mandatory privacy awareness and training within three (3)-working days of individuals having access to CMS PII. Providing privacy awareness and training annually thereafter and identifying those individuals who require special privacy role-based training, as well as maintaining appropriate training records for all applicable individuals in the organization. CMS record system is designed to retrieve information about individual via personal identifier (name, personal email address, home mailing address, personal or mobile phone number, etc.) and keeps the information provided safe according to the Privacy Act of 1974, as amended (5 U.S.C. Section 552a).  

CMS ensures it collects PII directly from the individual to the greatest extent practicable and before retrieving such information, CMS displays the Privacy Act Notification Statement in a prominently manner on the CMS public-facing website or on the form asking you for PII. CMS also adheres to the CMS requirements for security and protection of PII to improve the quality of PII operations.  

The CMS Privacy Office maintains a PII inventory list that includes, but is not limited to, completing, submitting, being re-validated every 365 days and having an approved Privacy Impact Assessment (PIA) and, as applicable, being covered by a current and signed System of Record Notice (SORN), Computer Matching Agreement (CMA), Memorandum of Agreement (MOA), Memorandum of Understanding (MOU), Letter of Intent (LOI), Interagency Agreement (IA), Information Exchange Agreement (IEA) and  Data Use Agreement(s) (DUA) in place to improve the quality of its operations.  

For additional information please contact the CMS privacy team Privacy@cms.hhs.gov 

Individual Requests 

Ensures organizations develop and document organization-wide policies and procedures checking the accuracy, the relevance, timeliness and the completeness of PII within their systems. Correcting or deleting PII that is inaccurate or outdated, incorrectly determined regarding impact or incorrectly de-identified can be vital to the type of business and services that CMS conducts.  

CMS provides individuals the right to amend and correct their PII/PHI, and/or their Electronic Health Record (EHR) maintained in a designated record set or a CMS Privacy Act System of Records. When an individual requests amendment/correction to PII/PHI, CMS acts on the request no later than sixty (60) days after receiving the request. 

If CMS is unable to act within this period, CMS will extend the time to complete the written request by no more than thirty (30) additional days after the initial 60 days. CMS organizational personnel consult with the SOP and legal counsel regarding appropriate instances of correction or deletion of PII. 

De-Identification   

De-Identification ensures organizations have a process in place to remove the association of PII elements such as name and date/place of birth that can be used to distinguish or trace an individual's identity from data sets elements that can be linked or linkable to an individual such as medical, financial and employment information. CMS creates datasets that do not identify individuals and makes them publicly available when there is legal authority permitting their creation and dissemination.  

CMS creates public use files (PUF) as part of the administration of its programs. PUFs are created from data contained in the Privacy Act Systems of Records. There are no restrictions on the use and disclosure of PUFs. CMS adheres to the HHS guidance for de-identification procedures to comply with the Privacy Rule and this security requirement when such information is not/or no longer necessary.