Data in transit and at rest
Data is exposed in two different ways and the controls differ accordingly. In transit it can be read or altered by anything on the path; at rest it can be read by anything with access to the storage, including backups, snapshots and the people who administer them. What follows is the set of controls to check against for each.
Data in transit
Section titled “Data in transit”Transport encryption
Section titled “Transport encryption”- TLS 1.3 for all data in transit, falling back no lower than TLS 1.2. TLS 1.3 is the current version of the protocol — there is nothing above it to require.
- Forward secrecy on any TLS 1.2 listener: ECDHE key exchange and AEAD cipher suites only. TLS 1.3 gives forward secrecy by construction, because every key exchange in it is ephemeral, so this is a TLS 1.2 configuration decision rather than a separate control.
- SSL 3.0 and TLS 1.0/1.1 disabled everywhere, including on internal listeners and on anything that terminates TLS on behalf of something else.
- End-to-end encryption where an intermediary terminates TLS but should not see the payload. Terminating at a load balancer and continuing in plaintext behind it is a decision to be taken deliberately, not by default.
Note that a cipher suite is not a cipher: AES-256 names an algorithm, whereas TLS_AES_256_GCM_SHA384
names a TLS 1.3 suite. Configuration that lists ciphers where suites are expected tends to be
configuration that was never tested.
Network controls
Section titled “Network controls”- Private connectivity — VPC endpoints, peering or a dedicated link — in preference to traversing the public internet at all.
- Network segmentation, so that reaching one service does not mean reaching the data stores of every other.
- An API gateway or equivalent as the single ingress point for service APIs, so that authentication, rate limiting and logging have one place to live.
- A web application firewall in front of anything publicly reachable.
- VPN for remote administrative access, with no standing inbound access to management ports.
Authentication and authorisation at the edge
Section titled “Authentication and authorisation at the edge”- Multi-factor authentication for human access, without exception for administrators.
- Certificate-based or workload-identity authentication between services, rather than shared static credentials.
- OAuth 2.0 and OpenID Connect for delegated authorisation and federated identity.
- JWTs validated on every hop that relies on them — signature, issuer, audience and expiry. A token that is decoded but not verified is a request parameter.
Operational practices
Section titled “Operational practices”- Certificate rotation automated and monitored, with expiry alerting well ahead of the date.
- TLS configuration re-tested after every change to a listener or a load balancer.
- HTTPS everywhere, with HSTS, and no mixed-content exceptions.
Data at rest
Section titled “Data at rest”Encryption
Section titled “Encryption”- AES-256 for file- and object-level encryption.
- Transparent data encryption on databases, understanding what it does and does not cover: it protects the files on disk, not a query issued by a credentialed caller.
- Volume-level encryption for anything holding a copy — including snapshots, backups and replicas, which are regularly forgotten.
- Encryption keys held in a managed key service rather than in application configuration.
Access control
Section titled “Access control”- Role-based access control, with roles that correspond to a job rather than to a person.
- Least privilege as the default grant, widened only on evidence that the narrower grant fails.
- Access reviews on a schedule, with a named owner per dataset who has to sign them off.
- Break-glass access that is time-bound, logged and alerted on.
Key management
Section titled “Key management”- Hardware security modules or a managed equivalent for key material.
- A documented rotation policy, and a demonstrated ability to rotate rather than a stated one.
- Key backup and recovery rehearsed — the failure mode of good key management is losing access to your own data.
- Separate keys for separate data categories, so that one compromised key does not open everything. See separation of duties.
Classification and lifecycle
Section titled “Classification and lifecycle”- Sensitivity levels defined, and every dataset assigned one.
- Retention periods set per level and enforced automatically rather than by intention.
- Deletion that actually deletes, including from backups, within the period the retention policy claims.
- A data inventory that records where each classified dataset lives — a control that cannot be applied to data nobody knows about.
Controls shared by both
Section titled “Controls shared by both”Monitoring and logging
Section titled “Monitoring and logging”- Audit trails for access attempts, successful and failed, on data stores as well as on applications.
- Alerting in real time on the events that matter — privilege changes, bulk reads, access from unexpected locations — rather than on volume.
- Log aggregation into a store with its own access controls, since logs frequently contain the data they describe.
- Regular security assessment: penetration testing, vulnerability scanning and code review, each on a stated cadence.
Governance
Section titled “Governance”- Security controls documented, so that an auditor and an on-call engineer read the same thing.
- Incident response procedures written down and rehearsed.
- Business continuity and disaster recovery plans tested against a real restore, not a checklist.
- Compliance obligations mapped to specific controls, so that a requirement has an owner.
Maintenance
Section titled “Maintenance”- Patching on a schedule with an emergency path for actively exploited issues.
- Configuration held as code and drift detected automatically.
- Anti-malware and data loss prevention where the data flows justify them.
- Capacity planning, because a control that is disabled to keep a system up is not a control.