Showing results for 
Search instead for 
Did you mean: 
Level 11

Host IPS state not reflected in query results (but correct in System Tree information)


Current environment details: All products and extensions in current support.  Issue noted on a number of different environments.  Versions cannot be confirmed for security reasons (an SR will be raised, and versions communicated).

Main issue is that the state of Host IPS (enabled/disabled) is not reflected in the queries that include the state in the results.  The following is a result of tests from a number of systems, along with what I suspect is going on:




Step by step to recreate issue (note that HIPS starts off as enabled on endpoint system):

1) Browse to system in ePO system tree, and click system name

2) Select products tab and then highlight Host Intrusion Prevention

3) Check Host IPS status.  Result: Shows as enabled

4) Browse to Queries and Reports > Shared Groups > Host Intrusion Prevention

5) Run query 'Host IPS: Host IPS status' query.  Drill down into results and confirm host IPS status for system in question.  Result: Shows as enabled

6) Log into protected system, and open HIPS console.

7) Unlock HIPS console, and disable Host IPS (deselect 'Enable Host IPS' checkbox) - click Apply

8) Rerun steps 1 through 5.   System Tree details show IPS status = enabled, query results show IPS status = enabled.  This is expected, as the properties have not been sent.  See further comments below.

9) Open the McAfee Agent on the protected endpoint and click 'collect and send props'

10)  Rerun steps 1 through 5, confirming that protected system last comms time in system tree is correct.  System Tree details shows IPS status = disabled, query results show IPS status = enabled.

11) Wait 15 minutes (see further comments below).  Note that due to restricted access, I cannot run the property translator task manually.  In other environments, I have run this manually, and can confirm that it has the same result as if I had waited for 15 minutes.

12) Rerun steps 1 through 5, System Tree details shows IPS status = disabled, query results shows IPS status = disabled




There appear to be two separate locations in the ePO DB that record the status of Host IPS.  If we call them LOCATION_A and LOCATION_B, we can say that the system properties uses LOCATION_A and the queries use LOCATION_B.

In step 8, neither LOCATION_A nor LOCATION_B have been updated.  See question Q1, below.

In step 10 (after props sent), LOCATION_A has been updated and LOCATION_B has not.

In step 12, both LOCATION_A and LOCATION_B have been updated

I suspect that the 15 minutes thing is the key here - when the IPS property translator server task runs in the background, LOCATION_B is updated to reflect the correct status, therefore this is likely to be a HIPS-specific table.  LOCATION_A is likely to be a more general system info table.  See question Q2, below.




Q1: I believe that if Host IPS is disabled via the protected systems HIPS console (I also suspect this would be the case if HIPS was disabled centrally by policy), ePO has no visibility of that state change until updated properties are sent to ePO, so we could potentially be waiting for next successful ASCI comms).  Following on from that, I believe it would be possible for a malicious person (with access to HIPS UI and unlock code) to disable HIPS, carry out a malicious action that would have normally been detected, and re-enable HIPS, all without being detected.  So we are looking really at an auditing issue here.  If my understanding could be confirmed, this may lead on to a PER.

Q2: Based on an ASCI of 1 hour, we could potentially be looking at a period of 75 minutes before a query showed the correct status of HIPS on a protected endpoint.  Is my understanding correct?  Also, am I correct in stating that there appears to be two locations within the ePO DB that store this information, and that system properties and queries use different sources/db locations for information?




Potentially related community post here.

UPDATE: Hyperlink additions don't appear to be working - 'here' above should link to:


0 Kudos