Just wondering if anybody else has had the same experience with the Policy Discovery feature of Application Control 6.2? I have been working with a customer on a proof of concept and we've been following instructions in the Best Practices guide to identify what specific policy configuration is needed to achieve their functional requirements. What we have found is that when in Observe mode, the number of Policy Discovery events reported to the ePO has been minimal however when in Enabled mode we get more comprehensive results. As I understand when in Observe mode the whitelist on the target system is updated automatically however a Policy Discovery event is supposedly also reported to ePO during next ASCI for the first event occurrence. I have also read that McAfee have added "filters" to prevent excessive Policy Discovery events being sent to the ePO, however our experience has left us concerned that Observe mode is not providing an accurate representation of events for us to formulate our policy.
It would be great to hear from others in the Application Control community that have had similar experiences and/or made observations.
Observe Mode does not show 1 to 1 Event mapping because we have put in intelligence to list the Change agents rather than 'all' the changes in Policy Discovery Page. Once a change agent has been captured, we optimize to not report rest of its change activity. For example if foobar.exe installer get 15 files on the disk, we list foobar.exe as a trust policy candidate and show indicative activity per host/per mode to map why we are listing that as a trust candidate vs in events you will probably 15 events for each file. This is the aggregation intelligence has been added v6.2 onwards.
The guiding Rule for marking a Change Agent as a Trust Updater is Reputation, Application Name and Prevalence.
So you may not see 1 to 1 mapping between Policy discovery suggestions and Events.
Having said that, if you are seeing activity by a Change Agent in events which was not reported in Observe mode, we would like to know about that. Please drop me a mail with details and we can look into it further.
I also am experiencing this. You can confirm that not all binary additions are reported back up (or logged locally on the endpoint for that matter) by downloading the Microsoft SysInternals Suite, which includes ~73 executables. Place the client into enabled mode, and run the attached execute script (edit first to point at your specific Sysinternals directory). App Control generates an event for every exe (execution denied). Now, place the client into observe mode, and execute the script. You'll only get 12 observations in the solidcore log (C:\ProgramData\McAfee\Solidcore\Logs). Hopefully this is addressed in a future release, as this leaves open the potential for a binary to execute without any reporting coming back into ePO.
and we seem to have the issue when executing binaries from a network path. Basically we get a Policy Discovery event for the first binary executed but any other binaries executed are simply not reported back to the ePO (some of which attempt to make changes to local files which are solidified). I initially suspected that Solidcore was adding the network path as a trusted directory as part of the dynamic whitelisting when in Observe mode, but when I interrogated to the whitelist via the CLI this network path was not found. I understand the need to filter/aggregate discovery events as to not overwhelm the ePO and to aid administrators formulate a policy, however with my experience using Policy Discovery in observe mode the logic appears overzealous in its event filtering.