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.
Additional improvements (and corrections) always appreciated.
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.
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.
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:
"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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!