Security

Can it withstand a deliberate attack?

Security is the pillar with an adversary. Everything else in this framework defends against entropy, accident, and load, forces that are indifferent to your design. Security defends against someone who studies your design specifically to defeat it, and who adapts when you improve.

That changes the engineering. You cannot reason about worst cases from a probability distribution, because the distribution moves. You cannot rely on a control being unlikely to be tested. And you cannot declare the work finished, because the attacker does not.

What this pillar covers

• Establishing a security baseline and measuring drift from it
• Segmentation and the containment of blast radius
• Data classification, and letting it drive every other control
• Identity: who can act, as what, and for how long
• Authorization: least privilege, and the review that keeps it least
• Network exposure and flow control
• Encryption in transit and at rest
• Hardening and patching
• Secrets
• Software supply chain integrity
• Detection, response, and rehearsal

What it does not cover

Where data physically resides, who at the provider could technically reach it, and how you prove compliance to an auditor belong to Sovereignty & Compliance. The two pillars meet constantly, encryption appears in both, but they answer different questions. Security asks whether an attacker can get in. Sovereignty asks who, legitimately and by design, already has access, and under which jurisdiction.

Availability under non-adversarial conditions belongs to Reliability. The detection and response tooling is shared with Operational Excellence; the threat-specific parts stay here.

The central idea

Assume breach. Not as pessimism but as a design constraint: build as though an attacker already holds a foothold inside your boundary, because eventually one will.

That single assumption reorganizes everything. Internal traffic gets verified rather than trusted by virtue of its origin. Credentials get lifetimes rather than permanence. Environments get segmented so that a compromise is a contained incident instead of a catastrophe. Detection becomes as important as prevention, because the interesting question stops being whether they get in and becomes how long they are inside before you notice.

The second idea is that security is upstream of itself. Nearly every control in this pillar depends on knowing what you are protecting. Which is why SEC 3, data classification, appears early and is referenced by almost everything after it. Teams that skip it end up applying uniform controls: too heavy for most of their data, too light for the part that mattered.

Where to start

1. Design principles
2. Tradeoffs

Questions

Eleven questions. Numbers follow the order the decisions are usually made in and do not indicate priority.

---

SEC 1: How do you establish a security baseline and detect drift from it?

Define the configuration standard the environment is expected to meet, derived from the frameworks you are actually assessed against. Measure drift automatically and treat a regression as an incident rather than a backlog item.

→ Best practices

SEC 2: How do you segment the environment to contain a compromise?

Isolation comes in strengths, from a separate organization down to a filter in your own code, and each step moves enforcement closer to that code. Choose the level per data set from its protection need rather than by default, and know who enforces the boundary you picked.

→ Best practices

SEC 3: How do you classify data, and how does the classification drive your controls?

Assign every data set a sensitivity class before deciding where it lives, how it is encrypted, who can reach it, and how long it is kept. Uniform controls across mixed classifications are simultaneously too expensive and too weak.

→ Best practices

SEC 4: How do you manage identities and the lifetime of their credentials?

Federate human identity to a single source with strong authentication. Give workloads their own identities with credentials that expire on their own rather than by someone remembering. Static long-lived keys are a finding, not a configuration.

→ Best practices

SEC 5: How do you grant least privilege and keep it least over time?

Assign the narrowest role that permits the work, prefer time-bound elevation for anything privileged, and review actual entitlements against intended ones on a fixed cadence. Permissions only accumulate unless something actively removes them.

→ Best practices

SEC 6: How do you control network flow and limit exposure?

Start from deny-all and open only the flows the workload needs, in the direction it needs them. Every publicly reachable endpoint should be a deliberate decision with a named owner, including egress: outbound access is how data leaves.

→ Best practices

SEC 7: How do you protect data in transit and at rest?

Encrypt all traffic including internal service-to-service calls, and all data at rest including backups, snapshots, and logs. Where classification demands it, hold the keys yourself and know exactly who can technically decrypt.

→ Best practices

SEC 8: How do you harden resources and keep them patched?

Reduce each component to what it needs to run, and establish a patching cadence with a defined maximum exposure window per severity. Unpatched known vulnerabilities are the most common route in and the least defensible in hindsight.

→ Best practices

SEC 9: How do you store and rotate application secrets?

Application secrets belong in a purpose-built store with access control, versioning, rotation, and an audit trail. Not in repositories, container images, environment files, configuration management, or CI variables.

→ Best practices

SEC 10: How do you secure the software supply chain?

Know what your artefacts are built from, scan dependencies and images continuously rather than at build time only, pull base images from a registry you control, and make the path from source to production tamper-evident.

→ Best practices

SEC 11: How do you detect security events and respond to them?

Collect security-relevant signals somewhere an attacker cannot edit them, alert on the patterns that matter, and define who does what when an alert fires. Rehearse it, an incident process first executed during an incident is a document, not a capability.

→ Best practices

Related

• Design principles
• Tradeoffs
• Sovereignty & Compliance: read SEC 3 and SEC 7 alongside SOV 1 and SOV 4