We'd love to hear about it! Click here to go to the product suggestion community
Hi,
I have a few questions about file restoring process after cleanup by intercept x.
1. How long does it take on average for Sophos Central to restore a single file?
2. What to do if a restored file has been picked up by Sophos as ML/PE-A then allowed but restore failed and been detected again?
3. What is the best way to deploy Intercept X in an environment where a large amount of custom tools is used and manually clicking allow to restore files is becoming a daunting task e.g. 10+ ML/PUA or ML/PE detections on a single developer's machine and there are 50+ developers.
I could not find any answer within the following KBAs:
https://community.sophos.com/kb/en-us/128136#restore
https://community.sophos.com/kb/en-us/127331
https://community.sophos.com/kb/en-us/127332
https://community.sophos.com/kb/en-us/127376
Any useful information other than above KBAs is greatly appreciated.
po
Hello-
File Restore takes only a few minutes after the endpoint has been able to download the configuration update from Sophos (this happens automatically every 5 minutes or so; or if you click Update Now from the Sophos Endpoint UI). It shouldn't take more than half an hour at the most, assuming that the updated configuration was downloaded to the machine, and applied without errors.
If restoration fails, then you would have to check the items mentioned in https://community.sophos.com/kb/en-us/127376 to see why restore fails, etc.
My question for you is - have you tried whitelisting via Path instead of hash value? If you plan to deploy Intercept X to your users, it should be possible to whitelist via Path, and have the tools your users use to save and execute files on the whitelisted path, in theory.
Thanks,
In reply to DianneY:
DianneY My question for you is - have you tried whitelisting via Path instead of hash value? If you plan to deploy Intercept X to your users, it should be possible to whitelist via Path, and have the tools your users use to save and execute files on the whitelisted path, in theory. Thanks,
The thing is there are so many tools within so many users (hint: development) and it's pratically impossible to ask everyone to put their tools in the same path.
In reply to ecompo:
Hi ecompo
If you'll try to whitelist the software through the hash, it will work till the time hash value which you have whitelisted is matching with the software.
The hash value can be changed after the updated version of the same software. As you have large number of customized development tools, Dianny has suggested this way because any change in the software could lead to the change of the hash value and software again will be detected as ML/PE.
Hello ecompo,
so many [custom] toolsI must admit, I don't have a clear picture of custom tools, and development doesn't necessarily imply many (different) tools and/or tools that are uncommon. Neither is a development tool necessarily a border case that can be expected to trigger a detection. Nor is uncommonness a deciding factor for ML.
As you mention ML/PUA, quoting from More information for Generic PUA ML: Detections can be cleaned, authorized, or sent to the lab to have a named detection added. Submitting samples is IMO a good idea. On the one hand a named (i.e. specific) detection can easier be dealt with. OTOH the result of a submission could also be an amendment of the detection effectively whitelisting a file (or better: a certain set of characteristics in a certain context, in other words: the whitelisting normally not only applies to a specific file but could cover updated version as well).While you should be able to mitigate false positive ML/PE-A detections in Central you can in addition submit a sample.
Christian
In reply to QC:
QC Hello ecompo, so many [custom] toolsI must admit, I don't have a clear picture of custom tools, and development doesn't necessarily imply many (different) tools and/or tools that are uncommon. Neither is a development tool necessarily a border case that can be expected to trigger a detection. Nor is uncommonness a deciding factor for ML.
Hello pohan,
I see, it's much clearer now.
Just my personal opinion: Intercept X (or another vendor's equivalent) is out-of-the-box "too paranoid" for such an environment. I'd be veeery careful when deploying it and likely wouldn't do it without the vendor's support. This particular information is definitely not published in red neon. Intercept X is like a plant security force. If the employees show uncommon behaviour or use things that resemble weapons - well ...