Strong ciphers + perfect forward secrecy
Demonstrate that all systems and applications enforce the use of cryptographically strong cipher suites with perfect forward secrecy while explicitly disabling weak or deprecated cryptographic algorithms.
Description
What this control does
This control mandates the use of cryptographically strong cipher suites with perfect forward secrecy (PFS) for all encrypted communications. Strong ciphers include AES-256-GCM, ChaCha20-Poly1305, and other algorithms with key lengths ≥256 bits for symmetric encryption and ≥2048 bits for asymmetric encryption, while explicitly prohibiting weak or deprecated algorithms such as RC4, DES, 3DES, MD5, and SHA-1. Perfect forward secrecy ensures that session keys cannot be compromised even if long-term private keys are later exposed, typically implemented through ephemeral Diffie-Hellman (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchanges. This control protects data in transit from both active interception and retrospective decryption attacks.
Control objective
What auditing this proves
Demonstrate that all systems and applications enforce the use of cryptographically strong cipher suites with perfect forward secrecy while explicitly disabling weak or deprecated cryptographic algorithms.
Associated risks
Risks this control addresses
- Passive network eavesdropping resulting in plaintext exposure of sensitive data through exploitation of weak cipher algorithms (e.g., RC4, DES)
- Retrospective decryption of captured encrypted traffic if long-term private keys are compromised in the absence of perfect forward secrecy
- Man-in-the-middle attacks exploiting downgrade vulnerabilities to force negotiation of weak cipher suites
- Compromise of session confidentiality through cryptanalytic attacks against deprecated hash functions (MD5, SHA-1) in cipher suites
- Non-compliance with regulatory requirements (PCI DSS, HIPAA, GDPR) mandating strong cryptography leading to financial penalties
- Data breach notification obligations triggered by exposure of protected information through cryptographic weaknesses
Testing procedure
How an auditor verifies this control
- Inventory all internet-facing and internal systems that handle encrypted communications including web servers, API gateways, VPN concentrators, mail servers, and database servers.
- Execute SSL/TLS configuration scans using tools such as nmap with ssl-enum-ciphers script, testssl.sh, or Qualys SSL Labs against each identified system to enumerate supported cipher suites.
- Review cipher suite configuration files (e.g., Apache ssl.conf, nginx.conf, IIS applicationHost.config, load balancer SSL profiles) to verify explicit cipher ordering and disabled weak algorithms.
- Verify that all enabled cipher suites implement perfect forward secrecy by confirming the presence of ECDHE or DHE key exchange mechanisms in scan results and configuration files.
- Confirm that weak or deprecated algorithms (RC4, DES, 3DES, MD5, SHA-1, SSLv2, SSLv3, TLS 1.0, TLS 1.1) are explicitly disabled in configuration files and absent from scan results.
- Test actual negotiated cipher suites by establishing sample connections from client systems using OpenSSL s_client or similar tools with verbose output to confirm PFS-enabled strong ciphers are selected.
- Review cryptographic standards documentation and configuration management records to verify organizational policy mandates strong ciphers with PFS and documents approved cipher suite lists.
- Validate that cipher suite configurations are subject to change control processes by reviewing recent configuration change tickets and approval records.
Where this control is tested