This is part 5 of a series on the hidden costs of poorly written firewall requests. Start with the overview if you haven’t read it.
The Friday afternoon compromise
It’s 3 PM on a Friday. A project is going live Monday morning. The firewall request came in Tuesday but it was incomplete. The security team asked for clarification Wednesday. The requester responded Thursday, but with only partial information. Now the project manager is pinging the security team lead asking if the rule can be in place by end of day.
The firewall engineer looks at the request. They have a source subnet but not a specific host. They have a destination server but the port is listed as “application ports” with no specifics. They have two options:
- Send it back again, ask for exact details, and tell the project manager the go-live is delayed until at least Wednesday.
- Write a rule for the whole source subnet to the destination server on a broad port range, get it done in 10 minutes, and let the project proceed.
Option 2 wins. Almost every time. And everyone involved knows it’s not ideal. The firewall engineer makes a mental note to tighten the rule later. The requester is relieved. The project manager is happy. Nobody is thinking about what just got added to the ruleset.
“We’ll tighten it later” never happens
This is the lie that keeps firewall rulesets bloated across the entire industry. And it’s not that people are dishonest. It’s that the conditions for “later” never arrive.
Monday morning, the firewall team has a fresh batch of requests. The engineer who wrote the broad rule on Friday is now working on those. The mental note about tightening the rule is already fading. By Wednesday, it’s gone entirely. Three weeks from now, nobody remembers that the rule was supposed to be temporary. Three months from now, someone queries the ruleset and sees a rule allowing a /24 subnet to reach a server on ports 1-65535 and wonders what it’s for. The business justification in the ticket says “application deployment.” That’s not enough to determine whether the rule can be narrowed without breaking something.
So it stays.
This pattern repeats across hundreds of rules over years. Each one was a reasonable decision at the time. Each one was supposed to be temporary. Collectively, they turn the firewall into something nobody fully understands or trusts.
The compounding effect
Individual broad rules are manageable. The problem is what happens when they accumulate.
Audit findings pile up. Every compliance framework, PCI DSS, CIS Controls, NIST, calls out overly permissive rules. When an auditor reviews your ruleset and finds dozens of rules using “any” for source, destination, or port, each one generates a finding. Each finding requires documentation, investigation, and a remediation plan. Security teams end up spending weeks preparing for audits that would take days if the ruleset were clean.
Troubleshooting becomes guesswork. When a security incident occurs and you need to trace network access, a clean ruleset tells a clear story. A bloated one tells you almost nothing. “Yes, this traffic was allowed, but so was everything else from that subnet.” Broad rules make it harder to distinguish legitimate access from unauthorized access, because the firewall was never configured to tell the difference.
Rule cleanup becomes risky. The longer a broad rule sits in production, the harder it is to tighten. Applications may have been built on top of the overly permissive access. Services you didn’t know about might be relying on ports that were never formally requested. Tightening a rule that’s been in place for two years risks breaking something, and nobody wants to be the person who caused an outage because they tried to clean up a firewall rule. So the rule stays broad. The debt compounds.
New requests inherit the mess. When a requester is preparing a new firewall request, they sometimes look at existing rules for reference. If the existing rules are broad and sloppy, the new request will be too. “The other rule for this subnet uses ‘any’ for ports, so I’ll just request ‘any’ as well.” Debt breeds debt.
The real timeline of a broad rule
Here’s what the life of a hastily approved rule actually looks like:
The “temporary” rule ends up costing more total effort than doing it properly the first time. The initial shortcut saved an hour. The audit response, the traffic analysis, the meetings about remediation, the risk acceptance documentation: that costs days.
Breaking the cycle
The root cause here isn’t lazy engineers or unreasonable project managers. It’s that the firewall request process creates situations where the only practical choice is a bad one. Fix the process and the pressure drops.
Pre-validation catches the obvious issues before the deadline hits. netbobr uses its built-in rules to alert the user when their requested firewall opening is obviously overly permissive. A requester can run their request through it for a quick validation before submitting the ticket. It’s not bulletproof, because nobody knows what least privilege means for your individual application, but it catches the issues where any security reviewer would have a concern from a risk perspective: overly broad port ranges, “any” protocol selections, zone policy conflicts. If the requester validates on Tuesday, the Friday afternoon panic doesn’t happen because the ticket arrived clean on Wednesday.
Require a tightening review as a formal step. If a broad rule has to be approved under deadline pressure, log it explicitly as a temporary exception with a mandatory review date. Not a mental note. Not a comment in the ticket. A scheduled ticket that appears in the queue 30 days later, assigned to someone, with the original request details and traffic logs attached. This turns “we’ll tighten it later” from a vague intention into a tracked task.
Track the ratio of broad rules to precise rules. If 40% of your implemented rules use “any” for source, destination, or port, that’s a leading indicator that your request process is broken. Measure it monthly. Report it. Make it visible. When security leadership can see the trend, they can allocate time for cleanup before the audit forces it.
Give the firewall team air cover to say no. This is a leadership problem, not a technical one. If the security team feels empowered to push back on incomplete requests without being blamed for project delays, they’ll push back. If every pushback results in an escalation to a VP, they’ll stop pushing back and start writing broad rules. Leadership needs to decide: is it acceptable to delay a go-live by two days for a proper firewall rule, or is it acceptable to carry an overly permissive rule for years? In practice, the two-day delay is always cheaper.
Close the feedback loop on deadline-driven compromises. After a broad rule is approved under pressure, follow up with the requesting team. Not to blame them, but to understand what went wrong in the process. Was the request submitted too late? Was the form too hard to fill out? Did they not know where to find the information? Each of these answers points to a different process fix. Without this follow-up, you’re treating symptoms while the root cause keeps producing new ones.
The real cost
Gartner has estimated that 99% of firewall breaches are caused by misconfiguration, not firewall flaws. Overly permissive rules are a misconfiguration. Every broad rule approved under deadline pressure is a small increase in the probability that your firewall won’t protect you when it matters.
That’s the real cost. Not the wasted hours, not the audit findings, not the cleanup projects. The real cost is that your firewall, the thing you’re counting on to enforce network segmentation and least-privilege access, is full of holes that your own process created.
Next in this series: Part 6: Tribal Knowledge Is Poisoning Your Firewall Ruleset