How Identity and Access Management Supports the CJIS Security Policy

Account Management

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require conditions 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 attributes listed for each account; [attribute table omitted]

e. Require approvals by organizational personnel with account management responsibilities for requests to create accounts;

f. Create, enable, modify, disable, and remove accounts in accordance with agency policy;

g. Monitor the use of accounts;

h. Notify account managers and system/network administrators within:

1. One day when accounts are no longer required;

2. One day when users are terminated or transferred; and

3. One day 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. Attributes as listed in AC-2(d)(3);

j. Review accounts for compliance with account management requirements at least annually;

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.

In practice: Each account type is defined and owned, group and role requests go through an approval workflow, and staff access is reviewed at least once a year. The identity platform automates the account lifecycle in between.

Account Management | Automated System Account Management

Support the management of system accounts using automated mechanisms including email, phone, and text notifications.

In practice: Joiner, mover and leaver events trigger account changes automatically, and email, phone or text notices go to the account owner and the security team when an account changes.

Account Management | Automated Temporary and Emergency Account Management

Automatically remove temporary and emergency accounts within 72 hours.

In practice: A temporary or emergency account is created with an expiry, and the platform removes it within 72 hours, so a short-term fix does not turn into a standing account.

Account Management | Disable Accounts

Disable accounts within one (1) week when the accounts:

a. Have expired;

b. Are no longer associated with a user or individual;

c. Are in violation of organizational policy; or

d. Have been inactive for 90 calendar days.

In practice: A routine report lists expired, orphaned and 90-day inactive accounts, and the help desk disables each one within a week of it showing up on the list.

Account Management | Automated Audit Actions

Automatically audit account creation, modification, enabling, disabling, and removal actions.

In practice: Account creation, changes, disabling and removal are logged automatically, so an analyst can trace any change on an account without asking an administrator.

Account Management | Disable Accounts for High-Risk Individuals

Disable accounts of individuals within 30 minutes of discovery of direct threats to the confidentiality, integrity, or availability of CJI.

In practice: When the security team finds a direct threat to criminal justice information, a runbook lets the help desk disable the person's accounts within 30 minutes through the identity platform.

Access Enforcement

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

In practice: People receive access to criminal justice systems through roles that were requested and signed off. The sign-in service refuses applications the person is not assigned to, and each application enforces the role inside it.

Separation of Duties

a. Identify and document separation of duties based on specific duties, operations, or information systems, as necessary, to mitigate risk to CJI; and

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

In practice: Request rules keep one person from holding conflicting duties, and a report lists any overlaps so a manager can correct them before they cause risk to criminal justice information.

Least Privilege

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

In practice: Staff get roles that match their work, and managers confirm those roles are still needed. Administrator rights are granted only when required, and shared administrator credentials are checked out from a privileged access vault.

Least Privilege | Authorize Access to Security Functions

Authorize access for personnel including security administrators, system and network administrators, and other privileged users with access to system control, monitoring, or administration functions (e.g., system administrators, information security personnel, maintainers, system programmers, etc.) to:

a. Established system accounts, configured access authorizations (i.e., permissions, privileges), set events to be audited, set intrusion detection parameters, and other security functions; and

b. Security-relevant information in hardware, software, and firmware.

In practice: Access for administrators of security and network tools is its own role, granted only after a documented request and sign-off, and removed when the duty ends.

Least Privilege | Non-Privileged Access for Nonsecurity Functions

Require that users of system accounts (or roles) with access to privileged security functions or security-relevant information (e.g., audit logs), use non-privileged accounts or roles, when accessing non-security functions.

In practice: People who administer security tools use a separate everyday account for email and ordinary work, so a mistake in the everyday account does not expose administrator rights.

Least Privilege | Privileged Accounts

Restrict privileged accounts on the system to privileged users.

In practice: A privileged account inventory lists each account with a named holder, and only people with an authorized administrator role can have one. Extras get removed.

Least Privilege | Review of User Privileges

a. Review annually the privileges assigned to non-privileged and privileged users to validate the need for such privileges; and

b. Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

In practice: Each year, managers and system owners confirm whether each person's regular and privileged access is still needed. Removals are carried out and the decisions are saved in a campaign record.

Least Privilege | Log Use of Privileged Functions

Log the execution of privileged functions.

In practice: Privileged sessions are recorded or logged, showing who ran administrator functions, on which system and at what time, so the security team can review that history.

Unsuccessful Logon Attempts

a. Enforce a limit of five (5) consecutive invalid logon attempts by a user during a 15-minute time period; and

b. Automatically lock the account or node until released by an administrator when the maximum number of unsuccessful attempts is exceeded.

In practice: The directory locks an account after five failed sign-ins in 15 minutes and keeps it locked until an administrator releases it, usually after the help desk verifies the caller.

Remote Access

a. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and

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

In practice: Each type of remote access is written down and authorized before use. The sign-in service applies those rules and requires MFA for remote sign-ins.

Identification and Authentication (Organizational Users)

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

In practice: Each employee signs in with their own named account through a single sign-on service, so every action in an application can be traced to one person.

Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Privileged Accounts

Implement multi-factor authentication for access to privileged accounts.

In practice: Administrators and other privileged users add a second sign-in step, like a security key or authenticator prompt, each time they open a privileged account.

Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Non-Privileged Accounts

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

In practice: Ordinary users also get a second sign-in step, such as a phone prompt, when they reach systems with criminal justice information. The identity team enrolls users and keeps the rule turned on.

Identification and Authentication (Organizational Users) | Access to Accounts, Replay Resistant

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

In practice: Sign-in uses replay-resistant methods, such as one-time passcodes or, more strongly, hardware keys and other phishing-resistant authenticators, for both administrators and regular users.

Identifier Management

Manage system identifiers by:

a. Receiving authorization from organizational personnel with identifier management responsibilities to assign an individual, group, role, service, or device identifier;

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

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

d. Preventing reuse of identifiers for one (1) year.

In practice: HR-driven onboarding assigns each person a unique ID after authorized sign-off. The ID is not reused for at least one year, and each service account or device gets its own identifier.

Authenticator Management

Manage system authenticators by:

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

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

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

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

e. Changing default authenticators prior to first use;

f. Changing or refreshing memorized secret authenticators annually or when there is evidence of authenticator compromise; changing or refreshing all other authenticator types as they expire or when there is evidence of authenticator compromise;

g. Protecting authenticator content from unauthorized disclosure and modification;

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

i. Changing authenticators for group or role accounts when membership to those accounts changes. [items j through o omitted: AAL2 specific requirements, privacy requirements, general AAL2 requirements, biometric requirements, authenticator binding and session management]

In practice: Credentials are issued only after the person's identity is checked. Passwords and keys for services are stored in a vault, rotated on a schedule, and phishing-resistant methods are encouraged.

Authenticator Management | Public Key Based Authentication

(a) 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

(b) 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.

In practice: Where staff or servers sign in with certificates or keys, each key pair is tied to one named person or service, and the private key's access is limited to that owner.

Identification and Authentication (Non-Organizational Users)

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

In practice: Staff of partner agencies and other non-organizational users sign in with their own identities through federation, so each outside user is individually identified and nobody shares a login.

Identification and Authentication (Non-Organizational Users) | Acceptance of External Authenticators

(a) Accept only external authenticators that are NIST-compliant; and

(b) Document and maintain a list of accepted external authenticators.

In practice: For a public-facing system, a written list records which outside authenticators the agency accepts, and the identity team updates it when the accepted list changes.

Identification and Authentication (Non-Organizational Users) | Use of Defined Profiles

Conform to the following profiles for identity management: Security Assertion Markup Language (SAML) or OpenID Connect.

In practice: Applications connect to outside partners using SAML or OpenID Connect, the two profiles the requirement names, and the integration team records which application uses which.

Re-Authentication

Require users to re-authenticate when: roles, authenticators, or credentials change, security categories of systems change, the execution of privileged functions occur, or every 12 hours.

In practice: Users must sign in again when they change roles, switch to a privileged function, or have been signed in for 12 hours, and the sign-in service applies those timers.

Identity Proofing

a. 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;

b. Resolve user identities to a unique individual; and

c. Collect, validate, and verify identity evidence.

In practice: HR checks a new hire's identity. The onboarding workflow then ties the new account to that one verified person and flags any duplicate or unmatched account.

Personnel Termination

Upon termination of individual employment:

a. Disable system access within twenty-four (24) hours;

b. Terminate or revoke any authenticators and credentials associated with the individual;

c. Conduct exit interviews that include a discussion of non-disclosure of CJI and PII;

d. Retrieve all security-related organizational system-related property; and

e. Retain access to organizational information and systems formerly controlled by terminated individual.

In practice: When HR records a termination, the leaver workflow disables the person's accounts within 24 hours and revokes their credentials, with a log entry for each step.

Personnel Transfer

a. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;

b. Initiate appropriate actions such as closing and establishing accounts and changing system access authorizations within twenty-four (24) hours;

c. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and

d. Notify organizational personnel with information security responsibilities, organizational personnel with personnel security responsibilities, system/network administrators, and organizational personnel with account management responsibilities prior to personnel transfer.

In practice: When someone moves to a new role, the new manager gets a task to confirm which existing access still applies, and anything no longer needed is removed.

Advanced Authentication

When accessing CJI from an authorized mobile device, advanced authentication shall be used by the authorized user unless the access to CJI is indirect as described in Identification and Authentication (IA). If access is indirect, then AA is not required.

In practice: The mobile device team owns the device setup. Identity contributes by requiring a strong second sign-in factor when staff open criminal justice information from an authorized phone or tablet.

Session Termination

Automatically terminate a user session after a user has been logged out.

In practice: The security team owns session behavior. Identity contributes by configuring single logout on the single sign-on service, so signing out also ends the session in connected applications that support it.

Use of External Systems

a. Establish agency-level policies governing the use of 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 personally-owned information systems including mobile devices (i.e., bring your own device [BYOD]) and publicly accessible systems for accessing, processing, storing, or transmitting CJI.

In practice: The agency sets the rules for outside systems and personal devices. Identity adds device-aware sign-in rules that allow or block access depending on whether the device is registered and managed.

Event Logging

a. Identify the types of events that the system is capable of logging in support of the audit function: authentication, file use, user/group management, events sufficient to establish what occurred, the sources of events, outcomes of events, and operational transactions (e.g., NCIC, III);

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:

All successful and unsuccessful:

1. System log-on attempts

2. Attempts to use:

a. Access permission on a user account, file, directory, or other system resource;

b. Create permission on a user account, file, directory, or other system resource;

c. Write permission on a user account, file, directory, or other system resource;

d. Delete permission on a user account, file, directory, or other system resource;

e. Change permission on a user account, file, directory, or other system resource.

3. Attempts to change account passwords

4. Actions by privileged accounts (i.e., root, Oracle, DBA, admin, etc.)

5. Attempts for users to:

a. Access the audit log file;

b. Modify the audit log file;

c. Destroy the audit log file.

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

In practice: The security team chooses which events to log. Identity contributes by turning on logging for sign-ins, group changes and privileged actions on the identity platform.

Content of Audit Records

Ensure that audit records contain information that establishes the following:

a. What type of event occurred;

b. When the event occurred;

c. Where the event occurred;

d. Source of the event;

e. Outcome of the event; and

f. Identity of any individuals, subjects, or objects/entities associated with the event.

In practice: System owners decide what audit records contain; each identity log entry adds what happened, when, where, the source, the result and which named account was involved.

Audit Record Review, Analysis, and Reporting

a. Review and analyze system audit records weekly for indications of inappropriate or unusual activity and the potential impact of the inappropriate or unusual activity;

b. Report findings to organizational personnel with audit review, analysis, and reporting responsibilities and organizational personnel with information security and privacy responsibilities; and

c. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

In practice: The security team reviews logs weekly and reports findings. Identity logs supply sign-in and permission-change records, and alerts point reviewers to unusual account activity.

Audit Record Generation

a. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on all systems generating required audit logs;

b. Allow organizational personnel with audit record generation responsibilities, organizational personnel with information security and privacy responsibilities, and system/network administrators to select the event types that are to be logged by specific components of the system; and

c. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

In practice: System owners enable audit logging on their systems; identity contributes by switching on log generation across the identity systems so account and sign-in events are captured.

Policy and Procedures

a. Develop, document, and disseminate to authorized personnel:

1. Agency/Entity identification and authentication 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 identification and authentication policy and the associated identification and authentication controls;

b. Designate organizational personnel with information security responsibilities to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and

c. Review and update the current identification and authentication:

1. Policy annually and following any security incidents involving unauthorized access to CJI or systems used to process, store, or transmit CJI; and

2. Procedures annually and following any security incidents involving unauthorized access to CJI or systems used to process, store, or transmit CJI.

In practice: The agency keeps a written sign-in policy with an owner and a review cycle. An assessment of the current identity setup gives the policy writers an accurate picture of what exists.

Identification and Authentication (Organizational Users) | Acceptance of PIV Credentials

Accept and electronically verify Personal Identity Verification-compliant credentials.

In practice: The security team decides which smart cards are accepted; the sign-in service checks each card's certificate electronically and links it to the holder's named account.

Device Identification and Authentication

Uniquely identify and authenticate agency-managed devices before establishing network connections. In the instance of local connection, the device must be approved by the agency and the device must be identified and authenticated prior to connection to an agency asset.

In practice: Agency laptops and other managed devices are registered and hold a certificate, and the network checks that certificate before it lets the device connect. The network team owns that check.

Authenticator Management | Protection of Authenticators

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

In practice: System owners set protection levels by data category; identity contributes a vault with limited access for privileged and service account passwords, keys and tokens.

Identification and Authentication (Non-Organizational Users) | Acceptance of PIV Credentials From Other Agencies

Accept and electronically verify Personal Identity Verification-compliant credentials from other federal, state, local, tribal, or territorial (SLTT) agencies.

In practice: Another agency's staff can use their own smart card to reach shared systems. The security team sets up the federation trust, and the sign-in service verifies the credential.

Personnel Screening

a. Screen individuals prior to authorizing access to the information system; [items a.1 through a.7 and b omitted: record check, access approval and access list requirements, and rescreening]

In practice: HR owns background screening. The onboarding workflow does not grant access to systems with criminal justice information until HR marks the person's screening as done.

External Personnel Security

a. Establish personnel security requirements, including security roles and responsibilities for external providers;

b. Require external providers to comply with personnel security policies and procedures established by the organization;

c. Document personnel security requirements;

d. Require external providers to notify organizational personnel with information security responsibilities, organizational personnel with personnel security responsibilities, system/network administrators, or organizational personnel with account management responsibilities of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within twenty-four (24) hours; and

e. Monitor provider compliance with personnel security requirements.

In practice: The agency sets security rules for providers; identity gives contractors and vendors sponsored accounts with an end date, re-confirmed by the sponsor and closed when the contract ends.

System Use Notification

a. Display a system use notification message to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

1. Users are accessing a restricted information 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 consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines, 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

3. Include a description of the authorized uses of the system.

Device Lock

a. Prevent further access to the system by initiating a device lock after a maximum of 30 minutes of inactivity and requiring the user to initiate a device lock before leaving the system unattended.

NOTE: In the interest of safety, devices that are: (1) part of a criminal justice conveyance; or (2) used to perform dispatch functions and located within a physically secure location; or (3) terminals designated solely for the purpose of receiving alert notifications (i.e., receive only terminals or ROT) used within physically secure location facilities that remain staffed when in operation, are exempt from this requirement.

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.