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

New! Sophos for Virtual Environments

Now shipping with all Server Protection licenses, Sophos for Virtual Environments is designed to efficiently secure virtual servers and desktops running on either VMware vSphere or Microsoft Hyper-V. By offloading malware detection to a centralized Security Virtual Machine, Sophos for Virtual Environments conserves critical resources on each guest machine, and eliminates scan and update storms.

  • Provides real-time threat protection and automated clean-up
  • Easy and flexible deployment; supports multiple hypervisors
  • Manage using Sophos Enterprise Console or Sophos Central
  • Included with all Sophos Server Protection licenses

Learn more:

  • New Virtualization Security web page
  • Frequently Asked Questions KBA

Note: Sophos for Virtual Environments replaces the Sophos AntiVirus for vShield product; existing vShield customers now have automatic entitlement to Sophos for Virtual Environments within their existing license.

Thanks

Mark



This thread was automatically locked due to age.
Parents
  • So the updated security solution requires all VMs in our infrastructure to connect to a security VM that sits on the VM Management network? This appears to be a major security risk.  Essentially all VMs in our infrastructure will have communicate to the same network the physical hosts live on. That is not good. 

     

    I also don't understand how installing hundreds of agents on VMs is lighter than the previous solution? 

     

    Also, the installer doesn't give you the option to specify 'log on as' for the Windows service and default to NT AUTHORITY, which requires domain permissions so the install breaks until I manually add the correct service log on. There needs to be an option to set this as a local service? Is it required to run as a network service? 

  • I also am curious if there is any plan to build out something that can view 'protected' VMs from a GUI or from the Sophos cloud console rather than having to comb through some obscure log file? I honestly can't believe that referencing a log file is the only way we know if VMs are protected. 

  • Hello  

    Thank you for your interest and questions on Sophos for Virtual Environments.

    1. All communication between the GVMs and SVM are encrypted to prevent eavesdropping and man-in-the-middle attacks. What other potential security risks are you concerned about?
    2. The previous solution also had an option of a Sophos thin agent, the new thin agent takes up 6mb of space and 20-50mb of memory (depending on your h/w specs and setup).

      Sophos for Virtual Environments also does not rely on 3rd party file inspection tools (such as VMtools) as the new thin agent has that capability built in. So its only one agent on all GVMs rather than multiple.

    3. The GVM installers automatically create their own dedicated user processes that have the minimum required set of privileges. As a security measure, these services can only be run by the dedicated user accounts created at install time.

    4. Yes there are plans to see more details around the GVMs within the management consoles. This was a restriction with the previous product, but as we have our own thin agent within Sophos for Virtual Environments we will be able to obtain granular GVM information.

    For more details the documentation is here https://www.sophos.com/en-us/support/documentation/sophos-for-virtual-environments.aspx#

    We also have a KBA landing page with FAQs and other helpful pages. https://community.sophos.com/kb/en-us/125791

     

    Cheers

     

    Mark

  • Thank you for the great response, below are my concerns. 

     

    1. My concern is that if any of our hundreds of VMs are compromised, they direct networking access to our management network that our physical hosts reside on. Most secure network designs will not have this networking enabled by default. I understand we can add additional layers of network security to help mitigate this risk but overall, I think the design is questionable. The previous solution used the VShield driver/Vshield server to execute tasks at the hypervisor level, this new solution seems to simply be a client/server config sitting on the management network that the physical host network. I have not seen any documentation to show otherwise rather than the high level information form the startup guide, which tells me nothing. I could be way off on this assessment, I am simply trying to understand the hypervisor component, which made the previous solution outstanding. 

     

    2. The primary resource issue for most virtual environments is not memory or disk space, it is CPU. This new solution adds multiple Windows services that do not use a lot of CPU resources but when you multiply that by hundreds or even thousands of VMs, it can be significant. This was the best part about the previous solution, there was ZERO resource hit on the guest VMs. 

     

    3. I understand the GVM installers create their own dedicated user processes, the problem is that the NT AUTHORITY user that the install tries to use does not work for us. We have to stop mid install and change to a local user. We can adjust with domain policy but again, questionable design to assume the NT AUTHORITY user has 'log on as a service' privileges on all VMs. 

     

    4. I understand this is the first release, any idea as to when GVM information will be a little more easier to obtain? For example, my infrastructure has approximately 750 VMs, 28 physical hosts across 6 data centers around the world. For me to have to check a log file to confirm each VM is secured is extremely challenging. I understand that I can script this for some type of automated solution but again, we shouldn't need to do this. 

     

    5. There is still essentially zero visibility into the scheduled/on demand scans. We have to comb the events for each security VM to confirm scans were run successfully. 

  • hello  

    Apologies for late reply.

     

    1. Isolation of the management network can be achieved by configuring the SVM with its primary network on the your management network, and using other non-management networks for traffic between GVMs and SVM. The SVM will not act as a router between networks.

      In the diagram below, SVM communicates with Central/SEC over the management network (tagged as the primary network when installing the SVM), with GVM1 and GVM2 over the “gvm-net1” network and with GVM2 and GVM3 over the “gvm-net2” network.

    2. Although SAV for vShield was "agentless" it did require VMtools, Sophos for Virtual Environments does not require 3rd party tools for inspection therefore the very thin agent does do multiple tasks. In addition to introspection and scanning, clean up is a new addition.
      To speed up scanning we also have a local cache on each of the GVMs which list out the known clean files previously scanned by other GVMs on that host. The files in this cache will not be required to be sent to the SVM for scanning.
    3. With the info it sounds like you may have removed the rights for one of the NT AUTHORITY user accounts to log on as a service. If you could send in the specific service is causing the problem then we could investigate further. We deploy four services, which run as the following users:

       

      SGVMScanningService : NT SERVICE\SGVMScanningService

      SGVMScanningIntegrationService : NT AUTHORITY\SYSTEM

      SGVMManagementService : NT SERVICE\SGVMManagementService

      SGVMDeploymentService : NT AUTHORITY\SYSTEM

      We assume that the system user would have the rights to log on as a service. In both cases where we use the SYSTEM account we do it because the privileges provided by NT AUTHORITY\LocalService or NT AUTHORITY\NetworkService are not sufficient for the roles of those services.

       With regards to the NT SERVICE\SGVMScanningService and NT SERVICE\SGVMManagementService users that we use, these are low privilege accounts restricted to use by our services and are currently the defaults on installation.

    4. We have a roadmap which does include more granular level information, once finalised I will be able to share this with you. We are collating all feedback from 1.0.1 to drive what we do next.
    5. I will feed this back into the list of enhancements we can do.

     

    Thanks again for your questions Tyler.

     

    Mark

     

Reply
  • hello  

    Apologies for late reply.

     

    1. Isolation of the management network can be achieved by configuring the SVM with its primary network on the your management network, and using other non-management networks for traffic between GVMs and SVM. The SVM will not act as a router between networks.

      In the diagram below, SVM communicates with Central/SEC over the management network (tagged as the primary network when installing the SVM), with GVM1 and GVM2 over the “gvm-net1” network and with GVM2 and GVM3 over the “gvm-net2” network.

    2. Although SAV for vShield was "agentless" it did require VMtools, Sophos for Virtual Environments does not require 3rd party tools for inspection therefore the very thin agent does do multiple tasks. In addition to introspection and scanning, clean up is a new addition.
      To speed up scanning we also have a local cache on each of the GVMs which list out the known clean files previously scanned by other GVMs on that host. The files in this cache will not be required to be sent to the SVM for scanning.
    3. With the info it sounds like you may have removed the rights for one of the NT AUTHORITY user accounts to log on as a service. If you could send in the specific service is causing the problem then we could investigate further. We deploy four services, which run as the following users:

       

      SGVMScanningService : NT SERVICE\SGVMScanningService

      SGVMScanningIntegrationService : NT AUTHORITY\SYSTEM

      SGVMManagementService : NT SERVICE\SGVMManagementService

      SGVMDeploymentService : NT AUTHORITY\SYSTEM

      We assume that the system user would have the rights to log on as a service. In both cases where we use the SYSTEM account we do it because the privileges provided by NT AUTHORITY\LocalService or NT AUTHORITY\NetworkService are not sufficient for the roles of those services.

       With regards to the NT SERVICE\SGVMScanningService and NT SERVICE\SGVMManagementService users that we use, these are low privilege accounts restricted to use by our services and are currently the defaults on installation.

    4. We have a roadmap which does include more granular level information, once finalised I will be able to share this with you. We are collating all feedback from 1.0.1 to drive what we do next.
    5. I will feed this back into the list of enhancements we can do.

     

    Thanks again for your questions Tyler.

     

    Mark

     

Children
  • Mark thank you for the great response. I have the solution deployed in a test environment and so far so good. Coming from a Trend Micro solution, performance is one of the primary components that I am testing and this new application seems to do very well. Although I am still very early in my testing. 

     

    My feedback for future enhancements/patches. 

     

    - Propagating the names of the protected GVMs to the Sophos portal. This would be extremely helpful. 

    - Give the user an option to set the service accounts being used. Most GPO environments do not give NT accounts log on a service rights OOB, I think this feature may cause a lot of issues in similar environments. Also, publish the Windows command line string as you previously did in order to easily script installs with the new service account feature. 

    - Develop an uninstall tool or publish better detailed uninstall scripts. The standard windows command INSTALLFILE /uninstall does not remove the 2 Sophos applications very well, for some reason I have had residual files remain, it seems to only remove one of the 2 installed applications. I have had issues with uninstalling using WMIC and powershell as well. The only way that I have successfully uninstalled the solution is using the GUI control panel and manually uninstalling the program one by one. An application I can run or a script I can execute to remove the Sophos application would be very helpful. 

     

    - Detailed network requirements. Port requirements, bandwidth requirements for SVM <-> GVM communication whether it be on the same or different physical hosts. The guide is somewhat murky on GVMs living on different physical hosts with bandwidth requirements and possible latency impact. 

     

    - Details on the Sophos service accounts and Windows services that are installed. Details on how files are passed to the new SVM for scanning, how caching occurs and best practices for full scans. These are all new features and there is very little information as to what any of these components do. 

     

    Thanks again for the response above. I hope I can assist with the continued growth of this new product. 

  •  

    A massive thank you for your feedback it is invaluable.  I will log the 1st 3 as future enhancements, GVM visibility is near the top of the list at the moment. 

    I will also log your request for detailed information regarding the network requirements and services used.

    You can add and comment on other feature requests here http://ideas.sophos.com/forums/285723-sophos-endpoint/category/127954-virtualisation

    There is a very open roadmap for Sophos for Virtual Environments, we have a long list of enhancements but we wish to order the priority of the work based on your and other customers feedback of version 1.0.

    Again thank you.

    Mark