Identification and authentication

Table of Contents

On this page

 

The controls and activities in the Identification and authentication (IA) family support the unique identification of users, processes acting on behalf of users and devices. They also support the authentication or verification of the identities of those users, processes or devices as a prerequisite to allowing access to organizational systems.

IA-01 Identification and authentication policy and procedures

Activity

  1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]
    1. [Selection (1 or more): Organization-level; Mission/business process-level; System-level] identification and authentication (IA) policy that
      1. addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance
      2. is consistent with applicable laws, jurisprudence, Orders in Council, directives, regulations, policies, standards, and guidelines
    2. procedures to facilitate the implementation of the identification and authentication policy and the associated identification and authentication controls
  2. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the identification and authentication policy and procedures
  3. Review and update the current identification and authentication
    1. policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]
    2. procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]

Discussion

Identification and authentication policy and procedures address the controls in the IA 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 identification and authentication policy and procedures.

In general, security and privacy program policies and procedures at the organization level are preferable and may remove 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 that reflect 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 identification and authentication policy and procedures include assessment or audit findings, security incidents or breaches, including those related to privacy, or changes in applicable laws, jurisprudence, Orders in Council, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.

Under PIPEDA, there is a carve-out in the legislation that states that names and contact information of individuals at work are not considered to be personal information.

GC discussion

Under the federal Privacy Act, individuals’ names or contact information at work is defined as personal information. For example, if non-organizational users rely on email addresses as part of their credentials, this would be a collection of personal information, with the associated controls required.

Related controls and activities

AC-01, PM-09, PS-08, SI-02, SI-12.

Enhancements

None.

References

Top of page 
 

IA-02 Identification and authentication (organizational users)

Control

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

Discussion

Organizational users include employees or individuals whom organizations consider to be of an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in AC-14 and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity.

Organizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication (MFA), some combination thereof. Identity credentials and biometric authenticators may, at times, be considered personal information. Consideration of the privacy concept of necessity versus proportionality requires that organizations collect just enough personal information required to ensure accurate authentication.

Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., non-local accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks.

The use of encrypted VPNs for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in IA-08.

GC discussion

Organizations can satisfy the identification and authentication requirements by complying with the requirements set by TBS.

Related controls and activities

AC-02, AC-03, AC-04, AC-14, AC-17, AC-18, AU-01, AU-06, IA-04, IA-05, IA-08, IA-13, MA-04, MA-05, PE-02, PL-04, SA-04, SA-08.

Enhancements

  • (01) Identification and authentication (organizational users): Strong MFA to privileged accounts
    • Implement strong MFA for access to privileged accounts.
    • Discussion: MFA requires the use of 2 or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a personal identification number (PIN)), something you have (e.g., a physical authenticator such as a cryptographic private key), or something you are (e.g., a biometric).
      MFA solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may employ authentication mechanisms at the application level, at their discretion, to provide increased security. Regardless of the type of access (i.e., local, network, remote), privileged accounts are authenticated using multi-factor options appropriate for the level of risk. Organizations can add additional security measures, such as additional or more rigorous authentication mechanisms, for specific types of access.
    • GC discussion: In the GC, privileged users should have Level of Assurance 4 (LoA4) MFA.
    • Related controls and activities: AC-05, AC-06.
  • (02) Identification and authentication (organizational users): MFA to non-privileged accounts
    • Implement MFA for access to non-privileged accounts.
    • Discussion: MFA requires the use of 2 or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a PIN), something you have (e.g., a physical authenticator such as a cryptographic private key), or something you are (e.g., a biometric).
      MFA solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards. In addition to authenticating users at the system level, organizations may also employ authentication mechanisms at the application level, at their discretion, to provide increased information security. Regardless of the type of access (i.e., local, network, remote), non-privileged accounts are authenticated using multi-factor options appropriate for the level of risk. Organizations can provide additional security measures, such as additional or more rigorous authentication mechanisms, for specific types of access.
    • GC discussion: In the GC, non-privileged users should have a minimum Level of Assurance 3 (LoA3) MFA.
    • Related controls and activities: AC-05.
  • (03) Identification and authentication (organizational Users): Local access to privileged accounts
    • Withdrawn: Incorporated into IA-02(01).
  • (04) Identification and authentication (organizational users): Local access to non-privileged accounts
    • Withdrawn: Incorporated into IA-02(02).
  • (05) Identification and authentication (organizational users): 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.
    • Discussion: Individual authentication prior to shared group authentication mitigates the risk of using group accounts or authenticators.
    • Related controls and activities: None.
  • (06) Identification and authentication (organizational users): Access to accounts — separate device
    • Implement MFA for [Selection (1 or more): local; network; remote] access to [Selection (1 or more): privileged accounts; non-privileged accounts] such that
      1. one of the factors is provided by a device separate from the system gaining access
      2. the device meets [Assignment: organization-defined strength of mechanism requirements]
    • Discussion: The purpose of requiring a device that is separate from the endpoint physical host through which the user is attempting to gain access as one of the factors during MFA is to reduce the likelihood of compromising the required secrets for authentication.
      Adversaries may have endpoint-focused exploits to be able to compromise such secrets and subsequently impersonate authorized users. Implementing one of the factors on a separate device (e.g., a hardware token), provides a greater strength of mechanism and an increased level of assurance in the authentication process by requiring heterogeneous exploits to simultaneously compromise the secrets processed by the endpoint and by the separate device.
      At times, the use of a separate device may involve the collection of personal information such as biometrics. Consideration of the privacy concept of necessity versus proportionality requires that organizations collect just enough personal information required to ensure accurate authentication.
    • Related controls and activities: AC-06.
  • (07) Identification and authentication (organizational users): Network access to non-privileged accounts — separate device
    • Withdrawn: Incorporated into IA-02(06).
  • (08) Identification and authentication (organizational users): Access to accounts — replay resistant
    • Implement replay-resistant authentication mechanisms for access to [Selection (1 or more): privileged accounts; non-privileged accounts].
    • Discussion: Authentication processes resist replay attacks if it is impractical to achieve successful authentications by replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges such as time-synchronous or cryptographic authenticators.
    • Related controls and activities: None.
  • (09) Identification and authentication (organizational users): Network access to non-privileged accounts — replay resistant
    • Withdrawn: Incorporated into IA-02(08).
  • (10) Identification and authentication (organizational users): Single sign-on
    • Provide a single sign-on capability for [Assignment: organization-defined system accounts and services].
    • Discussion: Single sign-on enables users to login once and gain access to multiple system resources. Organizations consider the operational efficiencies provided by single sign-on capabilities with the risk introduced by allowing access to multiple systems via a single authentication event. Single sign-on can present opportunities to improve system security, for example by providing the ability to add MFA for applications and systems (existing and new) that may not be able to natively support MFA.
    • Related controls and activities: None.
  • (11) Identification and authentication (organizational users): Remote access — separate device
    • Withdrawn: Incorporated into IA-02(06).
  • (12) Identification and authentication (organizational users): Use of hardware token GC-issued PKI-based credentials
    • Accept and electronically verify GC-issued hardware token public key infrastructure (PKI)-based credentials.
    • Discussion: None.
    • GC discussion: It is recommended that GC-issued hardware token PKI-based credentials apply to organizations implementing logical access control and physical access control systems. At times, these credentials may contain personal information. Consideration of the privacy concept of necessity versus proportionality requires that organizations collect just enough personal information required to ensure accurate authentication.
    • Related controls and activities: None.
  • (13) Identification and authentication (organizational users): Out-of-band authentication
    • Implement the following out-of-band authentication mechanisms under [Assignment: organization-defined conditions]: [Assignment: organization-defined out-of-band authentication].
    • Discussion: Out-of-band authentication refers to the use of 2 separate communication paths to identify and authenticate users or devices to an information system. The first path (i.e., the in-band path) is used to identify and authenticate users or devices and is generally the path through which information flows. The second path (i.e., the out-of-band path) is used to independently verify the authentication and/or requested action.
      For example, a user authenticates via a notebook computer to a remote server to which the user desires access and requests some action of the server via that communication path. Subsequently, the server contacts the user via the user’s cell phone to verify that the requested action originated from the user. The user may confirm the intended action to an individual on the telephone or provide an authentication code via the telephone.
      Out-of-band authentication can be used to mitigate actual or suspected adversary-in-the-middle attacks. The conditions or criteria for activation include suspicious activities, new threat indicators, elevated threat levels, or the impact or classification level of information in requested transactions.
    • Related controls and activities: IA-10, IA-11, SC-37.
  • (400) Identification and authentication (organizational users): MFA for remote access to privileged accounts
    • Withdrawn: Incorporated into IA-02(01) and IA-02(06).

References

Top of page 
 

IA-03 Device identification and authentication

Control

Uniquely identify and authenticate [Assignment: organization-defined devices and/or types of devices] before establishing a [Selection (1 or more): local; remote; network] connection.

Discussion

Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., MAC or Transmission Control Protocol/Internet Protocol (TCP/IP) addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible Authentication Protocol (EAP), RADIUS server with EAP-TLS authentication, or Kerberos) to identify and authenticate devices on local and wide area networks.

Organizations determine the required strength of authentication mechanisms based on the security categories of systems and mission or business requirements. Because of the challenges of implementing device authentication on a large scale, organizations can restrict the application of the control to a limited number/type of devices based on mission or business needs.

Related controls and activities

AC-17, AC-18, AC-19, AU-06, CA-03, CA-09, IA-04, IA-05, IA-09, IA-11, IA-13, SI-04.

Enhancements

  • (01) Device identification and authentication: Cryptographic bidirectional authentication
    • Authenticate [Assignment: organization-defined devices and/or types of devices] before establishing [Selection (1 or more): local; remote; network] connection using bidirectional authentication that is cryptographically based.
    • Discussion: A local connection is a connection with a device that communicates without the use of a network. A network connection is a connection with a device that communicates through a network. A remote connection is a connection with a device that communicates through an external network. Bidirectional authentication provides stronger protection to validate the identity of other devices for connections that are of greater risk.
    • Related controls and activities: SC-08, SC-12, SC-13.
  • (02) Device identification and authentication: Cryptographic bidirectional network authentication
    • Withdrawn: Incorporated into IA-03(01).
  • (03) Device identification and authentication: Dynamic address allocation
      1. Where addresses are allocated dynamically, standardize dynamic address allocation lease information and the lease duration assigned to devices in accordance with [Assignment: organization-defined lease information and lease duration]
      2. Audit lease information when assigned to a device
    • Discussion: The Dynamic Host Configuration Protocol (DHCP) is an example of a means by which clients can dynamically receive network address assignments.
    • Related controls and activities: AU-02.
  • (04) Device identification and authentication: Device attestation
    • Handle device identification and authentication based on attestation by [Assignment: organization-defined configuration management process].
    • Discussion: Device attestation refers to the identification and authentication of a device based on its configuration and known operating state. Device attestation can be determined via a cryptographic hash of the device. If device attestation is the means of identification and authentication, then it is important that patches and updates to the device are handled via a configuration management process such that the patches and updates are done securely and do not disrupt identification and authentication to other devices.
    • Related controls and activities: CM-02, CM-03, CM-06.

References

None.

Top of page 
 

IA-04 Identifier management

Control

Manage system identifiers by:

  1. receiving authorization from [Assignment: organization-defined personnel or roles] 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
  4. preventing reuse of identifiers for [Assignment: organization-defined time period]

Discussion

Common device identifiers include MAC addresses, IP addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of AC-02 use account names provided by IA-04.

Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices. At times, identifier management may require the collection of personal information. Consideration of the privacy concept of necessity versus proportionality requires that organizations collect just enough personal information required to ensure accurate authentication.

Related controls and activities

AC-05, IA-02, IA-03, IA-05, IA-08, IA-09, IA-12, MA-04, PE-02, PE-03, PE-04, PL-04, PM-12, PS-03, PS-04, PS-05, SC-37.

Enhancements

  • (01) Identifier management: Prohibit account identifiers as public identifiers
    • Prohibit the use of system account identifiers that are the same as public identifiers for individual accounts.
    • Discussion: Prohibiting account identifiers as public identifiers applies to any publicly disclosed account identifier used for communication, such as email and instant messaging. Prohibiting the use of systems account identifiers that are the same as some public identifier, such as the individual identifier section of an email address, makes it more difficult for adversaries to guess user identifiers. Prohibiting account identifiers as public identifiers without the implementation of other supporting controls only complicates guessing of identifiers. Additional protections are required for authenticators and credentials to protect the account.
    • Related controls and activities: AT-02, PT-07.
  • (02) Identifier management: Supervisor authorization
    • Withdrawn: Incorporated into IA-12(01).
  • (03) Identifier management: Multiple forms of certification
    • Withdrawn: Incorporated into IA-12(02).
  • (04) Identifier management: Identify user status
    • Manage individual identifiers by uniquely identifying each individual as [Assignment: organization-defined characteristic identifying individual status].
    • Discussion: Characteristics that identify the status of individuals include contractors, foreign nationals, and non-organizational users. Identifying the status of individuals by these characteristics provides additional information about the people with whom organizational personnel are communicating.
    • GC discussion: For example, it might be useful for a government employee to know that one of the individuals on an email message is a contractor. This is generally intended for use with national security systems.
    • Related controls and activities: None.
  • (05) Identifier management: Dynamic management
    • Manage individual identifiers dynamically in accordance with [Assignment: organization-defined dynamic identifier policy].
    • Discussion: In contrast with conventional approaches to identification that presume static accounts for preregistered users, many distributed systems establish identifiers at runtime for entities that were previously unknown. When identifiers are established at runtime for previously unknown entities, organizations can anticipate and provision for the dynamic establishment of identifiers. Pre-established trust relationships and mechanisms with appropriate authorities to validate credentials and related identifiers are essential.
    • Related controls and activities: AC-16.
  • (06) Identifier management: Cross-organization management
    • Coordinate with the following external organizations for cross-organization management of identifiers: [Assignment: organization-defined external organizations].
    • Discussion: Cross-organization identifier management provides the capability to identify individuals, groups, roles, or devices when conducting cross-organization activities involving the processing, storage, or transmission of information.
    • GC discussion: If there is a necessity to share personal information (such as identifiers) for cross-organization management - for example during a security investigation - consideration should be given to implementing an information sharing arrangement or agreement or contract documents designed to protect the personal identifiers.
    • Related controls and activities: AU-16, IA-02, IA-05.
  • (07) Identifier management: In-person registration
    • Withdrawn: Incorporated into IA-12(04).
  • (08) Identifier management: Pairwise pseudonymous identifiers
    • Generate pairwise pseudonymous identifiers.
    • Discussion: A pairwise pseudonymous identifier is an opaque unguessable subscriber identifier generated by an identity provider for use at a specific individual relying party. Generating distinct pairwise pseudonymous identifiers with no identifying information about a subscriber discourages the tracking and profiling of subscriber activity beyond the operational requirements established by an organization. The pairwise pseudonymous identifiers are unique to each relying party except in situations where relying parties can show a demonstrable relationship justifying an operational need for correlation, or all parties consent to being correlated in such a manner.
    • Related controls and activities: IA-05.
  • (09) Identifier management: Attribute maintenance and protection
    • Maintain the attributes for each uniquely identified individual, device, or service in [Assignment: organization-defined protected central storage].
    • Discussion: For each of the entities covered in IA-02, IA-03, IA-08, and IA-09, it is important to maintain the attributes for each authenticated entity on an ongoing basis in a central (protected) store.
    • Related controls and activities: None.
  • (400) Identifier management: Biometrics protection
    • Maintain adequate protection for biometrics in accordance with privacy regulations.
    • Discussion: Information collected about the individual for authentication purposes may constitute personal information and should be safeguarded appropriately. In cases where the biometrics are kept in their personally identifiable forms and are not hashed, it is important that they be protected in accordance with privacy regulations. It is not recommended to keep biometrics data in personally identifiable form for identification purposes.
    • Related controls and activities: None.
  • (401) Identifier management: Biometrics integrity
    • Ensure the integrity of collected biometrics.
    • Discussion: None.
    • GC discussion: The federal Privacy Act requires that organizations take all reasonable steps to ensure that personal information used for an administrative purpose by the institution is as accurate, up-to-date, and complete as possible.
    • Related controls and activities: None.

References

Top of page 
 

IA-05 Authenticator management

Control

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. changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type] or when [Assignment: organization-defined events] occur
  7. protecting authenticator content from unauthorized disclosure and modification
  8. requiring individuals to take, and having devices implement, specific controls to protect authenticators
  9. changing authenticators for group or role accounts when membership to those accounts changes

Discussion

Authenticators include passwords, cryptographic devices, biometrics, certificates, one-time password devices, and ID badges. Device authenticators include certificates and passwords. Initial authenticator content is the actual content of the authenticator (e.g., the initial password). In contrast, the requirements for authenticator content contain specific criteria or characteristics (e.g., minimum password length).

Developers may deliver system components with factory default authentication credentials (i.e., passwords) to allow for initial installation and configuration. Default authentication credentials are often well known, easily discoverable, and present a significant risk. The requirement to protect individual authenticators may be implemented via control PL-04 or PS-06 for authenticators in the possession of individuals and by controls AC-03, AC-06, and SC-28 for authenticators stored in organizational systems, including passwords stored in hashed or encrypted formats or files containing encrypted or hashed passwords accessible with administrator privileges.

Systems support authenticator management by organization-defined settings and restrictions for various authenticator characteristics (e.g., minimum password length, validation time window for time synchronous one-time tokens, and number of allowed rejections during the verification stage of biometric authentication). Actions can be taken to safeguard individual authenticators, including maintaining possession of authenticators, not sharing authenticators with others, and immediately reporting lost, stolen, or compromised authenticators. Authenticator management includes issuing and revoking authenticators for temporary access when no longer needed.

Related controls and activities

AC-03, AC-06, CM-06, IA-02, IA-04, IA-07, IA-08, IA-09, MA-04, PE-02, PL-04, SC-12, SC-13.

Enhancements

  • (01) Authenticator management: Password-based authentication
    • For password-based authentication:
      1. maintain a list of commonly used, expected, or compromised passwords and update the list [Assignment: organization-defined frequency] and when organizational passwords are suspected to have been compromised directly or indirectly
      2. when users create or update passwords, verify that the passwords are not found on the list of commonly used, expected, or compromised passwords in IA-05(01)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
      8. enforce the following composition and complexity rules: [Assignment: organization-defined composition and complexity rules]
    • Discussion: Password-based authentication applies to passwords regardless of whether they are used in single-factor or multi-factor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-05(01)h.
      Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.
      Recovery questions often require users to provide personal information. Consideration of the privacy concept of necessity versus proportionality requires that organizations collect just enough personal information required to ensure accurate authentication. The use of pre-registered knowledge tokens is not recommended for account recovery.
    • Related controls and activities: IA-06.
  • (02) Authenticator management: Public key-based authentication
      1. For public key-based authentication
        1. enforce authorized access to the corresponding private key
        2. map the authenticated identity to the account of the individual or group
      2. When PKI is used
        1. validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information
        2. implement a local cache of revocation data to support path discovery and validation
    • Discussion: Public key cryptography is a valid authentication mechanism for individuals, machines, and devices. For PKI solutions, status information for certification paths includes certificate revocation lists or certificate status protocol responses. Implementing a local cache of revocation data to support path discovery and validation also supports system availability in situations where organizations are unable to access revocation information via the network.
    • Related controls and activities: IA-03, SC-17.
  • (03) Authenticator management: In-person or trusted external party registration
    • Withdrawn: Incorporated into IA-12(04).
  • (04) Authenticator management: Automated support for password strength determination
    • Withdrawn: Incorporated into IA-05(01).
  • (05) Authenticator management: 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.
    • Discussion: Changing authenticators prior to the delivery and installation of system components extends the requirement for organizations to change default authenticators upon system installation by requiring developers and/or installers to provide unique authenticators or change default authenticators for system components prior to delivery and/or installation. However, it typically does not apply to developers of COTS IT products. Requirements for unique authenticators can be included in acquisition documents prepared by organizations when procuring systems or system components.
    • Related controls and activities: None.
  • (06) Authenticator management: Protection of authenticators
    • Protect authenticators commensurate with the security category of the information to which use of the authenticator permits access.
    • Discussion: For systems that contain multiple security categories of information without reliable physical or logical separation between categories, authenticators used to grant access to the systems are protected commensurate with the highest security category of information on the systems. Security categories of information are determined as part of the security categorization process.
    • Related controls and activities: RA-02.
  • (07) Authenticator management: No embedded unencrypted static authenticators
    • Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.
    • Discussion: In addition to applications, other forms of static storage include access scripts and function keys. Organizations exercise caution when determining whether embedded or stored authenticators are in encrypted or unencrypted form. If authenticators are used in the manner stored, then those representations are considered unencrypted authenticators.
    • Related controls and activities: None.
  • (08) Authenticator management: Multiple system accounts
    • Implement [Assignment: organization-defined security controls] to manage the risk of compromise due to individuals having accounts on multiple systems.
    • Discussion: When individuals have accounts on multiple systems and use the same authenticators such as passwords, there is the risk that a compromise of one account may lead to the compromise of other accounts. Alternative approaches include having different authenticators (passwords) on all systems, employing a single sign-on or federation mechanism, or using some form of one-time passwords on all systems. Organizations can also use rules of behaviour (see PL-04) and access agreements (see PS-06) to mitigate the risk of multiple system accounts.
    • Related controls and activities: PS-06.
  • (09) Authenticator management: Federated credential management
    • Use the following external organizations to federate credentials: [Assignment: organization-defined external organizations].
    • Discussion: Federation provides organizations with the capability to authenticate individuals and devices when conducting cross-organization activities involving the processing, storage, or transmission of information. Using a specific list of approved external organizations for authentication helps to ensure that those organizations are vetted and trusted.
    • Related controls and activities: AU-07, AU-16.
  • (10) Authenticator management: Dynamic credential binding
    • Bind identities and authenticators dynamically using the following rules: [Assignment: organization-defined binding rules].
    • Discussion: Authentication requires some form of binding between an identity and the authenticator that is used to confirm the identity. In conventional approaches, binding is established by pre-provisioning both the identity and the authenticator to the system. For example, the binding between a username (i.e., identity) and a password (i.e., authenticator) is accomplished by provisioning the identity and authenticator as a pair in the system.
      New authentication techniques allow the binding between the identity and the authenticator to be implemented external to a system. For example, with smartcard credentials, the identity and authenticator are bound together on the smartcard. Using these credentials, systems can authenticate identities that have not been pre-provisioned, dynamically provisioning the identity after authentication. In these situations, organizations can anticipate the dynamic provisioning of identities. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.
    • Related controls and activities: AU-16, IA-05.
  • (11) Authenticator management: Hardware token-based authentication
    • Withdrawn: Incorporated into IA-02(01) and IA-02(02).
  • (12) Authenticator management: Biometric authentication performance
    • For biometric-based authentication, employ mechanisms that satisfy the following biometric quality requirements [Assignment: organization-defined biometric quality requirements].
    • Discussion: Unlike password-based authentication, which provides exact matches of user-input passwords to stored passwords, biometric authentication does not provide exact matches. Depending on the type of biometric and the type of collection mechanism, there is likely to be some divergence from the presented biometric and the stored biometric that serves as the basis for comparison. Matching performance is the rate at which a biometric algorithm correctly results in a match for a genuine user and rejects other users. Biometric performance requirements include the match rate, which reflects the accuracy of the biometric matching algorithm used by a system.
    • GC discussion: The federal Privacy Act requires that organizations take all reasonable steps to ensure that personal information that is used for an administrative purpose by the institution is as accurate, up-to-date, and complete as possible.
    • Related controls and activities: AC-07.
  • (13) Authenticator management: Expiration of cached authenticators
    • Prohibit the use of cached authenticators after [Assignment: organization-defined time period].
    • Discussion: Cached authenticators are used to authenticate to the local machine when the network is not available. If cached authentication information is out of date, the validity of the authentication information may be questionable.
    • Related controls and activities: None.
  • (14) Authenticator management: 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.
    • Discussion: An organization-wide methodology for managing the content of PKI trust stores helps improve the accuracy and currency of PKI-based authentication credentials across the organization.
    • Related controls and activities: None.
  • (15) Authenticator management: Identity, credential and authentication assurance levels compliant products and services
    • Use only products and services for identity, credential, authentication, and access management that are compliant with the required assurance levels.
    • Discussion: None.
    • GC discussion: Products and services need to be compliant with the requirements set by TBS in its Standard on Identity and Credential Assurance and by the Cyber Centre in User authentication guidance for information technology systems (ITSP.30.031). The required identity, credential and authentication levels of assurance need to be documented and controls that mitigate risks and allow to achieve requirements must be applied.
    • Related controls and activities: None.
  • (16) Authenticator management: In-person or trusted external party authenticator issuance
    • Require that the issuance of [Assignment: organization-defined types of and/or specific authenticators] be conducted [Selection (1): in person; by a trusted external party] before [Assignment: organization-defined registration authority] with authorization by [Assignment: organization-defined personnel or roles].
    • Discussion: Issuing authenticators in person or by a trusted external party enhances and reinforces the trustworthiness of the identity proofing process.
    • Related controls and activities: IA-12.
  • (17) Authenticator management: Presentation attack detection for biometric authenticators
    • Employ presentation attack detection mechanisms for biometric-based authentication.
    • Discussion: Biometric characteristics do not constitute authentication secrets. Such characteristics can be obtained by online web accesses, taking a picture of someone with a camera phone to obtain facial images with or without their knowledge, lifting from objects that someone has touched (e.g., a latent fingerprint), or capturing a high-resolution image (e.g., an iris pattern). Presentation attack detection technologies, including liveness detection, can mitigate the risk of these types of attacks by making it difficult to produce artifacts intended to defeat the biometric sensor.
    • Related controls and activities: AC-07.
  • (18) Authenticator management: Password managers
      1. Employ [Assignment: organization-defined password managers] to generate and manage passwords
      2. Protect the passwords using [Assignment: organization-defined controls]
    • Discussion: For systems where static passwords are employed, it is often a challenge to ensure that the passwords are suitably complex and that the same passwords are not employed on multiple systems. A password manager is a solution to this problem as it automatically generates and stores strong and different passwords for various accounts. A potential risk of using password managers is that adversaries can target the collection of passwords generated by the password manager. Therefore, the collection of passwords requires protection including encrypting the passwords (see IA-05(01)d) and storing the collection offline in a token.
    • Related controls and activities: None.

References

Top of page 
 

IA-06 Authentication feedback

Control

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

Discussion

Authentication feedback from systems does not provide information that would allow unauthorized individuals to compromise authentication mechanisms. For some types of systems, such as desktops or notebooks with relatively large monitors, the threat (referred to as shoulder surfing) may be significant. For other types of systems, such as mobile devices with small displays, the threat may be less significant and is balanced against the increased likelihood of typographic input errors due to small keyboards. Thus, the means for obscuring authentication feedback is selected accordingly. Obscuring authentication feedback includes displaying asterisks when users type passwords into input devices or displaying feedback for a very limited time before obscuring it.

Related controls and activities

AC-03.

Enhancements

None.

References

None.

Top of page 
 

IA-07 Cryptographic module authentication

Control

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

Discussion

Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role.

Related controls and activities

AC-03, IA-05, SA-04, SC-12, SC-13.

Enhancements

None.

References

Top of page 
 

IA-08 Identification and authentication (non-organizational users)

Control

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

Discussion

Non-organizational users include system users other than organizational users explicitly covered by IA-02. Non-organizational users are uniquely identified and authenticated for accesses other than those explicitly identified and documented in AC-14. Identification and authentication of non-organizational users accessing federal systems may be required to protect federal, proprietary, or personal information (with exceptions noted for national security systems). Organizations consider many factors — including security, privacy, scalability, and practicality — when balancing the need to ensure ease of use for access to federal information and systems with the need to protect and adequately mitigate risk.

Related controls and activities

AC-02, AC-06, AC-14, AC-17, AC-18, AU-06, IA-02, IA-04, IA-05, IA-10, IA-11, IA-13, MA-04, RA-03, SA-04, SC-08.

Enhancements

  • (01) Identification and authentication (non-organizational users): Acceptance of PKI-based credentials from other agencies
    • Accept and electronically verify PKI-based credentials from other GC departments and agencies.
    • Discussion: None.
    • GC discussion: Acceptance of PKI-based credentials from other GC departments and agencies applies to both logical and physical access control systems.
    • Related controls and activities: PE-03.
  • (02) Identification and authentication (non-organizational users): Acceptance of external authenticators
      1. Accept only external authenticators that are compliant with ITSP.30.031-appropriate level of assurance
      2. Document and maintain a list of accepted external authenticators
    • Discussion: None.
    • GC discussion: Approved external authenticators meet or exceed the minimum GC technical, security, privacy, and organizational maturity requirements. Meeting or exceeding GC requirements allows GC relying parties to trust external authenticators in connection with an authentication transaction at a specified authenticator assurance level. Examples of this in the GC are the Sign-In Partners and GCKey programs.
      Sign-In Partners are private sector organizations that have partnered with SecureKey Technologies to enable their customers to use their online credentials to access GC services. GCKey is the government-branded issued credential. Both have the same authentication process and security requirements and are compliant with the Privacy Act.
    • Related controls and activities: None.
  • (03) Identification and authentication (non-organizational users): Use of Federal Identity, Credential, and Access Management (FICAM)-approved products
    • Withdrawn: Incorporated into IA-08(02) and specific to the US.
  • (04) Identification and authentication (non-organizational users): Use of defined profiles
    • Conform to the following profiles for identity management [Assignment: organization-defined identity management profiles].
    • Discussion: Organizations define profiles for identity management based on open identity management standards. To ensure that open identity management standards are viable, robust, reliable, sustainable, and interoperable as documented, the GC assesses and scopes the standards and technology implementations against applicable laws, Orders in Council, directives, policies, regulations, standards, and guidelines.
    • Related controls and activities: None.
  • (05) Identification and authentication (non-organizational users): Acceptance of Personal Identity Verification (PIV)-I credentials
    • Accept and verify federated or PKI credentials that meet [Assignment: organization-defined policy].
    • Discussion: Acceptance of PIV-I credentials can be implemented by PIV, PIV-I, and other commercial or external identity providers. The acceptance and verification of PIV-I-compliant credentials in Canada is only possible for logical access control systems. The acceptance and verification of PIV-I credentials address non-federal issuers of identity cards that desire to interoperate with the GC PKI-based systems and that can be trusted by GC-relying parties.
      The PIV-I meets the token requirements of the X.509 certificate policy for the Canadian Federal PKI Bridge. PIV-I credentials are the credentials issued by a PIV-I provider whose PIV-I certificate policy maps to the Canadian Federal PKI Bridge. A PIV-I provider is cross-certified with the Federal Bridge CA (directly or through another PKI bridge) with policies that have been mapped and approved as meeting the requirements defined in the Canadian Federal PKI Bridge certificate policy.
    • Related controls and activities: None.
  • (06) Identification and authentication (non-organizational users): Disassociability
    • Implement the following measures to disassociate user attributes or identifier assertion relationships among individuals, credential service providers, and relying parties: [Assignment: organization-defined measures].
    • Discussion: Federated identity solutions can create increased privacy risks due to the tracking and profiling of individuals. Using identifier mapping tables or cryptographic techniques to blind credential service providers and relying parties from each other or to make identity attributes less visible to transmitting parties can reduce these privacy risks.
    • Related controls and activities: None.
  • (400) Identification and authentication (non-organizational users): Identity and credential assurance
    • Withdrawn: Incorporated into IA-05(15).

References

Top of page 
 

IA-09 Service identification and authentication

Control

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

Discussion

Services that may require identification and authentication include web applications using digital certificates or services or applications that query a database. Identification and authentication methods for system services and applications include information or code signing, provenance graphs, and electronic signatures that indicate the sources of services. Decisions regarding the validity of identification and authentication claims can be made by services separate from the services acting on those decisions. This can occur in distributed system architectures. In such situations, the identification and authentication decisions (instead of actual identifiers and authentication data) are provided to the services that need to act on those decisions.

Related controls and activities

IA-03, IA-04, IA-05, IA-13, SC-08.

Enhancements

  • (01) Service identification and authentication: Information exchange
    • Withdrawn: Incorporated into IA-09.
  • (02) Service identification and authentication: Transmission of decisions
    • Withdrawn: Incorporated into IA-09.

References

None.

Top of page 
 

IA-10 Adaptive authentication

Control

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

Discussion

Adversaries may compromise individual authentication mechanisms employed by organizations and subsequently attempt to impersonate legitimate users. To address this threat, organizations may employ specific techniques or mechanisms and establish protocols to assess suspicious behaviour. Suspicious behaviour may include accessing information that individuals do not typically access as part of their duties, roles, or responsibilities; accessing greater quantities of information than individuals would routinely access; or attempting to access information from suspicious network addresses.

When pre-established conditions or triggers occur, organizations can require individuals to provide additional authentication information. Another potential use for adaptive authentication is to increase the strength of mechanism based on the number or types of records being accessed. Adaptive authentication does not replace and is not used to avoid the use of MFA mechanisms but can augment implementations of MFA.

Related controls and activities

IA-02, IA-08.

Enhancements

None.

References

Top of page 
 

IA-11 Re-authentication

Control

Require users to re-authenticate when [Assignment: organization-defined circumstances or situations requiring re-authentication].

Discussion

In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators, or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically.

Related controls and activities

AC-03, AC-11, IA-02, IA-03, IA-04, IA-08.

Enhancements

None.

References

None.

Top of page 
 

IA-12 Identity proofing

Control

  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
  3. Collect, validate, and verify identity evidence

Discussion

Identity proofing is the process of collecting, validating, and verifying a user’s identity information for the purposes of establishing credentials for accessing a system. The information required for identity proofing may require the collection or confirmation of personal information data elements, such as date of birth. Identity proofing is intended to mitigate threats to the registration of users and the establishment of their accounts.

Organizations may be subject to laws, Orders in Council, directives, regulations, or policies that address the collection of identity evidence. Organizational personnel should consult with the appropriate privacy senior official or executive and legal counsel regarding such requirements. Any personal information requested from an individual for identity proofing requires that the organization collecting the information have lawful authority for the collection.

GC discussion

Standards and guidelines specifying identity assurance levels for identity proofing include Appendix A: Standard on Identity and Credential Assurance of the TBS Directive on Identity Management.

Related controls and activities

AC-05, IA-01, IA-02, IA-03, IA-04, IA-05, IA-06, IA-08, IA-13.

Enhancements

  • (01) Identity proofing: Supervisor authorization
    • Require that the registration process to receive an account for logical access includes supervisor or sponsor authorization.
    • Discussion: Including supervisor or sponsor authorization as part of the registration process provides an additional level of scrutiny to ensure that the user’s management chain is aware of the account, the account is essential to carry out organizational missions and functions, and the user’s privileges are appropriate for the anticipated responsibilities and authorities within the organization.
    • Related controls and activities: None.
  • (02) Identity proofing: Identity evidence
    • Require evidence of individual identification be presented to the registration authority.
    • Discussion: Identity evidence, such as documentary evidence or a combination of documents and biometrics, reduces the likelihood of individuals using fraudulent identification to establish an identity or at least increases the work factor of potential adversaries. The forms of acceptable evidence are consistent with the risks to the systems, roles, and privileges associated with the user’s account.
      Most forms of identity evidence are considered to be personal information; in the case of biometrics, this information may be subject to additional safeguard requirements. Biometric information, if collected for individual identification, should only be used for the purpose for which it was collected. When considering the use of biometrics, the registration authority should consider if the collection is demonstrably necessary; likely to be effective; considers the loss of individual privacy against the benefit gained; and whether there is a less privacy-invasive approach that achieves the same identity confirmation.
    • Related controls and activities: None.
  • (03) Identity proofing: Identity evidence validation and verification
    • Require that the presented identity evidence be validated and verified through [Assignment: organizational defined methods of validation and verification].
    • Discussion: Validation and verification of identity evidence increases the assurance that accounts and identifiers are being established for the correct user and authenticators are being bound to that user. Validation refers to the process of confirming that the evidence is genuine and authentic, and the data contained in the evidence is correct, current, and related to an individual. Verification confirms and establishes a linkage between the claimed identity and the actual existence of the user presenting the evidence. Acceptable methods for validating and verifying identity evidence are consistent with the risks to the systems, roles, and privileges associated with the user’s account.
    • GC discussion: Validation and verification of identity evidence is a requirement of the Privacy Act.
    • Related controls and activities: None.
  • (04) Identity proofing: In-person validation and verification
    • Require that the validation and verification of identity evidence be conducted in person before a designated registration authority.
    • Discussion: In-person proofing reduces the likelihood of fraudulent credentials being issued because it requires the physical presence of individuals, the presentation of physical identity documents, and actual face-to-face interactions with designated registration authorities.
    • Related controls and activities: None.
  • (05) Identity proofing: Address confirmation
    • Require that a [Selection (1): registration code; notice of proofing] be delivered through an out-of-band channel to verify the users address (physical or digital) of record.
    • Discussion: To make it more difficult for adversaries to pose as legitimate users during the identity proofing process, organizations can use out-of-band methods to ensure that the individual associated with an address of record is the same individual that participated in the registration. Confirmation can take the form of a temporary enrollment code or a notice of proofing. The delivery address for these artifacts is obtained from records and not self-asserted by the user. The address can include a physical or digital address. A home address is an example of a physical address. Email addresses and telephone numbers are examples of digital addresses.
    • Related controls and activities: IA-12.
  • (06) Identity proofing: Accept externally proofed identities
    • Accept externally proofed identities at [Assignment: organization-defined identity assurance level].
    • Discussion: To limit unnecessary re-proofing of identities, particularly of users without GC-issued PKI credentials, organizations accept proofing conducted at a commensurate level of assurance by other agencies or organizations. Proofing is consistent with organizational security policy and the identity assurance level appropriate for the system, application, or information accessed. Accepting externally proofed identities is a fundamental component of managing federated identities across agencies and organizations.
    • Related controls and activities: IA-03, IA-04, IA-05, IA-08.

References

Top of page 
 

IA-13 Identity providers and authorization servers

Control

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 [Assignment: organization-defined identification and authentication policy] using [Assignment: organization-defined mechanisms].

Discussion

Identity providers, both internal and external to the organization, manage the user, device and NPE authenticators, and issue statements, often called identity assertions, attesting to identities of other systems or systems components.

Authorization servers create and issue access tokens to identified and authenticated users and devices that can be used to gain access to system or information resources. For example, single sign-on (SSO) provides identity provider and authorization server functions. Authenticator management (to include credential management) is covered by IA-05.

Related controls and activities

AC-03, IA-02, IA-03, IA-08, IA-09, IA-12.

Enhancements

  • (01) Identity providers and authorization servers: Protection of cryptographic keys
    • Cryptographic keys that protect access tokens are generated, managed, and protected from disclosure and misuse.
    • Discussion: Identity assertions and access tokens are typically digitally signed. The private keys used to sign these assertions and tokens are protected commensurate with the impact of the system and information resources that can be accessed.
    • Related controls and activities: SC-12, SC-13.
  • (02) Identity providers and authorization servers: 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.
    • Discussion: This includes verification of digital signatures protecting identity assertions and access tokens, as well as included metadata. Metadata includes information about the access request such as information unique to the user, system, or information resource being accessed, or the transaction itself such as time. Protected system and information resources could include connected networks, applications, and APIs.
    • Related controls and activities: None.
  • (03) Identity providers and authorization servers: Token management
    • In accordance with [Assignment: organization-defined identification and authentication policy], assertions and access tokens are:
      1. generated
      2. issued
      3. refreshed
      4. revoked
      5. time-restricted
      6. audience-restricted
    • Discussion: An access token is a piece of data that represents the authorization granted to a user or NPE to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience – for example, an application or security domain – and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens.
    • Related controls and activities: None.

References

Table of Contents
Date modified: