I've found that fairly often HIPS will block some processes from running even though there is an exception created to allow a certain activity to happen. And sometimes, even an exception that was working correctly will suddenly start blocking a process that was supposed to be allowed. In another case, I had a set of Exchange Clusters that keep getting blocked by a signature that had an exception created for it so I had HIPS automatically create an exception, and it still kept blocking the process

Can anyone tell me why?

Anticipating in advance some of the standard questions, I *am* checking the IPS rules policies applied to the specific OU this system resides in. The systems are successfully checking in to the ePO server and apparently getting policy updates.

The exception rule is fairly broad; "all users" are allowed to run a specific authorized process, no advanced details are specified. In most cases the rule was created automatically by HIPS ('Create exception'), and edited to make it relevant to a broader set of users/hostnames.

Just speculating out loud, a couple of things come to mind that I wondered if it was relevant or not.

For one, I stuck with the default "Exception name" field when creating exceptions. If multiple exceptions were created based on the same signature, would having duplicate exception names maybe cause HIPS to scan just the first exception and skip the second exception? (I noticed in many cases, when the exceptions wouldn't successfully apply there were multiple but separate exceptions to that particular HIPS signature).

Another thing I wondered about, even though a machine appears to be successfully communicating with the ePO server, how can you tell for sure that it's actually receiving and applying any policy changes?

You might need to open a Service Request to have this reviewed further. With HIPS debug logging enabled, we can compare the exception and violation together to ensure that match properly.

For one, I stuck with the default "Exception name" field when creating exceptions. If multiple exceptions were created based on the same signature, would having duplicate exception names maybe cause HIPS to scan just the first exception and skip the second exception? (I noticed in many cases, when the exceptions wouldn't successfully apply there were multiple but separate exceptions to that particular HIPS signature).

When adding IPS Exceptions via an event, the Exception name will carry over to the event, but once you edit the Exception, you can change the name. Exceptions with duplicate names is not known to cause any issues that I've seen.

Another thing I wondered about, even though a machine appears to be successfully communicating with the ePO server, how can you tell for sure that it's actually receiving and applying any policy changes?

Since the HIPS Client UI doesn't have much configuration to display, the method I've used (for basic checking) is firewall rule changes. Those are displayed visibly in the HIPS Client UI console.

This is interesting, because we have this EXACT same issue. Some random signature will suddenly start firing on some process we've already allowed via exception. Then, the only solution is to re-save the IPS Rules policy, perhaps with the original exception re-created, in a flurry to try to prevent the possible outage or user impact that the block was causing.

It is very frustrating. This has happened a couple of times in the last year. In both cases, we've opened support tickets, but it required us to submit various log files and MERs, but by the time we could collect those logs, we had already fixed the issue through the standard "re-save the policy" trick, so our logs were pretty much useless. Makes no sense at all.

In one case, nothing happened policy-wise that would have even caused systems to refresh their policies, and in another case, it strangely corresponded to a HIPS content update that was pushed out to clients, but the offending signatures were not ones that were changed in the content update.

I suppose I'm glad that this is now a semi-documented issue, and that this is not just happening to us, so we have somewhere to point when we're asked for an explanation when this happens again.

Yea, that's the approach I usually use to get the exceptions re-applied; just re-save the file and hope the ePO sees it as a policy update and pushes out the change.

Kary Tankink - do you know if it might be possible that if there's a large number of exceptions in a policy that it might start reaching a limit where it starts to get unreliable? i.e. if the number of exceptions created in a policy starts to get large, say more than 100 or so, does the policy start to gag or something?

Kary Tankink - do you know if it might be possible that if there's a large number of exceptions in a policy that it might start reaching a limit where it starts to get unreliable? i.e. if the number of exceptions created in a policy starts to get large, say more than 100 or so, does the policy start to gag or something?

I don't have any specific information/solutions about this, but if you are having issues like this, I would definitely get McAfee Support involved. In regards to a large number of exceptions, I would recommend following best practices on policy management (if you already aren't doing so). The IPS Rules and Trusted Application policy are multi-slot policies, so instead of trying to run with a single large policy, instead use smaller policies to manage exceptions.

See page 38, section FAQ — Multiple-instance policies for details on how multi-slotting policies work within Host IPS.

There is likely a deeper root to the issue, but sometimes when clicking "create exception" on an event, versus trying to create a manual exception will ease the issue. Some people may be having these same symptoms described in this thread, but may not have the same root problem.

We opened a support ticket with McAfee Platinum support. It turns out there's a known issue in HIPS 7 that McAfee doesn't intend to fix; the fix is upgrade to HIPS 8.

What's happening under the hood, is that the "advanced details" of one exception merges (on its own, without anything being done by the end user) with another exception that doesn't have any advanced details configured. In effect, this makes an existing exception much more restrictive than it's supposed to be. It doesn't actually change the xml file containing the IPS rules policy, but somehow the way the exception is applied to the system gets garbled with extra unwanted restrictions.

The way to fix it is as mentioned in an earlier post - clicking through the menus on that particular exception without making any actual changes to the policy, and then saving at the end, which forces ePO to think the policy has been updated and it gets pushed out as a new policy once again.

We don't seem to have the issue on some customized IPS rules policies created for a specific much smaller subset of machines. The two policies where we have the issue are policies that have a large number of exceptions (i.e. ~ 150 exceptions) and have a very large number of machines using that policy.

Thanks for updating - our issue is HIPS 8, similar intermittent issue impacting hosts tagged for a policy deployment with assignment rules. In our case traced to faulty ePO extension for HIPS. Updated, and OK. Only additional item was that policy assignment rules had to be 're-saved' before the issue was corrected.