Every cloud environment I've ever worked in has one. A security group with a rule that's too open. A 0.0.0.0/0 on a port that has no business being reachable from the whole internet. An "allow all" that got added during a migration three years ago and was going to be temporary. A legacy rule nobody remembers writing.
And here's the part that makes it interesting: everybody already knows about it. It's not hiding. Security has flagged it. The team that owns the account agrees it should be tightened. There's no argument about whether it's wrong. It's wrong, everyone says so, and it's still there.
That last part is what I want to talk about, because it's not laziness and it's not incompetence. It's the most honest example I know of the thing this whole series is about.
Put yourself in the seat of the person who'd actually make the change. You go to narrow that rule. First question: what's actually using it? And nobody can answer that with certainty. Maybe it's a batch job that runs quarterly. Maybe it's a monitoring probe from a vendor. Maybe it's nothing and it's been dead for years. Maybe it's the thing that pages you at 2am if it stops working. You don't know, because there's no reliable inventory of what depends on that rule — and the rule has been there long enough that the people who'd remember are gone.
So now you're being asked to change something, you can't fully see what it holds up, and if you tighten it and you're wrong, something breaks. Not in a clean, obvious way — in the way cloud networking breaks, where a connection just silently starts timing out and it takes three people two hours to trace it back to your change. And there's no button that puts it back the way it was. You revert by hand, under pressure, hoping you remembered the old CIDR exactly.
Then stack the incentives on top. The person best positioned to tighten that rule is measured on uptime. Tightening it is all downside for them: if nothing breaks, nobody notices; if something breaks, it's their name on the change that caused the outage. Doing nothing is the only move that's safe for the person making it.
When security says "just tighten it," what the owner hears is "take a personal risk you can't size, for a reward you won't get credit for, with no clean way back if you're wrong." And they're not being difficult. That's an accurate reading of the situation. The reason a known, agreed-upon exposure sits there for years isn't that people don't care. It's that the rational move for every individual is to leave it alone.
This one rule has all three problems in it at once. You can't prove what depends on it — that's the inventory problem. You can't undo it cleanly if it breaks — that's the missing rollback. And the person who'd make the change is punished for the downside and unrewarded for the upside — that's the incentive mismatch. It's the same story from the rest of this series, compressed into a single line in a single security group.
Imagine the person tightening that rule could see, before they touched anything, what actually talks through it — the live dependencies, not a guess. And imagine that if they narrowed it and something did break, putting it back was one deliberate action, not an hour of manual reconstruction under pressure.
Now the whole calculation flips. The change is knowable and it's reversible. You're not betting your on-call reputation on a guess anymore. You tighten the rule, you watch, and if you were wrong you're back where you started in the time it takes to notice.
The rule everyone knows is wrong doesn't stay wrong because it's hard to type the new CIDR. It stays wrong because of everything around the change — what you can't see, and what you can't take back. Fix those two things and the standoff that's lasted three years becomes a two-minute change.