Security: design principles

1. Assume breach

Design as though an attacker already has a foothold inside your boundary. Not because your perimeter is bad, but because every perimeter eventually fails and the ones that fail quietly are the dangerous kind.

The consequences are structural. Internal service calls authenticate rather than trusting the network they arrived on. A compromised workload identity reaches its own data and nothing else. Lateral movement is something you actively obstruct, not something the perimeter was supposed to prevent. And detection carries weight equal to prevention, because under this assumption the interesting metric is not whether an intrusion occurs but how long it goes unnoticed.

This principle is what makes the difference between an architecture with a hard shell and a soft interior, and one that is uniformly resistant.

2. Trust is granted, never inherited

Being inside the network is not an identity. Neither is having been authenticated an hour ago, nor running in the same project as something trustworthy.

Every access decision should be made on current evidence: who is asking, what they are asking for, whether their credential is still valid, whether the request fits the pattern. Location is a weak signal that was historically over-weighted because it was easy to measure.

The practical test is to ask, for any component: what would this be able to reach if its credentials were stolen tonight? If the answer is “everything in its network segment”, trust is being inherited somewhere.

3. Least privilege, expiring by default

Grant the narrowest permission that allows the work, and grant it for the shortest time that allows the work.

The second half is the one that gets dropped. Permissions accumulate: someone needed elevated access for a migration in March and still has it. Entitlement growth is silent, unidirectional, and eventually produces an environment where the theoretical access model and the actual one have nothing in common.

Prefer mechanisms that expire on their own over mechanisms that require someone to remember to revoke. Short-lived credentials, time-bound elevation, access that must be renewed rather than removed. A control that depends on human diligence over years is a control that has already failed; it just has not been tested yet.

4. Layer defences; no single control is load-bearing

Every control fails eventually, misconfigured, bypassed, or defeated by a technique that did not exist when it was chosen. The question for any control is not whether it might fail, but what happens when it does.

If the answer is “the attacker reaches the data”, that control was load-bearing and the design is brittle. Encryption at rest matters precisely because access controls sometimes fail. Network segmentation matters precisely because a workload sometimes gets compromised. Each layer is justified by the assumed failure of the ones around it.

The corollary is worth stating: layering means accepting that individual controls are imperfect, which is a healthier posture than the search for the one control that is not.

5. Security is continuous, not a milestone

An environment is secure at a moment, against known techniques, in its current configuration. All three of those change.

Configurations drift. Dependencies acquire disclosed vulnerabilities weeks after you shipped them. Permissions accumulate. Someone opens a port for debugging and the change outlives the debugging session by two years. None of this involves anyone doing anything wrong. It is the normal entropy of a system under active development.

Which means security posture has to be measured, repeatedly and automatically, against a stated baseline. A penetration test is a sample, not a state. The useful question is not “was this secure when we built it” but “how would we know if it stopped being secure last Tuesday”.

---

Related

• Overview: the questions this pillar asks
• Tradeoffs
• Sovereignty & Compliance principles: the adjacent pillar, and the one most often confused with this one