Attachment J- Selected Controls (Low) (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

Low 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. 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. 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

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 system. Adequate security for mobile devices goes beyond the requirements specified in AC-19. Many safeguards for mobile devices are reflected in other controls. AC-20 addresses mobile devices that are not organization-controlled.

Access Control Technical AC- 20 AC-20 Use of External Systems a. Identify [ACF-defined controls asserted to be implemented on external systems], consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and

2. Process, store, or transmit organization-controlled information using external systems; or

b. Prohibit the use of [ACF-defined types of external systems]. External systems are systems that are used by but not part of organizational systems, and for which the organization has no direct control over the implementation of required controls or the assessment of control effectiveness. External systems include personally owned systems, components, or devices; privately owned computing and communications devices in commercial or public facilities; systems owned or controlled by nonfederal organizations; systems managed by contractors; and federal information systems that are not owned by, operated by, or under the direct supervision or authority of the organization. External systems also include systems owned or operated by other components within the same organization and systems within the organization with different authorization boundaries. Organizations have the option to prohibit the use of any type of external system or prohibit the use of specified types of external systems, (e.g., prohibit the use of any external system that is not organizationally owned or prohibit the use of personally-owned systems).

For some external systems (i.e., systems operated by other organizations), the trust relationships that have been established between those organizations and the originating organization may be such that no explicit terms and conditions are required. Systems within these organizations may not be considered external. These situations occur when, for example, there are pre-existing information exchange agreements (either implicit or explicit) established between organizations or components or when such agreements are specified by applicable laws, executive orders, directives, regulations, policies, or standards. Authorized individuals include organizational personnel, contractors, or other individuals with authorized access to organizational systems and over which organizations have the authority to impose specific rules of behavior regarding system access. Restrictions that organizations impose on authorized individuals need not be uniform, as the restrictions may vary depending on trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments.

External systems used to access public interfaces to organizational systems are outside the scope of AC-20. Organizations establish specific terms and conditions for the use of external systems in accordance with organizational security policies and procedures. At a minimum, terms and conditions address the specific types of applications that can be accessed on organizational systems from external systems and the highest security category of information that can be processed, stored, or transmitted on external systems. If the terms and conditions with the owners of the external systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.

Access Control Technical AC- 22 AC-22 Publicly Accessible Content a. Designate individuals authorized to make information publicly accessible;

b. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;

c. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and

1. [HHS or ACF] awareness and training 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 awareness and training policy and the associated awareness and training controls;

b. Designate an [either an HHS or ACF defined official] to manage the development, documentation, and dissemination of the awareness and training policy and procedures; and

c. Review and update the current awareness and training:

1. Policy [annually] and following [ACF-defined events]; and

1. As part of initial training for new users and [Annually] thereafter; and

2. When required by system changes or following [ACF-defined events];

b. Employ the following techniques to increase the security and privacy awareness of system users [phishing emails and other ACF defined techniques];

c. Update literacy training and awareness content [annually] and following [ACF-defined events]; and

d. Incorporate lessons learned from internal or external security incidents or breaches into literacy training and awareness techniques. Organizations provide basic and advanced levels of literacy training to system users, including measures to test the knowledge level of users. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework). The content includes an understanding of the need for security and privacy as well as actions by users to maintain security and personal privacy and to respond to suspected incidents. The content addresses the need for operations security and the handling of personally identifiable information.

Awareness techniques include displaying posters, offering supplies inscribed with security and privacy reminders, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events. Literacy training after the initial training described in AT-2a.1 is conducted at a minimum frequency consistent with applicable laws, directives, regulations, and policies. Subsequent literacy training may be satisfied by one or more short ad hoc sessions and include topical information on recent attack schemes, changes to organizational security and privacy policies, revised security and privacy expectations, or a subset of topics from the initial training. Updating literacy training and awareness content on a regular basis helps to ensure that the content remains relevant. Events that may precipitate an update to literacy training and awareness content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

1. Before authorizing access to the system, information, or performing assigned duties, and [annually] thereafter; and

2. When required by system changes;

b. Update role-based training content [annually] and following [ACF-defined events]; and

c. Incorporate lessons learned from internal or external security incidents or breaches into role-based training.

Reference:

Requirements for Role-Based Training of Personnel with Significant Security Responsibilities Organizations determine the content of training based on the assigned roles and responsibilities of individuals as well as the security and privacy requirements of organizations and the systems to which personnel have authorized access, including technical training specifically tailored for assigned duties. Roles that may require role-based training include senior leaders or management officials (e.g., head of agency/chief executive officer, chief information officer, senior accountable official for risk management, senior agency information security officer, senior agency official for privacy), system owners; authorizing officials; system security officers; privacy officers; acquisition and procurement officials; enterprise architects; systems engineers; software developers; systems security engineers; privacy engineers; system, network, and database administrators; auditors; personnel conducting configuration management activities; personnel performing verification and validation activities; personnel with access to system-level software; control assessors; personnel with contingency planning and incident response duties; personnel with privacy management responsibilities; and personnel with access to personally identifiable information.

Comprehensive role-based training addresses management, operational, and technical roles and responsibilities covering physical, personnel, and technical controls. Role-based training also includes policies, procedures, tools, methods, and artifacts for the security and privacy roles defined. Organizations provide the training necessary for individuals to fulfill their responsibilities related to operations and supply chain risk management within the context of organizational security and privacy programs. Role-based training also applies to contractors who provide services to federal agencies. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Updating role-based training on a regular basis helps to ensure that the content remains relevant and effective. Events that may precipitate an update to role-based training content include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

1. [HHS/ACF] audit and accountability 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 audit and accountability policy and the associated audit and accountability controls;

b. Designate an [ACF-defined official] to manage the development, documentation, and dissemination of the audit and accountability policy and procedures; and

c. Review and update the current audit and accountability:

1. Policy [annually] and following [the identification of evolving threats, issuance of new or significantly changed existing Federal laws, executive orders, directives, regulations, and HHS/ACF policies, identification of emerging technology and information technology service delivery models and determination that adjustments are deemed necessary to improve its effectiveness based upon feedback from the HHS/ACF System personnel]; and

[i. The following events must be identified within server audit logs:

• Server startup and shutdown;

• Loading and unloading of services;

• Installation and removal of software;

• System alerts and error messages;

• User logon and logoff (successful or unsuccessful);

• System administration activities;

• Accesses to sensitive information, files, and systems

• Account creation, modification, or deletion;

• Modifications of privileges and access controls; and,

• Additional security-related events, as required by the System Owner (SO) or to support the nature of the supported business and applications.

ii. The following events must be identified within application and database audit logs:

• Modifications to the application;

• Application alerts and error messages;

• User logon and logoff (successful or unsuccessful);

• System administration activities;

• Accesses to information and files

• Account creation, modification, or deletion; and,

• Modifications of privileges and access controls.

• (Moderate and High only) Read access to sensitive information

• (Moderate and High only) Modification to sensitive information

• (Moderate and High only) Printing sensitive information

iii. The following events must be identified within network device (e.g., router, firewall, switch, wireless access point) audit logs:

• Device startup and shutdown;

• Administrator logon and logoff (successful or unsuccessful);

• Configuration changes;

• Account creation, modification, or deletion;

• Modifications of privileges and access controls; and,

• System alerts and error messages.];

b. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;

c. Specify the following event types for logging within the system: [Unsuccessful log-on attempts that result in a locked account/node; Configuration changes; Application alerts and error messages; System administration activities; Modification of privileges and access; and Account creation, modification, or deletion];

d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and

e. Review and update the event types selected for logging [within every 365 days and whenever there is a significant system modification]. An event is an observable occurrence in a system. The types of events that require logging are those events that are significant and relevant to the security of systems and the privacy of individuals. Event logging also supports specific monitoring and auditing needs. Event types include password changes, failed logons or failed accesses related to systems, security or privacy attribute changes, administrative privilege usage, PIV credential usage, data action changes, query parameters, or external credential usage. In determining the set of event types that require logging, organizations consider the monitoring and auditing appropriate for each of the controls to be implemented. For completeness, event logging includes all protocols that are operational and supported by the system.

To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance. The types of events that organizations desire to be logged may change. Reviewing and updating the set of logged events is necessary to help ensure that the events remain relevant and continue to support the needs of the organization. Organizations consider how the types of logging events can reveal information about individuals that may give rise to privacy risk and how best to mitigate such risks. For example, there is the potential to reveal personally identifiable information in the audit trail, especially if the logging event is based on patterns or time of usage.

Event logging requirements, including the need to log specific event types, may be referenced in other controls and control enhancements. These include AC-2(4), AC-3(10), AC-6(9), AC-17(1), CM-3f, CM-5(1), IA-3(3)(b), MA-4(1), MP-4(2), PE-3, PM-21, PT-7, RA-8, SC-7(9), SC-7(15), SI-3(8), SI-4(22), SI-7(8), and SI-10(1). Organizations include event types that are required by applicable laws, executive orders, directives, policies, regulations, standards, and guidelines. Audit records can be generated at various levels, including at the packet level as information traverses the network.