An enterprise platform has accumulated thousands of network security rules over years, and nobody can determine whether a given rule is still needed. What is the diagnosis and what would you change?

The diagnosis

Rules were added and never removed, because the cost of adding is borne once and the cost of removing is unbounded risk. Every rule was created to solve a real problem. Nobody can safely delete one, because nothing records who needed it, and the cost of being wrong — breaking production — is much larger than the benefit of tidiness.

The result is a policy that grows monotonically. Its stated purpose is least privilege, and its actual effect is a large permissive surface nobody understands.

Two aggravating factors:

• Rules reference IP ranges rather than identities, so they cannot be read as intent. A rule allowing 10.4.0.0/16 says nothing about what may talk to what.
• No expiry. Rules added for a migration completed three years ago still exist.

What to change

1. Rules reference identity, not addresses. Security groups referencing other security groups, or policy expressed in terms of service identity. Then a rule reads as "the order service may reach the payment service", which is reviewable, survives IP changes, and can be reasoned about by someone who was not there.

2. Every rule carries an owner, a justification and an expiry. Metadata enforced at creation. An expiry does not mean automatic deletion — it means automatic review, with a default toward removal if nobody claims it.

3. Flow logs to prove usage. The reason nobody can delete a rule is missing information, and that information is obtainable: measure which rules actually carry traffic. A rule with no matching flows for ninety days is a strong deletion candidate, and the evidence makes the decision defensible.

4. Delete in observation mode first. Where the tooling supports it, mark a rule for removal and log what would have been denied. This converts a risky deletion into a measurement, which is what makes cleanup politically possible.

5. Default-deny with explicit allow, expressed as code. Policy in version control, reviewed like software, applied by pipeline. This solves the ownership question structurally: a rule has an author, a review and a history.

6. Micro-segmentation only where it pays. Full per-service segmentation is expensive to maintain. Segment by trust boundary — internet-facing, application, data, management — and apply fine-grained rules only inside the boundaries that matter.

What not to do

Do not attempt a big-bang cleanup. Deleting hundreds of rules at once produces an outage whose cause is one of hundreds of changes, and the organisational consequence is a permanent freeze on ever touching network policy again. Incremental, evidence-backed removal with observation mode is slower and is the only approach that survives its first mistake.

The principle

A security control nobody understands is not a security control. A permissive rule that is documented, owned and reviewed is safer than a restrictive one that is unexplained — because the second will eventually be worked around by someone in a hurry, and nobody will know it happened.