Security Virtualization. Part 2

Continuing to translate the article "Virtualization Security" by Terry Komperda.

Security Virtualization. Part 1

7. RECOMMENDATIONS AND OPTIMAL METHODS FOR SAFE VIRTUALIZATION
')
7.1 Administrator Access and Separation of Duties

• Give server administrators the right to turn on / off their server only.
• You may want to give administrators the right to deploy new VMs, and not to edit existing virtual machines. Other administrators, in turn, will only have the right to change existing VMs, and not to create new ones.
• Separate authentication must be present for each guest OS, unless there is a compelling reason for two or more guests to use the same data.
• This may seem counterintuitive to the general idea, but the larger the environment, the easier it is to divide rights into functions. One administrator cannot simultaneously manage storage, and domains, and virtualized infrastructure and networks.

7.2 Desktop Virtualization and Security
The following five effective measures will ensure that there is no unauthorized and insecure virtualization in the environment:

1. Update your valid usage policy.
   State the exact conditions under which you can install virtualization software and determine what confirmations are required for this. Specify which programs can be run and how they should be protected. Clearly define the consequences that employees will face if they do not follow the rules.
2. Limit the use of virtual machines only to users who need them.
   Most users do not need VMs on their computers. Prevent the installation of free downloadable software for corporate desktops and laptops. Restrict rights to a small group of developers and testers of virtual tools and VMs, and help them understand that they still need to adhere to corporate security policies.
3. Always make sure your virtualization and antivirus software is up to date.
   Make sure that all VMs have the same firewalls, antivirus, and IDS / IPS as on desktops and laptops.
4. Choose a security policy that supports virtualization
   Ensure that there are no known security policy conflicts with existing virtualization platforms.
5. Create and update a secure VM build library
   Create a VM build repository containing all the configuration settings, security software and patches that users can download for their own use.

7.3 Network Security

• Disconnect all unused NICs so that there is no easy way to get on the network.
• Make sure that the host platform that connects the hypervisor and guests to the physical network is secure by setting permissions for files, managing users and groups, and setting up logging and time synchronization.
• Encrypt all traffic between clients and hosts, between management systems and the hypervisor, and between the hypervisor and hosts using SSL.
• Secure IP communications between two hosts with encryption and authentication of each IP packet.
• Do not use self-signed certificates or default certificates — they are vulnerable to a man-in-the-middle attack.
• Place virtual switches in mixed mode for monitoring purposes and enable MAC address filtering to prevent MAC spoofing.

7.4 Data Storage Networks

• iSCSI and NFS must be placed on dedicated storage networks or non-routing VLANs.
• Use IPSec to encrypt iSCSI traffic to prevent snooping (tracking).
• iSCSI supports Call Handshake Authentication Protocol (CHAP), and this should be used for authentication purposes before granting access.
• When using iSCSI or NFS, use physical switches to detect and deny IP or MAC addresses.
• NFS is easy to set up, but it is the least secure choice for storage. Configure the NFS server by restricting access to specific IP addresses associated with your hypervisors, or use a firewall to restrict traffic to specific hosts. If the NFS server supports IPSec, use it to secure the traffic between the NFS server and the hypervisor.
• All traffic to and from repositories must be isolated from storage traffic.
• Do not send fiber optic traffic over Ethernet (FCOE), as this combines storage traffic with other types of data.
• Use zoning for a fiber channel, which is actually access control at the switch level and is similar to VLAN. Despite numerous topologies, zoning is the simplest and safest form. The bus adapter is in its own zone with a target device to prevent initiators from trying to communicate with each other.

7.5 Disaster Recovery

• Keep a firewall, security, and IPS / IDS on your disaster recovery site. If the firewall is disabled at the disaster recovery site, check it regularly until an emergency situation occurs or the rules of this firewall are different from the main ones.
• Take proper control of changes so that the backup and the primary site are as identical as possible.
• Logging and monitoring at the disaster recovery site should be treated the same as if these actions were performed on the primary site.
• Audit and test for overcoming your disaster recovery node separately from the main, but with the same frequency and giving the process the same value.
• Any exact repetition of your backup site should be encrypted.
• Place a copy of your disaster recovery plan at a remote location.
• Move your backup tools and store them offline.

7.6 Audit and logging

• Use centralized logging to determine if guests have gone offline. These guests may be desynchronized due to patches and updates. Log events to the VM (such as power on, power off, suspend, resume), changes in hardware configuration, or any logon associated with elevated privileges. Monitor and log all virtual machines that have been copied, moved, or deleted.
• Verification files should be read-only and should only be read by employees involved in the audit in order to preserve the integrity of the information. Unauthorized attempts to gain access to audit files and other virtual resources should also be logged.
• Perform regular checks of your environment, including virtual networks, storage systems, hypervisor, VMs, and management systems.
• Send log files to a remote server.

7.7 Virtual Machine Security

• Virtual machines should not be located in data storage, backup, and network management systems that are connected to the hypervisor.
• Screensavers are absolutely not needed in virtual machines. In addition, do not use screen savers on physical servers that heavily involve the processor, since they can overload the processor resources needed for the VM.
• VMs should not have access to or view the resources used by the kernel or host. These resources include storage networks and networks responsible for moving virtual machines.
• Do not create more virtual machines than required. Track all your running VMs to track potential penetration points for attacks. Limit the use of VMs only to the circle of critical employees.
• Turn off all unused VMs.
• Unused physical ports, such as USB on the VM, should be disabled.
• Use IPSec or other forms of encryption between the host and the VM.
• Prepare everything you need to plan, deploy, repair and backup your virtual machines.
• Physical devices, such as CD-ROMs and floppy drives, can be controlled indirectly by the VM or directly by the host. Configure this feature separately on each VM and on all virtual machines, disable the default connection to the host. If this is not done, the VM can request access to the host during the boot process and other virtual machines can be blocked, thereby delaying the boot process.
• You may want to consider using VLANs on a single virtual switch for traffic segmentation.
• When the VMs are moved, the active memory and status are transmitted over the network to the new host as plain text. Isolate this traffic from the organization's network to an isolated segment that is not available and is configured using a separate vswitch switch or VLAN.
• Any suspended VMs must be running in a test or lab environment so that any configuration changes can be tested to prevent hacking in a production environment.
• VMs should not have direct access to the data store of virtual machines or to the repository.
• Consider virtual modules to provide anti-virus protection for your VMs. Such models provide an agentless approach. Performance will improve, since processing does not lie on a separate virtual machine. The disadvantage of some of these models is that they provide protection against viruses, rather than additional control of modules, IDS / IPS, firewalls and web filtering, which are present in more traditional modules.
• Consider placing a virtual module on a host by connecting a small driver to the VM that will remove the update processes from individual virtual machines. The central signature database allows you to make sure that the protection is always up to date, even if the VM was previously offline. Security also follows the workload as it moves from host to host. This approach can also apply protection to certain VM groups or perform deep scan on some selected machines.
• A security policy can be used to ensure that a new VM is not allowed to join a virtual machine group or cluster, if it does not have specific settings or if certain updates are not installed.
• Do not install workloads with different levels of trust on the same security domain or on the same physical server. There is a chance of confusing levels of trust when users can create and deploy their own VMs.
• Some organizations limit the number of virtual machines on a single physical server, or designate physical network adapters for each VM for isolation purposes. Other companies do not allow VMs to move to other hosts. While security is important, make sure you don’t kill all the benefits of virtualization with such strategies.
• Be careful in accepting one VM or a small group of virtual machines and then assigning them to a VLAN for separation and isolation. This can lead to the growth of the VLAN network and additional difficulties, creating additional tasks for the administrator.
• Restrict access to inactive virtual machines.
• Any VM placed in the DMZ is open to access via the Internet and open to attack. Do not allow VMs in the DMZ to access storage or networks.
• When two or more virtual machines are on the same VLAN and virtual switch, the traffic between the VMs is not secure. Consider enabling virtual firewalls on these virtual machines for security purposes.
• Set a limit on the processor of any virtual machines that can access the Internet. Thus, if the VMs are hacked, the attack will not be launched on other hosts.
• If users are allowed to create virtual machines, consider allowing them to create VMs using an authorized template.
• Consider deploying a VM security to eliminate the agent on each virtual machine. This can eliminate antivirus storms and other difficulties that are possible if all hosts and virtual machines start scanning for malware at the same time.
• Check the OS on the VM using script and user login to make sure that the virtual machines have been updated. If the virtual machine is not compatible with the updates, the script can disconnect the user and notify the support team. Or, non-compliant VMs may be stored in a DMZ or testing environment, and may not have access to the network until they are properly updated.
• Disable any copy and paste functionality to protect data confidentiality and the integrity of the hypervisor and virtual machines.
• A virtual firewall connected to the VM always moves with it to ensure that the security policy is enforced before, during and after any movement.
• The Security Gateway (firewall and IDS / IPS) can be used to check traffic between virtual machines.
• Ensure that any VMs that process protected information are isolated from other virtual machines so that the data is not combined with other data or is accessible from other virtual machines.

7.8 Management Systems

• Secure communications between management systems and hosts to prevent data loss, eavesdropping, and any chance for a man-in-the-middle attack. Enable one or more of the available SSH, IPSec, and SSL protocols for this purpose.
• Use a unified management system and security policy to cover both physical and virtual environments. If you do not apply this approach, you will need to double the work of creating reports and analyzing any problems.
• Do not allow the administrative server to be accessible from all workstations. Hacking this server can have an impact on virtual machines and data storage. To prevent this, set the management server on a separate subnet of user VLAN computers and then place it behind the firewall. These are two completely different security zones. Define network switch access checklists and set appropriate firewall rules. Change the default permissions on these servers so that the administrator does not have access to the whole environment.
• Separate administrative servers from database servers.

7.9 Hypervisor Security

• Install hotfixes and updates from the manufacturer of the hypervisor as soon as they become available. Maintain this good patch management process to reduce the risk of hypervisor vulnerabilities. Install the latest service pack on guest computers and host, and remove any applications with a history of vulnerabilities.
• Disable any unused virtual hardware that connects to the hypervisor.
• Disable unnecessary services such as clipboard or file sharing.
• Regularly check the hypervisor for any potential signs of hacking. Constantly monitor and analyze the hypervisor logs.
• Do not set up the management interface for the hypervisor on your local network.
• Disable all local management of the hypervisor and require the use of a centralized management application.
• Enter two-factor authentication for any administrator actions on the hypervisor.

7.10 Snapshots and images

• No guest OS images should have write permissions.
• Protect virtual machines with the hypervisor snapshot functionality, as screenshots can capture the current state of the VM. The screenshot saves the OS, configuration settings, the status of data and applications contained on the VM at a particular point in time.

7.1 Time Synchronization

• Temporary Network Protocol (NTP) must be enabled and configured to synchronize with the time server near your network and NTP must work on the host. Guest virtual machines should be used either on the same server where the host is located, or use the host itself as an NTP server. If the VM layer allows the guest OS to synchronize time directly from the server, then this should be used, since this is the easiest way to implement.
• Key hashing mechanism authentication should be used between NTP peers to prevent unauthorized access.

7.12 Remote Access

• Some firms use remote administration (VNC) as a cross-platform remote desktop feature. Messages are not always encrypted when used. Encryption can be supplied in the settings of the supplier or through third-party plug-ins. Do not let these VNC connections connect to the Internet, whether they are encrypted or not. Control these connections through VPN or SSH tunneling.
• Remote access control should be limited to a small set of system IP addresses that have access to these features.
• Any remote access should ask for a username and password, additionally applying a complex password policy. For reliable protection of the environment, use two-step authentication or one-time passwords.
• Remote communication with any management tools must be encrypted and authenticated.
• When using SSH, disable protocol version 1, disable admin or root SSH login, and require users to use role-based access control or use their own individual accounts. Use a command like sudo, as it allows you to record all actions in the log (which will indicate what was done, when and by whom).
• Do not allow any remote access to the server or hypervisor.

7.13 Backup

• Encrypt any backup data streams in case the server image is stolen. Stored data must have access checklists to control actions for copying or mounting images.
• Protection of network levels, for example, VLANs, as well as access control lists, must be present to protect backup data (stored or transmitted).
• Do not allow root accounts to be backed up.
• Any backups that are sent to the disaster recovery site over the network must be securely encrypted.
• Regularly back up your OS and data, and also make a full backup once a week. Extend your backup with remote storage and external storage solutions.
• When using virtualization, disk backup is just as important as in traditional environments. Virtual backup backups should also be included in your backup policy.

7.14 Customizing and Managing Changes

• Ensure that any physical or virtual servers are protected before deploying them. Monitor any configuration changes to detect unauthorized changes or mismatches due to the installation of updates or patches.
• Protect physical and virtual switches as well as virtual hardware and gateways before deploying them.
• Do not allow infrastructure changes without documentation and testing in a lab environment that is as identical as possible to the production environment. Answer these questions before making any changes:
• What are the consequences of change?
• Who and what will be influenced?
• How big is the potential risk of change?
• Is it possible to revert changes if necessary?
• How long does it take to roll back the changes?
• Monitor VM configurations and warnings that changes to the desired configuration are required.
• Ensure that existing patch management products support work in a virtual environment and platforms.

7.15 Server Pools and Virtual Service Offers

• Segment server pools in case they contain different levels of servers, such as public web servers and database servers that contain personal information. Be sure to use security features to ensure that servers are protected from access from the Internet and from themselves. Failure to use segmentation in server pools can mean that hacking a single server will have a negative impact on the entire server pool.
• For virtual service offerings (VSOs), back up any user data, organization data, documents, databases, status information to virtual servers, as well as any Active Directory data using a standard backup policy and policy.
• Separate server pools from VSO from a security point of view. Users interacting with VSO should not have access to physical servers that are controlled by administrators.
• The above practical tips and recommendations will be effective if used in conjunction with already existing traditional security measures, and are not a replacement for already deployed security tools. Nevertheless, virtualization is quite different in the sense that if you do not apply these recommendations, you will not get a fully secure hybrid (physical and virtual) environment.

8. ADDITIONAL QUESTIONS, RECOMMENDATIONS AND ADVICE FOR VIRTUALIZED CLOUD
Many of the above recommendations and tips are effective for the data center, corporate and cloud environments, but the Cloud itself differs from the two above mentioned environments and requires other means of protection due to its size, multi-tenancy and the fact that the VM does not always stay within cozy physical perimeter around which you can create a security system. The following are some of the important points to take into account:

• The security of the hypervisor is even more important in the Cloud due to the scale of the potential hacking.
• VMs need to be tracked by their owners throughout the life cycle of the virtual machines. They must be hosted on servers that meet the collocation requirements of other virtual machines, and must use VM tagging for tracking purposes.
• To isolate the traffic of one user VM from another user VM, you must use a VLAN. This requires expansion of the VLAN beyond the basic switch infrastructure. There may be a problem with scaling VLAN capabilities to support very large clouds.
• Automation is necessary for security in the cloud because of its scale. Security in the cloud should be better planned and better managed.
• The utilization of IP addresses and IDs can be a problem if the user can access data from another client. There should be a robust process that allows you to apply VM assignment and reassignment.
• The central repository is an attractive object in the cloud. Data protection and encryption must be properly applied wherever data is stored, transmitted or processed.
• Standards are required if you plan to move to another Cloud Service Providers (CSP). This includes data, firewalls, virtual machines, and network settings.
• Cloud users, it is important that their data is stored separately from other users in a single cloud storage.
• You need to use automated lifecycle management tools to track new deployments. CSPs must also inform customers to limit the number of users who can commission a VM.
• Use standard VM images to maintain environmental integrity.
• A virtual machine for a dedicated scan cannot be used in the cloud to protect other VMs, since they do not control the hypervisor. In a multi-user environment, an agent-based approach should be used.
• Encryption keys for data centers must be secure. When keys are properly protected, uncontrolled VMs caught in data centers are unmounted and unreadable.
• A security policy tied to physical attributes, such as a physical server, IP address, or the delimitation of a physical host (used for isolation or MAC addresses), does not make sense in the cloud. Security policy should be tied to logical attributes, not physical. Identification, group, or role of users of the application, as well as load sensitivity, become important. The policy should be context-sensitive and adaptive.
• Standards are needed to bring together all security in the cloud. Clients and CSPs must distinguish between security obligations.
• In such an infrastructure as a service environment, the client is responsible for maintaining the patch versions of any designated VMs, and is also responsible for properly configuring the VPN after the initial installation.
• The old access control model is based on machines and is focused on IP. The model in the cloud must be user based. Network Access Control (NAC) defines who you are and what you have access to. Access control should be dynamic, as users come from anywhere, at any time, from any device, and can also request access simultaneously from multiple devices.
• Data Loss Prevention (DLP) is becoming an extremely important process and fingerprints need to be used so that DLP tracking tools can recognize data. When a policy violation occurs, quarantine and response measures must be entered.
• Protection and scanning of suspended VMs remains CSP.
• A full system scan in the cloud should not be used, as this degrades performance.
• If this is offered by the CSP, users should use the allocated resources, as they are more secure.
• Cloud extends the scope of security tasks to ensure the protection of resources and user data. The attack surface is much larger due to its scale and any breach can affect various clients and all the data they have entrusted to the cloud service provider for storing their data.

9. CONCLUSION
Virtualization introduces new security challenges for businesses. Virtual components and environments cannot be protected only by existing security mechanisms and processes. Virtualization creates another network, which is a hybrid between a physically centered network created and a new virtual or logical environment. To make sure that security is at the proper level, many factors and additional degrees of protection should be considered along with additional planning and training, as well as personnel training. Virtualization security should not be what you think of after creating a new virtual infrastructure and all components are in place. Security in this area will improve with the development of virtualization technology. In this area it is necessary to apply standards so that firms have rules to follow in the new environment.