A.8.24
Use of cryptography
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control requires the organization to define through policy, and operate consistently, when, where, and at what strength cryptography is applied in order to protect the confidentiality, integrity, and authenticity of information. Cryptography is not completed by algorithm selection alone: the full key lifecycle from generation to destruction, together with legal/regulatory constraints (nationally approved algorithms, import/export rules, contractual requirements), must be considered for the protection to be effective in practice. The objective is to exclude unvalidated in-house algorithms and weak configurations, maintain cryptographic strength proportionate to the level of risk, and be prepared to replace algorithms as they age over time.
Key checkpoints
- Is an organization-wide policy on the use of cryptography established, specifying the scope of application (data at rest, data in transit, authentication data, and so on) and the approved algorithms/minimum key lengths?
- Do the algorithms and key lengths in use meet current recommended levels, and are weak or to-be-retired algorithms (legacy hashes/block ciphers) identified with a replacement plan in place?
- Are management procedures and responsibilities defined for the entire key lifecycle: generation/distribution/storage/use/rotation/destruction/recovery?
- Is storage/transport encryption applied according to classification, risk, and obligations, with password-verification hashing distinguished from encryption of recoverable data and exceptions recorded?
- Are legal/regulatory cryptography requirements (nationally approved algorithms, import/export rules, contractual requirements) identified and complied with?
- Is access to cryptographic modules/key stores (HSM, KMS, and so on) controlled, and are related activities logged and reviewed?
Implementation guidance
- Document the scope, list of approved algorithms, minimum key lengths, operating modes, and exception approval procedure in the cryptography policy, and prioritize the targets of application by linking to risk assessment results.
- Apply encryption at rest (disk/database/file) and encryption in transit (secure protocols/versions such as TLS) distinctly, and disable weak protocols (legacy TLS) and weak cipher suites.
- Generate keys from a secure random source and store them in a protected key store suited to the key's purpose and risk (an HSM, a KMS, an OS- or TPM-backed keystore, an access-restricted key file, and so on). Never embed plaintext keys in source code, configuration files, or logs.
- Define rotation and recovery policies by key type and purpose. On suspected compromise, revoke use for new encryption/signing and replace the key; where existing data must be recovered, decrypt/migrate it under restricted procedures before secure key destruction. Decide backup/escrow needs by key purpose and apply separation of access and dual control.
- Use only validated standard algorithms and trustworthy libraries, prohibit in-house cryptographic development, and continuously manage the versions of libraries in use and their known vulnerabilities.
- Build crypto-agility into the design to prepare for the aging of algorithms/key strength, and periodically re-review and update the policy and its state of implementation.
Evidence
- Cryptography policy/guideline documents and the approved algorithm/minimum key length reference table
- Status table of encryption at rest/in transit (algorithm/key length/protocol version per target system)
- Key management procedures and the key lifecycle register (generation/rotation/destruction history)
- Access privilege lists and access/operation logs for key stores (HSM, KMS, and so on)
- TLS configuration review results (evidence of disabling weak versions/cipher suites) and vulnerability assessment reports
- Records of the review of compliance with cryptography-related laws/regulations
Nonconformity examples
- A cryptography policy exists but lacks the scope of application and minimum key length criteria, so cryptography is applied inconsistently across systems.
- Information requiring encryption under risk or applicable obligations is stored without protection, or password verification uses unsuitable schemes such as plain MD5/SHA-1.
- Legacy TLS (1.0/1.1) and weak cipher suites remain enabled on production servers.
- Cryptographic keys are hardcoded in plaintext within application source code, configuration files, or repositories.
- Key-purpose-appropriate lifetime/rotation criteria and compromise-response procedures are absent, allowing continued use of keys that can no longer be trusted.
- An unvalidated proprietary cryptographic algorithm is used, or an approved-algorithm requirement actually applicable to the organization is not met.