Use of cryptography

What the requirement asks

The organization is to define and apply rules for using cryptography effectively, key management included. Purpose: apply cryptography correctly and to good effect so information stays confidential, genuine or unaltered in line with business and security requirements and the legal, regulatory and contractual rules on cryptography. Guidance: consider a topic-specific cryptography policy setting general principles, needed to gain the benefits and avoid misuse; the protection level and classification of information, which determine the type, strength and quality of algorithms; encryption of information on mobile endpoints and storage media and in transit to them; the approach to key management, including generating and protecting keys and recovering encrypted information when keys are lost, compromised or damaged; roles for implementing the rules and for key management including generation; approved or mandatory standards, algorithms, cipher strengths, solutions and usage practices; and the effect of encryption on controls that inspect content, such as malware detection or content filtering. Take into account national regulations and restrictions on cryptography in different countries and cross-border flows of encrypted information (5.31), and make agreements with external cryptographic service providers such as certification authorities cover liability, service reliability and response times (5.22). Keys need secure handling across their whole life, from creation, storage, archiving, retrieval and distribution to retirement and destruction, based on agreed standards and procedures for: generating keys for different systems and applications; issuing and obtaining public key certificates; distributing keys to intended parties and activating them on receipt; storing keys and granting authorized access; changing or updating keys, with rules on when and how; handling compromised keys; revoking or deactivating keys, for instance on compromise or when a user leaves, archiving them in that case; recovering lost or corrupted keys; backing up or archiving keys; destroying keys; logging and auditing key management; setting activation and deactivation dates so keys are used only within their permitted period; and handling legal demands for access to keys, such as producing decrypted evidence in court. All keys need protection from modification and loss, and secret and private keys also from unauthorized use and disclosure; equipment that generates, stores or archives keys is physically protected, and the authenticity of public keys often matters too. Other information: public key authenticity is usually handled through certificate authorities and certificates, or manually for small numbers of keys; cryptography supports confidentiality (encryption), integrity and authenticity (digital signatures, message authentication codes, file integrity checks), non-repudiation and authentication of users and entities; ISO/IEC 11770 covers key management. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Cryptography needs a policy and a key lifecycle. The guidance asks for the algorithm, the key, the storage, the rotation and the retirement.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the topic-specific cryptography policy with approved algorithms, key lengths, protocols and usage by information classification and one live sample together.

Evidence an assessor asks for

• Cryptography policyThe topic-specific cryptography policy with approved algorithms, key lengths, protocols and usage by information classification
• Cryptography policyKey management procedures covering generation, distribution, storage, rotation, revocation, recovery, backup, destruction and activation periods
• Cryptography policyKey inventory or HSM and key management service records with logs of key management activity
• Cryptography policyEvidence of encryption on endpoints, removable media and data in transit, aligned with the policy
• Cryptography policyContracts or SLAs with certification authorities and other cryptographic service providers covering liability, reliability and response times
• Cryptography policyAssessment of cryptography laws for each relevant jurisdiction and of the impact of encryption on content inspection controls

The question an assessor will ask

An assessor will ask for the topic-specific cryptography policy with approved algorithms, key lengths, protocols and usage by information classification, then trace it to the system it protects. For A.8.24 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Deprecated algorithms or short keys remain in use because no approved list is enforced
• Keys have no defined lifetime and are never rotated
• Private keys are stored alongside the data they protect or in source code
• Expired or compromised certificates are not revoked promptly

Before the next audit

Before the next audit, check one live sample for this gap: deprecated algorithms or short keys remain in use because no approved list is enforced.