The Temporary Permanent Firewall Rule

At 09:17 on a Monday, I discovered a firewall rule that shouldn't exist.

The Discovery

I was reviewing our firewall configuration—routine quarterly audit, documented and scheduled—when I found it.

Rule #147: ALLOW ANY:ANY from 10.0.5.0/24 to ANY:ANY

Translation: anything from the entire Marketing subnet could access anything, anywhere, on any port. No restrictions. No limits. A digital skeleton key to the entire infrastructure.

I checked the rule metadata. Created: October 12th. Three months ago. Comment field: "TEMP - Marketing presentation - DELETE AFTER DEMO"

I did not delete it. Instead, I sent a message to the TTY: "Conference room. Now. Bring your notes."

The TTY arrived within two minutes, which suggested they knew exactly what this was about.

OPERATOR: "The firewall rule."

I pulled up the configuration on the conference room display.

TTY: "Ah. Right. That."

OPERATOR: "Explain."

The Story

The TTY's explanation came in that particular cadence of someone who knows they've made a mistake but isn't quite sure which part was the mistake.

TTY: "There was a user request. Marketing needed to access the development database for a presentation. Real-time data integration demo for a client. Very important."

OPERATOR: "Continue."

TTY: "They needed it urgently. Like, presentation-starting-in-thirty-minutes urgently."

OPERATOR: "And you created a firewall rule allowing their entire subnet unrestricted access to everything."

TTY: "Not everything. Just... network-accessible resources."

OPERATOR: "That is the definition of everything."

TTY: "I was going to make it more specific, but I didn't know which exact server they needed, and they were really stressed, and they said they'd tell me which system after the presentation, and—"

OPERATOR: "And you added 'TEMP' to the comment field and assumed you'd remember to remove it."

TTY: "...yes."

OPERATOR: "Three months ago."

The TTY looked at the date stamp.

TTY: "Oh."

OPERATOR: "Oh."

The Investigation

I pulled up access logs for the past three months. Rule #147 had been used. Extensively.

October 12th: Original presentation access. Legitimate use case.

October 13th: Marketing accessing development database. Fine.

October 18th: Marketing accessing production database. Less fine.

October 24th: Marketing accessing HR systems. Definitely not fine.

November 3rd: Marketing accessing server management panel. How did they even find that?

November 19th: Marketing accessing the security camera feeds. Why.

December 8th: Marketing accessing... my personal documentation repository.

OPERATOR: "They've been exploring."

TTY: "Exploring?"

OPERATOR: "When you give users access to systems, they will click on things. Every link. Every button. Every possible path. Not maliciously. Curiosity. Boredom. The human need to see what's behind closed doors."

I pulled up the access logs for December 8th. Someone from Marketing had read my entire incident documentation from the Great UPS Incident. They'd also accessed the TTY's training notes. And the coffee machine maintenance schedule.

OPERATOR: "Nothing sensitive was compromised. But only because we practice defense in depth and most systems require authentication beyond network access. Your firewall rule opened the door. Subsequent security layers prevented catastrophe."

TTY: "So... no harm done?"

OPERATOR: "Educational harm."

The Lesson (Delivered Theatrically)

I could have simply deleted the rule, sent a stern email, and moved on.

But the TTY needed to understand why this mattered. Not just "don't do this again" but why temporary rules are dangerous and privilege escalation is subtle.

So I did what any reasonable infrastructure architect would do: I created a comprehensive audit report.

"Network Access Control Review: Analysis of Temporary Rule Persistence and Privilege Expansion"

Twenty pages. Including:

• Timeline of rule creation and expansion of use
• Map of all systems accessed via the rule
• Risk assessment matrix (color-coded, naturally)
• Comparison of intended access vs. actual access
• Projection of what could have happened if the rule remained another quarter

I included a section titled "The Principle of Least Privilege: A Case Study" that used this exact scenario as the example.

Then I did something educational: I created a proper firewall rule—specific source IPs, specific destination, specific ports, specific protocols—and showed the TTY what it should have looked like.

Rule #148: ALLOW 10.0.5.42:ANY to 10.0.8.15:3306 (MySQL)
Comment: "Marketing dashboard - Readonly user only - Expires 2025-01-15"
Auto-expire: Enabled
Review date: Weekly

OPERATOR: "This is a temporary rule. Specific source. Specific destination. Specific purpose. Expiration date. Automatic cleanup. Weekly review reminder."

TTY: "That's... a lot more work than what I did."

OPERATOR: "Yes. Security is often more work. But 'quick and temporary' becomes 'permanent and dangerous' faster than you think."

Resolution & Documentation

I deleted Rule #147 at 10:35. Seventeen systems immediately logged connection failures from the Marketing subnet. I had anticipated this.

Three tickets arrived within minutes:

• "Can't access the dev database anymore"
• "Dashboard not loading"
• "Camera feeds down?" (I have questions about this one)

The TTY handled the tickets. They created specific, limited-scope rules for the legitimate use cases. They documented each rule. They set expiration reminders.

It took two hours to properly configure what the original rule had done in thirty seconds.

TTY: "This is so much slower."

OPERATOR: "Yes. But in three months, we won't be having this conversation again."

The TTY is learning.

The Operator's Notes

The moral: 'temporary' in IT is a lie we tell ourselves. Temporary rules become permanent. Quick fixes become technical debt. 'Just for now' becomes 'how it's always been.'

The principle of least privilege isn't about being paranoid. It's about being specific. Access should be narrow, purposeful, and time-limited. Not because users are malicious—they usually aren't—but because access expands to fill available permissions.

The TTY now understands that every firewall rule is a promise: 'This traffic is allowed because...' If you can't finish that sentence specifically, the rule is too broad.

Rule #147 is deleted. Rule #148 and friends are properly scoped. Marketing has appropriate access. The camera feeds remain a mystery.

Quarterly audit: complete. TTY education: ongoing. Documentation: extensive.

Such is security architecture.