IA – Identification and Authentication

NIST SP 800-53 Rev. 5 – IA – Identification and Authentication

1.Kravtext (engelskt original)#

IA-1 – Policy and Procedures#

• a. Develop, document, and disseminate to [organization-defined personnel or roles]:
  • 1. [organization-level or mission/business process-level or system-level] 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 an [organization-defined official] 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 [organization-defined frequency] and following [organization-defined events] ; and
  • 2. Procedures [organization-defined frequency] and following [organization-defined events].

IA-2 – Identification and Authentication (Organizational Users)#

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

IA-2(1) – Multi-factor Authentication to Privileged Accounts

Implement multi-factor authentication for access to privileged accounts.

IA-2(2) – Multi-factor Authentication to Non-privileged Accounts

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

IA-2(3) – Local Access to Privileged Accounts

IA-2(4) – Local 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 or network or remote] access to [privileged accounts or non-privileged accounts] such that:

• (a) One of the factors is provided by a device separate from the system gaining access; and
• (b) The device meets [organization-defined strength of mechanism requirements].

IA-2(7) – Network Access to Non-privileged Accounts — Separate Device

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

Implement replay-resistant authentication mechanisms for access to [privileged accounts or non-privileged accounts].

IA-2(9) – Network Access to Non-privileged Accounts — Replay Resistant

IA-2(10) – Single Sign-on

Provide a single sign-on capability for [organization-defined system accounts and services].

IA-2(11) – Remote Access — Separate Device

IA-2(12) – Acceptance of PIV Credentials

Accept and electronically verify Personal Identity Verification-compliant credentials.

IA-2(13) – Out-of-band Authentication

Implement the following out-of-band authentication mechanisms under [organization-defined conditions]: [organization-defined out-of-band authentication].

IA-3 – Device Identification and Authentication#

Uniquely identify and authenticate [organization-defined devices and/or types of devices] before establishing a [local or remote or network] connection.

IA-3(1) – Cryptographic Bidirectional Authentication

Authenticate [organization-defined devices and/or types of devices] before establishing [local or remote or network] connection using bidirectional authentication that is cryptographically based.

IA-3(2) – Cryptographic Bidirectional Network Authentication

IA-3(3) – Dynamic Address Allocation

• (a) Where addresses are allocated dynamically, standardize dynamic address allocation lease information and the lease duration assigned to devices in accordance with [organization-defined lease information and lease duration] ; and
• (b) Audit lease information when assigned to a device.

IA-3(4) – Device Attestation

Handle device identification and authentication based on attestation by [organization-defined configuration management process].

IA-4 – Identifier Management#

Manage system identifiers by:

• a. Receiving authorization from [organization-defined personnel or roles] 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 [organization-defined time period].

IA-4(1) – Prohibit Account Identifiers as Public Identifiers

Prohibit the use of system account identifiers that are the same as public identifiers for individual accounts.

IA-4(2) – Supervisor Authorization

IA-4(3) – Multiple Forms of Certification

IA-4(4) – Identify User Status

Manage individual identifiers by uniquely identifying each individual as [organization-defined characteristics].

IA-4(5) – Dynamic Management

Manage individual identifiers dynamically in accordance with [organization-defined dynamic identifier policy].

IA-4(6) – Cross-organization Management

Coordinate with the following external organizations for cross-organization management of identifiers: [organization-defined external organizations].

IA-4(7) – In-person Registration

IA-4(8) – Pairwise Pseudonymous Identifiers

Generate pairwise pseudonymous identifiers.

IA-4(9) – Attribute Maintenance and Protection

Maintain the attributes for each uniquely identified individual, device, or service in [organization-defined protected central storage].

IA-5 – 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 authenticators [organization-defined time period by authenticator type] or when [organization-defined events] occur;
• 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.

IA-5(1) – Password-based Authentication

For password-based authentication:

• (a) Maintain a list of commonly-used, expected, or compromised passwords and update the list [organization-defined frequency] and when organizational passwords are suspected to have been compromised directly or indirectly;
• (b) 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);
• (c) Transmit passwords only over cryptographically-protected channels;
• (d) Store passwords using an approved salted key derivation function, preferably using a keyed hash;
• (e) Require immediate selection of a new password upon account recovery;
• (f) Allow user selection of long passwords and passphrases, including spaces and all printable characters;
• (g) Employ automated tools to assist the user in selecting strong password authenticators; and
• (h) Enforce the following composition and complexity rules: [organization-defined composition and complexity rules].

IA-5(2) – 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.

IA-5(3) – In-person or Trusted External Party Registration

IA-5(4) – Automated Support for Password Strength Determination

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(8) – Multiple System Accounts

Implement [organization-defined security controls] to manage the risk of compromise due to individuals having accounts on multiple systems.

IA-5(9) – Federated Credential Management

Use the following external organizations to federate credentials: [organization-defined external organizations].

IA-5(10) – Dynamic Credential Binding

Bind identities and authenticators dynamically using the following rules: [organization-defined binding rules].

IA-5(11) – Hardware Token-based Authentication

IA-5(12) – Biometric Authentication Performance

For biometric-based authentication, employ mechanisms that satisfy the following biometric quality requirements [organization-defined biometric quality requirements].

IA-5(13) – Expiration of Cached Authenticators

Prohibit the use of cached authenticators after [organization-defined time period].

IA-5(14) – Managing Content of PKI Trust Stores

For PKI-based authentication, employ an organization-wide methodology for managing the content of PKI trust stores installed across all platforms, including networks, operating systems, browsers, and applications.

IA-5(15) – GSA-approved Products and Services

Use only General Services Administration-approved products and services for identity, credential, and access management.

IA-5(16) – In-person or Trusted External Party Authenticator Issuance

Require that the issuance of [organization-defined types of and/or specific authenticators] be conducted [in person or by a trusted external party] before [organization-defined registration authority] with authorization by [organization-defined personnel or roles].

IA-5(17) – Presentation Attack Detection for Biometric Authenticators

Employ presentation attack detection mechanisms for biometric-based authentication.

IA-5(18) – Password Managers

• (a) Employ [organization-defined password managers] to generate and manage passwords; and
• (b) Protect the passwords using [organization-defined controls].

IA-6 – Authentication 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 Authenticators

• (a) Accept only external authenticators that are NIST-compliant; and
• (b) Document and maintain a list of accepted external authenticators.

IA-8(3) – Use of FICAM-approved Products

IA-8(4) – Use of Defined Profiles

Conform to the following profiles for identity management [organization-defined identity management profiles].

IA-8(5) – Acceptance of PIV-I Credentials

Accept and verify federated or PKI credentials that meet [organization-defined policy].

IA-8(6) – Disassociability

Implement the following measures to disassociate user attributes or identifier assertion relationships among individuals, credential service providers, and relying parties: [organization-defined measures].

IA-9 – Service Identification and Authentication#

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

IA-9(1) – Information Exchange

IA-9(2) – Transmission of Decisions

IA-10 – Adaptive Authentication#

Require individuals accessing the system to employ [organization-defined supplemental authentication techniques or mechanisms] under specific [organization-defined circumstances or situations].

IA-11 – Re-authentication#

Require users to re-authenticate when [organization-defined circumstances or situations].

IA-12 – 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.

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 [organization-defined methods of validation and verification].

IA-12(4) – In-person Validation and Verification

Require that the validation and verification of identity evidence be conducted in person before a designated registration authority.

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.

IA-12(6) – Accept Externally-proofed Identities

Accept externally-proofed identities at [organization-defined identity assurance level].

IA-13 – Identity Providers and Authorization Servers#

Employ identity providers and authorization servers to manage user, device, and non-person entity (NPE) identities, attributes, and access rights supporting authentication and authorization decisions in accordance with [organization-defined policy] using [organization-defined mechanisms].

IA-13(1) – Protection of Cryptographic Keys

Cryptographic keys that protect access tokens are generated, managed, and protected from disclosure and misuse.

IA-13(2) – Verification of Identity Assertions and Access Tokens

The source and integrity of identity assertions and access tokens are verified before granting access to system and information resources.

IA-13(3) – Token Management

In accordance with [organization-defined value], assertions and access tokens are:

• (a) generated;
• (b) issued;
• (c) refreshed;
• (d) revoked;
• (e) time-restricted; and
• (f) audience-restricted.

National Institute of Standards and Technology, OSCAL release 5.2.0. Republished courtesy of the National Institute of Standards and Technology. CC0 1.0. Source.