This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Intercept X/Central scans and events

Hello dear community,

I would like to draw your attention to the following facts for the Sophos Intercept X and Sophos Central.
Unfortunately, the details of a scan cannot be included in the assessment of the status of a computer.
Unfortunately, the information is not clear and can lead to incorrect assumptions.
We noticed that a scan that is not completed has the same entry in the events as a scan that "really" ran. It is therefore not possible to assess whether a scan has run correctly based on the events.
As an an example:
I started a 'User initiated scan' and aborted after about 10 seconds. The scan is specified in the events in Sophos Central as "Scan 'User Initiated Scan' completed" and the Sophos Intercept X also shows the time of the canceled scan as the time of the last scan.
Our Scheduled Scan ran on the same day. This is also listed in the Sophos Central events with "Scan 'Sophos Central Scheduled Scan' completed".
This means that the correct execution of a scan cannot be judged from the entries. So it has to be with every scan the worst-case scenario can be assumed that this was not carried out correctly.

We have already addressed this issue at Sophos and received the following response:


"This is as designed - We don't say "completed successfully". We say "scan has completed", which it has. Complete means it's
stopped whether it's because it's scanned everything or the user has stopped it, doesn't make a difference."


From my point of view, this makes a big difference when evaluating the security of a computer!



This thread was automatically locked due to age.
Parents
  • Hi Silvio,

    Thanks for reaching out to the Sophos Community Forum. 

    There was an issue where on-demand or scheduled scans would finish enumerating much earlier than expected. This applied to any devices updated to Sophos' newer endpoint architecture. 

    A fix for this was recently released to all customers. Could you share the "Sophos Core Agent" version shown on any affected devices? 

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • Hello Kushal,

    the problem is not that a scan ends unexpectedly earlier than expected. But that all scans, completely run through or aborted, have the same message in the events. Unfortunately, this means that the notifications in the events are completely useless.

    Kind regards,

    Silvio

Reply
  • Hello Kushal,

    the problem is not that a scan ends unexpectedly earlier than expected. But that all scans, completely run through or aborted, have the same message in the events. Unfortunately, this means that the notifications in the events are completely useless.

    Kind regards,

    Silvio

Children
  • The main strategy of the Sophos Endpoint is defence in depth. The primary protection filter is at time of access to a file - we apply multiple checks at this point to determine if the file (data or PE) is malicious or not. Then we also have a during execution/access level of checking (this is the stuff like CryptoGuard and AMSI protections) that monitors what a PE is doing so even if the on execution check failed to catch it, we see what it's doing and can stop it then too. 

    We also check things when they are written to disk - which catches a lot of these things.

    Bulk scanning of files at rest is not a very effective anymore. The file will have been inspected at write, and again if it is ever accessed. So, having a crawler walk the file structure to catch things will only be effective at finding files that were present before the endpoint was installed and never accessed. OR, if you mount a drive and the files are already present. However, we would inspect the file as soon as someone or a process tried to access it so the protection is still in effect. 

    RichardP

    Program Manager, Support Readiness | CISSP | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Hello RichardP,
    the focus on real-time scanning is correct and a good approach and I didn't doubt that. I also agree that full scans and/or scheduled scans are no longer the best approach. But if I have such a feature in my product, and you certainly won't dispute that it's there. Then the events regarding a performed scan or a canceled scan should not be identical. Unfortunately, you do not address this fact in any way.
    It makes a difference whether a scan was canceled or completed, regardless of whether it made sense or not. These processes cannot and must not lead to the same result! However, since both processes currently lead to the same result in the logs, you can also omit these entries because they have absolutely no meaningfulness. They are simply worthless.

    Would I contact you and tell you that my computer is infected and ask you how it could have happened, even though I had scanned my computer completely an hour earlier. As proof of this, I would show you the result from the event logs. Can you believe that I did a complete scan of my computer beforehand using this event log?

    Kind regards,

    Silvio

  • I understand your point of view and your concerns. 

    I will bring it up with the development department. 

    My reply was to highlight that there isn't a protection gap when a scan is cancelled. However, I understand that having two paths to the same reporting element and not being able to differentiate them could cause confusion.

    RichardP

    Program Manager, Support Readiness | CISSP | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.