I am in the processing of migrating our pc's from EPO 3.6.1 to EPO 4.5 We are still using VSE 8.5i with Patch 8
I logged into EPO 4.5 and saw a malware report that showed one pc had malware. I checked the report and it shows malware detected on a file ApacheDirectory Studio-version#.exe (this is the Open Source Apache Directory Studio). I know there is no virus or malware on that file. The Threat Event Description is: Scan Timed Out.
Is it normal for EPO to report a virus just because a scan timed out?
This is normal. If a scan times out, the scanner does not know for certain that the file is clean: the safest approach therefore is to flag it as a threat. (The same thing applies to password-protected files that can't be scanned.)
Although Joe Bidgood's point is valid--that it is safer to report that something is malicious when it's "unknown"--I also have found this reporting feature mildly annoying. In my opinion, the ePO shouldn't report something as malicious unless it's truly malicious. Personally, I've modified the "Threats Detected" report filter to exclude Event IDs 1059 (scan timed out) and 1051 (password protected). Then I just created a separate report that I consider less critical for the scan timeouts and password protected files which picks up on those event IDs.
You're not alone - a lot of people regard scan timeouts and password-protected alerts as irritating and disable them in exactly the manner you describe. Ultimately of course it's a judgement call: if, in your environment, you're happy to ignore these alerts, then ePO will let you do that. It would be *really* annoying if you couldn't
The default behaviour is correct, though - "only report it as clean if you're sure it's clean" is an inherently safer position than "only report it as hostile if you're sure it's hostile". As a company we'd be remiss if we defaulted to the less-secure position
I think that my gripe lies with the fact that the report categorizes password protected files and scan timeouts as a "virus" in the "threat type". Such a file *could* be infected with something but I don't think it's fair to state that it *IS* a virus. I understand why McAfee wants to classify these files this way but it has the potential to cause problems for the ePO system administrators... If you have a manager or even an internal audit department that requires you to provide them with infection reports, they are going to give the system administrator a hard time because of all these "virus" infections. It doesn't matter to them that you don't believe these are critical--they are numbers on a report and so, without understanding what "scan timeout" or "encrypted file" means, it's automatically critical and bad because it's a "virus". Personally, I think it would be better if the "threat type" was "Suspect" or "Undetermined" instead of "Virus".
I completely understand your point I'd recommend either entering that as an FMR (Feature Modification Request) directly, or open a case with Support and ask for it to be FMR'd.
Thanks, Joe... I can't speak for kjhurni but it's not as big of a deal for me now that I figured out how to get them off of the reports. I can see how it would be a point of confusion for newer ePO system administrators, though. Submitting an FMR is okay but, IMHO, if McAfee is that concerned about what user base thinks of their products and they are looking for input/ideas on features, they'll also be proactive and read the forums. In many cases (but not all), I've gotten better responses from helpful users in the forum than I have from technical support.
Incidentally, if anyone is interested in submitting an FMR, you can find it here...
Yes, I will submit an FMR to change this as well. I like the "suspect" or "unknown" rather than just label it as a virus.
And thanks for the information on how to modify the report/query so that it doesn't do that.
Another option is simply to have EPO not even collect information on these IDs. In v4.0 you can set this under Configuration, Server Settings, Event Filtering. This way your database isn't filling up with this stuff.
However, I personally use runcmd's idea of creating a report without Event IDs 1051 and 1059 just in case I need the data for troubleshooting, etc.