Prisma Access HIP object Windows patch management

[K.Herath]

We have created a HIP profile and configured windows patch management. However, the options under this is not very clear. I have to get some clarifications on this

Missing Patches - Severity

1. When the operator is set to Greater Than or Equal To, what values are valid in the field?
2. We currently use 3, assuming this represents Critical Windows security patches. Please clarify whether this is correct and what the other values represent.
3. What do each of the three options in the Check drop-down mean?
4. How does each option behave when the Item Table is populated or left empty?
   Enforcement outcome
1. If the HIP profile is attached to a deny security policy, which combinations would block a Windows endpoint with missing Critical security patches?
2. What other useful enforcement outcomes can be achieved through different combinations of these settings?
   
   GlobalProtect Prisma Access 

[JayGolf]

Hi @K.Herath ,

The patch severity values are:

0 = Low

1 = Moderate

2 = Important

3 = Critical.

So your current setting of Greater Than or Equal To 3 is correct if you want the HIP object to match endpoints with missing Critical patches.

The Check options evaluate the missing patches reported by the endpoint:

has-any: Matches when the endpoint is missing any patch that meets the configured criteria.

has-none: Matches when none of the configured patch entries are reported as missing.

has-all: Matches when all configured patch entries are reported as missing.

When the Item Table is populated, the Check selection is evaluated against the patches entered in that table, together with the configured severity.

When the Item Table is empty, the severity becomes the primary condition. For example:

Severity: Greater Than or Equal To 3

Check: has-any

Item Table: empty

This should match a Windows endpoint reporting at least one missing Critical patch.

To block those endpoints, add the HIP object to a HIP profile and reference that profile in a deny security policy above the applicable allow rule.

I would recommend validating the behavior first using the endpoint’s HIP report and the HIP Match logs before applying the deny rule broadly.