Security Policy organization best practices?

[jsalmans]

We're working on an audit of our security policies to start getting rid of some generalized rules and start making things more specific.  I figured we could do some organization at the same time.  I'm curious how others are organizing their security policies and what best practices might be here.

Coming from an ASA background, my original security policy setup on our PA boxes was to organize and group based on source zone, organized then by zones of higher to lower security concern.  This has made it easy to see how related rules work together wihtout needing to try to use search filters.  On the other hand, it isn't the most efficient due to:

• Higher utilized firewall rules may not be towards the top
• Where one rule could be used if access to a host, network, or zone used the same application/services for all sources, in this design a separate rule would be created with the same destination and app/service info for each source zone.

I've also considered the use of useless rules as organizational dividers.  Creating a rule that allows or disallows the same leve of access as the rule above it, but is named something like "Start of Internet rules-------------------" and then disabling the rule would allow for a certain amount of visual organization.

[BPry]

@jsalmans,

Honestly I would just utilize tags. With the tag browser you can easily search through the policies where you require to do so, and the majority of my configuration is done through straight up XML modifications that get pushed out to the firewalls. Really there isn't a 'best practice' for this, it's whatever works for you and your team. 

Also just FYI on the following,

• Higher utilized firewall rules may not be towards the top
  • This really doesn't matter. While the security policies are read in a top-down approach the time seperation between the first rule and the last is so minimal that you can barely measure a difference when you're actively trying to. 

[jsalmans]

Thanks @BPry

So after thinking about this more and reading your reply... since we have Panorama, I was wondering if the Pre and Post rule organization may help as well.  Our initial deployment was all done on our firewalls, so when we converted to Panorama pretty much everything went in as a Pre rule.

What I was thinking was to design a grid view in our internal documentation that would have our security zones listed on both axis.  We could use this to help determine what type of ruleset would likely be needed for each zone-to-zone situation (i.e. blacklist or whitelist).  I was thinking then that the default rule for each combination ("allow all" rule for a blacklist and "deny all" rule for a whitelist) could exist in the Post ruleset.  Pretty much everything else we'd add would be in the Pre ruleset.

For zone combinations that share a list type, blacklist or whitelist, security policy could be shared if the access required is the same.