ENS not detecting eicar.txt but detecting eicar.com on the excluded path

[haaris]

Hi,

In ENS I observed that on the excluded path eicar.txt not getting detected which is correct since the path is excluded but why eicar.com is getting detected and deleted by     ENS if it’s excluded.Why this is happening?How can we confirm that the path is excluded 

[jess_arman · Accepted solution]

@haaris It is possible that if you have a default, low, high risk process policy and you are only putting this exclusion into your "default process policy", but have not placed it into your "high risk" policy set, or "low risk" (in the event you have scanning enabled there; unnecessary if scanning is disabled), then you have gaps in your exclusion attempt and this is highly likely to be the cause of your detection. 

If you are looking to confirm the system is recieving the configured exclusions, you can look within the ENS console and review the settings reflected in the respective policy areas. If you do not see that the exclusions are applied, then you will need to review the policy assignment in ePO and also the health of the McAfee Agent's ability to enforce policies.

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?

[haaris]

Hi @jess_arman,

Policies are applied locally that I already checked and eicar.txt is not detecting on the folder path which is excluded but the problem is that its detecting eicar.com on the same path

[Former Member]

Hi @haaris

As @jess_arman advised, you would need to check that you have the exclusion in all locations (high/ low risk path exclusions if you are using these settings). If you don't, then processes such as high risk processes will still detect the EICAR > most popular example of this is explorer.exe (it's defined as a high risk process) so will still detect the EICAR unless you exclude the EICAR path/ or file from high risk processes.

[jess_arman]

@haaris The discrepancy you're describing sounds even more so like an instance where you have gaps due to only putting the exclusion in "default" and not "high risk". The reason is revealed when you examine what type of process touches a .txt and a .com file type---it's going to be different, and these can fall into different process categories. So, we can only assume that the process touching .txt is in the appropriately excluded split of the policy, whereas what touches .com is not.
Are you able to confirm this?

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?

[haaris]

Hi @jess_arman,

I added the same exclusion in high risk and found that eicar.com is now not detected and deleted.Probably this is what you said but if this the reason that means I have to add each excluded path in high risk also?Till now we never excluded path in high risk.

[jess_arman]

@haaris Then up until now you either had a single process policy (not broken out into default, low, and high risk), or you have been lucky that the only processes that touched the files you needed to exclude fell within the default process policy (which is everything that isn't explicitly defined as high or low risk) and allowed you to avoid scanning. However, the only way for something to be completely excluded in a muti-risked process policy is for the exclusion to be included in each category that has scanning enabled---most often only default and high-risk.

I'm glad you were able to resolve the issue.

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?