Back

Employ cryptographic controls that comply with applicable requirements.


CONTROL ID
12491
CONTROL TYPE
Technical Security
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Manage the use of encryption controls and cryptographic controls., CC ID: 00570

There are no implementation support Controls.


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • The FI should ensure all cryptographic algorithms used have been subject to rigorous testing or vetting to meet the identified security objectives and requirements. (§ 10.1.4, Technology Risk Management Guidelines, January 2021)
  • Symmetric cryptographic algorithms are not used in Electronic Codebook Mode. (Security Control: 0479; Revision: 4, Australian Government Information Security Manual, March 2021)
  • Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used to protect OFFICIAL: Sensitive or PROTECTED data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure. (Control: ISM-0465; Revision: 9, Australian Government Information Security Manual, June 2023)
  • ECDH and ECDSA are used in preference to DH and DSA. (Control: ISM-0994; Revision: 6, Australian Government Information Security Manual, June 2023)
  • DSA is not used for digital signatures. (Control: ISM-1760; Revision: 0, Australian Government Information Security Manual, June 2023)
  • Only the latest version of TLS is used for TLS connections. (Control: ISM-1139; Revision: 6, Australian Government Information Security Manual, June 2023)
  • ASD-approved HACE is used when encrypting media that contains SECRET or TOP SECRET data. (Control: ISM-0460; Revision: 12, Australian Government Information Security Manual, June 2023)
  • ASD-approved HACE is used to protect SECRET and TOP SECRET data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure. (Control: ISM-0467; Revision: 11, Australian Government Information Security Manual, June 2023)
  • Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used when encrypting media that contains OFFICIAL: Sensitive or PROTECTED data. (Control: ISM-0457; Revision: 9, Australian Government Information Security Manual, June 2023)
  • An ASD-Approved Cryptographic Algorithm (AACA) or high assurance cryptographic algorithm is used when encrypting media. (Control: ISM-1080; Revision: 5, Australian Government Information Security Manual, June 2023)
  • Only AACAs or high assurance cryptographic algorithms are used by cryptographic equipment and software. (Control: ISM-0471; Revision: 7, Australian Government Information Security Manual, June 2023)
  • Anonymous DH is not used for TLS connections. (Control: ISM-1373; Revision: 2, Australian Government Information Security Manual, June 2023)
  • Perfect Forward Secrecy (PFS) is used for TLS connections. (Control: ISM-1453; Revision: 1, Australian Government Information Security Manual, June 2023)
  • The ESP protocol is used for authentication and encryption of IPsec connections. (Control: ISM-0496; Revision: 5, Australian Government Information Security Manual, June 2023)
  • IKE version 2 is used for key exchange when establishing IPsec connections. (Control: ISM-1233; Revision: 2, Australian Government Information Security Manual, June 2023)
  • PFS is used for IPsec connections. (Control: ISM-1000; Revision: 4, Australian Government Information Security Manual, June 2023)
  • Only AACPs or high assurance cryptographic protocols are used by cryptographic equipment and software. (Control: ISM-0481; Revision: 6, Australian Government Information Security Manual, June 2023)
  • Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used to protect OFFICIAL: Sensitive or PROTECTED data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure. (Control: ISM-0465; Revision: 9, Australian Government Information Security Manual, September 2023)
  • ECDH and ECDSA are used in preference to DH and DSA. (Control: ISM-0994; Revision: 6, Australian Government Information Security Manual, September 2023)
  • DSA is not used for digital signatures. (Control: ISM-1760; Revision: 0, Australian Government Information Security Manual, September 2023)
  • Only the latest version of TLS is used for TLS connections. (Control: ISM-1139; Revision: 6, Australian Government Information Security Manual, September 2023)
  • Cryptographic equipment or software that has completed a Common Criteria evaluation against a Protection Profile is used when encrypting media that contains OFFICIAL: Sensitive or PROTECTED data. (Control: ISM-0457; Revision: 9, Australian Government Information Security Manual, September 2023)
  • An ASD-Approved Cryptographic Algorithm (AACA) or high assurance cryptographic algorithm is used when encrypting media. (Control: ISM-1080; Revision: 5, Australian Government Information Security Manual, September 2023)
  • Only AACAs or high assurance cryptographic algorithms are used by cryptographic equipment and software. (Control: ISM-0471; Revision: 7, Australian Government Information Security Manual, September 2023)
  • Anonymous DH is not used for TLS connections. (Control: ISM-1373; Revision: 2, Australian Government Information Security Manual, September 2023)
  • Perfect Forward Secrecy (PFS) is used for TLS connections. (Control: ISM-1453; Revision: 1, Australian Government Information Security Manual, September 2023)
  • The ESP protocol is used for authentication and encryption of IPsec connections. (Control: ISM-0496; Revision: 5, Australian Government Information Security Manual, September 2023)
  • IKE version 2 is used for key exchange when establishing IPsec connections. (Control: ISM-1233; Revision: 2, Australian Government Information Security Manual, September 2023)
  • PFS is used for IPsec connections. (Control: ISM-1000; Revision: 4, Australian Government Information Security Manual, September 2023)
  • Only AACPs or high assurance cryptographic protocols are used by cryptographic equipment and software. (Control: ISM-0481; Revision: 6, Australian Government Information Security Manual, September 2023)
  • HACE is used when encrypting media that contains SECRET or TOP SECRET data. (Control: ISM-0460; Revision: 13, Australian Government Information Security Manual, September 2023)
  • HACE is used to protect SECRET and TOP SECRET data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure. (Control: ISM-0467; Revision: 12, Australian Government Information Security Manual, September 2023)
  • Authentication mechanisms used to authenticate users against a device shall use best practice cryptography, appropriate to the properties of the technology, risk and usage. (Provision 5.1-3, CYBER; Cyber Security for Consumer Internet of Things: Baseline Requirements, ETSI EN 303 645, V2.1.1)
  • The legal parameters for the use of cryptography are taken into account. (5.1.1 Requirements (must) Bullet 2, Information Security Assessment, Version 5.1)
  • ensure that the algorithms and keys used for the symmetric key authentication conform to 8.5. (5.16.1 ¶ 1 d), IEC 62443-4-2: Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components, Edition 1.0)
  • Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: - Only trusted keys and certificates are accepted. - The protocol in use only supports secure versions or configurations. - The encryption st… (4.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, v3.2.1)
  • Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: - Only trusted keys and certificates are accepted. - The protocol in use only supports secure versions or configurations. - The encryption st… (4.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • Are security protocols implemented to use only secure configurations, and to not support insecure versions or configurations? (4.1(c), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
  • Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations. (4.1.e, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS. (4.1.h, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received. For example, for browser-based implementations: - “HTTPS” appears as the browser Universal Record Locator (URL) protocol, and - Cardholder data is only reques… (4.1.g, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • Review documented policies and procedures to verify processes are specified for the following: - For acceptance of only trusted keys and/or certificates - For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported) - For imp… (4.1.b, Payment Card Industry (PCI) Data Security Standard, Testing Procedures, Version 3.2)
  • If the device uses two keys for MAC generation or verification, the technique utilized is in accordance with ISO 16609. (F3, Payment Card Industry (PCI), PIN Transaction Security (PTS) Hardware Security Module (HSM) - Security Requirements, Version 3.0)
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. (4.2.1 Bullet 3, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Requirements, Version 4.0)
  • Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations. (2.2.7.d, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Testing Procedures, Version 4.0)
  • Examine system configurations to verify that strong cryptography and security protocols are implemented in accordance with all elements specified in this requirement. (4.2.1.b, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Testing Procedures, Version 4.0)
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. (4.2.1 Bullet 3, Self-Assessment Questionnaire A-EP and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. (4.2.1 Bullet 3, Self-Assessment Questionnaire C and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. (4.2.1 Bullet 3, Self-Assessment Questionnaire D for Merchants and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. (4.2.1 Bullet 3, Self-Assessment Questionnaire D for Service Providers and Attestation of Compliance for use with PCI DSS Version 4.0)
  • Verify that approved cryptographic algorithms are used in the generation, seeding, and verification of OTPs. (2.8.3, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that approved cryptographic algorithms are used in the generation, seeding, and verification. (2.9.3, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that session tokens are generated using approved cryptographic algorithms. (3.2.4, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. (6.2.2, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred. (9.1.2, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol should be the preferred option. (9.1.3, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility. (6.2.5, Application Security Verification Standard 4.0.3, 4.0.3)
  • The cloud service customer should implement cryptographic controls for its use of cloud services if justified by the risk analysis. The controls should be of sufficient strength to mitigate the identified risks, whether those controls are supplied by the cloud service customer or by the cloud servic… (§ 10.1.1 Table: Cloud service customer, ISO/IEC 27017:2015, Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services, First edition 2015-12-15)
  • If cryptography is required, the component shall use cryptographic security mechanisms according to internationally recognized and proven security practices and recommendations (8.5.1 ¶ 1, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • The selection of cryptographic protection should be based on a threat and risk analysis which covers the value of the information being protected, the consequences of the confidentiality and integrity of the information being breached, the time period during which the information is confidential and… (8.5.2 ¶ 1, Security for Industrial Automation and Control Systems, Part 4-2: Technical Security Requirements for IACS components)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, StateRAMP Security Controls Baseline Summary Category 1, Version 1.1)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, StateRAMP Security Controls Baseline Summary Category 1, Version 1.1)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, StateRAMP Security Controls Baseline Summary Category 2, Version 1.1)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, StateRAMP Security Controls Baseline Summary Category 2, Version 1.1)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, StateRAMP Security Controls Baseline Summary Category 3, Version 1.1)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, StateRAMP Security Controls Baseline Summary Category 3, Version 1.1)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, StateRAMP Security Controls Baseline Summary High Sensitivity Level, Version 1.1)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, StateRAMP Security Controls Baseline Summary High Sensitivity Level, Version 1.1)
  • Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. (SC.L2-3.13.11 CUI Encryption, Cybersecurity Maturity Model Certification, Version 2.0, Level 2)
  • Using FIPS 140-2 validated cryptography modules (minimally Level 1) operated in FIPS Mode in accordance with Federal government policy / standards for the protection of all CUI. (Section 5.11 ¶ 3 Bullet 2, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • All encryption identified, except as stated otherwise, must be accomplished using FIPS 140-2 validated cryptography modules operated in FIPS mode. (Section 5.10.2.3 ¶ 3, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • If the DoD information is sensitive government information (e.g., FOUO or CUI), FIPS 140-2 validated software cryptography modules operated in FIPS mode must be used. (Section 5.10.6 ¶ 1 Bullet 10, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • All Data replication must traverse a CSP's private internal network (physical or virtual) from CSP offering site/location to the DR/COOP facility and protect the data in transit. If this network traverses the Internet, the network connection must be encrypted end-to-end in an IPsec tunnel implemente… (Section 5.10.3.3 ¶ 3, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in §170.299). (§ 170.210 (f), 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology, current as of January 2024)
  • General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 8, 2014 (incorporated by reference in §170.299). (§ 170.210 (a) (2), 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology, current as of January 2024)
  • Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in §170.299). (§ 170.210 (f), 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, current as of July 14, 2020)
  • General. Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 8, 2014 (incorporated by reference in §170.299). (§ 170.210 (a) (2), 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, current as of July 14, 2020)
  • When CJI is transmitted outside the boundary of the physically secure location, the data shall be immediately protected via encryption. When encryption is employed, the cryptographic module used shall be FIPS 140-2 certified and use a symmetric cipher key strength of at least 128 bit strength to pro… (§ 5.10.1.2.1 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • When CJI is transmitted outside the boundary of the physically secure location, the data shall be immediately protected via encryption. When encryption is employed, the cryptographic module used shall be FIPS 140-2 certified and use a symmetric cipher key strength of at least 128 bit strength to pro… (§ 5.10.1.2.1 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.9.1, Version 5.9.1)
  • When CJI is at rest (i.e. stored digitally) outside the boundary of the physically secure location, the data shall be protected via encryption. When encryption is employed, agencies shall either encrypt CJI in accordance with the standard in Section 5.10.1.2.1 above, or use a symmetric cipher that i… (§ 5.10.1.2.2 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.9.1, Version 5.9.1)
  • The information system implements [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 High Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) High Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) Low Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • The information system implements [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Moderate Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) Moderate Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • The information system implements [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Low Baseline Controls, FedRAMP Baseline Security Controls, 8/28/2018)
  • Implement the following types of cryptography required for each specified cryptographic use: [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography]. (SC-13b., FedRAMP Security Controls High Baseline, Version 5)
  • Implement the following types of cryptography required for each specified cryptographic use: [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography]. (SC-13b., FedRAMP Security Controls Low Baseline, Version 5)
  • Implement the following types of cryptography required for each specified cryptographic use: [FedRAMP Assignment: FIPS-validated or NSA-approved cryptography]. (SC-13b., FedRAMP Security Controls Moderate Baseline, Version 5)
  • Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. (SC-13b., Control Baselines for Information Systems and Organizations, NIST SP 800-53B, High Impact Baseline, October 2020)
  • Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. (SC-13b., Control Baselines for Information Systems and Organizations, NIST SP 800-53B, Low Impact Baseline, October 2020)
  • Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. (SC-13b., Control Baselines for Information Systems and Organizations, NIST SP 800-53B, Moderate Impact Baseline, October 2020)
  • Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved. (SA-4(7)(b), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 2 Controls)
  • Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved. (SA-4(7)(b), Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST Special Publication 800-161, Revision 1, Appendix A, C-SCRM Level 3 Controls)
  • When a single-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output. (5.1.4.2 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Cryptographic authenticators used at AAL1 SHALL use approved cryptography. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise (e.g., by malware) of the user endpoint in which they are running and SHOULD NOT complet… (4.1.2 ¶ 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Cryptographic authenticators used at AAL2 SHALL use approved cryptography. Authenticators procured by government agencies SHALL be validated to meet the requirements of FIPS 140 Level 1. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attem… (4.2.2 ¶ 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • When a multi-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output. The verifier or CSP SHALL also establish, via t… (5.1.5.2 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used. (5.1.9.1 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • At IAL2 and above, identifying information is associated with the digital identity and the subscriber has undergone an identity proofing process as described in SP 800-63A. As a result, authenticators at the same AAL as the desired IAL SHALL be bound to the account. For example, if the subscriber ha… (6.1.1 ¶ 4, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • To be considered verifier compromise resistant, public keys stored by the verifier SHALL be associated with the use of approved cryptographic algorithms and SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publicati… (5.2.7 ¶ 3, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The challenge nonce SHALL be at least 64 bits in length, and SHALL either be unique over the authenticator's lifetime or statistically unique (i.e., generated using an approved random bit generator [SP 800-90Ar1]). The verification operation SHALL use approved cryptography. (5.1.7.2 ¶ 3, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime.… (5.1.5.1 ¶ 3, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Approved cryptographic algorithms SHALL be used to establish verifier impersonation resistance where it is required. Keys used for this purpose SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). (5.2.5 ¶ 3, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation. A session MAY be considered at a lower AAL than the authentication event but… (7.1 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber's account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that p… (4.3 ¶ 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used. (5.1.7.1 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The assertion signature SHALL either be a digital signature using asymmetric keys or a MAC using a symmetric key shared between the RP and issuer. Shared symmetric keys used for this purpose by the IdP SHALL be independent for each RP to which they send assertions, and are normally established durin… (6.2.2 ¶ 2, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • Reference to a given key SHALL be trusted at the same level as all other information within the assertion. (6.1.2 ¶ 4 3., Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • All encryption of assertions SHALL use approved cryptography. (6.2.3 ¶ 2, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1 High Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1 Low Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1 Moderate Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control: Low Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control: Moderate Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control: High Baseline Controls, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • If cryptography is selected, the most effective safeguard is to use a complete cryptographic system approved by the NIST/ Communications Security Establishment (CSE) Cryptographic Module Validation Program (CMVP). Within this program standards are maintained to ensure that cryptographic systems were… (§ 6.2.16.1 ICS-specific Recommendations and Guidance ¶ 5, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • Use only modules that can be certified to comply with a standard, such as FIPS 140-2 [90] through the Cryptographic Module Validation Program (CMVP). (§ 6.2.16.1 ICS-specific Recommendations and Guidance ¶ 10, Guide to Industrial Control Systems (ICS) Security, Revision 2)
  • Traditional approaches for data at rest encryption often involve the use of host-based capabilities that may be incompatible with containers. Thus, organizations should use tools for encrypting data used with containers that allow the data to be accessed properly from containers regardless of the no… (4.3.2 ¶ 3, NIST SP 800-190, Application Container Security Guide)
  • Regardless of the tool chosen, organizations should ensure that secrets are only provided to the specific containers that require them, based on a pre-defined and administrator-controlled setting, and that secrets are always encrypted at rest and in transit using Federal Information Processing Stand… (4.1.4 ¶ 3, NIST SP 800-190, Application Container Security Guide)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Revision 4)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, High Impact Baseline, Revision 4)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Low Impact Baseline, Revision 4)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Low Impact Baseline, Revision 4)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Moderate Impact Baseline, Revision 4)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Moderate Impact Baseline, Revision 4)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Requires, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated. (SA-4(7)(b), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • The information system implements [Assignment: organization-defined cryptographic uses and type of cryptography required for each use] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved. (SA-4(7)(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. (SC-13b., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved. (SA-4(7)(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Implement the following types of cryptography required for each specified cryptographic use: [Assignment: organization-defined types of cryptography for each specified cryptographic use]. (SC-13b., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Requires, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated. (SA-4(7) ¶ 1(b), Supply Chain Risk Management Practices for Federal Information Systems and Organizations, NIST Special Publication 800-161, April 2015)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, TX-RAMP Security Controls Baseline Level 1)
  • The information system, for hardware token-based authentication, employs mechanisms that satisfy [Assignment: organization-defined token quality requirements]. (IA-5(11) ¶ 1, TX-RAMP Security Controls Baseline Level 2)
  • The information system implements [TX-RAMP Assignment: FIPS-validated or NSA-approved cryptography] in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (SC-13 Control, TX-RAMP Security Controls Baseline Level 2)