Questions regarding Sophos Central file restore

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  

    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.

  • In reply to ecompo:

    Hello ecompo,

    so many [custom] tools
    I 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 MLDetections 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] tools
    I 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.

     

     

     
    I appreciate your inputs.
     
    In my part of the world where many hardware manufactures and OEM/ODM run their business, it's not uncommon to see hardware developers or embedded system engineers constantly develop their own tools to test equipment, devices, circuits, etc. 
     
    e.g:
     
     
     
    Imaging you're planing on deploying Intercept X to an environment where 100+ developers' computer and you experience something like the above screenshots at the first 5 computers, would you keep rolling out intercept x?
     
    Every developer has their own tools and/or software developed by a supplier/vendor engineer for variety purpose. Most of the tools are not signed and some of them are legacy tools that don't have a backup or second copy. 
     
    My problem with Intercept X's Deep Learning's auto cleanup is that it doesn't give the sysadmin a way to disable the function. And i just recently learned that restore feature only supports files size up to 50 MB.
    So once a 50mb+ legacy tool being detected as ML PUA/ML-PE then it is gone. This particular information is nowhere be found within existing published KBA or training materials( I really hope I am wrong on this one). 
     
    pohan
  • In reply to ecompo:

    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 ...

    Christian