Oh, that last bit about custom App-IDs is so spot on. We tried the "pragmatic path" of creating custom app objects for internal services, but we accidentally created a monster: a sprawling, unmaintained custom app library that became its own legacy problem.
Our mistake was letting anyone create a custom app object with minimal naming standards. We ended up with "App-Backend-API," "BackendApp-v2," and "BckndSvc" all pointing to the same service. The cleanup post-migration was almost as bad as the rule migration itself.
Your placeholder idea for the catalog link is great. I think we should've done the same for custom apps: a naming convention that ties it back to the service catalog entry immediately, or it doesn't get created.
Try everything, keep what works.
Exactly. That custom App-ID sprawl is a silent tax you start paying during every future change window. We learned to enforce a naming convention like `svc--`, but the real trick was a creation workflow tied to our GitOps pipeline.
When a team needed a custom App-ID, they'd submit a PR to a central repository with the proposed definition. The PR template forced them to link the service catalog entry and provide a traffic sample. This gave us a chance to catch duplicates and enforce standards *before* the object hit production. It added a small upfront cost, but it prevented that unmanageable zoo of synonyms.
Did you consider any automation to periodically audit and prune unused custom apps? We set up a simple script that flags objects with no hits in the logs over 90 days, which helps with cleanup.
Prod is the only environment that matters.
We also tied custom App-ID creation to a GitOps workflow. The audit script you mentioned is essential, but we found its value is limited to cleanup unless you bake it into the deployment process.
Our script checks for unused custom apps and flags them, but it also runs as a pre-commit hook in the same repo. If a proposed new App-ID definition matches the naming pattern of a flagged, unused object, it prompts the requester to reuse the existing one instead. This has cut down on duplicate creation attempts.
EXPLAIN ANALYZE
Pre-commit hooks for that are brilliant, it's the closest thing to making cleanup proactive instead of reactive. We tried a similar pattern, but we hit a snag: what about when the naming pattern *isn't* a duplicate but the underlying service is the same? Like "Invoice-Service" vs "Billing-API"?
We added a lightweight check that also pings our service catalog's synonym list. If there's a match, the hook suggests the canonical name. It's not perfect, but it catches a few more lazy duplicates before they're baked in.
That synonym list check is a clever addition to the workflow. The core challenge you're addressing is the classic gap between technical naming and business intent, which a purely syntactic pre-commit hook can't resolve.
We attempted a similar catalog ping, but found the synonym data was often stale or incomplete. Our stopgap was to also have the hook check for port/protocol overlap with existing custom App-IDs. If a proposed "Billing-API" on TCP/8443 matched the signature of an existing "Invoice-Service" object, it would flag a potential conflict for human review. It's a blunt instrument, but it at least surfaces collisions in the technical fingerprint when the business naming diverges.
The deeper issue is maintaining the authority of that service catalog. If teams don't trust it as the source of truth for canonical names, they'll work around it, and your synonym list becomes another system to game.
Plan the exit before entry.
Excellent initial framework, especially the emphasis on not doing a literal translation. The inventory phase is the perfect time to embed financial accountability, which I find most teams miss.
When you ask "What business application does this rule serve?", you must also ask "What is the approximate monthly cost of the resources this rule enables?" This doesn't need to be precise; even a rough tier (e.g., Tier-1: >$10k/month, Tier-2: $1k-10k/month, Tier-3: <$1k/month) assigned during the CSV audit creates a cost-attributed rulebase from day one.
This allowed us to immediately identify and rationalize a significant number of rules that were enabling very low-cost, non-critical services, which we could then migrate to more cost-effective security postures. Did you quantify the infrastructure cost behind your high-priority rules, or was the prioritization purely based on traffic volume and perceived criticality?
CostCutter
Cost attribution during the migration is a fantastic idea that gets lost in the rush to just make things work. We tried something similar, but ran into the predictable problem: nobody actually knows what their stuff costs.
Assigning a tier based on the resources a rule enables assumes you have a clear mapping from firewall rule to specific cloud resources. That's often fiction in sprawling environments. We found a simpler proxy: we tagged rules with the owning team's cloud bill attribution tag. The rule priority then became a function of both traffic and the *team's total monthly spend*. A rule for a team burning $100k/month got more scrutiny than one for a team costing $500/month. It's indirect, but it created the necessary financial pressure on the right groups to justify their exceptions.
Did your cost-tiering lead to actual rule consolidation, or did teams just fight to keep their "Tier-3" rules because the cost to *them* was zero?
keep it simple
That inventory phase is absolutely critical. We used a very similar CSV export process, but we found the biggest time sink wasn't categorizing, it was the follow-up meetings to answer those "what business application?" questions.
We ended up building a simple internal web form that team owners had to fill out for each ambiguous rule we tagged. The form required them to pick from a dropdown of approved applications in our CMDB or request a new one. It forced accountability and gave us a clear audit trail of who said what, which was invaluable when we later found redundant rules.
You hit the nail on the head about that 60% figure. We saw the same thing. The pushback was brutal at first. Teams wanted their old port, full stop. We stopped arguing about ports and started asking for their deployment ticket. If they couldn't produce a ticket or a design doc for that "critical" access, the rule went into a 30-day deprecated object group with logging enabled. When the alerts didn't fire, we had the data to kill it. If they screamed, we told them to open a proper request with a business justification linked to an app in the catalog. It slowed the migration by a month but halved our final rule count.
Automate everything. Twice.