Thank you for your post.
This rule is free to be enabled. This is a rule that strictly works on certain conditions that would trigger it to block and application where one critical rule that gets hit here is:
"Installation of applications in non standard paths".
If you have a false positive that does not fall under this category, I would request you to kindly help us by reporting this using a Service Request so that we can look into it for you. Also if you have not done already, please go through the marked solutions for further understanding of this issue.
I sincerely hope this helps!
The Rule does exist. So if you have an application that is not installed in the regular installation location and if the rule is enabled, then the problem may exist for that specific environment. This is not dependent on version of ePO or ENS, but the version of Exploit Prevention Content you have in place.
Can you confirm that this application is installed in the "standard installation path"? If yes, can you kindly please raise a Service Request so that we can look into this for you?
Firstly Thank you reporting the issue here and actively help us wit the investigation. To clarify our current stance on this issue I would like to submit the below draft.
If you are facing an False positive due to the new Signature introduced exploit prevention content (9845) with the Threat name: Malware Behavior: Windows EFS Abuse,
What does Support do when we report this to them?
Support will raise an issue internally with our Labs team who will validate this reported False positive internally and check if we can add exclusion at content level which will be released subsequently on the next Exploit prevention content release or a future version as applicable until which our exclusion should serve the purpose.
If we still receive the False Positive, what is the use of the newer signature released by McAfee? What have you done in it to mitigate the issue?
Based on our initial analysis and Customer reports we were able to pick up the most critical application identified which can hamper production environment and we added exclusion to the signature. Additionally, we have disabled this rule and lowered it's severity so that it can be enabled by users based on their requirement - just like few other low severity rules we have in place.
I have updated to the latest content 9863 and I can see that the signature is not disabled by default in the policy I have. Why is it so?
This would actually be a nice question though! Answer is straight forward. We do not disable/enable signatures that are of non High severity in any custom policy. Basically the changes of the new content will reflect in the McAfee default policy and if you have a custom policy where this is enabled, you may have to disable it manually if needed.
All other queries and addition of exclusion should be well explained in this KBA:
False positive mitigation for Exploit Prevention signature 6148 for non-standard installation paths
I sincerely hope this is of some use to all of you here. Please feel free to ask more questions if you have any with respect to this post!