The Skeleton
Policy scaffold

Cryptography and Key Management Policy

States what must be encrypted, with what, and who can reach the keys, which is the part that actually decides the strength.

What it has to decide

  1. Approved algorithms and minimum key lengths

    Name them, and reference a standard rather than restating one, so the policy does not need reissuing every time guidance moves.

  2. What must be encrypted, in which state

    At rest, in transit, and in use where applicable. Blanket statements that everything is encrypted are unverifiable and therefore untrue somewhere.

  3. Where keys live, and who can reach them

    This is the whole policy. Encryption whose keys sit beside the data on the same system with the same access controls has changed nothing except the compliance answer.

  4. Separation of duties over keys

    The person who administers the data store must not also administer the keys protecting it.

  5. Rotation and revocation, with periods

    Say the period, and say what happens on suspected compromise, including the plan for re-encrypting existing data.

  6. Certificate lifecycle

    Ownership, inventory and expiry alerting. Expired certificates cause more outages than most attacks.

How it is usually got wrong

  • Data is encrypted at rest by the storage platform, and every account with data access also has key access, so the control resists only physical theft of a disk.
  • Keys are held in source control, or in an environment variable readable by the whole deployment pipeline.
  • There is no key inventory, so the blast radius of a compromised key cannot be determined.
  • Rotation is stated annually and has never occurred, because nobody has worked out how to re-encrypt what already exists.
  • Certificate expiry is discovered by the outage rather than by an alert.

Worked extract

What a decision looks like once it has been madeData classified Confidential or Restricted is encrypted at rest using AES-256 or an equivalent approved algorithm, and in transit using TLS 1.2 or above. Keys protecting Restricted data are held in a dedicated key management service and are not accessible to any credential that also has access to the data they protect. Administration of the key management service is separated from administration of the data stores, and no individual holds both roles. Data-encrypting keys are rotated every twelve months and key-encrypting keys every twenty-four months; where rotation requires re-encryption of existing data, the re-encryption plan is documented before the key is issued rather than after. All certificates are recorded in the certificate inventory with a named owner, and alerts are raised at sixty, thirty and seven days before expiry.