When do multiple policies make sense?

[Sam_Ponder]

Hello Checkpoint Gurus,

When does it make sense to have multiple policies?

Our current environment is the following:

• a 4600 cluster(r77.30) - main office
• a 5400 cluster(r80.10) - in testing to replace the 4600 cluster in the main office
• a 5400 (r80.10) - DR data center
• a 3200 cluster (r80.10) remote office
• some 1180(r77.20) for remote offices - that are going to be migrated to 3200's (r80.10)
• a 410 mgmt appliance (r80.10)

We are running IPS on everything, except a few of the 1180's, and have plans on using IPS on the replacement 3200's.

I was thinking the following would make sense:

• a policy for all the r77.x
• a policy for all the r80.10

Any suggestions, comments or critiques are greatly welcomed and appreciated.

Thanks in advance.

Sam

[PhoneBoy]

In the case of R77.x and R80.x gateways, it definitely makes sense to have separate policies.

This allows you to leverage the new features of R80 policies such as inline layers on the gateways that support them.

For other situations, "it depends."

For many sites that have the same basic policy requirements (e.g. branch offices only allowing outbound access) it makes sense to combine them into a single policy.

If a given site needs a radically different access policy, I would give it a separate policy.

[Sam_Ponder]

Thank you, Dameon.

[Ben_Collins]

For a deployment of this size, I'm a fan of one policy per site.  This allows for the individual sites to have smaller, more concise, easier to read and manage policies.  It also makes it easier and less human error prone to make changes to one site while leaving other unaffected.  I've run into problems before where the wrong install on was used in 1 rule of a 500 rule policy, or where policy has been installed accidentally to production environments outside of change management because of the combined policy.  I find it way easier to keep a policy well organized if it's smaller and only for a specific site.  For larger deployments I definitely support grouping of like policies together though, so perhaps the 1100 offices could be grouped into a shared policy, but the other sites probably have different enough needs that they can justify a policy of their own.

[Maarten_Sjouw]

As an MSP we run all kinds of combinations of single policy with 10 gateways to 10 policies for 12 gateways.

It all depends on commonalities and differences. 

Anything that has a DMZ and a local office behind it that more or less uses the same outgoing policy as all branch offices, you can go either way, depending on the number of rules you need for the DMZ environment and the internet access rules.

To minimize problems that, when you need to allow a specific remote application for all your users, will pop up as you forget to add it to one of the policies, this will not happen when you have a single policy.

When you have a lot of lines for the DMZ and a few for internet access, you could opt for a single policy for that DMZ site and use a layer that you reuse for different policies.

Don't forget that you can also use the Install-On column when you have a mix, in these cases we use a group of rules specific to that location and use section titles to show where each location specific rules start.

So the bottom-line comes down to the point where you have to look at the functionalities, group them together when you have many overlapping rules and separate the others into a policy per function/location.

The version has nothing to do with it, if you feel you need to start using layered policies, you need to make sure the gateways this applies to are upgraded to R80.10.