How does your org manage change requests and shared rules for firewalls?

I'm trying to improve information availability and change management on my team. Since we're upgrading some of our boundary equipment, it seems that now is the best time to try and change things for the better.

From my experience, it seems that Palo's lend themselves to enterprise management much more so than Juniper or Cisco variants. However, our Palo deployment is relatively young and we still have plenty of other vendors to support. Excepting the Palos, all of our management of other vendors is CLI-only.

Basic information / issues:

• All FW Change requests are submitted via ticket.

• Post-deployment, customers frequently do not maintain records of their ticket.

• Internally, it is up to the engineer to track the tickets they work (e.g. it is not tracked in a central location outside of the ticketing system).

• Customers frequently request after-the-fact additions to their changes (sometimes submit a new one, sometimes not).

• No internal documentation or tags/notes on the FW on a per-ticket basis for rules.

What the above means is that, depending on the person doing the ticket, we may have one rule that allows the original request but the follow-on rule (even if it is technically only adding a single IP) may be a separate rule entirely. This has lead to pretty severe bloat with rules, especially if the ports or IPs submitted are superfluous. Does your org implement timely rule reviews and delete any unused or modify 0-hit rules?

This issue is somewhat compounded by having multiple DMZs and multiple egress points, so some DMZs may have a rule or NAT that needs to be replicated / advertised / etc. in case of failover, which may add a layer of complexity to tracking changes or migrating rules.

Additionally, how does your org standard object names or rule sets? This is, again, dependent on the engineer and there may be objects such as "1.1.1.1-32-DEPT1" or "DC1-DNS." It's not terrible, but I'd like some type of order.

And finally... with all of this combined together, sometimes we have rules that just draw blanks. No idea why it's there, who it belongs to, etc. but we still need them to exist. The ultimate goal is to eliminate that and make the rules easily trackable and engineer-readable.

Would appreciate any suggestions!