OCISO Systems Security Management

• Internal Flow or Collection
• PIA Validation (PIA Refresh/Annual Review)

• Name
• E-Mail Address
• Phone Numbers
• Device Identifiers
• Other - Login Credentials: User IDs and passwords. These login credentials are originated from a separate CMS application, which is the Enterprise User Administration (EUA) used to create the user within the application. Any PII of rolodex information to be collected is from internal employee resources, not public.

• Employees
• Vendors/Suppliers/Contractors

There is the potential for PII to be collected as part of a Forensic investigation.

CDM as part of the DHS initiative portion of "who is on the network" requires PII in the form of user fields. 

• Online
• Email

• Within the OPDIV

• Within HHS: The data flows to the DHS Dashboard at HHS

OSSM is not intended to collect or maintain PII outside of official POC information and login credentials for users of the OSSM application.   Based on the "Warning Banner" displayed at the time of login for any CMS system, CMS has the legal authority to collect and view this information at any time to ensure that CMS systems are not vulnerable to a security breach.

PII is collected as part of the Master User Record (MUR) file. This will contain Active Directory rolodex information and be passed along to the HHS DHS CDM Dashboard. Standard PII breach notification procedures apply (defined in the Risk Management Handbook, Chapter 8, Incident Response, which includes standard Breach Notification procedures.)

PII may be indirectly collected and may be revealed during forensic investigations; however, there is no way to foresee and therefore disclose that this information will be revealed.  However, standard PII breach notification procedures apply (defined in the Risk Management Handbook, Chapter 8, Incident Response, which includes standard Breach Notification procedures.)

This is not applicable. Information is collected based on general system log files and is searched by automated security programs to see if CMS systems have been compromised or could be compromised. Except for contact information, and login credentials there is no way to foresee and therefore disclose that this information will be revealed.

Additionally, an official log-on banner must be acknowledged when accessing CMS systems and warns each user that their use is subject to monitoring. OSSM is not the originator of the employee and contractor POC information, and therefore there is no ability to opt-out of the information collected.

The PII (Contact information and login credentials) is originated from a separate CMS application, which is the Enterprise User Administration (EUA), therefore there is no ability to opt-out. If the user requires access to OSSM they cannot 'opt-out' of providing their PII to EUA, as these are used to create the user within the applications.

This is not applicable because OSSM is not designed to intentionally collect PII information. OSSM is not the originator of the employee and contractor POC information and login credentials, and therefore is no resolution process in place. The PII (Contact information and login credentials) is originated from a separate CMS application, which is the Enterprise User Administration (EUA).

Standard reporting procedures for PII breaches apply and can be found in the Incident Response, Risk Management Handbook, Chapter 8, which includes standard Breach Notification procedures.

• Administrators: Access to PII (if any) is required by Security Operations Center (SOC) personnel and forensic specialists during their regular duties for incident detection, incident response, and forensic analysis
• Contractors: Access to PII (if any) is required by Security Operations Center (SOC) personnel and direct contractors as well as forensic specialists and direct contractors during their regular duties for incident detection, incident response, and forensic analysis.

Individuals requesting access to OSSM must sign an Account request form prior to account creation. Account request form must also be filed indicating name, email, phone number and access level needed. This form is reviewed and approved by the System information Security Officer (ISSO) prior to account creation. OSSM uses the principle of least privilege as well as a role-based access control to ensure system users are granted access on a "need-to-know" and "need-to-access" commensurate with their assigned duties.

Activities of all users are logged and reviewed by OSSM ISSO to identify abnormal activities if any.

OSSM uses the principle of least privilege as well as a role-based access control to ensure system users are granted access on a "need-to-know" and "need-to-access" commensurate with their assigned duties. 

Activities of all users are logged and reviewed by OSSM ISSO to identify abnormal activities if any.

CMS conducts periodic security training on topics of interest throughout the year.  Additionally, twice annually, specific security / privacy training is provided to CMS business owners on a range of relevant and timely security and privacy topics by CMS Security Control Oversight and Update Training (CSCOUT).

CMS employees and direct contractors with privileged access are required to complete role-based training and meet continuing education requirements commensurate with their role. Other training avenues such as conferences, seminars and classroom training provided by CMS/HHS is available apart from the regular annual training.

Any storage structures that contains OSSM PII are located and backed up within secure FedRAMP authorized cloud facilities with storage zones in geographically disparate zones Destroy 1-year(s) after system is superseded by a new iteration or when no longer needed for agency/IT administrative purposes to ensure continuity of security controls throughout the life of the system. For data within Splunk and passed through, the data is rolled off and removed after a rolling window of 90-days to 1-year at most unless required by m-21-31 or other agency requirements.

OSSM is not designed to provide inheritance of controls related to log and data storage. The onus of log retention and adherence to federal mandates lies upon the application, business owners, or underlying GSS services. DAA-GRS2013-00060001, DAA-GRS2013-0006-0002

OSSM uses the principle of least privilege as well as a role-based access control to ensure system administrators, and users are granted access on a "need-to-know" and "need-to-access" commensurate with their assigned duties.

Activities of all users are logged and reviewed by OSSM ISSO to identify abnormal activities if any.

OSSM is a Hybrid hosted in a secured facility and FedRAMP approved AWS cloud environment. Physical controls are in place such as security guards to ensure access to the buildings are granted to only authorize individuals. Identification of personnel is checked at the facility.

OSSM is built using industry best practices and independently reviewed against Federal Information Security Management Act (FISMA) and National Institute of Science and Technology (NIST) Security and Privacy controls to ensure technical, operational, and management controls are properly applied.

Personally Identifiable Information (PII) in OSSM is secured administratively by ensuring that the system goes through the Assessment and Authorization (A&A) process, and all documentation is submitted to the Information Security & Privacy Group (ISPG) that supports the system and to comply with Federal Information Security Management Act (FISMA) regulations.