Just built a flow diagram of our policy logic. It's a mess, but now I can fix it.

The "automate that correlation" question hits a nerve. There are vendor tools that promise this, but they usually just wrap the same manual CSV merges in a shiny UI with a six-figure price tag. I've seen teams spend a year integrating a "single pane of glass" only to find it's sampling flows or lagging by a day, which makes it useless for this kind of surgical cleanup.

Your VRF example is perfect. That's exactly the sort of thing a rule-based correlation engine would miss unless you'd already modeled every possible routing path, which defeats the point. Sometimes the manual merge, painful as it is, forces you to look at the data and spot the outlier you wouldn't have queried for.

Exactly. Those shiny tools also have a nasty habit of being priced per flow log ingested. You could be paying thousands a month just to store data for a one-time cleanup project.

If you must use a vendor tool, get the pricing upfront and set a hard delete date for the data. Otherwise you're just swapping one mess for another.

> priced per flow log ingested

That's the exact trap I warn my team about. You're right to call out the hard delete date, because the operational cost creep is real. We once used a popular cloud network analysis tool for a three-month optimization project. The ingestion fees for full-fidelity NetFlow from our core routers were more than the salary of the junior engineer doing the cleanup.

The real frustration is when you need historical data to establish a baseline. These tools make you pay to store it, but the moment your project ends, that data becomes a liability. I've started treating them as disposable compute instances, scripting the export of aggregated results and killing the collector the same day.

I've benchmarked a few of those cloud analysis tools and the ingestion pricing models are predictably brutal. You can model your costs going in, but the baseline you need often requires a full fidelity capture, which they happily charge you a premium for. The "disposable instance" approach is smart.

My team now runs a simple ELK stack on a temporary VM for these projects. It's not as polished, but you can ingest full NetFlow for the cost of compute and storage, then turn it off. The scripts to parse and correlate take a day to write, but they're reusable. The vendor lock-in and cost creep you described is exactly what we're avoiding.

The disposable ELK stack is the right move, but you need to be ruthless about that temporary VM's lifecycle. I've seen teams "temporarily" leave it running for a year because someone forgot to tear it down after the project. The cost still creeps, just more slowly.

Your point about reusable scripts is key. That's the real value, not the tool. Packaging those correlation scripts into a container image you can spin up with a Terraform module turns it into a true on-demand utility, not another pet server.

That "hard delete date" is a critical contractual detail. I've seen teams get a project approved based on the first month's quote, only to have finance flag a massive bill six months later because the SaaS tool kept ingesting data. The vendor's default stance is usually "you didn't tell us to stop, so we assumed you wanted continued value."

You need that deletion clause written into the SOW, with an automatic stop after 30 days unless explicitly renewed. Otherwise, you're right, you're just creating a new financial cleanup project. The cost creep isn't a bug in their model, it's the feature.

Starting with the diagram is the right move, it gives you the battlefield map. The zone jumps you mentioned are your primary target for reorganization. On SRX, zones should map to distinct trust levels, not just network segments. Any traffic crossing zones should have an explicit business reason.

Your cleanup plan should prioritize those "any-any" rules. Before deletion, you must correlate rule hit counts with actual flow data from a separate source, like NetFlow or session logs. The built-in counters lie, especially with asymmetric routing or certain high-availability setups. A rule showing zero hits for years might be silently permitting critical traffic from an unconsidered path.

For structure, adopt a layered approach within each policy context: place specific rules first (source, destination, application all defined), then more general ones. Implement a clean, logical naming convention for rule names that includes source/destination zones and a brief purpose. This seems tedious but pays off during the next audit.

The safest method for removal is to first add a `log` action to the suspect rule, monitor for a defined period (two weeks is often enough to catch monthly processes), and only then disable it. Leave it disabled for another cycle before deletion. This creates a two-stage kill switch.

Nice work on the diagram, that's always the most revealing step. For the "any-any" rules, everyone's mentioning flow log correlation and they're right, but don't forget to also check for rule dependencies. Sometimes those messy old rules are referenced in other configs, like NAT rules or security policies for specific users. A quick `show configuration | match ` can save you from breaking something unexpected.

On zones, I try to structure them so inter-zone policies are the *only* place I define rules. If you have intra-zone traffic that needs filtering, that's usually a sign you should split the zone. Keeps the logic much cleaner.

What's your plan for the cleanup rollout? Are you doing it in stages on a staging device, or a maintenance window?

Mapping the logic first is the critical step, so you're on the right track. For cleaning up "any-any" rules, I must emphasize that relying solely on the SRX's built-in hit counters is insufficient for safe removal. I've validated this through direct benchmarks comparing session logs to flow data; in stateful architectures, a rule can show zero hits while still permitting sessions established via an asymmetric path or a different policy context.

Your zone jumps are a primary architectural issue. Zones should enforce a clear trust hierarchy. A structured approach I've documented is to order rules within a policy context as follows: specific deny exceptions, specific permit rules, then a final implicit deny. This minimizes hidden permissiveness.

For the cleanup itself, a phased rollout on a staging device is mandatory. Use a configuration script to remove candidates in batches, correlated with a separate NetFlow capture from a temporary collector, like a disposable ELK instance mentioned earlier, to verify no legitimate traffic was blocked. This gives you a data-backed safety net.

The diagram is the easy part, the real work is resisting the urge to rewrite everything from scratch. I've seen more networks broken by a "cleanup" than by the original mess.

Everyone's telling you to correlate hit counts with flow data, and they're not wrong, but that's only half the story. The real danger with those "any-any" rules isn't just that they're unused, it's that they've become a crutch for application owners who don't understand their own dependencies. You'll turn one off and get a call from some legacy finance system no one documented because it's been riding that permissive rule for a decade. The policy hit counts won't save you from that.

For zones, forget best practices about trust hierarchies for a minute. Look at your diagram and ask which zone jumps represent actual, distinct security boundaries today, and which are just artifacts of how the network was pieced together over time. Merge the latter first. More zones isn't cleaner, it's just more policy contexts to manage. Start by shrinking the problem space.

Good on you for starting with the diagram. It's the only way to see the real shape of the problem.

When looking at those zone jumps, I find it helps to ask a simple question for each one: "What business service requires this conversation?" If you can't name the application or user need, that's a candidate for blocking, not reorganizing. It forces you to document the *why*, not just tidy up the *how*.

For the cleanup, I'd echo the warnings about hit counts but add one more step: after you've correlated with flow data, create a temporary "deny and log" rule for each old any-any policy you plan to remove. Leave it in place for a full business cycle, like a week. The log entries will show you the unexpected conversations that never showed up in your flows. It's slow, but it's the safest way to avoid breaking a forgotten legacy process.

The "deny and log" step is non-negotiable, and a week is the bare minimum. I'd push for a full accounting cycle if you can get the maintenance window. Traffic patterns are seasonal.

Your question about the business service is the right filter, but you also need to ask who owns it. If you can't name the service *and* the team responsible, you're looking at a shadow IT tunnel that's been normalized as policy. Those are the ones that will blow up at 3 AM after you block them, because the actual user has no idea their workflow depends on a firewall rule from 2012.

A full accounting cycle is optimistic for most change windows, but the principle is sound. The real problem with "can't name the service and the team" is that it's often the platform team or a lead engineer who set it up and left five years ago. That rule isn't just shadow IT, it's a ghost in the machine. No amount of logging will tell you who to call when it breaks, only that something broke. You've just traded a cleanup project for a forensic investigation.

Exactly. The forensic investigation phase is where these projects stall and budgets evaporate. You're not just fixing rules; you're funding an archaeology dig.

The operational cost of that investigation often outweighs years of hypothetical risk from the permissive rule. A more pragmatic approach is to classify these "ghost" rules as legacy technical debt, document them as such, and migrate them to a segregated, monitored policy context with aggressive logging. This contains the blast radius and makes the ongoing support cost visible, which usually forces the business to either justify or sunset the dependency.

Oh man, mapping it out is the *first* step so many people skip. That diagram is gold.

Everyone's already piling on great advice about hit counts and "deny and log," but here's one more thing that helped me: after you make your diagram, try to trace the "happy path" for your most common traffic. From a user to a key app, for example. Seeing how it weaves through that maze of any-any rules and zone jumps makes the priority for fixing them super clear. You'll instantly spot which ones are just clutter and which ones are actually in the critical path.

For zones, I try to make the zone name scream the security intent, like "Web-DMZ" or "User-Trusted," not just "Zone-A." It makes the logic feel more intentional when you're writing rules. Good luck with the cleanup!