The standard nobody reads
Almost every organisation has a security or infrastructure standard: a document with reasonable rules. Almost every one also has resources that break it. Not out of bad faith, but because whoever writes the change does not have the standard in front of them at that moment, and whoever reviews it cannot check thirty rules by eye on every change.
From document to check
The alternative is to write the rules as code that runs against every plan before it is applied:
- 'No data storage may be public.'
- 'All disks and databases are encrypted.'
- 'Every resource carries owner, application and environment tags' (the ones cost allocation needs).
- 'Only these regions are permitted.'
- 'No administration port open to the internet.'
If the plan breaks any of them, the change stops with a message saying which rule, on which resource and why.
Severity levels
Not all rules carry the same weight:
- Blocking: the change is not applied (exposed data, encryption switched off).
- Warnings: it is applied, but recorded and reviewed by somebody (an optional tag missing).
And for exceptional cases, documented exceptions: with an owner, a reason and a review date, never silent (the same logic as in reviewing without slowing down).
Why it works
The standard stops depending on the memory of whoever writes and the attention of whoever reviews. It is met every time, in every environment, on every change. And because the rule is written in one place, improving it improves every review at once.
Rules protect what gets built from code. What remains is whatever existed before it.
How we apply it: Automation and IaC.