REQUEST: Grace period for GlobalProtect patch checking

[jjhernandez]

Problem:

Because of occasional issues with vendor patches, like MS had early this year, (see URL below), very few companies release patches/updates to clients or servers on the day of release. They test the updates first, then release them days or even weeks later after testing has shown no major issues. GlobalProtect has no capability to delay patch checking to address this test cycle.

http://blog.norsecorp.com/2015/02/16/microsoft-users-battle-buggy-patches-in-februarys-releases/?mkt... 

Request:

1. Add a “grace period” capability into GlobalProtect to delay the checking of patch levels by "N" days from the date of release. Example: Wait 14 days before checking for Patch Tuesday patches to accomodate the testing of the patches.
2. The grace period “out of the box” should be 0 days by default in order to not change existing behavior. Users can then change the default grace period from there.
3. Include groups for "batched" updates released by a vendor. For example; Group defined for each MS Patch Tuesday, group defined for each Apple Security Day release, and so on.
4. Nested groups and user-defined groups should also be available. 
5. Ability to set and/or override the default grace period on a per-patch basis or per-group basis. This would allow customers to address urgent issues such as Zero Day exploits (reduced grace period, possibly all the way to 0) and to delay or prevent enforcement (increased grace period, or set to -1 for “do not enforce”) for low priority and/or problematic updates.

Additional improvements (and corrections) always appreciated.

[nwetech]

I too have put this feature request in directly to our local Palo Alto rep. over 6 months ago.  We have been waiting to implement Windows Update HIP checks until this feature becomes available.

[abarhorst]

I strongly support this request. The current capabilities make HIP matching against patch-management almost useless for us. I cannot enforce patch based policies against ordinary users since the firewall would immediately block traffic as soon as a new patch becomes available. There needs to be a way to match/enforce patch policies only if a patch has not been applied within a configurable period of time after the client first detects the new patch. This would seem like a no-brainer to me. Puzzled as to why this function does not exist in such an expensive product. 

[jjhernandez]

Amending my own request:

The GlobalProtect client simply queries the updaters on the system (Windows Update, Apple Updater, and other supported system updating tools) for what updates/patches they think needs to be applied and reports that information back to the firewalls to have HIP policy applied to them. The data is basically the update and sometimes (not always) the severity information. 

Net: The firewalls today have no clue about the age of a given update/patch that needs to be applied, and therefore can't do a grace period. 

How to make it work: In the enterprise space, using Microsoft WSUS, centralized Apple Updates, etc. allows the enterprise to control the release of updates to the workstations to a schedule of the enterprise's choosing. I.E. Test updates before generally releasing. 

Net: If the central updating server doesn't release the updates, the workstations wont show as needing updates/patches, and the need for a grace period mostly disappears. 

That being said, there is STILL a need for a grace period:

• For Enterprise customers to have a bit of time between release from centralized update servers to everyone actually getting the patches.
• For BYOD or personal devices to have a bit of time between updates being released from vendors and for them to actually received and apply the patches. 

[abarhorst]

"That being said, there is STILL a need for a grace period: For Enterprise customers to have a bit of time between release from centralized update servers to everyone actually getting the patches."

This is specifically what I was referring to. We use WSUS. If a patch is approved, then workstations are immediately locked out of controlled network resources as soon as Windows Update client scans the server at the next scheduled interval. There is no reason why the globalconnect client itself could not be modified to set it's own date/timestamp flag each time a new update is seen, and then pass this data on to the firewall for evaluating the rules.  

[skuo2020]

Looks like we are still waiting for this :grace period" feature for almost 7 years?  This is a must so we can check on BYOD machines.