Back

Configure the encryption strength to be appropriate for the encryption methodology of the cryptographic controls.


CONTROL ID
12492
CONTROL TYPE
Technical Security
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Use strong data encryption to transmit in scope data or in scope information, as necessary., CC ID: 00564

There are no implementation support Controls.


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • It is necessary to take data protection measures for important data in order to conceal the data content in case of tapping during data transfer. (P4.1. ¶ 1, FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • Normally, a minimum of 128-bit SSL encryption is expected. Constant advances in computer hardware, cryptanalysis and distributed brute force techniques may induce use of larger key lengths periodically. It is expected that banks will properly evaluate security requirements associated with their inte… (Critical components of information security 14) (v), Guidelines on Information Security, Electronic Banking, Technology Risk Management and Cyber Frauds)
  • MAS expects an FI to properly evaluate security requirements associated with its internet systems and adopt encryption algorithms which are of well-established international standards and subjected to rigorous scrutiny by an international community of cryptographers or approved by authoritative prof… (§ 12.1.3, Monetary Authority of Singapore: Technology Risk Management Guidelines)
  • The FI should adopt cryptographic algorithms from well-established international standards. The FI should also select an appropriate algorithm and encryption key length that meet its security objectives and requirements. (§ 10.1.2, Technology Risk Management Guidelines, January 2021)
  • ECDH and ECDSA are used in preference to DH and DSA. (Security Control: 0994; Revision: 5, Australian Government Information Security Manual, March 2021)
  • An APRA-regulated entity would typically select cryptographic techniques based on the nature of the activity and the sensitivity and criticality of the data involved. The cryptographic techniques would typically be reviewed on a regular basis to ensure that they remain commensurate with vulnerabilit… (Attachment E 2., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • APRA envisages that a regulated entity would select encryption algorithms from the population of well-established and proven international standards that have been subjected to rigorous public scrutiny and verification of effectiveness. The length of a cryptographic key would typically be selected t… (Attachment E 3., APRA Prudential Practice Guide CPG 234 Information Security, June 2019)
  • In APRA's view, cryptographic techniques would normally be used to control access to sensitive data/information, both in storage and in transit. The strength of the cryptographic techniques deployed would be commensurate with the sensitivity and criticality of the data/information as well as other s… (¶ 50, APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • APRA envisages that a regulated institution would select algorithms from the population of well established and proven international standards that have been subjected to rigorous public scrutiny and verification of effectiveness (e.g. Triple DES, AES etc.). The length of a cryptographic key would t… (Attachment F ¶ 4, APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • A regulated institution would normally select appropriate cryptographic techniques based on the control effectiveness required and the sensitivity and criticality of the data/information involved. The institution's chosen cryptographic techniques would normally be reviewed on a regular basis to ensu… (Attachment F ¶ 3, APRA Prudential Practice Guide 234: Management of security risk in information and information technology, May 2013)
  • Risk-based regulations for the use of encryption which are compared to schemes for the classification of information and take the communication channel, type, strength and quality of the encryption into account (Section 5.8 KRY-01 Basic requirement ¶ 1 Bullet 2, Cloud Computing Compliance Controls Catalogue (C5))
  • 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)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.2)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.2)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.2)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.2)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • Is the proper encryption strength implemented for the encryption methodology in use (check vendor recommendations/best practices)? (4.1(d), 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 proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.) (4.1.f, 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)
  • The length of the MAC being generated or verified is in accordance with ISO 16609 and as agreed to by the sender and receiver. (F2, Payment Card Industry (PCI), PIN Transaction Security (PTS) Hardware Security Module (HSM) - Security Requirements, Version 3.0)
  • The encryption strength is appropriate for the encryption methodology in use. (4.2.1 Bullet 4, Payment Card Industry Data Security Standard Requirements and Testing Procedures, Defined Approach Requirements, Version 4.0)
  • The encryption strength is appropriate for the encryption methodology in use. (4.2.1 Bullet 4, Self-Assessment Questionnaire A-EP and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The encryption strength is appropriate for the encryption methodology in use. (4.2.1 Bullet 4, Self-Assessment Questionnaire C and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The encryption strength is appropriate for the encryption methodology in use. (4.2.1 Bullet 4, Self-Assessment Questionnaire D for Merchants and Attestation of Compliance for use with PCI DSS Version 4.0)
  • The encryption strength is appropriate for the encryption methodology in use. (4.2.1 Bullet 4, Self-Assessment Questionnaire D for Service Providers and Attestation of Compliance for use with PCI DSS Version 4.0)
  • Verify that an additional iteration of a key derivation function is performed, using a salt value that is secret and known only to the verifier. Generate the salt value using an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest re… (2.4.5, Application Security Verification Standard 4.0.3, 4.0.3)
  • Use encryption algorithms that are appropriate for data protection, considering the classification of data, associated risks, and usability of the encryption technology. (CEK-04, Cloud Controls Matrix, v4.0)
  • The entity protects cryptographic keys during generation, storage, use, and destruction. Cryptographic modules, algorithms, key lengths, and architectures are appropriate based on the entity's risk mitigation strategy. (CC6.1 ¶ 3 Bullet 11 Protects Cryptographic Keys, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus – 2022))
  • In-stream - Encryption implementations in the transport layer, such as pre-agreed passwords, are acceptable. (ACCEPTABLE ENCRYPTION APPROACHES - SOFTWARE-BASED ENCRYPTION: 4., HIPAA HCFA Internet Security Policy, November 1998)
  • Standard. A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4 (August 2015) (incorporated by reference in §170.299). (§ 170.210 (c) (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)
  • Standard. A hashing algorithm with a security strength equal to or greater than SHA-2 as specified by NIST in FIPS Publication 180-4 (August 2015) (incorporated by reference in §170.299). (§ 170.210 (c) (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)
  • PIV Cards MAY support card activation by the card management system to support card personalization and post-issuance card update. To activate the card for personalization or update, the card management system SHALL perform a challenge response protocol using cryptographic keys stored on the card in… (4.3.2 ¶ 1, FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors)
  • Before deploying encryption, first determine if encryption is an appropriate solution for the specific ICS application, because authentication and integrity are generally the key security issues for ICS applications. Other cryptographic solutions such as cryptographic hashes should also be considere… (§ 6.2.16.1 ICS-specific Recommendations and Guidance ¶ 1, Guide to Industrial Control Systems (ICS) Security, Revision 2)