Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 1051 views
  • Users 0 members are here
Options
Suggested
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

IDE Change Control

bhx90

Hi,

It seems we were fortunate with this false positive being able to centrally disable on access scan and selecting update now to update the 700 locations we have Sophos deployed in.

It does raise the question of change management.  I mean we all probably spend hours testing new software, patches and hotfixes prior to deployment but just let AV updates install themselves on workstations and servers without a second thought.  My concern would be Sophos blocking a critical application, not just is own updater or even the functionality of management from the console.

This is the second false positive I’’’’ve experienced within 6 years use of Sophos.  The previous one quarantined winvnc.exe back in July 2010 meaning we were unable to remote connect to the workstations.

I would be interested in hearing if any fellow customers use a test environment to test IDE’’’’s before letting them into the Production environment as I’’’’m trying to weigh up the risks of another false positive against exposing the workstations to new vulnerabilities as I’’’’ve delayed the updates. 

Thanks in advance

:32825


This thread was automatically locked due to age.
  • 0

    Hello bhx90,

    IIRC there were others and at least one with a more serious impact.

    Before commenting on testing some words on the risk and impact of FPs. The worst case are FP detections with an associated cleanup routine - especially if they hit an OS component. They are very rare but known to happen. Usually on a running system they can be successfully dealt with from remote, but if they occur during start-up you are hosed. Almost all FPs are due to generic detections which don't have an associated automated cleanup routine. Unless you have configured an alternate action (Move, Delete) no real harm is done. The SEC manual and the Policy Setup Guide are vague on this setting, but the SESC Help is very clear: Use these settings only if advised to by Sophos technical support. 

    I've failed to locate a Best Practices Guide for 10.x. The Version 9.7 (and lower) Anti-Virus and HIPS settings: guide to on-access settings states:

    The other options ‘‘‘‘Delete’’’’ and ‘‘‘‘Deny access and move’’’’ could be used in special circumstances (such as when Sophos Technical Support advises you to select this option).

    We don’’’’t recommend that you allow the virus scanner to automatically delete infected files, as sometimes legitimate files can be detected. If you do enable this setting, you should check the logs regularly to ensure that you haven’’’’t deleted any important files

    for 10.x I've only found Recommended on-access scanning settings for 10.x which does not include this warning. IMO not including this warning in all applicable documentation (and a knowledgebase article) is a serious omission. Nevertheless one should be aware of the possible impact of Delete.

    The maximum interval you can set for download if threat detection data is one day, Sophos normally releases new updates every few hours. There's no fixed schedule for threat detection data updates - thus you'd have to effectively disconnect your production SUM and update the Warehouse it updates from manually. If course it could be done.

    Then there's the tests themselves. The minimum is: apply the latest updates, run all important applications, if you have scheduled scans run them, reboot the client.  

    Every now a then there are new variants of threats which are either only generically detected or not at all. Although most of the time only a few clients are affected they might be unusable until an updated detection is available. Depending on the circumstances additional action might be required to clean them up. Not having the latest detections naturally increases the risk of "missed" threats.

    Now compare the effort needed to set up and manage the required infrastructure, to perform the necessary tests and to deal with the possible additional infections to the one caused by FPs. For our installation the result is clear.

    Christian

    :32923
  • 0

    Thanks for the information.

    Regards

    :32981