This is the final part of a series on the hidden costs of poorly written firewall requests. Start with the overview if you haven’t read it.
The copy-paste problem
Every organization has a Dave. Dave is the guy who got a firewall rule approved six months ago for a project that’s similar to yours. You don’t really know how to fill out the firewall request form, and the documentation is either nonexistent or a 30-page PDF you don’t have time to read. But Dave’s ticket went through. So you ask Dave to forward you his request, you swap out the server names, and you submit it.
Dave’s request was incomplete. It had the wrong subnet mask. It listed three ports when only one was needed. The business justification said “same as project X” which doesn’t actually tell anyone anything. But it got approved because the firewall engineer on duty that day knew the environment well enough to fill in the gaps mentally, and because it was a slow week.
Your copied request, submitted three months later, lands on a different engineer who doesn’t have that context. And the cycle of back-and-forth begins.
Why people rely on tribal knowledge
Nobody copies old tickets because they want to submit a bad request. They do it because the alternatives are worse.
The official documentation is overwhelming or missing. Most organizations have a network security policy. It’s 40 pages long, written in security jargon, and was last updated in 2019. Nobody reads it to figure out how to fill in a firewall request form. Other organizations have no guidance at all, just the form and the assumption that you’ll figure it out.
The form gives no examples. As covered in part 3 of this series, most forms are designed to collect data, not to teach. And as explained in part 5, in some cases, nobody has time to read the ones that do teach. A requester staring at a blank form with no reference has two choices: guess or find someone who’s done it before. Copying a previous ticket is faster and feels safer than guessing.
Asking the security team feels adversarial. In organizations where the relationship between requesters and the security team is strained, people avoid asking for help. They don’t want to look incompetent. They don’t want to bother the team. They don’t want to get lectured about what they should already know. So they rely on peer knowledge instead, even when that knowledge is incomplete or outdated.
It worked last time. The most insidious part of tribal knowledge is that it often produces results. Dave’s incomplete request got approved. Your copy of Dave’s request might get approved too, especially if it lands on an engineer who takes the path of least resistance. Each successful submission reinforces the belief that this is how it’s done. The fact that the resulting rule is broader than necessary or based on incorrect information doesn’t surface until much later, if it surfaces at all.
How tribal knowledge degrades the ruleset
The damage from copy-paste culture is cumulative and subtle. No single copied ticket is a disaster. But over years, the effects stack up.
Errors replicate. If Dave’s original ticket had the wrong port, every copy of Dave’s ticket has the wrong port. If the subnet mask was too broad, every derivative request inherits that over-permissive scope. One mistake doesn’t just persist. It multiplies.
Outdated information spreads. Server IPs change. Subnets get reorganized. Applications move to new hosts. Dave’s ticket from six months ago referenced infrastructure that may no longer exist in the same configuration. The person copying the ticket doesn’t check whether the details are still current, because they’re not aware that anything changed.
Business justifications become meaningless. When people copy tickets, they often copy the justification too, or write something equally vague: “per standard process,” “same as previous request,” “needed for app deployment.” The firewall team can’t assess risk from these descriptions. They can’t determine whether the access is still needed during a cleanup review. The justification field, which is supposed to be the link between a rule and its business purpose, becomes noise.
Patterns calcify. Over time, the copied ticket format becomes the de facto standard. New team members learn to write firewall requests by looking at what their colleagues submitted, not by reading documentation. The organization develops an informal template that nobody designed, nobody validates, and nobody maintains. It just evolved from one guy’s ticket that happened to get approved.
The feedback loop that never closes
The core issue behind tribal knowledge reliance is the absence of a feedback loop. When a request is incomplete and the firewall team fills in the blanks or approves a broad rule, the requester never learns what was wrong. They submitted something, it got approved, and they move on. There’s no signal telling them “here’s what a better request would have looked like.”
This means the organization’s collective knowledge about how to write firewall requests never improves. Each person learns just enough to get their ticket through, often from the person who came before them, who learned the same way. It’s a game of telephone where the original message was already garbled.
Nobody in this loop ever learns the right way to do it. They only learn a way that sometimes works.
Breaking the tribal knowledge cycle
Create and maintain living examples. Not documentation. Examples. Two or three annotated firewall requests that show exactly what a complete, well-written ticket looks like, with explanations of why each field is filled in the way it is. Post them next to the request form. Link to them in the confirmation email when someone starts a new ticket. Update them when the form or the environment changes. People will pattern-match against examples far more readily than they’ll read a policy document.
Build a reference catalog for common scenarios. Most firewall requests fall into a handful of categories: web application needs database access, application needs to reach an external API, new server needs management access, vendor needs remote access for support. For each common scenario, publish a template showing the expected values. “If you’re requesting database access for a web application, here’s what the request should look like.” This replaces the informal tribal templates with maintained, accurate ones.
Send useful feedback on every rejected ticket. Not “incomplete, please resubmit.” Instead: “The destination port field is blank. For the application you mentioned (Product X), the required port is TCP 5432 per the vendor documentation here: [link]. Please update and resubmit.” This teaches the requester something specific. The next time they submit a ticket, they’re more likely to look up the port themselves. Multiply that across dozens of requesters and the baseline quality of submissions starts climbing.
Make good requests visible. When a request comes in that’s perfectly written on the first attempt, acknowledge it. A quick message to the team, a thumbs-up in the ticket, a mention in a team meeting. Positive reinforcement is cheap and it works. It also gives other requesters something to aspire to, a real example from a real colleague, instead of copying Dave’s bad ticket from six months ago.
The cultural shift
Tribal knowledge fills a vacuum. It exists because nothing better was available. The way to displace it isn’t to tell people to stop copying tickets. It’s to give them something better to copy.
This is the through-line of this entire series. Bad firewall requests aren’t caused by bad people. They’re caused by a process that doesn’t give people the information, the tools, or the feedback they need to do it right. Fix the process and the people follow.
Clear examples. Accessible tools. Immediate feedback. A form that helps instead of hinders. These are small investments. But they compound in the same way that bad tribal knowledge compounds, just in the opposite direction. Each good request makes the next one more likely. Each useful piece of feedback raises the floor. Over months, the ticket queue looks different. Over years, the entire ruleset looks different.
The hidden cost of bad firewall requests starts with a process that leaves people guessing. It ends when you give them a reason to stop.
This is the final post in the series. Read the full series:
- Part 1: The Hidden Cost of Poorly Written Firewall Requests (Overview)
- Part 2: The Translation Gap - Why App Teams and Firewall Teams Speak Different Languages
- Part 3: Your Firewall Request Form Is Setting People Up to Fail
- Part 4: Nobody Reads the Docs (and Your Firewall Pays the Price)
- Part 5: How Deadline Pressure Turns Firewall Rules Into Technical Debt
- Part 6: Tribal Knowledge Is Poisoning Your Firewall Ruleset