User:Shawndouglas/sandbox/sublevel3

From LIMSWiki
Jump to navigationJump to search

IA-1 Identification and authentication policy and procedures

This control recommends the organization develop, document, disseminate, review, and update identification and authentication policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of identification and authentication action but also to address how those policies and procedures will be implemented, reviewed, and updated.

Additional resources:

IA-2 Identification and authentication for organizational users

This control recommends the system be able to identify and authenticate a user or user-propagated process as a single, unique entity by using one or more mechanisms. The choice of these mechanisms will be guided by organizational policy, regulations, laws, standards, and guidance documents. According to NIST, authentication mechanisms will be based on "(i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric)."

Additional resources:

IA-2 (1) Identification and authentication for organizational users: Network access to privileged accounts

This control enhancement recommends the system be able to implement multifactor authentication to privileged accounts being accessed over the network. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines network access as "access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses)."

Additional resources:

IA-2 (2) Identification and authentication for organizational users: Network access to non-privileged accounts

This control enhancement recommends the system be able to implement multifactor authentication to non-privileged accounts being accessed over the network. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines network access as "access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses)."

Additional resources:

IA-2 (3) Identification and authentication for organizational users: Local access to privileged accounts

This control enhancement recommends the system be able to implement multifactor authentication to privileged accounts being accessed locally. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines local access as "any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks."

Additional resources:

IA-2 (4) Identification and authentication for organizational users: Local access to non-privileged accounts

This control enhancement recommends the system be able to implement multifactor authentication to non-privileged accounts being accessed locally. "Multifactor authentication requires the use of two or more different factors to achieve authentication." NIST defines local access as "any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks." Note that NIST considers this a "High" baseline control; this type of authentication for non-privileged local accounts may not be required.

Additional resources:

IA-2 (10) Identification and authentication for organizational users: Single sign-on

This control enhancement recommends the system be configurable to allow, if desired, single sign-on to specified system accounts and services, such that a user can log in once and gain access to multiple system resources.

Additional resources:

IA-2 (12) Identification and authentication for organizational users: Acceptance of personal identity verification credentials

This control enhancement recommends the system be capable of accepting and electronically verifying personal identity verification (PIV) credentials. The U.S. General Services Administration (GSA) says of PIV credentials: "PIV credentials have certificates and key pairs, pin numbers, biometrics like fingerprints and pictures, and other unique identifiers. When put together into a PIV credential, it provides the capability to implement multi-factor authentication for networks, applications and buildings."[1] These types of credentials are most often associated with federal agencies, and as such this control enhancement may not be required for a non-federal entity or organization.

Additional resources:

IA-4 Identifier management

This control recommends the organization ensure the individual, group, role, and device identifiers in the system be selected, assigned, and disabled by authorized individuals or roles only. Those same individuals or roles will be responsible for both preventing the reuse of those identifiers for and disabling those identifiers after a specified period of time (including "never").

Additional resources:

IA-5 Authenticator management

This control recommends the organization ensure the individual, group, role, and device receiving a new authenticator has their identity verified, while also ensuring those new authenticators are properly defined, are sufficiently strong, and are backed by administrative and cybersecurity policy and procedure. That policy and procedure should address how authenticators are managed if lost, compromised, or damaged, as well as how to revoke the authenticators. Policy and procedure should also address use and reuse restrictions, refreshing rules, protection recommendations, personnel and device safeguards, and membership/role changes for authenticators.

Additional resources:

IA-5 (1) Authenticator management: Password-based authentication

This control enhancement recommends the system's password-based authentication be configurable to allow specific password-related rules set by the organization. This includes rules related to password complexity (case sensitivity, number of characters by type, uppercase-lowercase mix, numbers and special characters), minimum and maximum password lifetime rules, changed and updated password rules, and password reuse rules. The system should also be capable of allowing for the creation of temporary passwords and the storage and transmittal of passwords in an encrypted fashion.

Additional resources:

IA-5 (4) Authenticator management: Automated support for password strength determination

This control enhancement recommends the organization employ (or, ensure the system employs) some type of automation in determining if password authenticators are sufficiently strong to satisfy organizational policy. This is strongly related to IA-5 (1).

Additional resources:

IA-5 (11) Authenticator management: Hardware token-based authentication

This control enhancement recommends the organization—if it plans on implementing public key infrastructure (PKI) tokens, which "provide secure storage for digital certificates and private keys"[2]—employ mechanisms that satisfy organization-based token quality requirements.

Additional resources:

IA-6 Authenticator feedback

This control recommends the system obscure how authentication information, such as passwords, is entered, using mechanisms such as showing asterisks instead of the password characters or limiting visual feedback of each password character to an extremely brief period of time.

Additional resources: LIMSpec 32.41

IA-7 Cryptographic module verification

This control recommends the system be capable of authenticating access to a cryptographic module, ensuring the user is authorized to assume the requested role and perform role-based actions within that module.

Additional resources:

IA-8 Identification and authentication for non-organizational users

This control recommends the system be able to identify and authenticate a non-organizational user or user-propagated process as a single, unique entity by using one or more mechanisms. The choice of these mechanisms will be guided by organizational policy, regulations, laws, standards, and guidance documents. According to NIST, authentication mechanisms will be based on "(i) something you know (e.g., password, personal identification number [PIN]); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric)."

Additional resources:

IA-8 (1) Identification and authentication for non-organizational users: Acceptance of personal identity verification credentials from other agencies

This control enhancement recommends the system be capable of accepting and electronically verifying PIV credentials from more than just the primary organization or agency. The U.S. General Services Administration (GSA) says of PIV credentials: "PIV credentials have certificates and key pairs, pin numbers, biometrics like fingerprints and pictures, and other unique identifiers. When put together into a PIV credential, it provides the capability to implement multi-factor authentication for networks, applications and buildings."[1] These types of credentials are most often associated with federal agencies, and as such this control enhancement may not be required for a non-federal entity or organization.

Additional resources:

IA-8 (2) Identification and authentication for non-organizational users: Acceptance of third-party credentials

This control enhancement recommends the system be capable of accepting and electronically verifying FICAM-approved third-party credentials. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."[3]

These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized third parties (such as contractors) to use PKI token-based authentication for logical and physical access to systems.

Additional resources:

IA-8 (3) Identification and authentication for non-organizational users: Use of FICAM-approved products

This control enhancement recommends the organization employ only FICAM-approved system components when accepting and electronically verifying FICAM-approved credentials. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."[3]

These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized individuals to use PKI token-based authentication for logical and physical access to systems. In that case, the organization may wish to set a baseline standard for system components employed to accept and verify those PKI tokens.

Additional resources:

IA-8 (4) Identification and authentication for non-organizational users: Use of FICAM-issued profiles

This control enhancement recommends a system that accepts and electronically verifies FICAM-approved credentials conform to FICAM-issued implementation profiles of protocols such as SAML 2.0 and OpenID 2.0, as well as other protocols such as the FICAM Backend Attribute Exchange. FICAM is the U.S. federal government's implementation of the Identity, Credential, and Access Management (ICAM) architecture plan, which is a set of philosophies and resources that allow an organization to "enable the right individual to access the right resource at the right time for the right reason."[3]

These types of credentials are most associated with federal agencies, and as such this control enhancement would not be required for a non-federal entity or organization. However, while specifically intended for ensuring non-federal government entities can access federal systems in a standardized way, this control enhancement could be altered to address the needs of non-federal organizations requiring authorized individuals to use PKI token-based authentication for logical and physical access to systems. In that case, the organization may wish to set a baseline standard for how the system implements protocols that manage how PKI tokens are accepted and verified.

Additional resources:

References

  1. ↑ 1.0 1.1 "Introduction - PIV Guides". PIV Usage Guides. General Services Administration. https://piv.idmanagement.gov/. Retrieved 23 July 2020. 
  2. ↑ "PKI Tokens". Microcosm Ltd. https://www.microcosm.com/products/pki-tokens. Retrieved 23 July 2020. 
  3. ↑ 3.0 3.1 3.2 "Introduction". Federal Identity, Credential, and Access Management Architecture. General Services Administration. https://arch.idmanagement.gov/. Retrieved 23 July 2020. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel3&oldid=46483"