This is part 2 of a series on the hidden costs of poorly written firewall requests. Start with the overview if you haven’t read it.

Two correct descriptions of the same thing

Ask a developer what network access their application needs and you’ll get something like: “The API gateway talks to the payment service, which talks to the transaction database.”

That’s accurate. It’s also completely useless for writing a firewall rule.

Now ask the firewall engineer what they need to implement that access:

  • Source: 10.12.4.15/32
  • Destination: 10.20.8.7/32
  • Protocol: TCP
  • Port: 5432
  • Business justification: Payment processing for order service v2.3

Same access. Same intent. Completely different language. And between those two descriptions is a translation step that nobody formally owns.

This is not a knowledge problem

It’s tempting to say “developers just need to learn how firewalls work.” And sure, a basic understanding helps. But this framing misses the point. A backend developer shouldn’t need to memorize IP addresses any more than a firewall engineer should need to understand the payment service’s retry logic. These are different jobs with different mental models, and both models are valid within their own context.

The problem isn’t that either side is wrong. It’s that the handoff between them has no translator.

Think about how other cross-team dependencies work. When a developer needs a database, they don’t write the DDL and send it to the DBA team raw. There’s usually a request process that asks for things in terms the developer understands: what data are you storing, how much traffic do you expect, what’s the retention requirement. The DBA team translates that into schemas and configurations. Firewall requests, for some reason, skip this translation layer entirely. The requester is expected to show up already speaking the firewall team’s language.

What happens without a translator

When there’s no translation layer, one of three things happens. And none of them are good.

The requester guesses. They know they need “database access” so they Google the default port for PostgreSQL, find 5432, and put that in the request. Sometimes they’re right. Sometimes the database is running on a non-standard port, or behind a proxy, or in a different subnet than they assumed. The ticket goes through, the rule gets created, the app doesn’t work. Now you’ve got a second ticket to troubleshoot why the first rule didn’t help, followed by a third ticket for the actual correct rule. Three tickets where one would have done it.

The requester asks around. They message a colleague who did something similar last quarter. That colleague gives them values from memory, which may or may not be current. IP addresses change. Servers get migrated. Subnets get reorganized. The information is stale before it hits the ticket. Another round-trip.

The requester gives up and goes vague. “Please open access from the app servers to the database servers.” They know this isn’t specific enough, but they don’t know how to be more specific without spending an hour they don’t have tracking down network details that aren’t their job to maintain. So they submit what they have and wait for the firewall team to ask the right questions. This is the most common outcome, and it’s the one that generates the most back-and-forth.

The gap in the org chart

In most organizations, nobody owns this translation. The application team owns the application. The network/security team owns the firewall. The space between them, where “the app talks to the database” becomes “TCP 5432 from 10.12.4.15 to 10.20.8.7,” is an organizational no-man’s-land.

Some companies try to bridge this with a network architect or a solutions architect role. When it works, it works well. These people understand both sides and can translate. But they’re usually spread thin across dozens of projects and can’t sit in on every firewall request.

Other companies put the burden on the security team itself. The firewall engineers become the de facto translators, reverse-engineering the requester’s intent from vague descriptions and tribal knowledge about the environment. This works when the team is small and everyone knows the infrastructure. It falls apart at scale, when the firewall team is processing hundreds of requests a month for systems they’ve never seen.

Bridging the gap

The fix isn’t to make developers into network engineers or vice versa. It’s to build the translation into the process so nobody has to do it from scratch every time.

Make infrastructure information accessible. If your CMDB or IPAM has accurate records, give application teams read access. Most requesters would happily provide the correct source IP if they could look it up in under a minute. The problem is they can’t, so they guess or leave it blank. When organizations open up these tools (even read-only), the quality of firewall requests improves immediately. Not because people suddenly understand networking, but because they can copy the right value from a system of record instead of guessing.

Build a service-to-network mapping. If you have a service catalog, extend it to include network details. When a developer looks up “Payment Service v2.3,” the catalog should show them which hosts it runs on, what ports it uses, and what network zone it sits in. This isn’t a trivial project, but it pays dividends everywhere, not just in firewall requests.

Use pre-validation to catch the translation errors. Even with better tools, people will make mistakes. This is one of the reasons I built netbobr. It catches things like invalid IPs, zone conflicts, and port mismatches before the ticket reaches the firewall team. It won’t translate “the app talks to the database” into a proper five-tuple, but it will tell the requester when what they’ve entered doesn’t make sense, and give them specific feedback on what to fix. That’s the difference between “your request is incomplete” and “the destination IP you entered isn’t in any defined network zone, here are the zones available.”

Normalize the ask, not the answer. Instead of a form that asks for raw IPs and ports, consider a form that starts with what the requester actually knows: application name, environment, what service they’re connecting to, and why. Let the form (or the process behind it) do the lookup. Not every organization can automate this fully, but even a partially guided process is better than a blank text field that says “Destination IP.”

The real cost of the gap

The translation gap doesn’t just create bad tickets. It creates resentment. Requesters feel like the security team is deliberately making things hard. Security teams feel like requesters can’t be bothered to do the basics. Both are wrong. Both are reacting to a process that forces them to work across a language barrier with no support.

Every organization has this gap. The ones that struggle are the ones pretending it doesn’t exist, or blaming one side for not speaking the other’s language. The ones that do well are the ones that build a bridge and make it easy to cross.

Next in this series: Part 3: Your Firewall Request Form Is Setting People Up to Fail