Introduction

Access is the ability to make use of any system resource. Access Control (AC) is the process of granting or denying specific requests to:

1. Obtain and use the information and related information processing services
2. Enter specific physical facilities (e.g., federal buildings, military establishments, border crossing entrances)

Access Control entails the regulation of who or what is allowed to access resources in an information system or network. As an important aspect of information security, access control helps to prevent unauthorized access to systems, services, and data.

Access Control focuses on how the organization must limit system access to authorized users, to processes acting on behalf of authorized users, or to devices (including other systems), and how the organization must limit the types of transactions and functions that authorized users are permitted to conduct. Access Control can be implemented in various ways, including but not limited to the use of passwords, biometric authentication, and permissions assigned to specific users or groups. The level of access granted to an individual or a system may vary depending on their roles or responsibilities within an organization.

Access control, a selective restriction of access to systems or data, consists of two main components: authentication and authorization. Authentication is the verification of the identity of a user, process, or device, and it is often the prerequisite to allowing access to resources in a system. Authorization, on the other hand, is the process of granting or denying specific requests:

1. For obtaining and using information and related information processing services
2. To enter specific physical facilities (e.g., Federal buildings, military establishments, and border crossing entrances)

Authentication and authorization are concerned with determining the allowed activities of legitimate users and mediating every attempt to access the resources in the system or an authorized entrance into a federal facility. The access must be based on the principle of least privilege. In some systems, complete access is granted after successful authentication of the user, but most systems require more sophisticated and complex controls. In addition to the authentication mechanism (such as a password or token), access control is concerned with how authorizations are structured. In some cases, authorization may mirror the structure of the organization, while in others it may be based on the sensitivity level of various information resources with the roles and responsibilities of the user accessing those resources.

The requirements for the use or the prohibitions against the use of various system resources also vary from one system to another. For example, some information may be available to all users, some may be available to specific groups or divisions, and some may be accessible to only a few individuals or groups across the agency. While users must have access to the specific information needed to perform their jobs, denial of access to non-job-related information may be enforced. It may also be important to control the type of access that is permitted (e.g., the ability for an average user to execute, but not change, system programs). These various types of access restrictions enforce policy, and ensure that unauthorized actions are not permitted.

Purpose

The purpose of this document is to serve as a guide for managing access by providing background information and an overview of access control policies, procedures, and processes for restricted resources and data across the Centers for Medicare & Medicaid (CMS).

To implement the security requirements for the Access Control (AC) family, as identified in NIST Special Publication (SP) 800-53 Revision 5 Security and Privacy Controls for Information Systems and Organizations, HHS Policy for Information Security and Privacy Protection (IS2P), CMS Information Systems Security and Privacy Policy (IS2P2), and the CMS Acceptable Risk Safeguards (ARS), this manual also defines the rules around access to resources, and how access is allowed or denied by ensuring that only authorized personnel are granted access to critical information and resources while maintaining the security and confidentiality of sensitive information and Controlled Unclassified Information (CUI).

This document is also intended to provide a consistent and secure approach to managing access to information and systems by serving as a reference for all CMS federal employees, contractors, and other authorized personnel. By following the processes outlined in this manual, CMS can minimize the risk of security breaches, data theft, and unauthorized access, thereby safeguarding the confidentiality, integrity, and availability of its systems and protecting the stakeholders.

Applicability and scope

Federal information systems are required to incorporate information security controls to protect the systems supporting their operations and missions. CMS is required to ensure the adequate protection of its information systems and must meet a minimum level of information security.

Further, the use of controls is mandatory for federal information systems in accordance with Office of Management and Budget (OMB) Circular A-130, and the provisions of the Federal Information Security Modernization Act [FISMA] of 2014, which requires the implementation of minimum controls to protect federal information and information systems. This program manual, along with the CMS ARS, satisfies the requirements of FISMA, and OMB Policies, among other laws, regulations, and policies, and will improve communication among stakeholders on how access to information systems or networks within the agency is managed.

To this, the program manual applies to all CMS personnel or entities:

• Conducting business for CMS
• Collecting or maintaining information for CMS
• Using or operating information systems on behalf of CMS, whether directly or through contractual relationships.

The lists of CMS personnel or entities include, but are not limited to:

• Organizational components, centers, or offices
• Federal employees, contractor personnel, interns, or other non-government employees operating on behalf of CMS.

This document is also applicable to all Information Technology (IT) resources, including network and computer hardware, software and applications, mobile devices, and telecommunication systems owned or operated by (or on behalf of) CMS.

Roles and responsibilities

Please refer to the CMS IS2P2: Roles and Responsibilities and HHS Policy for Information Security and Privacy Protection (IS2P) Section 7 Roles and Responsibilities for the specific roles of CMS staff positions, contractors, or any entity operating on behalf of CMS. Further, the responsibilities related to the specific role(s) in the CMS IS2P2:

• Supervisors
• System/Network Administrators 

or HHS IS2P:

• Section 7.33 (System Administrator)
• Section 7.37 (Supervisor)

for roles supporting the AC control family are as follows:

Supervisors 

• Authorize and (or) approve the creation of new user accounts.
• Ensure the access role is based on the principle of least privilege to ensure the user only has the authorized access rights to systems and information that is only enough to perform the duties described within their job description.
• Ensure the user account is disabled and (or) removed when the employee separates from the position and no longer requires access.  

System Administrators [ADMIN]  
(e.g., database administrators, network administrators, web administrators, and application administrators)

• Ensure that when performing administrator-type functions (e.g., as a privileged user), the ADMIN is logged on their privileged account only and their responsibilities are established to perform just those privileged functions with defined privileged commands and privileged processes.
• Follow the established CMS system security protocols and processes as established in the System Security and Privacy Plan (SSPP) for onboarding new employees for new account creation, once the individual has completed all pre-required onboarding activities before account issuance (e.g., filing out required application for access forms and receiving the appropriate approvals, completing required security awareness and role-based training, completing any person proofing requirements, obtaining a required CMS-approved hard token credentials [PIV card, RSA token, etc.] for multi-factor authentication, etc.) or for any user requiring a modification to their account security credentials.
• Ensure the account security credential(s) are issued to the appropriate authorized individual user.
• Ensure all the security-related activities required are met to ensure the secure establishment and management of user accounts. (Refer to Account Management below).

CMS Access Control services and practices

This section describes an overview of some of the CMS services and practices that assist in the discussion and the implementation of the AC family as outlined in the CMS ARS and the CMS IS2P2. The information in this section provides some important considerations for implementing Access Control based on the mission and business requirements of CMS, its operational environments, and the assessments of organizational and system risks. The additional information contained in this section also explains the purpose of the control and the mechanisms to meet the control requirements.

Please consult the CMS ARS for specific procedures.

Account management

Account Management control is required to establish the requirements for managing CMS systems and user accounts throughout the account lifecycle. The Office of Information Technology (OIT) implements mechanisms that are responsible for all account management-related activities. These mechanisms help to ensure CMS personnel or entities have secure, authorized access to CMS business applications. The primary functions of an account management feature are:

• Registration
• Authentication
• Authorization
• Identity and User Account Lifecycle Management.

The account control mechanisms are also required to authorize and monitor the use of guest or anonymous accounts, and remove, disable, or otherwise secure unnecessary accounts.

The following details the CMS-specific process for Account Management:

1. CMS information systems must have a documented Access Control procedure to document account life cycle activities. A description of all authorized system users, account access privileges, and other applicable account attributes must be documented.
2. Account creation, changes, disabling, and retiring are requested using the channels documented in the applicable access control procedure or the system security and privacy plan.
3. The following requirements are adhered to before creating, enabling, modifying, disabling, or removing accounts:

• Valid access authorization
• Intended system usage
• Satisfactory completion of mandatory training requirements (Security Awareness Training [SAT] in the Awareness and Training [AT] family of controls [and annually thereafter]; pre-access and role-based training within the prescribed timeframe), acknowledgment of Rules of Behavior for General Users, and signed request forms.
• A valid justification must be supplied if access rights are above what is minimally necessary to perform the duties of the job.
• List of functions required to perform job duties
• Authorization and approval from applicable information account managers as described in the system security and privacy plan.

   4. The Primary Information System Security Officer (P-ISSO) (or alternate) is tasked with:

• Ensuring access control policies and procedures are followed.
• Auditing account management activities to ensure compliance.
• Reviewing access privileges to ensure all users have justifiable permissions.
• Enforce account management lifecycle activities.

The CMS ARS requires removing or disabling default user accounts, renaming active default user accounts, implementing a centralized control of user access administrator functions, regulating and defining the access provided to contractors, searchable automated account management results by CMS Cybersecurity Integration Center (CCIC), and all raw security information/results from relevant automated tools must be available in an unaltered format to the CCIC.

Account managers must be notified when a CMS system user is terminated or transferred, and the user’s associated account removed, disabled, revoked, or otherwise secured within a Mission/Business/System-defined timeframe, and not to exceed 30 days from the date of termination or transfer. Account managers must also be notified when there are changes in the user's system usage or need to know.

Automated system account management

Automated System Account Management is required to manage, create, enable, modify, disable, revoked, retire, and remove CMS system account(s) when a user is terminated or transferred. CMS access control tools leverage the use of emails or text messaging to notify managers and users of account lifecycle events. These tools have automated capabilities to review user account activities and usage and report atypical behavior using email notifications.

CMS system administrators must be notified via automated email whenever a user account lifecycle event has occurred. Automated email mechanisms must be in place to support the management of system accounts. Additionally, users are emailed prior to password expiration and are allowed to make the necessary password changes.

Automated temporary and emergency account management

Automated temporary and emergency account management is required to automatically remove or disable the access rights of temporary or emergency accounts after a predefined period after activation rather than at the convenience of the system administrator. Automatic removal or disabling of accounts provides a more consistent implementation.

CMS temporary and emergency accounts are managed in accordance with the system’s account management procedures or the security and privacy plan. These accounts are provisioned only when necessary and authorized, and they must be established with a fixed duration based on the need not to exceed the CMS parameter.

Disable accounts

CMS systems are configured to automatically disable accounts that are expired, no longer associated with a user or individual, violate CMS policy, or have been inactive for a predefined period. 

For an inactive account, a scheduled task reconciles the Last Login Date from the system database and locks the user account if the period reached its expiration date. Users who have not logged in during the inactivity period are marked as inactive and their accounts locked. The user will be notified at the next logon attempt that their account has been locked and can make use of the self-unlock feature or an IT Service Desk request for a user account reset.

All these processes support the concepts of least privilege and least functionality that reduce the attack surface of systems. 

Automated audit actions

CMS access control systems are required to utilize the capability to automatically produce event logs for system administrators to review for administrative actions. These may include account creation, modification, enabling, disabling, and removal actions for audit record review, analysis, and reporting. In addition to any other actions defined in the applicable system security and privacy plan.

CMS systems must be configured to log and audit the following account lifecycle events:

• Creation
• Enabling
• Modification
• Disabling and;
• Removal (Retirement and Termination).

Notifications for these relevant and significant events are sent to the system administrators or managers as documented in the applicable security and privacy plan. Account actions in Active Directory (AD) are logged and exported to a Security Incident and Event Management (SIEM) tool where custom alerts are created, which notify appropriate individuals of these activities.

Inactivity logout

Inactivity logout after a defined period reduces the risks of unauthorized access to CMS systems. This is accomplished by setting a lock on the system after 90 minutes of inactivity to prevent users from obtaining information from the display device while an authorized user is actively logged into the system or application. Users are also encouraged to lock their systems when leaving the vicinity and are required to log out at the end of a normal work period.

Usage conditions

Clearly defined account usage conditions establish and describe the specific conditions or circumstances under which CMS system accounts can be used. These conditions help enforce the principle of least privilege, increase user accountability, and enable effective account monitoring. CMS defines these usage conditions for particular system accounts as necessary to provide adequate information protections and configure systems to enforce them.

The following details the usage conditions that are set and must be met before access is granted to CMS systems:

• CMS requires all users who have been provisioned a User ID to complete an initial and annual certification of access needs, as well as the security Computer Based Training (CBT) course. Access is revoked for users who have not complied with these requirements annually.
• CMS users are required to accept the government warning displayed on the CMS warning banner before accessing CMS Government-Furnished Equipments (GFEs), CMS VPN connections, or CMS Virtual Desktop Infrastructure (VDI) using CITRIX Workspace connections. This warning banner is an acknowledgment of monitoring and usage restrictions.
• All users must complete all CMS system-related documentation including access request forms, HHS rules of behavior for General Users, and any additional training required based on individuals with Significant Information Security Responsibilities (SISR), e.g., Role Based Training (RBT) for any user identified with significant information security and privacy responsibilities, as required in the applicable system security and privacy plan.
• CMS users are prohibited from accessing systems from non-US locations during foreign travels without first obtaining official leadership approval. For more information on the approval process, review Chapter 10: Foreign Travel of the CMS Physical Security Handbook.

​​​​​​​Account monitoring for atypical usage

The administrative monitoring of activities associated with CMS system accounts is established to determine unusual and malicious use. CMS security teams monitor accounts for atypical usage that may include assessing systems at unusual days and times or from locations that are not consistent with the normal usage patterns of individuals, and for unusual information transfer volumes. Monitoring may also reveal rogue behavior by individuals or an attack in progress. There is coordination between CMS systems and the security teams through the CCIC to monitor system accounts and their usage and report to CMS incident response teams.

The following details the CMS-specific process for monitoring user accounts for atypical usage.

CMS employs several security appliances and devices to assist with the ongoing monitoring of systems, as well as related system accounts, for atypical usage.

Firewalls: Network- and host-based firewalls are used to monitor traffic and generate daily reports covering the last 24 hours of activity.

Security Information and Event Management (SIEM): This solution is used to review logs generated from applications, databases, and servers for analysis by CMS security teams.

In accordance with CMS information system Incident Response Plans, CMS CCIC should be notified immediately of potential security incidents upon discovery.

​​​​​​​Disable accounts for high-risk individuals

Disabling the accounts for high-risk individuals reduces the risks posed by an insider threat that could adversely impact CMS IT assets, environment, operations, and individuals. Users who pose significant security or privacy risks include individuals for whom reliable evidence indicates either intention to use authorized access to a system to cause harm or through whom adversaries will cause harm.

Disabling accounts of high-risk individuals is a minimum requirement for the HHS Policy for Rules of Behavior for Use of Information and IT Resources because of the possibility of abusing access privileges to sensitive information and CUI, including information protected under the Privacy Act.

Account management activities must be expedited for the revocation of access for high-risk user accounts. Notification is sent to the appropriate security personnel as documented in the system security and privacy plan using the appropriate channels (email or phone). After being notified, the account must be disabled within a reasonable time frame not to exceed the CMS-established parameter from the time the high-risk account is identified.

​​​​​​​Access enforcement

Access control policies and the associated access enforcement mechanisms are employed to automatically control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the systems. These access control mechanisms must restrict access to any sensitive information, CUI or personally identifiable information (PII) and protected health information (PHI).

CMS systems are configured to enforce approved authorizations for logical access to information and system resources that support its mission and business functions, in accordance with applicable access control policies.

Further, access enforcement mechanisms can be employed at the application and service level to provide increased information security and privacy. Assigned privileges and rules are used to allow logical access to systems, applications, and databases. These privileges are assigned during the account creation and modification account lifecycle.

​​​​​​​Controlled release

Controlled release of information ensures systems implement technical or procedural means to validate the controls implemented by any external systems before releasing information to them. All external systems or entities (i.e., departments, agencies, or commercial entities not managed by CMS) must provide controls that are commensurate with those implemented by CMS to protect the released information. The means used to determine the adequacy of the controls provided by the recipient systems may include conducting periodic assessments (inspections/tests), establishing agreements between CMS and external entities, or some other process. The adequacy of the implemented controls on those external systems ensures a consistent adjudication of the security and privacy policy that protects the information and individuals’ privacy.

​​​​​​​Individual access

CMS allow access to individuals that enable them to review personally identifiable information about them collected via legislative mandates and healthcare programs. Access helps individuals to develop an understanding of how their personally identifiable information is processed, handled, and disseminated to ensure their data is accurate and secure. Access mechanisms can include request forms and application interfaces. As stipulated by the Privacy Act, individual record access procedures are contained in systems of record notices (SORN) and the SORNs published on the Federal Register and CMS/HHS websites.

However, individual access to certain types of records contained in the HHS Exempt Systems of Records may be exempt, in full or in part, from certain requirements of the Privacy Act, based on rulemakings promulgated under subsection (j) or (k) of the Privacy Act (5 U.S.C. § 552a(j), (k)). Note that 5 U.S.C §. 552a(d)(5) excludes material compiled in reasonable anticipation of a civil action or proceeding from the Privacy Act's access requirement, in all systems of records, without the need for rulemaking.

​​​​​​​Information flow enforcement

Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) without regard to subsequent access to that information. Flow control restrictions may include blocking external traffic that claims to be from within CMS, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from CMS's internal web proxy server, and limiting information transfers between CMS and other external entities based on data structures and content.

Transferring information between CMS and other external entities may require an agreement specifying how the information flow is enforced using interconnection security agreements (ISA), information exchange security agreements, memoranda of understanding or agreement (MOU/MOA), service level agreements (SLA), or other exchange agreements (as defined in the applicable security and privacy plans).

Information flow enforcement may also include prohibiting information transfers between connected systems (i.e., allowing access only), verifying write permissions before accepting information from another security or privacy domain or connected system, employing hardware mechanisms to enforce one-way information flows, and implementing trustworthy regarding mechanisms to reassign security or privacy attributes and labels. 

The following details the CMS-specific process for implementing information flow enforcement.

CMS uses a variety of methods and applications to enforce information flow with systems and between interconnected systems.

• The CMS access control systems are configured to enforce approved authorizations within CMS information systems and other interconnections. For more information on interconnections and information sharing, please review AC-21 in the CMS ARS.
• Virtual Local Area Networks (VLANs) are used to provide environment and zone separation with firewall device control between each interconnected VLAN. Firewall rules are then configured to restrict information flows to only authorized users.
• Interconnection between different server types within the CMS information system environment is controlled by network devices including firewalls. Rules are set up to allow traffic to authorized destination internet protocol (IP) addresses only.

​​​​​​​Flow control of encrypted information

CMS systems are configured to prevent encrypted information from bypassing information flow control mechanisms by either blocking the flow of the encrypted information or terminating communications sessions that attempt to pass encrypted information. Flow control mechanisms may include content checking, security policy filters, and data type identifiers. The term encryption is extended to cover encoded data that are not recognized by the filtering mechanisms.

​​​​​​​Separation of duties

Separation of duties for CMS’s accounts is enforced to address the potential for abuse of authorized privileges and reduces the risk of malevolent activity without collusion. Each individual`s responsibilities and privileges within CMS`s environment are defined in a way that inhibits intentional or inadvertent unauthorized activity. Through the use of job codes, roles, and access rights, the workflows for authorization are separated in the CMS environment. A job code is a role that grants a group of users, access to defined resources. All ISSOs are required to ensure that these requirements are implemented effectively and meet the minimum control standards within the CMS ARS in their respective systems during authorization.

Further, implementing separation of duties control reduces the risk of inappropriate access to CMS's sensitive information and CUI (e.g., separating employees that perform security and breach investigations from routine mission and business functions).

CMS Business owners control the access to their respective CMS systems. They create privileges that limit an individual's account access only to those systems for which there is a business need. Access rights are established while considering the separation of duties based on the following factors:

• Dividing mission functions and information system support functions among different individuals and/or roles.
• Conducting information system support functions with different individuals (e.g., system management, programming, configuration management, quality assurance and testing, and network security).
• Ensuring security personnel administering access control functions do not also administer approval or audit functions.

​​​​​​​Least privilege

CMS employs the principle of least privilege to ensure that its information system accounts are provisioned at privilege levels no higher than necessary to accomplish the mission/business functions. In other words, the system access privileges are only enough, i.e., at a minimum, for a user to perform their assigned duties as prescribed in their job descriptions. CMS systems are configured to prevent non-privileged accounts from having access to security or audit-related settings and controls. It is strictly prohibited to knowingly exceed authorized access according to the HHS Policy for Rules of Behavior For Use of Information and IT Resources.

At CMS, role-based access control is used to restrict access to system functions only to designated individuals. The restrictions must be based on the minimum necessary access required to complete specific system activities. These restrictions must be included in system-specific documentation, and are necessary to ensure that only authorized users are permitted access to files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of their job duties. Unnecessary access rights associated with services that are not required for the operation of the system should be disabled.

The concept of least privilege aligns with the notion of limiting access to CMS's sensitive information and CUI to those individuals with a documented need to know in the performance of their job duties.

​​​​​​​Authorize access to security functions

Security functions in CMS are limited only to authorized personnel. Security functions include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for events to be audited, and establishing intrusion detection parameters.

CMS personnel classified as privileged users, according to the CMS IS2P2, are:

• Application Administrators
• Database Administrators
• System Developers and Maintainers
• System/Network Administrators
• Website Owner/Administrators.

The following details the CMS-specific process for authorizing access to security functions:

• Access is granted based on the privileged role and approved job codes, with privileged functions restricted to individuals with administrative or security functionality requirements.
• The privileged account is restricted to privileged functions only and cannot be used to perform normal user (i.e., non-privileged accounts) functions concurrently.
• Approved servers may use RBAC which is implemented using Active Directory (AD) group memberships. Non-privileged accounts have no access to servers.
• System configurations and parameters are by group policy (GPO).

​​​​​​​Non-privileged access for non-security functions

The implementation of non-privileged access for nonsecurity functions limits security exposure or incidents that might occur when users perform operations from within privileged accounts or roles. CMS-privileged accounts or roles must be used only when necessary to perform system administration and security duties. Also, CMS systems must be configured to prevent non-privileged users from executing privileged functions.

CMS-privileged users with access to security functions are provisioned with and required to use their non-privileged accounts to perform duties that do not require that level of access. The separation of privileged and non-privileged accounts also prevents unintended or unauthorized loss, modification, or exposure. For example, a System Administrator (SYSADMIN) would have a separate account to perform SYSADMIN functions, and a typical USER account to perform normal user functions such as email, application access [Word Documents, Spreadsheets, Presentations, etc.], etc. The SYSADMIN cannot perform SYSADMIN functions under the typical USER account or role.

In addition, the typical USER account or role cannot perform SYSADMIN-type functions such as administration/ management of the following: operating systems, network operations (telecommunications devices, firewalls, DMZ, servers, database administration, etc.), application servers, database servers, etc. In other words, any operation that would require Operating System (OS), ADMIN, or root-level access to perform ADMIN-type services or operations.

​​​​​​​Network access to privileged commands

CMS restricts the ability to perform privileged commands across the network connection as opposed to the local access on its systems. CMS limits network access to activities requiring elevated privileges to situations where there is a compelling operational need. For example, a compelling operational need may include routine administration (management) of remote security and infrastructure devices across a dedicated management network (see the CMS Technical Reference Architecture [TRA] for additional information).

Network access to privileged commands is limited to specific roles listed as privileged users in CMS IS2P2. These roles are:

• Application Administrators
• Database Administrators
• System Developers and Maintainers
• System/Network Administrators
• Website Owner/Administrators 
• Additional roles as documented in the System Security and Privacy Plan (SSPP).

CMS personnel are approved for such access by requesting the necessary roles or privileges. The process of requesting and approving these roles or privileges (as documented in the system security and privacy plan) acts as a control to ensure the privilege is being assigned to the right user.

​​​​​​​Privileged accounts

CMS limits who is authorized to perform administrative or security functions on its systems. These functions may include configuring access permissions, setting audit logs, and performing system management functions. This level of access needs to be limited because it further protects sensitive information and CUI from being comprised by reducing the number of individuals who possess unnecessary high privileges.

Privileged accounts are limited only to specific roles that require the performance of privileged functions in the CMS environment. These roles are:

• Application Administrators
• Database Administrators
• System Developers and Maintainers
• System/Network Administrators
• Website Owner/Administrators 
• Additional roles as documented in the SSPP.

CMS personnel are approved for such access through the appropriate account privileges. The process of requesting and approving these account privileges (as documented in the SSPP) acts as a control to ensure the privilege is being assigned to the right user.

​​​​​​​Review of user privileges

In CMS, certain assigned user privileges may change over time to reflect changes in the mission and business functions, environments of operation, technologies, or threats. A periodic review of all assigned user privileges is necessary to determine if the rationale for assigning such privileges remains valid. If the need cannot be revalidated, appropriate corrective actions must be taken to address it.

​​​​​​​Log use of privileged functions

Log the use of all privileged functions to ensure that there is accountability for all CMS system accounts with privileged functions because of the elevated permissions to access, and grant access, to sensitive information and CUI.

The following details the CMS-specific process for logging the use of privileged functions:

• CMS systems audit the use of privileged functions via logging user accounts that have the right to conduct privileged functions only on the system. 
• The audit logs must include a user account trail of privileged commands executed intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts.
• These logs are then audited and reviewed using a SIEM tool.

​​​​​​​Prohibit non-privileged users from executing privileged functions

Prohibit non-privileged users from executing privileged functions so that appropriate individuals have access to privileged functions only based on their roles and responsibilities. Non-privileged users may not have the same level of trust as privileged users. Privileged users have access beyond that of a non-privileged user, and as such, may have a greater ability to access sensitive information and CUI. Privileged accounts typically may have root-level access to the system at the operating system (OS) level and therefore “keys to the kingdom” level of access to all components or services of that system. For this reason, systems must have the ability to trace (audit) the actions of the user who initiated them and what actions were taken. 

The assignment of privileged functions to user accounts should be based on the role and the level of responsibility of the user, while still accounting for the principle of least privilege. Privileged functions are assigned to a user account through approved roles or privileges and the approval process acts as a safeguard to ensure access is being provisioned to the right user, who have been appropriately authorized for the escalated privilege. 

Users' accounts are set up to allow only the necessary functions authorized, thereby enforcing the principle of least privilege.

​​​​​​​Unsuccessful logon attempts

The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded counteracts denial of service attacks and ensures that the user account is accessed only by the owner of that account. Automatic account lockouts are initiated by systems and are usually temporary and automatically released after a predetermined period as established by the CMS system administrators.

The implementation standards contained in the CMS ARS are determined by the system’s risk categorization as stated below:

High: Configure the information system to lock out the user account automatically after three (3) invalid login attempts during a 120-minute time window. Require the lockout to persist until released by an administrator.

Moderate: Configure the information system to lock out the user account automatically after five (5) invalid login attempts during a 120-minute time window. Require the lockout to persist for a minimum of one (1) hour.

Low: Configure the information system to disable access for at least fifteen (15) minutes after five (5) invalid login attempts during a 120-minute time window.

CMS users will experience a lockout if they reach the maximum number of invalid login attempts. Users will be locked out indefinitely and must contact the CMS IT Service Desk or their system administrator to request their account to be unlocked.

​​​​​​​System use notification

CMS systems are configured to display an approved notification to be accepted by users before login. This notification provides appropriate security and privacy notifications as well as terms of use of the system. All CMS information systems are configured to display a system-use notification message before granting access. This is commonly referred to as a “System Warning Banner”. 

HHS has an established language approved for use as defined in the CMS ARS AC-08 System Use Notification control. The system must use the HHS-approved warning banner text unless the system is collecting Federal Tax Information (FTI), then the IRS Publication 1075 requires the system to use the approved text specified in Exhibit 8 Warning Banner Examples from the IRS AC-08 System Use Notification control standard. The warning banner notification message must be displayed upon successful logon, obtaining an affirmation in the workflow from the user of their understanding and acceptance of the warning before gaining system access. This warning message notifies users that the CMS system is owned by the U.S. Government and describes conditions for access, acceptable use, and access limitations. The warning is presented at the secure gateway, and again at the system/device level. The approved warning/notification message should require forced user interaction and require the user to explicitly select the “I Accept” button before proceeding to log on to the system. The system should retain the notification message or banner on the screen until users take the explicit action(s) to log on to or further access the system.

The warning banner language has very important legal implications for CMS and its system resources. Should content need to be added to this banner, submit the modified warning banner language to the CMS CIO for review and approval prior to implementation. If a system has character limitations related to the warning banner display, the CMS CIO can provide an abbreviated warning banner version. The IRS Publication 1075 in Exhibit 8 Warning Banner Examples also has approved abbreviated warning banner versions available to use. If this banner is inconsistent with any directives, policies, regulations, or standards, notify the CMS CIO immediately.

All systems and network devices under CMS control must prominently display the notice and consent banner immediately upon users’ authentication to the system, including, but not limited to, websites, web pages where substantial personal information from the public is collected, Secure File Transfer Protocol (SFTP), Secure Shell (SSH), or other services accessed.

The CMS ARS provides additional requirements for the content and the implementation of System Use Notifications as specified by the AC-08 System Use Notification control standard.

​​​​​​​Concurrent session control

CMS defines and implements the maximum number of concurrent sessions for information system accounts globally, by account type (e.g., privileged user, non-privileged user, domain, specific application), by account, or any combination thereof. A session is defined as an encounter between an end-user interface device (e.g., computer, terminal, process) and an application, including a network logon. One user session is the time between starting the application and quitting or exiting the application. For example, if a user can use separate browsers to open concurrent sessions with the same user account and log out of any of the concurrent sessions to terminate the other sessions, safeguards must be implemented to counteract this type of action.

CMS limits network log-on sessions to one (1) user/network/application session at a time by implementing the appropriate configuration settings. However, if a concurrent session of more than one (1) is required for the system, it needs to be documented in the applicable SSPP and approved by the CMS Authorizing Official (AO) during the Authorized To Operate (ATO) approval process.

​​​​​​​Device lock

Device locks are actions taken to prevent logical access to systems when a period of inactivity has been detected on a CMS user account. This control is configured to protect sensitive information and CUI from unauthorized access when CMS system users are away from their workstations for a CMS-defined period of inactivity. Identification and authentication requirements must be met for users to re-establish access to the system. Group Policy is used to configure the device lock requirements.

The following details the CMS-specific process for implementing device lock:

• CMS information systems, along with GFE computers distributed to CMS Federal staff and contractors, are configured with a fifteen (15) minute device lock on the operating system. The user will be required to re-authenticate themselves to continue accessing CMS resources.
• Windows and UNIX servers are configured to lock the application, after thirty (30) minutes of inactivity. The user will be required to re-authenticate themselves to continue accessing CMS resources.

​​​​​​​Pattern-hiding displays

Pattern-hiding displays conceal, via the device lock, information with a publicly viewable image. All CMS systems are configured to conceal information that is previously available on the display with a screen saver. Pattern-Hiding Displays mitigate against unauthorized viewing of any sensitive information and CUI, especially PII or PHI. This type of threat is commonly referred to as “shoulder surfing”.

The following details the CMS-specific process for implementing pattern-hiding displays:

• The system conceals information previously available on the display with a screen saver built into the operating system of the GFE. 
• CMS users can make use of this display before leaving GFE computers unattended or concealing information from unauthorized personnel. 
• The login screen is only available by pressing CTRL-ALT-DEL.

​​​​​​​Session termination

Session termination ensures that all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) continue after the session is terminated. The conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.

CMS systems are configured to terminate user login sessions after a certain period of inactivity. For systems-specific login sessions, the system must implement automatic session termination based on a predefined condition or trigger outlined in their respective system security and privacy plan (SSPP).

​​​​​​​Permitted actions without identification or authentication

Some specific user actions are permitted on CMS systems without identification or authentication required. Systems may allow a limited number of user actions like access to CMS public websites or other publicly accessible CMS systems that do not contain any sensitive information and CUI, but only the information that is appropriate for public consumption.

All CMS systems that are not intended to be utilized by the public require proper user account processes and authentication. Please refer to the NIST Special Publication (SP) 800-63 series regarding Digital Identity Guidelines (NIST SP 800-63, SP 800-63A, SP 800-63B, SP 800-63C).

​​​​​​​Remote access

Remote access is access to CMS systems by users (or processes acting on behalf of users) that communicate through external networks (for example, the Internet or non-secure telecommunication pathways and protocols) via CMS-approved VPNs or CMS VDI via the CITRIX Workspace. The use of CMS-approved VPNs or VDI does not make the access non-remote. However, the use of VPNs or VDI, when adequately provisioned with appropriate security controls (e.g., employing appropriate encryption techniques for confidentiality and integrity protection) provides sufficient information security assurance to the organization that it can effectively treat such connections as safe internal networks. Remote access to CMS network resources is securely configured and must meet, as a minimum, the following security requirements for posture validation:

1. Up-to-date system patches
2. Current malware/anti-virus software with up-to-date patches
3. A host-based intrusion detection system(s)
4. Disable functionality that provides the capability for automatic execution of code and
5. Employs CMS-required encryption which is the Federal Information Processing Standard (FIPS) 140-2 validated cryptographic module at a minimum.

The following details the CMS-specific process for implementing the remote access control:

• The system should utilize a CMS-approved VPN(s) or VDI to ensure the security of the sessions and the integrity of client-based applications.
• CMS users are not allowed to access CMS systems remotely without a CMS-issued RSA hard token or FIPS 201 PIV card, along with an approved EUA job code.
• Access to the secure CMS VPN or CMS VDI will authenticate the user account using the EUA job code.
• The VPN solution used by CMS also includes a Network Access Control (NAC) component that performs a security assessment and verifies the latest critical operating system patches and up-to-date malware/anti-virus signatures. 
• If the computer fails any one of these checks, it will be quarantined, i.e., preventing remote users from connecting to the CMS network with machines that aren't up to date with malware/anti-virus signatures or OS patch levels, and securing the computer by placing VPN login credentials into a secured area with limited or no access to the CMS network until those conditions are remediated. In the remediation process, CMS users are instructed to obtain required updates from Windows Software Update Service (WSUS) servers or other update servers. 
• CMS contractors will be notified that they will need to disconnect from the VPN and update their computers by downloading the latest Microsoft critical patches and/or antivirus signatures before access is granted.
• Remote access for privileged functions must be permitted only for compelling operational needs, must be strictly controlled, and must be explicitly authorized, in writing, by the CMS AO, i.e., the CIO (Chief Information Officer) or his/her designated representative.

Additional information on connecting to the CMS Network using an approved CMS VPN service can be found in the Remote Access Support. Additional information for CMS Federal Employees or contractors using the CMS VDI can be found at CMS Employees and Contractors How-To-Guide VDI.

​​​​​​​Monitoring and control

CMS systems are configured to employ automated mechanisms and establish parameters that facilitate the monitoring and control of remote access. User activities are also monitored and audited to ensure compliance with CMS remote access policies, as applicable to each CMS information system. For more information on remote access, visit the CMS Remote Access Support website.

An Intrusion Detection System (IDS) is deployed to protect and monitor the integrity of the systems. Continuous monitoring is also deployed by the CMS Information Security and Privacy Group (ISPG) to ensure compliance with CMS policies.

​​​​​​​Protection of confidentiality and integrity using encryption

All CMS systems shall implement cryptographic mechanisms to protect remote access sessions. All encryption solutions used throughout CMS must be FIPS 140-3 tested and validated. The confidentiality and integrity of remote sessions, sensitive information and CUI shall be protected with end-to-end encryption commensurate with the sensitivity level of the data.

Systems must utilize a CMS-approved secure VPN or VDI solution to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Every access to the CMS Secure VPN or VDI requires authentication using secure user system account credentials. 

When applicable and available, sessions should be secured with FIPS 140-3 hardware security modules and FIPS 140-3 compliant algorithms.

​​​​​​​Managed Access Control points

All CMS remote accesses must be routed through authorized and managed network access control points to protect the network connections. A Trusted Internet Connection (TIC) must be utilized for all external network connections.

The following details the CMS-specific process for implementing managed access control points:

All systems must utilize CMS-approved secure VPN or VDI connections to ensure the confidentiality of the remote access sessions, the integrity of client-based applications, and the availability of the VPN or VDI session. Administrative access should be limited to designated CMS-approved VPN or VDI solutions. Based on the designated VPN or VDI solution, configurations for firewall rules, Intrusion Detection and Prevention System policies, server policies, and active directory group policies as implemented in collaboration with AC control family requirements, will limit remote access.

​​​​​​​Privileged commands and access

The execution of privileged commands and access via remote access is restricted. Remote access for privileged commands and access should only be permitted if operational needs cannot otherwise be met via a direct connection in a secured access-controlled environment.

Systems should be configured to allow privileged user accounts to execute privileged commands to security-relevant information via remote access under special circumstances associated with the need to complete a task for critical operational needs. If a system opts to enable appropriate privileged commands via remote access, the rationale for the permission must be documented in the SSPP and approved via the CMS AO during the ATO approval process.

​​​​​​​Wireless access

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) are in charge of 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 AO, i.e., the CMS CIO or the designated representative.

If wireless access is authorized and approved by the AO during the ATO process, CMS establishes usage restrictions and configuration/connection requirements such as:

• FIPS 140-3 encryption protection is enabled
• Access points are placed in secure areas where physical access controls can be implemented, monitored, and audited
• Access points are shut down, i.e., powered off, when not in use (nights, weekends)
• A stateful inspection firewall is implemented between the wireless network and the wired infrastructure; where a direct telecommunication wired connection is established
• Media Address Control (MAC) address authentication is utilized
• Personal firewalls are utilized on the endpoint device, e.g., laptop, and file sharing is disabled on all wireless clients
• Intrusion detection agents are deployed on the wireless side of the firewall device
• Wireless activity is monitored and recorded, and the records are regularly reviewed
• Adheres to CMS Policy for Wireless Client Access and HHS Standard for IEEE 802.11 Wireless Local Area Network (WLAN).

Rogue wireless devices, i.e., unauthorized WAPs, that are connected to the network can be detected by the wireless intrusion prevention system (WIPS). 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 additional information on how to connect an approved wireless connection to CMS, please refer to the CMS Wireless Network Connection Guide.

​​​​​​​Authentication and encryption

All CMS systems are protected against wireless networking capabilities by using authentication and the encryption of both users and devices. Wireless networking capabilities represent a significant potential vulnerability that can be exploited by adversaries.

The CMS Baltimore Data Center Group (BDCG) manages the wireless functionality and security in the enterprise environment. The CMS IUSG monitors for unauthorized wireless access to CMS systems and prohibits the installation of WAP devices to systems unless explicitly authorized, in writing, by the CMS AO, i.e., the CMS CIO or the designated representative. For more information on Authentication and Encryption, please refer to the System and Communications Protection (SC) and the Identification and Authentication (IA) Controls of the CMS ARS.

All wireless access points are configured to authenticate users and devices before access is granted. Also, all WLAN components use FIPS 140-3 approved cryptographic algorithms to protect the confidentiality and integrity of WLAN communications.

​​​​​​​Disable wireless networking

All wireless network capabilities embedded within CMS systems components must be disabled before issuance and deployment. Disabling all the wireless capabilities when not needed for essential CMS missions or functions can reduce susceptibility to threats by adversaries involving wireless technologies.

​​​​​​​Restrict configurations by users

Access enforcement mechanisms are employed to restrict access to configure wireless networking capability only to selected and authorized users. Only CMS-approved and authorized users should be allowed to configure network capabilities. The responsibility of securing the CMS wireless network should rest in the hands of network administrators with system administrator (SYSADMIN) type accounts, that only allow SYSADMIN type commands to be performed under this type of SYSADMIN role.

The following details the CMS-specific process for implementing restrictions on access to wireless configurations.

1. CMS restricts access to wireless networking configurations only to the authorized role of a network administrator.
2. Wireless networking capabilities are also confined within CMS boundaries.

Antennas and transmission power levels

CMS limits the unauthorized use of wireless communications outside of CMS-controlled boundaries. Radio antennas and transmission power levels must be calibrated to reduce the probability that usable signals can be intercepted by unauthorized users. Network traffic must be continuously monitored within CMS boundaries to detect and respond to intrusion and network misuse.

​​​​​​​Access Control for mobile devices

All CMS-controlled mobile devices, including when such devices are outside of the CMS-controlled areas, must abide by the established configuration requirements, connection requirements, and implementation guidance in the CMS ARS when connected to the CMS environment.

CMS network administrators must set usage restrictions, configuration, and connection requirements for all mobile devices. The CMS Guidance for Government Furnished Mobile Devices provides information on the responsible use of CMS-issued mobile devices. 

The following details the CMS-specific process for implementing access control requirements for mobile devices:

• All CMS-issued laptops utilize full disk encryption software that is FIPS 140-3 validated
• CMS-procured removable storage media are configured for use by the contracted maintainer and use CMS-approved encryption for the storage of information
• Any non-GFE equipment being connected internally to the network requires a fully signed Rules of Behavior for General Users form which details CMS' Operational Division (OpDiv) security responsibilities relative to the equipment being connected, along with prior approval from the CMS AO during the ATO process. The document also details the responsibilities the requester will fulfill or face possible disciplinary and/or non-disciplinary actions. Please refer to the HHS RoB, Section 6.3 Non-compliance for a list of potential adverse actions that may be taken against a user for non-compliance.

GFE equipment may be connected remotely via VPN (using the established VPN for the Contractors' process). VPN authentication involves remote NAC checks that ensure the integrity of the system.

​​​​​​​Full device or container-based encryption

All CMS-issued mobile devices must be encrypted using full device or container-based encryption mechanisms to protect the confidentiality and integrity of the data and information contained. Container-based encryption provides a more fine-grained approach to data and information encryption on mobile devices, including encrypting selected data structures such as files, records, or fields. Since mobile devices are more likely to be lost or stolen, sensitive information on a mobile device(s) is more vulnerable to unauthorized disclosures and encryption reduces this vulnerability.

At CMS, FIPS 140-3 encryption mechanisms are used to protect the confidentiality and integrity of information on CMS-issued mobile devices. CMS utilizes media and port protection software to encrypt removable media endpoint devices.

​​​​​​​Use of external systems

CMS employs mechanisms that prohibit the use of external devices to access the systems within the network without a formal approval process. CMS complies with the HHS Policy for Rules of Behavior For Use of Information and IT Resources, which strictly prohibits the use of personal devices to conduct CMS-related business without written and approved authorization by the CMS AO under the ATO approval process.

The following details the CMS-specific process for the use of external information systems control requirements:

• CMS prohibits the use of external systems without explicit written approval from the AO. 
• CMS does not allow the use of external systems that are not approved and do not meet CMS security requirements. If approval is granted, the recipient verifies the terms and conditions, ensures the required controls are implemented for the identified FIPS 199 system categorization to mitigate the associated risks, limits user access accordingly, and documents the control implementations in the SSPP.
• Access to PII from external systems (including, but not limited to, personally owned information systems/devices) is reinforced by a binding agreement to terms and conditions of the CMS’s privacy requirements to ensure awareness and accountability of both parties under the Interconnection Security Agreement approval process.

​​​​​​​Limits on authorized use

CMS ensures that only authorized users are permitted to use external systems to access its systems, and these systems must have the necessary security configurations implemented before access is granted. These necessary security requirements are implemented and the CMS access control policies regarding the use of external systems are enforced.

The following details the CMS-specific process for limiting the authorized use of external information systems:

• CMS does not permit the use of external systems that are not approved and do not meet the CMS security requirements for accessing CMS systems per the HHS Policy for Rules of Behavior For Use of Information and IT Resources.
• External systems can only access CMS systems using approved VPN or VDI access and firewall/security verification software, which must be installed on each machine. This applies to federal employees and contractor personnel utilizing CMS GFE (laptop or desktop) only or approved corporate-issued computers per the contract.

​​​​​​​Portable storage devices — restricted use

CMS limits the use of its controlled-portable storage devices in external systems. Conditions of use or restrictions on these devices should be documented and configured by network administrators.

CMS has configured CMS-issued portable and mobile devices to meet federal requirements. CMS has provided several control implementations that support and manage how its information is used within portable storage devices. These include a policy to incorporate a methodology for protecting the information and the rules used to manage the information while in transit. For more information, review the CMS Storage Device and Encryption website.

​​​​​​​Information sharing

Information sharing control puts restrictions on CMS-sensitive information and CUI, such as personally identifiable information (PII), contract-sensitive information, proprietary information, and classified information related to special access programs or compartments, based on a formal or administrative risk-based determination. Depending on the information-sharing circumstances, sharing partners may be defined at the individual, group, or organizational level. Information may be defined by content, type, security category, or special access program/compartment.

Guidance for information sharing between CMS and other organizations is specified in the CMS Privacy Handbook. The document specifies the requirements for information sharing in the following documents:

• Interconnection Security Agreement (ISA): System interconnections are defined within CFACTS and require a supporting “signed” ISA between CMS and non-CMS organizations as part of the SSP/ATO process.
• Memorandum of Understanding (MOU): Defines the relationship of two or more federal partners that enter into a joint project or collaboration in which they each contribute their resources.
• Data Use Agreement (DUA): tracks disclosures of PII/PHI to third parties to ensure that any transaction of data is compliant with the Privacy Act of 1974 and the HIPAA Privacy Rule.
• Information Exchange Agreements (IEA): Is needed when Personally Identifiable Information (PII) needs to be shared externally, and that will not have an adverse impact on the beneficiary.
• Computer Matching Agreements (CMA): A written agreement establishing the conditions, safeguards, and procedures under which a federal agency agrees to disclose data with another federal or state agency when there is a computerized comparison of two or more automated Systems of Records (SORs).
• Other forms of documented agreements required for different situations. 

For additional guidance related to the above agreements and documents, please review the Privacy Handbook. The ISSO is responsible for developing and managing any agreement utilized for information sharing and should coordinate with the appropriate Data Guardian and Privacy Advisor.

​​​​​​​Publicly accessible content

Per applicable laws, executive orders, directives, policies, regulations, standards, and guidelines, the general public is not authorized to access non-public information, such as information protected under the Privacy Act information (e.g., PII/PHI), CMS sensitive information (e.g., data with a federal information classification standard, For Official Use Only [FOUO], or Controlled Unclassified Information [CUI]), and CMS proprietary information (e.g., proprietary acquisition data). This control addresses systems that are controlled by CMS and are accessible to the public, typically without requiring identification or authentication.

The following details the CMS-specific process for adhering to requirements for publicly accessible content:

Network Connections

CMS Website Owners/Administrators are charged with limiting the connections to publicly available CMS websites and web services to approved secure protocols and adhering to Hypertext Transfer Protocol (HTTP) Strict Transport Security (HSTS) practices.

• Although general public access to the CMS internal network is not allowed, CMS websites are accessible by the public and protected by several Private Internet Exchange (PIX) firewalls
• Outbound internet connections from CMS users are protected by Application Intelligence (NG AI) firewalls.

Public Content

• The CMS system personnel should reach out to the CMS Information Security and Privacy Group (ISPG) to review the proposed content of information on a publicly accessible system (including a public website) before posting or publication to ensure that nonpublic information is not included.
• The frequency of the review will be commensurate with the frequency information is posted. Whenever new information is being considered to be uploaded to a site, it should trigger a review process to ascertain it complies with CMS policy.

The system should consult the ISPG for clarification as to if the information is suitable for public accessibility and publication.