“Production is down. We just need this IP and port opened right now. Security can review later. Please.”
If you work in security, networking, or infra, you’ve heard that sentence. More than once. And not just at 3pm on a Tuesday. It shows up Friday at 11:07 p.m., right before a release, or mid-incident, with customer impact on the line.
This isn’t “the dev team doesn’t care about security.” It’s a structural failure.
And if you leave it alone, it creates two kinds of long-term risk for the company:
You end up with an ever-growing pile of ad-hoc firewall exceptions that nobody fully understands but everyone is afraid to touch.
You lose the ability to answer basic audit questions like “Who opened this rule, why, and why is it still open?”
In this post, we’ll walk through why this fire-drill pattern keeps happening — and how to break it without slowing the business.
Problem #1: It turns into a fight between “keep the business running” vs “protect the company”
The person asking for the exception is under pressure: downtime, blocked release, angry customer.
The security / network owner is under a different pressure: exposure, breach surface, audit, regulatory impact.
They’re both right.
But because there’s no consistent process, it becomes personal. The request turns into “Are you going to unblock me or are you going to block me?” instead of “Which workflow are we in?”
At that point, firewall policy stops being technical and becomes political. That’s when bad decisions get made at 11 p.m.
In a healthy model, this isn’t a fight at all. It’s just one ticket moving through a defined lifecycle.
Problem #2: The request almost never includes the info needed to say yes safely
Real-world requests often look like this:
“We need DB access opened.”
“Our vendor needs this allowed.”
“Just open 443, it’s only HTTPS.”
That’s basically useless from a risk standpoint.
Security/network can’t approve (or deny intelligently) without basic context:
So what happens? Back-and-forth. Stalled releases. Frustration. And then pressure ramps: “This is urgent. Why are you slowing us down?”
What looks like urgency is often just missing structure.
Here’s the fix: require a proper request template.
A minimally acceptable firewall exception request should include all 5 of these:
Source (Who/which system is initiating the traffic?)
Destination (Exact target IP / FQDN / service?)
Port / Protocol (Not “HTTPS,” but 443/TCP to X.)
Business justification (What dies if we don’t allow this?)
Expiry date (When should this rule be automatically revoked?)
Once those 5 fields exist, two good things happen:
Security can review based on risk, not guesswork.
You have evidence for later: who asked, why they asked, and under what assumptions it was approved.
If those 5 fields are missing, what you actually have is “Slack DMs are now our firewall governance layer.” That’s not process. That’s liability.
Problem #3: “We’ll close it later” almost never actually happens
One of the most dangerous sentences in infrastructure operations:
“Just open it for now. We’ll lock it back down once things are stable.”
In practice, “later” means “never.”
Why that’s dangerous:
Temporary inbound rules stay exposed to the internet far longer than anyone intended.
Internal zones get linked in ways that make lateral movement trivial if an account or machine is compromised.
The rule set becomes so noisy that eventually nobody’s sure which entries are critical, and which ones are landmines.
This is not “technical debt.”
This is “standing external access plus no owner.” That’s breach fuel — and audit pain.
This is why expiry is not optional. Every exception should come with an end date by default.
One way to enforce that is to classify requests by urgency and map them to SLAs and expirations, for example:
Emergency: 4h SLA for review/approval/deploy, very short default expiry.
Standard: 24h SLA.
Planned / recurring: 72h SLA, bundled into the next approved change window.
The cultural rule you want is simple:
A firewall rule with no expiry date is treated as an unmanaged backdoor.
Once people internalize that, “just this once, leave it open forever” stops being acceptable.
Problem #4: Auditors will absolutely ask, and you will absolutely need an answer
Firewall changes are part of most security and compliance frameworks (ISO 27001, SOC 2, etc.). The auditor — internal or external — will ask the same four questions every time:
Who requested this rule?
Who approved it?
Why was it needed (business justification)?
When does it expire?
If you can’t answer those, you don’t look “fast and pragmatic.”
You look “uncontrolled.”
And at that point, Security gets labeled as the team that “can’t prove they’re in control of network exposure.” That hurts you in audits, in customer security questionnaires, and internally with leadership.
Flip side: if you can answer those four questions in a single click, Security suddenly stops being “the team that says no” and becomes “the team that can prove we’re safe.” That’s a credibility shift.
The real issue isn’t the firewall. It’s the lack of workflow.
Everything above sounds like a security/infra problem. But most of it is actually a workflow and evidence problem.
Here’s what a mature firewall change lifecycle looks like:
Request
Submitted via a standard form that forces: source, destination, port/protocol, business justification, expiry date.
Review
Approval
Deployment
Verification
Expiry
When this workflow is tied into your ITSM (Jira / ServiceNow) and your network logs:
Evidence (“who asked / who approved / why / when it ends”) is captured automatically.
“Closing the rule” becomes default behavior instead of wishful thinking.
Dev/infra teams can self-label urgency, which makes SLA expectations predictable instead of political.
That last point is huge.
This is not “Security is adding more red tape.”
This is “We’re all tired of 11 p.m. panic requests, so we’re going to stop operating like a group chat and start operating like an actual change process.”
“Production is down. We just need this IP and port opened right now. Security can review later. Please.”
If you work in security, networking, or infra, you’ve heard that sentence. More than once. And not just at 3pm on a Tuesday. It shows up Friday at 11:07 p.m., right before a release, or mid-incident, with customer impact on the line.
This isn’t “the dev team doesn’t care about security.” It’s a structural failure.
And if you leave it alone, it creates two kinds of long-term risk for the company:
You end up with an ever-growing pile of ad-hoc firewall exceptions that nobody fully understands but everyone is afraid to touch.
You lose the ability to answer basic audit questions like “Who opened this rule, why, and why is it still open?”
In this post, we’ll walk through why this fire-drill pattern keeps happening — and how to break it without slowing the business.
Problem #1: It turns into a fight between “keep the business running” vs “protect the company”
The person asking for the exception is under pressure: downtime, blocked release, angry customer.
The security / network owner is under a different pressure: exposure, breach surface, audit, regulatory impact.
They’re both right.
But because there’s no consistent process, it becomes personal. The request turns into “Are you going to unblock me or are you going to block me?” instead of “Which workflow are we in?”
At that point, firewall policy stops being technical and becomes political. That’s when bad decisions get made at 11 p.m.
In a healthy model, this isn’t a fight at all. It’s just one ticket moving through a defined lifecycle.
Problem #2: The request almost never includes the info needed to say yes safely
Real-world requests often look like this:
“We need DB access opened.”
“Our vendor needs this allowed.”
“Just open 443, it’s only HTTPS.”
That’s basically useless from a risk standpoint.
Security/network can’t approve (or deny intelligently) without basic context:
From where, to where?
Exact port and protocol?
What breaks if we don’t allow it?
How long do you need this open?
So what happens? Back-and-forth. Stalled releases. Frustration. And then pressure ramps: “This is urgent. Why are you slowing us down?”
What looks like urgency is often just missing structure.
Here’s the fix: require a proper request template.
A minimally acceptable firewall exception request should include all 5 of these:
Source (Who/which system is initiating the traffic?)
Destination (Exact target IP / FQDN / service?)
Port / Protocol (Not “HTTPS,” but 443/TCP to X.)
Business justification (What dies if we don’t allow this?)
Expiry date (When should this rule be automatically revoked?)
Once those 5 fields exist, two good things happen:
Security can review based on risk, not guesswork.
You have evidence for later: who asked, why they asked, and under what assumptions it was approved.
If those 5 fields are missing, what you actually have is “Slack DMs are now our firewall governance layer.” That’s not process. That’s liability.
Problem #3: “We’ll close it later” almost never actually happens
One of the most dangerous sentences in infrastructure operations:
“Just open it for now. We’ll lock it back down once things are stable.”
In practice, “later” means “never.”
Why that’s dangerous:
Temporary inbound rules stay exposed to the internet far longer than anyone intended.
Internal zones get linked in ways that make lateral movement trivial if an account or machine is compromised.
The rule set becomes so noisy that eventually nobody’s sure which entries are critical, and which ones are landmines.
This is not “technical debt.”
This is “standing external access plus no owner.” That’s breach fuel — and audit pain.
This is why expiry is not optional. Every exception should come with an end date by default.
One way to enforce that is to classify requests by urgency and map them to SLAs and expirations, for example:
Emergency: 4h SLA for review/approval/deploy, very short default expiry.
Standard: 24h SLA.
Planned / recurring: 72h SLA, bundled into the next approved change window.
The cultural rule you want is simple:
A firewall rule with no expiry date is treated as an unmanaged backdoor.
Once people internalize that, “just this once, leave it open forever” stops being acceptable.
Problem #4: Auditors will absolutely ask, and you will absolutely need an answer
Firewall changes are part of most security and compliance frameworks (ISO 27001, SOC 2, etc.). The auditor — internal or external — will ask the same four questions every time:
Who requested this rule?
Who approved it?
Why was it needed (business justification)?
When does it expire?
If you can’t answer those, you don’t look “fast and pragmatic.”
You look “uncontrolled.”
And at that point, Security gets labeled as the team that “can’t prove they’re in control of network exposure.” That hurts you in audits, in customer security questionnaires, and internally with leadership.
Flip side: if you can answer those four questions in a single click, Security suddenly stops being “the team that says no” and becomes “the team that can prove we’re safe.” That’s a credibility shift.
The real issue isn’t the firewall. It’s the lack of workflow.
Everything above sounds like a security/infra problem. But most of it is actually a workflow and evidence problem.
Here’s what a mature firewall change lifecycle looks like:
Request
Submitted via a standard form that forces: source, destination, port/protocol, business justification, expiry date.
Review
Security / network looks at risk versus business impact. This is where you decide “emergency route” vs “standard route.”
Approval
Routed based on a pre-defined approval matrix.
Example: external inbound access might require both the service owner and a security lead to sign off.
Deployment
The rule is actually pushed to the firewall / cloud SG / gateway.
Verification
You confirm in logs that the rule is behaving as intended — not over-broad, not silently allowing way more than expected.
Expiry
The rule is automatically closed/rolled back at (or before) its expiry, unless it’s explicitly re-requested.
When this workflow is tied into your ITSM (Jira / ServiceNow) and your network logs:
Evidence (“who asked / who approved / why / when it ends”) is captured automatically.
“Closing the rule” becomes default behavior instead of wishful thinking.
Dev/infra teams can self-label urgency, which makes SLA expectations predictable instead of political.
That last point is huge.
This is not “Security is adding more red tape.”
This is “We’re all tired of 11 p.m. panic requests, so we’re going to stop operating like a group chat and start operating like an actual change process.”