Global protect gateway is reusing cached HIP reports by default if no HIP report is received at login

[M.Theeuwes]

Dear all,

We experienced a strange issue recently where a client of ours reported a connectivity issue (not related to HIP, but related to a firewall rule). When we tried to find the client in the recent HIP logs we noticed its last HIP report was from a few months earlier.

In the security logs the client was visible as connected that day.  We created a TAC case for this trough our Palo Alto supplier and we learned from TAC that by default a Global Protect gateway “reuses” the last known cached HIP report at initial login if it for some reason can’t receive a new fresh HIP report from the client. In this case the client had something installed that interfered with HTTPS traffic. After cleaning this client all worked fine for that client.

But the fact that the Global Protect gateway by default “recycles” an old cached HIP report if it does not receive a fresh copy at initial login got us “spooked” of cause. (Because a malicious actor could also prevent a client from sending in the latest HIP report by “messing up” the HTTPS connection). We discussed this case further with TAC but their final verdict is that the function of reusing of the last available HIP report is “by design” for stability / availability reasons and that this can’t be manually altered. Only mitigation is to set a log-expiration and disk-quota setting on the HIP reports to 1 day (which is the minimum allowed value). This of cause mitigates the risk a bit for us (narrowing the “attack window”) . But does not solve the problem fully. Because with a setting of 1 day a “compromised” client can still “pass” the HIP check falsely with a cached report if it connected “healthy” before on that same day. According to TAC we can only open a feature request to get an option to disable this default HIP report “recycle” behavior. Which our supplier did in our name. But we don’t know if or when this feature request would be handled. We are of cause not verry happy with this case outcome. We implemented HIP checks (and bought the Global Protect license) to keep possibly compromised clients “out”, and now we learned this check can be “bypassed” if a report is not sent at all by the client (by accident or maliciously).

Did anybody else experience this problem before? If so, are there any other mitigations / solutions we and TAC might have missed?

Kind regards,
Mark Theeuwes
IT Architect/Network Engineer

SHIMANO EUROPE B.V.
High Tech Campus 92
5656 AG Eindhoven (NL)
mark.theeuwes@shimano-eu.com
http://www.shimano.com

[BPry]

@M.Theeuwes,

Sadly there's not a lot of good solutions for this outside of custom monitoring being built out. You can get an active client list through the API and validate that they have a HIP report on the firewall active within a provided timeframe. It's a tacky solution to something that shouldn't need to be monitored, but that's what I've found to be the best middle ground.