Define and use cryptography standards
You must establish and apply sound cryptographic practices to have any strong and sustainable security assurances. Almost all technical security assurances ultimately depend on cryptography including authentication and authorization mechanisms, communication security (such as TLS/SSL), data security, and more. If attackers can find a weakness in the underlying cryptographic implementation, all of the other security assurances will quickly unravel.
It is critically important to use the correct cryptographic solution to protect data from unintended disclosure or alteration while data is being stored (at rest) or transmitted (in transit). To achieve this, it’s necessary to know what data you need to protect via encryption, what mechanisms should be used to encrypt that data and how encryption keys and certificates will be managed.
Threat modeling, described in practice 3, is a great way to help identify scenarios where data that needs to be protected by encryption exists.
Because this is a complex topic where many developers are not cryptography experts, it is critical to have clear standards and guidance (documentation, examples, etc.) for how to use cryptography properly and to prevent the implementation of bespoke algorithms.
Providing specifics on every element (algorithms, key lengths, cipher modes, key and initial vector generation techniques and usages, and cryptographic libraries) of the encryption implementation is also necessary and requires expert input, which may not be available. However, a good general rule is to only use industry-vetted encryption libraries as it is intended to ensure a correct and secure implementation of the cryptographic algorithms as well as appropriate security patching as needed.
4.1 Encrypt data in transit and at rest - Ensure data is encrypted at rest and in transit, this includes security-sensitive information and management and control data. For encryption in transit, use only strong versions of TLS (see recommendation) for all internet traffic and ideally, traffic within private networks. For encryption at rest, be sure you understand the protections an encryption solution provides. While many easily deployable encryption solutions exist to protect data on a device or disk from theft (offline attack), they do not protect against online compromise through application logic, and additional solutions are required in these situations to encrypt data before it's written to storage (encrypt in transit).
- Microsoft Learn: Solving the TLS 1.0 Problem, 2nd Edition
- Microsoft Learn: Disable legacy TLS
4.2 Post-Quantum Cryptography (PQC) - We recommend prioritizing symmetric encryption where applicable and subsequently adopting post-quantum cryptography (PQC) for asymmetric encryption once standardized and approved by relevant setting bodies and governments, as recommended by cybersecurity agencies globally.
- Microsoft: Post-quantum cryptography (PQC)
- Microsoft: Starting your journey to become quantum-safe
4.3 Cryptographic agility - The practice of implementing cryptographic solutions to enable changes to new cryptographic mechanisms, algorithms and libraries when the need arises, such as in the case of vulnerabilities discovered in libraries that compromise sound algorithms, or when an encryption algorithm might be considered broken at any time. Cryptographic agility is critical to any successful plan to efficiently apply new cryptographic updates, including the adoption of quantum-safe algorithms.
- Microsoft Research: Cryptographic agility and its relationship to circular encryption
4.4 Encryption key and certificate management and rotation - Encrypting data is only a portion of a successful cryptography standard and it's also essential to define how to manage, protect and rotate encryption keys and certificates. Keys and certificates have a limited lifespan, and it is necessary to define mechanisms to manage the lifecycle of keys and certificates, including mechanisms to both create new keys and certificates once the previous ones are near expiration and to rapidly rotate in the event of a security incident, such as unintended access. Anyone who can access an encryption key or private key can access the encrypted data, and therefore it's necessary to control who (whether a person or a service) has access (see Practice 2.1 Identity) and provide a clear audit log of that access (see Practice 2.5 Use approved tools).
- Microsoft Learn: Encryption and key management overview
- Microsoft Learn: Encryption and key management in Azure