Difference between revisions of "User:Shawndouglas/sandbox/sublevel3"

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
====CP-1 Contingency planning policy and procedures====
====IA-1 Identification and authentication policy and procedures====
This control recommends the organization develop, document, disseminate, review, and update contingency planning policies and procedures. It asks organizations to not only address the purpose, scope, roles, responsibilities, and enforcement of contingency planning action but also to address how those policies and procedures will be implemented, reviewed, and updated.  
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-12/rev-1/final NIST Special Publications 800-12, Rev. 1], pages 61–62
* [https://csrc.nist.gov/publications/detail/sp/800-12/rev-1/final NIST Special Publications 800-12, Rev. 1], pages 62–63
* [https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final NIST Special Publications 800-34, Rev. 1]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-100/final NIST Special Publications 800-100], pages 78–83
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Maintaining_Laboratory_Workflow_and_Operations#7._Document_management LIMSpec 7.1, 7.2]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Maintaining_Laboratory_Workflow_and_Operations#7._Document_management LIMSpec 7.1, 7.2]


====CP-2 Contingency plan====
====IA-2 Identification and authentication for organizational users====
This control recommends the organization develop, document, disseminate, review, and update a contingency plan for the system. As part of this process, the organization should identify its business and cybersecurity goals, as well as its processes, particularly goals and processes that have been marked as critical or essential to overall operations. The plan should also address the importance of keeping those goals and processes intact despite any disruption, as well as any recovery objectives, restoration priorities, and responsible parties (including their roles and contact information). The plan should be reviewed and approved by key personnel, and reviewed again at a determined frequency, with any changes resulting in updating, communicating, and protecting the revised plan.
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final NIST Special Publications 800-34, Rev. 1]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* No LIMSpec comp (organizational policy rather than system specification)
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.35], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#34._System_administration 34.4], and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity 35.3]


====CP-3 Contingency training====
====IA-2 (1) Identification and authentication for organizational users: Network access to privileged accounts====
This control recommends the organization supply the appropriate training concerning contingency plan enactment to the relevant system users at a defined frequency, when the system changes significantly, or when a user takes on a contingency role or responsibility.
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-16/final NIST Special Publications 800-16]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]
* [https://csrc.nist.gov/publications/detail/sp/800-50/final NIST Special Publications 800-50]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Maintaining_Laboratory_Workflow_and_Operations#8._Resource_management LIMSpec 8.3, 8.5, and 8.7]


====CP-4 Contingency plan testing====
====IA-2 (2) Identification and authentication for organizational users: Network access to non-privileged accounts====
This control recommends the organization develop and regularly use testing methods to test the system contingency plan for its effectiveness, as well as how well prepared system users are to execute the plan. The organization should review the results of such tests and apply corrective action, if needed.
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final NIST Special Publications 800-34, Rev. 1]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]
* [https://csrc.nist.gov/publications/detail/sp/800-84/final NIST Special Publications 800-84]
* No LIMSpec comp (organizational policy rather than system specification)


====CP-9 Information system backup====
====IA-2 (3) Identification and authentication for organizational users: Local access to privileged accounts====
This control recommends the organization back up the system's user-level and system-level information, as well as system documentation, at defined frequencies. The organization should make efforts to protect the confidentiality, integrity, and availability of any data backups.
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final NIST Special Publications 800-34, Rev. 1]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Technology_and_Performance_Improvements#27._Systems_integration LIMSpec 27.11]


====CP-10 Information system recovery and reconstitution====
====IA-2 (4) Identification and authentication for organizational users: Local access to non-privileged accounts====
This control recommends the organization retain the capability of recovering and reconstituting the system to a recent known state in the wake of a system disruption, compromise, or failure. This may be done in an automatic or manual fashion.
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''':
'''Additional resources''':
* [https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final NIST Special Publications 800-34, Rev. 1]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.3]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Technology_and_Performance_Improvements#27._Systems_integration LIMSpec 27.11]
 
====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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.24]
 
====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."<ref name="GSA_IntroPIV">{{cite web |url=https://piv.idmanagement.gov/ |title=Introduction - PIV Guides |work=PIV Usage Guides |publisher=General Services Administration |accessdate=23 July 2020}}</ref> 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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 21.17]
 
====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''':
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.26 and 32.28]
 
====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''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-73/4/final NIST Special Publications 800-73-4]
* [https://csrc.nist.gov/publications/detail/sp/800-76/2/final NIST Special Publications 800-76-2]
* [https://csrc.nist.gov/publications/detail/sp/800-78/4/final NIST Special Publications 800-78-4]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.26, 32.27, 32.34, and 32.35]
 
====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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.10], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management 32.27, 32.28, and 32.40]
 
====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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.10] and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management 32.40]
 
====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"<ref name="MicrocosmPKITokens">{{cite web |url=https://www.microcosm.com/products/pki-tokens |title=PKI Tokens |publisher=Microcosm Ltd |accessdate=23 July 2020}}</ref>—employ mechanisms that satisfy organization-based token quality requirements.
 
'''Additional resources''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Specialty_Laboratory_Functions#21._Forensic_case_and_data_management LIMSpec 21.17]
 
====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''':
[https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management 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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 35.5]
 
====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''':
* [https://pacs.idmanagement.gov/ GSA Physical Access Control System Guide]
* [https://csrc.nist.gov/publications/detail/sp/800-63/3/final NIST Special Publications 800-63-3]
* [https://csrc.nist.gov/publications/detail/sp/800-116/rev-1/final NIST Special Publications 800-116, Rev. 1]
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#32._Configuration_management LIMSpec 32.25, 32.35], [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#34._System_administration 34.4], and [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity 35.3]
 
====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."<ref name="GSA_IntroPIV" /> 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''':
* [https://www.limswiki.org/index.php/LII:LIMSpec/Security_and_Integrity_of_Systems_and_Operations#35._Cybersecurity LIMSpec 21.17]
 
====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."<ref name="GSA-FICAM">{{cite web |url=https://arch.idmanagement.gov/ |title=Introduction |work=Federal Identity, Credential, and Access Management Architecture |publisher=General Services Administration |accessdate=23 July 2020}}</ref>
 
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''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
====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."<ref name="GSA-FICAM" />
 
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''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
====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."<ref name="GSA-FICAM" />
 
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''':
* [https://arch.idmanagement.gov/ FICAM Enterprise Architecture Guide]
* [https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/FICAM_Roadmap_and_Implem_Guid.pdf FICAM Roadmap and Implementation Guidance]
* No LIMSpec comp (LIMSpec currently doesn't address FICAM requirements)
 
==References==
{{Reflist|colwidth=30em}}

Revision as of 20:47, 16 February 2022

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.