acknowledgements, what actually happens?

Hello,

there is no simple answer as it depends besides other things on the threats found. Although a thousand machines out of 8k might have accumulated over time the number is IMO way too high. I think there is room for improvement.

It's always a good idea to look up the threat's analysis and the suggested actions by following the link from the Computer details or entering the name on the Security analyses page. Most of the time you'll be referred to the general instructions for removing certain kinds of threats. The console gives you only so much information and it is advisable that your admins have access to the Anti-Virus logs (SAV.txt) on the clients.

Let's start with the "pathological cases" where visiting the client is required

"Proactive" detection is not perfect so as yet unknown threats could slip in and it might even be necessary to boot from an external drive or at least boot into safe mode to get rid of it (of course once an IDE has been issued) or use a custom tool (especially when a rootkit is involved). These cases are rare and shouldn't give you one out of eight.

Now to the normal situation

machines with quarantined items - to make sure, these are clients with outstanding alerts in SEC, right? You get a persistent alert when a detected threat is not cleaned up or deleted because:

1. the on-access or scan settings do not specify automatic cleanup and/or deletion
2. cleanup requires a full scan
3. cleanup failed
4. the particular threat type can't be cleaned

If you (1) don't use automatic cleanup many of the threats will be shown as cleanable and you just initiate cleanup from the console. Certain types and some adware or PUA will not be cleanable (for example generically detected threats or in case of the latter when an uninstall is needed - if users don't have the rights to install software you shouldn't see most of these). In case of on-access detection acknowledge the un-cleanable threats and run a full system scan - whatever has "disappeared" in the meantime (e.g. from a temp directory) will be removed also from quarantine, still existing threats will again trigger an alert and some of the threats might now also be cleanable. If there are still items remaining move the client temporarily to a group with "aggressive" cleanup settings and either wait for the threats to be cleaned/deleted upon access or schedule a scan.

(2) is self-evident

(3) in this case try to determine the reason. As on-access runs with the user's rights cleanup will fail if he has only read access. A scheduled scan will remove the threat, also accessing the file remotely with sufficient rights will trigger successful cleanup. Or - the file might no longer exist (often the case with temp or cache directories) in which case you simply acknowledge the alert. The file might be locked (I have seen such cases with "new" (i.e. undetected or partially detected) FakeAV where the running process locks the file) but is often deleted when the client is rebooted (provided that a "matching" IDE is already available). If you detect something "unknown" (whether by observation or through generic detection) please send in a sample (and try to include everything which might be related and looks fishy).

Locks can also occur with files in the cache (e.g. Content.IE5) - usually you can safely acknowledge them.

(4) Files exhibiting suspicious behavior are a special case. If they are legitimate you authorize them in SEC. The corresponding alerts will be removed once the clients apply the new policy and report back to the console. If you are not sure about the nature of the item send in a sample. In case it is clean it might get "whitelisted", in case it is malicious an IDE will be issued - if neither you'll either authorize it or simply acknowledge the alert. 

With some experimentation your Sophos admins might be able to bring it down to a few dozen remaining "cases" or less - but as I said, it depends. 

HTH

Christian

Hello,

there is no simple answer as it depends besides other things on the threats found. Although a thousand machines out of 8k might have accumulated over time the number is IMO way too high. I think there is room for improvement.

It's always a good idea to look up the threat's analysis and the suggested actions by following the link from the Computer details or entering the name on the Security analyses page. Most of the time you'll be referred to the general instructions for removing certain kinds of threats. The console gives you only so much information and it is advisable that your admins have access to the Anti-Virus logs (SAV.txt) on the clients.

Let's start with the "pathological cases" where visiting the client is required

"Proactive" detection is not perfect so as yet unknown threats could slip in and it might even be necessary to boot from an external drive or at least boot into safe mode to get rid of it (of course once an IDE has been issued) or use a custom tool (especially when a rootkit is involved). These cases are rare and shouldn't give you one out of eight.

Now to the normal situation

machines with quarantined items - to make sure, these are clients with outstanding alerts in SEC, right? You get a persistent alert when a detected threat is not cleaned up or deleted because:

1. the on-access or scan settings do not specify automatic cleanup and/or deletion
2. cleanup requires a full scan
3. cleanup failed
4. the particular threat type can't be cleaned

If you (1) don't use automatic cleanup many of the threats will be shown as cleanable and you just initiate cleanup from the console. Certain types and some adware or PUA will not be cleanable (for example generically detected threats or in case of the latter when an uninstall is needed - if users don't have the rights to install software you shouldn't see most of these). In case of on-access detection acknowledge the un-cleanable threats and run a full system scan - whatever has "disappeared" in the meantime (e.g. from a temp directory) will be removed also from quarantine, still existing threats will again trigger an alert and some of the threats might now also be cleanable. If there are still items remaining move the client temporarily to a group with "aggressive" cleanup settings and either wait for the threats to be cleaned/deleted upon access or schedule a scan.

(2) is self-evident

(3) in this case try to determine the reason. As on-access runs with the user's rights cleanup will fail if he has only read access. A scheduled scan will remove the threat, also accessing the file remotely with sufficient rights will trigger successful cleanup. Or - the file might no longer exist (often the case with temp or cache directories) in which case you simply acknowledge the alert. The file might be locked (I have seen such cases with "new" (i.e. undetected or partially detected) FakeAV where the running process locks the file) but is often deleted when the client is rebooted (provided that a "matching" IDE is already available). If you detect something "unknown" (whether by observation or through generic detection) please send in a sample (and try to include everything which might be related and looks fishy).

Locks can also occur with files in the cache (e.g. Content.IE5) - usually you can safely acknowledge them.

(4) Files exhibiting suspicious behavior are a special case. If they are legitimate you authorize them in SEC. The corresponding alerts will be removed once the clients apply the new policy and report back to the console. If you are not sure about the nature of the item send in a sample. In case it is clean it might get "whitelisted", in case it is malicious an IDE will be issued - if neither you'll either authorize it or simply acknowledge the alert. 

With some experimentation your Sophos admins might be able to bring it down to a few dozen remaining "cases" or less - but as I said, it depends. 

HTH

Christian