Attachment I- Selected Controls (Moderate) (Amd 0003).xlsx

Instructions

[Bold and bracketed] text = should be replaced with details Yellow background = Security Control requried by FedRAMP Orange background = Guidance or instructions

Moderate Control Catalog

1. [Selection (one or more): Organization-level; Mission/business process-level; System-level] access control policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the access control policy and the associated access controls;

b. Designate an [the ACF CISO or other ACF-defined official] to manage the development, documentation, and dissemination of the access control policy and procedures; and

c. Review and update the current access control:

1. Policy [at least every three (3) years and following ACF-defined events] and following [Assignment: organization-defined events]; and

2. Procedures [at least every three (3) years] and following [ACF-defined events]. Access control policy and procedures address the controls in the AC family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of access control policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies reflecting the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to access control policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. Part (a1): ACF has developed and documented an Access Control Policy which has been disseminated to all ACF personnel. It can be found at: https://connect.acf.hhs.gov/sites/default/files/assets/access_control_policy_04172020_v10.pdf. The access control policy addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and Part (a2): Procedures to facilitate the implementation of the access control policy and associated access controls; and Part (b1): Reviews and updates the current access control policy at least every 3 years Part (b2): Reviews and updates the current access control procedures at least every 3 years.

Access Control Technical AC- 2 AC-2 Account Management a. Define and document the types of accounts allowed and specifically prohibited for use within the system [(e.g., individual, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service)];

b. Assign account managers;

c. Require [the Information System Owner or Information System Security Officer to define prerequisites and criteria (based on user role(s) matrix defined in system SSP)] for group and role membership;

d. Specify:

1. Authorized users of the system;

2. Group and role membership; and

3. Access authorizations (i.e., privileges) and [the following attributes as defined in the user role(s) matrix in SSP System Description Narrative Template: User Types: Internal or External; Privileged (P), Non-Privileged (NP), or No Logical Access (NLA); FIPS199 and other system attributes such as HVA, Financial or Privacy designated systems; Authorized Privileges; and the system purpose or functions performed (as required)] for each account;

e. Require approvals by [ACF-defined personnel or roles] for requests to create accounts;

f. Create, enable, modify, disable, and remove accounts in accordance with [i. Favorable suitability adjudication, as appropriate for Federal and contractor employees.

ii. Completion of the HHS RoB and, as needed, system-specific RoB.

iii. Completion of HHS/ACF cybersecurity and privacy awareness training.

iv. Individual and unique assignment of user credentials.];

g. Monitor the use of accounts;

h. Notify account managers and [ACF-defined personnel or roles] within:

1. [ACF-defined time period] when accounts are no longer required;

2. [ACF-defined time period] when users are terminated or transferred; and

3. [ACF-defined time period] when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. [ACF-defined attributes (as required)];

j. Review accounts for compliance with account management requirements [at least within every 365 days];

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes. Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service. Identification of authorized system users and the specification of access privileges reflect the requirements in other controls in the security plan. Users requiring administrative privileges on system accounts receive additional scrutiny by organizational personnel responsible for approving such accounts and privileged access, including system owner, mission or business owner, senior agency information security officer, or senior agency official for privacy. Types of accounts that organizations may wish to prohibit due to increased risk include shared, group, emergency, anonymous, temporary, and guest accounts.

Where access involves personally identifiable information, security programs collaborate with the senior agency official for privacy to establish the specific conditions for group and role membership; specify authorized users, group and role membership, and access authorizations for each account; and create, adjust, or remove system accounts in accordance with organizational policies. Policies can include such information as account expiration dates or other factors that trigger the disabling of accounts. Organizations may choose to define access privileges or other attributes by account, type of account, or a combination of the two. Examples of other attributes required for authorizing access include restrictions on time of day, day of week, and point of origin. In defining other system account attributes, organizations consider system-related requirements and mission/business requirements. Failure to consider these factors could affect system availability.

Temporary and emergency accounts are intended for short-term use. Organizations establish temporary accounts as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. Organizations establish emergency accounts in response to crisis situations and with the need for rapid account activation. Therefore, emergency account activation may bypass normal account authorization processes. Emergency and temporary accounts are not to be confused with infrequently used accounts, including local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort). Such accounts remain available and are not subject to automatic disabling or removal dates. Conditions for disabling or deactivating accounts include when shared/group, emergency, or temporary accounts are no longer required and when individuals are transferred or terminated. Changing shared/group authenticators when members leave the group is intended to ensure that former group members do not retain access to the shared or group account. Some types of system accounts may require specialized training.

(1) Temporary Accounts: Automatically disable

- Low System: 60 days or less (does not need to be an automatic process for low systems)

- Moderate System: 60 days or less

- High Systems: 30 days or less

(2) Emergency Accounts: Automatically remove

- Low System: 60 days or less (does not need to be an automatic process for low systems)

- Moderate System: 60 days or less

- High Systems: 30 days or less

(a) Have expired;

(b) Are no longer associated with a user or individual;

(c) Are in violation of organizational policy; or

[a. Keep export-controlled information from being transmitted unencrypted.

b. Restrict web requests to the Internet that are not from the internal web proxy server.

c. Limit information transfers between organizations based on data structures and content.

d. Require a signed interagency agreement or interconnection security agreement (ISA) prior to transmission of information for interconnected systems.

e. Require the connecting organization to have a valid Authority to Operate prior to connection and transmission.

f. Positive source and destination address checking to restrict rogue networks from manipulating the ACF routing tables.

g. Authentication to ensure that routing tables do not become corrupted with false entries.

h. Use network address translation to obfuscate internal network addresses

i. Email data leak prevention to maintain compliance, identify and monitor the safe handling of PII.

j. Firewalls shall limit inbound and outbound network traffic to only that which is necessary to accomplish the ACF mission.]. Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information. Flow control restrictions include blocking external traffic that claims to be from within the organization, keeping export-controlled information from being transmitted in the clear to the Internet, restricting web requests that are not from the internal web proxy server, and limiting information transfers between organizations based on data structures and content. Transferring information between organizations may require an agreement specifying how the information flow is enforced (see CA-3). Transferring information between systems in different security or privacy domains with different security or privacy policies introduces the risk that such transfers violate one or more domain security or privacy policies. In such situations, information owners/stewards provide guidance at designated policy enforcement points between connected systems. Organizations consider mandating specific architectural solutions to enforce specific security and privacy policies. Enforcement includes 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 regrading mechanisms to reassign security or privacy attributes and labels.

Organizations commonly employ information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations within systems and between connected systems. Flow control is based on the characteristics of the information and/or the information path. Enforcement occurs, for example, in boundary protection devices that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or provide a message-filtering capability based on message content. Organizations also consider the trustworthiness of filtering and/or inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Control enhancements 3 through 32 primarily address cross-domain solution needs that focus on more advanced filtering techniques, in-depth analysis, and stronger flow enforcement mechanisms implemented in cross-domain products, such as high-assurance guards. Such capabilities are generally not available in commercial off-the-shelf products. Information flow enforcement also applies to control plane traffic (e.g., routing and DNS).

Access Control Technical AC- 5 AC-5 Separation of Duties a. Identify and document [i. Security administration is an independent responsibility and shall not be assigned to a system/application programmer, database administrator, system administrator, system operator, or security auditor. Functions performed by security administrators shall be entirely separated from the functions performed by system/application programmers, database administrators, system administrators, system operators, and security auditors.

ii. Security administrators’ functions shall be separated security auditors’ functions to reduce the likelihood of fraudulent action (i.e., failing to report on or mitigate security issues).

iii. Security auditors shall have full administrative control over all security audit and log files. These personnel, however, will not have data altering capability for security devices, security management devices, audit and security logs, or ACF infrastructure devices.]; and

b. Define system access authorizations to support separation of duties.

(a) [Security functions (deployed in hardware, software, and firmware) including, at a minimum:

• Setting/modifying audit logs and auditing behavior;

• Setting/modifying boundary protection system rules;

• Configuring/modifying access authorizations (i.e., permissions, privileges);

• Setting/modifying authentication parameters; and

• Setting/modifying system configurations and parameters.; and]; and

[1. For user ID and Password:

Low - for normal users: OpDiv-defined parameters; and for privileged users: five user/account attempts within 120 minutes.

Moderate - for all users: five user/account attempts within 120 minutes.

High - for all users: three user/account attempts within 120 minutes.

2. For all two-factor authentications using a PIV card, configure the maximum allowable login attempts as specified by the type of card and trusting certificate. The maximum allowed PIN attempts for each PIV card stock is specified below:

• Fifteen (15) attempts – for 64k card stock in either Cybertrust / Verizon Business CA or those converted to Entrust certificates (64k card stock only); and •Ten (10) attempts – for modern 128k cards issued by the Entrust CA.]; and

b. When the maximum number of unsuccessful attempts is exceeded, automatically enforces the following:

[Low - locks the account/node for 15 minutes.

Moderate - locks the account/node for 15 minutes High - locks the account/node until released by an administrator].

1. Users are accessing a U.S. Government system;

2. System usage may be monitored, recorded, and subject to audit;

3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and

4. Use of the system indicates consent to monitoring and recording;

b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and

c. For publicly accessible systems:

1. Display system use information [ACF-defined conditions], before granting further access to the publicly accessible system;

2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and

b. For high risk information systems, the inactivity period is 15 minutes. ].

b. Authorize each type of remote access to the system prior to allowing such connections.

[c. Access to HHS Webmail using personally-owned equipment is authorized. Access to other systems/networks using personally-owned equipment is prohibited without written authorization from the appropriate OpDiv CIO, or an approved policy allowing the use of personally-owned equipment. If the OpDiv allows the use of personally-owned equipment on Department systems or networks:

1. Personally-owned equipment must be scanned before being connected to Department systems or networks to ensure compliance with OpDiv system requirements (such as patch management requirements); and

Reference:

remote connection. ]; and

b. Authorize each type of wireless access to the system prior to allowing such connections.

[c. The organization ensures that:

1. For OpDivs that adopt wireless communications, OpDiv CIOs approve and distribute the overall wireless plan for his or her respective organization;

2. OpDivs adhere to the HHS Policy for Securing Wireless Local Area Networks; and

Due to the large variety of mobile devices with different characteristics and capabilities, organizational restrictions may vary for the different classes or types of such devices. Usage restrictions and specific implementation guidance for mobile devices include configuration management, device identification and authentication, implementation of mandatory protective software, scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware.

Usage restrictions and authorization to connect may vary among organizational systems. For example, the organization may authorize the connection of mobile devices to its network and impose a set of usage restrictions, while a system owner may withhold authorization for mobile device connection to specific applications or impose additional usage restrictions before allowing mobile device connections to a…