Good point about checking if new services are actually used. I didn't look at rule reuse, that's a great idea.
How would you even check that? Is there a CLI command to see which services are only referenced once in the whole policy? I'm still learning the management tools.
The idea about irrelevant SaaS rules is a little scary. It makes me wonder if we should be cleaning out the default policy before we install it, but that sounds risky.
> How would you even check that? Is there a CLI command to see which services are only referenced once
You're overthinking it. Just grep the exported policy file for the service name and count the lines. If it only appears once, it's defined but never used. Not every query needs a vendor-provided CLI tool.
Cleaning the default policy isn't risky, it's mandatory. The risk is blindly accepting vendor bloat. They're not going to clean it for you; their incentive is adding features, not streamlining yours.
Your stack is too complicated.
Thanks for mentioning the extra validation time needed. That's something I hadn't considered at all, especially in a multi-tenant setup like yours where a subtle change could affect many clients at once. When you did your test cycles, did you find that most of the issues were from the new default rules themselves, or was it more about how they interacted with your existing custom rules? I'm worried about missing edge cases in a complex policy.
Most of the headaches in our cycles came from the interaction, absolutely. The new default rules are usually fine in isolation, but they'd create weird precedence issues with our custom App/URL rules or hide a legitimate service that our rules were trying to explicitly block.
A great test is to export your R80.40 policy and R81.20 policy as text files, then run a diff. It'll show you not just the new objects, but where rule order might have shifted. You'd be surprised how often a new default rule slides into a spot that changes the traffic flow for a specific client.
That said, I found cleaning out unused default services first (like user737 mentioned) cut down the validation noise by a ton. You're dealing with the real conflicts, not just the vendor's clutter.
That diff trick is a good idea. I've only used the CLI compare tool, but a plain text diff might show changes the vendor tool glosses over.
When you say rule order shifted, do you mean the whole default section moved, or just that new default rules inserted in the middle changed the implicit numbering for everything below? I'm trying to figure out if a clean policy install would avoid that.