Install Policy: X Changes from Y sessions number

[Aidan_Luby]

Our management server has about 8 policies now and I used to like the Install Policy window where it indicates the amount of changes and sessions since the last install of the selected policy but now I find it confusing and misleading.

Our administrators often say: "Should I install this policy? I only changed 2 things but it shows hundreds of changes since the last install."

It's misleading because these numbers are the amount of changes in any session or policy on the current SMS since the current selected policy has been pushed, even if most of those changes or sessions never impacted the current policy. 

I can understand some changes are global and affect all policies but most are not. I also understand a lot of changes are just objects changed and added/removed in the global object database but it would then be useful if during install of a policy it shows the amount of global changes compared to the amount of changes that actually apply to the current policy being installed. So the second number would include rules that are changed added or deleted on the current policy, or to objects that are in the current policy.

Below is an image of what I saw last time I went to install policy on one of the gateways that doesn't get many edits done to it. About 600 or so of these changes have nothing to do with the policy I was about to install. I know the context of this but other administrators might get very confused and just choose to not install at all when they see this number. 

What do you think?

[Vladimir]

Valid question, but what would you expect to see if, for instance, you have changed a single object's properties with that object being present in multiple policies?

This will inevitably lead to counter increments for each rule where the object is present, each group this object is a member of, etc..

In that later case, if an object is a member of multiple groups, even if the group is not used in the rulebase, it will still be counted as a change.

[Aidan_Luby]

You might be correct about the complexity of that. I think you would just have a counter per policy of rules changed added or removed that are part of the policy installation. This counter could consider just rules added changed or deleted; or it could also include rules changed by objects edited elsewhere. I still think this is doable.

[Timothy_Hall]

That limitation as far as number of displayed changes was already noted in my document here:

R80+ Change Control: A Visual Guide 

I'd say that all the necessary data is probably there in the postgres database to make the number of displayed changes reported on the policy installation screen only the ones that directly impact the configuration of that gateway.  But what about things like Global Properties, Automatic NAT rules, implied rules and such?  While it may well be possible to calculate this information, the overhead involved in larger configs would almost certainly cause a delay at the install policy screen and is probably not something that should be performed automatically every time policy is installed, unless the administrator explicitly asks for it.  As it stands now the total number of changes being reported at the policy installation screen is quick and easy to calculate and just a basic sanity check.

In R77.30 and earlier SmartWorkflow had a "Compare Policies" (diff) feature that is exactly what you are looking for.  There has been some occasional chatter about the functions of SmartWorkflow being integrated into R80+ management, see here:

Will (Smart)Workflow come back?

Supported software blades in R80 

This was also mentioned in the follow up to the Dorit Dor‌ AMA:

https://community.checkpoint.com/community/checkmates-live/blog/2017/09/02/i-am-dorit-dor-vp-of-prod... 

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Aidan_Luby]

I'd say for things like the Automatic NAT policy you would include those changes in the calculation if the Installation Target matches that of the policy that's currently selected. I think this could apply in other global places as well.

[Steve_Runyon]

I, too, found this discomfiting at first. I've handled changes in two ways:

- install all policies once a week no matter what to keep the change count from being too high.

- in each session name or comment, mention the policy that the changes affect, so in the "view changes" list you can tell which ones you can ignore