1905 Identification and Authentication Policy

Georgia State Seal

Department of Human Services
Online Directives Information System

Index:

POL1905

Revised:

06/02/2025

Next Review:

06/02/2027

Subject: DHS Information Security Policies

Policy

This policy establishes the Enterprise Identification and Authentication Policy, for managing risks from user access (organizational, non-organizational) and authentication into company information assets through the establishment of an effective identification and authentication program. The identification and authentication program helps DHS implement security best practices with regards to identification and authentication into company information assets.

Authority

  1. United States Department of Commerce National Institute for Standards and Technology (NIST)

  2. United States Internal Revenue Service

  3. United States Department of Health & Human Services – Administration of Children and Families (ACF), Office of Child Support Services (OCSS)

  4. United States Department of Health & Human Services - Centers for Medicare & Medicaid Services (CMS)

  5. Georgia Technology Authority

  6. Social Security Administration

  7. Federal Bureau Investigation (Criminal Justice Information Services)

References

Applicability

The scope of this policy is applicable to all Information Technology (IT) resources owned or operated by DHS. Any information, not specifically identified as the property of other parties, that is transmitted or stored on DHS IT resources (including email, messages, and files) is the property of DHS. All users (DHS employees, contractors, vendors, or others) of IT resources are responsible for adhering to this policy.

Definitions

None

Responsibilities

DHS shall adopt the Identification and Authentication principles established in NIST SP 800-53 “Identification and Authentication,” Control Family guidelines, as the official policy for this domain. The following subsections outline the Identification and Authentication standards that constitute DHS policy. Each DHS Business System is then bound to this policy, and shall develop or adhere to a program plan which demonstrates compliance with the policy related to the standards documented.

IA-1 Identification and Authentication Policy and Procedures

  1. Develop, document, and disseminate to designated agency personnel:

    1. All organizational level identification and authentication policy that:

      1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

      2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

    2. Procedures to facilitate the implementation of the identification and authentication policy and the associated controls.

  2. Designate an agency official to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and

  3. Review and update the current identification and authentication:

    1. Policy every one (1) year (or if there is a significant change); and

    2. Procedures every one (1) year, (or when there is a significant change).

IA-2 Identification and Authentication (Organizational User)

  1. Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.

IA-2 (1) Multifactor Authentication to Privileged Accounts:

Implement multi-factor authentication for access to privileged accounts.

IA-2 (2) Multifactor Authentication to Non-Privileged Accounts:

Implement multi-factor authentication for access to non-privileged accounts.

IA-2 (5) Individual Authentication with Group Authentication:

When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.

IA-2 (6) Access to Accounts – Separate Device:

Implement multi-factor authentication for local, network, and remote access to privileged accounts and non-privileged accounts such that:

  1. One of the factors is provided by a device separate from the system gaining access; and

  2. The device meets Authenticator Assurance Level 2 (AAL) per NIST SP 800-63.

IA-2 (8) Access to Accounts – Replay Resistant:

Implement replay-resistant authentication mechanisms for access to privileged and non-privileged accounts with network access.

IA-3 Device Identification and Authentication

Uniquely identify and authenticate devices that require authentication mechanisms, which, at a minimum, use shared information (Media Access Control [MAC] or Internet Protocol [IP] address) and access control lists to control remote network access before establishing a local, remote or network connection.

IA-3 (1) Cryptographic Bidirectional Authentication:

Authenticate all devices before establishing a remote network connection using bidirectional authentication that is cryptographically based.

IA-4 Identifier Management

Manage system identifiers by:

  1. Receiving authorization from designated agency officials to assign an individual, group, role, service, or device identifier;

  2. Selecting an identifier that identifies an individual, group, role, service, or device;

  3. Assigning the identifier to the intended individual, group, role, service, or device; and

  4. Preventing reuse of identifiers indefinitely

IA-4 (4) Identify User Status:

Manage individual identifiers by uniquely identifying each individual as agency-defined characteristic identifying individual status (e.g., Contractor).

IA-5 Authenticator Management

Manage system authenticators by:

  1. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator;

  2. Establishing initial authenticator content for any authenticators issued by the organization;

  3. Ensuring that authenticators have sufficient strength of mechanism for their intended use;

  4. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators;

  5. Changing default authenticators prior to first use;

  6. Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators;

  7. Changing or refreshing authenticators:

    1. At least every 90 days for all user accounts

    2. At least every 366 days for service accounts or when authenticators:

    3. Are no longer valid in the event such as loss, theft or suspected compromise and requiring immediate change;or

    4. Must be changed immediately upon system installation (e.g., default or vendor-supplied passwords);

  8. Protecting authenticator content from unauthorized disclosure and modification;

  9. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and

  10. Changing authenticators for group or role accounts when membership to those accounts’ changes.

IA-5 (1) Password-Based Authentication:

For password-based authentication:

  1. Maintain a list of commonly-used, expected, or compromised passwords and update the list using a frequency defined in applicable security/privacy plans, but not to exceed one (1) year and when organizational passwords are suspected to have been compromised directly or indirectly.

    1. The list may include, but is not limited to:

      1. Passwords obtained from previous breach corpuses.

      2. Dictionary words.

      3. Repetitive or sequential characters (e.g., ‘aaaaaa’, ‘1234abcd’.)

      4. Context-specific words, such as the name of the service, the username, and derivatives thereof.

  2. Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);

    1. At least annually, change existing passwords found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);

  3. Transmit passwords only over cryptographically-protected channels;

  4. Store passwords using an approved salted key derivation function, preferably using a keyed hash;

  5. Require immediate selection of a new password upon account recovery;

  6. Allow user selection of long passwords and passphrases, including spaces and all printable characters;

  7. Employ automated tools to assist the user in selecting strong password authenticators; and

  8. Enforce the following composition and complexity rules:

    1. Enforce minimum password length of fourteen (15) characters.

    2. Enforce password lifetime restrictions:

      1. Service accounts passwords shall expire within 180 days (inclusive).

    3. Password History/Reuse:

      1. For all systems: 24 generations.

      2. For systems unable to implement history/reuse restriction by generations but are able to restrict history/reuse for a specified time period, passwords shall not be reusable for a period of six (6) months.

IRS.1:

Train users not to use a single dictionary word as their password.

IRS.2:

For IT devices using a personal identification number (PIN) as an authenticator for MFA, enforce the following requirements:

  1. Minimum length of eight (8) digits. If the system does not enforce a minimum length of 8 digits, the maximum length possible must be used;

  2. Enforce complex sequences (e.g., 73961548 – no repeating digits and no sequential digits);

  3. Do not store with the SmartCard; and

  4. Do not share.

IA-5 (2) Public Key-Based Authentication:

  1. For public key-based authentication:

    1. Enforce authorized access to the corresponding private key; and

    2. Map the authenticated identity to the account of the individual or group; and

  2. When public key infrastructure (PKI) is used:

    1. Validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information; and

    2. Implement a local cache of revocation data to support path discovery and validation.

IA-5 (5) Change Authenticators Prior to Delivery:

Require developers and installers of system components to provide unique authenticators or change default authenticators prior to delivery and installation.

IA-5 (6) Protection of Authenticators:

Protect authenticators commensurate with the security category of the information to which use of the authenticator permits access.

IA-5 (7) No Embedded Unencrypted Static Authenticators:

Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.

IA-5 (12) Biometric Authentication Performance:

For biometric-based authentication, employ mechanisms that satisfy the following biometric quality requirements defined in NIST SP 800-63.

IA-6 Authenticator Feedback

Obscure feedback of authentication information during the authentication process to protect the information from possible exploitation and use by unauthorized individuals.

IA-7 Cryptographic Module Authentication

Implement mechanisms for authentication to a cryptographic module that meet the requirements of applicable laws, executive orders, directives, policies, regulations, standards, and guidelines for such authentication.

IA-8 Identification and Authentication (Non-Organizational Users)

Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.

IA-8 (1) Acceptance of PIV Credentials From Other Agencies

Accept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.

IA-8 (2) Acceptance of External Credentials:

  1. Accept only external authenticators that are NIST-compliant; and

  2. Document and maintain a list of accepted external authenticators.

IA-8 (4) Use of Defined Profiles:

Conform to the following profiles for identity management: NIST or FICAM-issued profiles.

IRS.1:

Deploy identification and authentication technology consistent with the results of the e-authentication risk analysis.

IA-9: Service Identification and Authentication

Uniquely identify and authenticate agency-defined system services and applications before establishing communications with devices, users, or other services or applications.

IA-11: Re-Authentication

Require users to re-authenticate when switching to a privileged user role.

IA-12: Identity Proofing

  1. Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines;

  2. Resolve user identities to a unique individual; and

  3. Collect, validate, and verify identity evidence.

IA-12 (1) Supervisor Authorization:

Require that the registration process to receive an account for logical access includes supervisor or sponsor authorization.

IA-12 (2) Identity Evidence:

Require evidence of individual identification be presented to the registration authority.

IA-12 (3) Identity Evidence Validation and Verification:

Require that the presented identity evidence be validated and verified through NIST SP 800-63 compliant methods of validation and verification.

IA-12 (5) Address Confirmation:

Require that a registration code or notice of proofing be delivered through an out-of-band channel to verify the users address (physical or digital) of record. == History

Date Change User Version

Evaluation

The Office of Information Technology (OIT), upon recommendation of the DHS Chief Information Security Officer (CISO), evaluates this policy annually by:

  1. Comparing its content and intent to evolving regulatory compliance standards imposed upon the Agency, such as, IRS 1075, NIST 800-53, and CMS MARS-E.

  2. Addressing any deficiencies or gaps discovered during periodic audits conducted by Georgia DOAA or other regulatory bodies, such as, IRS, CMS, SSA, FBI, etc.