Tom Olzak recommends specific updates that address the security of your virtualized environment that may not be in traditional security policies.
Server virtualization is no longer a new, tentative technology for most organizations. Rather, it is a common approach to implementing business solutions without the long process of CAPEX justification and hardware implementation. However, the ease with which IT can implement virtual machines (VMs), and the proliferation of stored VMs, introduces risk not addressed in traditional security policies.
Guest and host servers require the same basic security configurations as physical application or database servers: anti-malware, access controls, patch management, monitoring, etc. Challenges arise when applying certain controls across multiple VM application/database servers all managed via a hypervisor. Further, additional access control considerations challenge segregation of duties. So even if the host system is locked down, hypervisor and VM security requires additional steps, starting with adjustments to policy, standards, and guidelines. Areas of virtualization-driven policy review include:
- Segregating system management (logical and physical)
- Securing and patching VMs
- Monitoring and responding to events
- Managing change
These apply both to your internal systems and systems hosted by cloud service providers (CSPs). Include them in any initial and ongoing assessments of CSP risk.
Segregating system management
In traditional server implementations, administrator access provides full management capabilities across all resources. While this is a good idea for physical server implementations, it is a very bad idea for virtualized environments.
Enabling access segregation begins with physically isolating hypervisor management from host and VM access. Each host server should contain at least two physical network interface cards (NICs). Configure one NIC for management access only. Add this NIC to a network segment with an access control list restricting access to only those devices/users directly responsible for maintaining the hypervisor and for VM creation and suspension.
The basic premise for virtualization security is assignment of management access by role. This is easily done when using management solutions provided by VMware and Microsoft. The intended outcome is ensuring separation of administrative rights and permissions. Policies should contain restrictions unique to virtualization:
- Segregate host platform administrator access from VMs and VM management access. Engineers assigned to maintain the host OS and hardware do not need to create, suspend, or access VMs and the hypervisor.
- Use different passwords for each VM. Don’t fall into the trap of assigning all VMs on a single host the same password.
- Restrict access to each VM based on separation of duties, need-to-know, and least privilege. For example, an IT staff member might need access to a VM for OS or business application maintenance and support. However, he or she doesn’t necessarily need access to the other VMs.
- Restrict VM and hypervisor management access only to those directly responsible for maintaining the virtual environment.
Securing and patching VMs
Existing policies should already cover virtual server security; it is exactly the same as physical server security. Install anti-malware software on each VM, close all unused ports, and perform other server hardening steps to reduce and control each VM’s attack surface. Base the amount of security for each VM on the risk to the organization if it is compromised. To mitigate costs and help control information assurance across a virtualized data center, do not mix data of different classifications on the same VM. Group VMs of the same classification on the same host.
Patching policy usually applies only to operational servers, but virtualization introduces a new challenge: patching stored VM images. Images are sets of files stored in a secure folder. One of the benefits of virtualization is a quick recovery of a server with a stored image. Another is creating stored images representing baseline VM environments used when creating new virtual servers. Do not forget them when patching. If you do, you’ll likely expose your network to threats looking for a vulnerability you already patched in production.
Both VMware and Microsoft provide tools to patch VM images.
Monitoring and responding to events
Incident response for virtual environments is similar to that used for traditional data centers. Five differences exist that you should add to your policies and standards (Olzak, 2011, InfoSec Institute):
- Group VMs according to data classification, as discussed above.
- Ensure monitoring tools see packets internal to VMs managed by the same hypervisor. Monitoring tools exist for virtual servers and the data passing between them. Link the logs to your log management or SIEM solution to ensure system visibility. Adjust your incident response policies and processes to assume that all VMs on the same host are compromised if one is confirmed infected or owned by an attacker. In addition to monitoring, integrate existing IPS or implement a virtual IPS solution where appropriate.
- Segment virtual networks. Use VLANs, or a similar mechanism, to isolate sets of VMs on the same host and across hosts. Virtual switches make this easy to manage. For more information on VM isolation, see Five Steps to Incident Management in a Virtualized Environment.
- Remedy forensics issues. Ensure all VMs and host systems sync with your time server for forensics and auditing purposes. Time services include:
a. NIST Internet Time Services
b. How to configure an authoritative time server in Windows Server
- Track all MAC addresses during VM initialization and moves. This ensures consistent historical logging of VMs across various host systems. Finally, adjust response and forensics policies and procedures to include seizure of all VM system files. File names and locations vary by vendor.
- Mitigate business impact. This is an inherent quality of virtualization, if implemented. Ensure current VM snapshots exist to facilitate quick recovery during or after a business continuity event.
Change management, as a critical piece of ensuring consistent security across all systems and network segments, should already be in place. However, additional considerations exist when virtualizing servers.
- Avoid sprawl. Sprawl as applied to virtualization implies an uncontrolled proliferation of VMs. Because VMs are easy to implement—especially when standard images exist—it’s easy for IT to get into the habit of creating servers when existing servers would work just fine. Unless change management and operational processes control this, a data center can quickly become complex and unmanageable.
- Ensure business continuity. Be sure the final image of a production server is stored safely where it provides a quick path to recovery. Update the stored image each time you make a change to the production instance.
- Secure VM files. Ensure all files associated with running or stored VMs are kept behind a high wall. No one should have access except IT staff directly responsible for VM file management and VM instantiation.
- Segregate access to virtualized environments based on user role. This includes separating hypervisor, host OS, and VM OS and application administration.
- Maintain VM file sets in folders locked down and monitored. Use vendor or third-party tools to patch inactive VM files to prevent introduction of vulnerabilities.
- Expand log management and alerting activities to include traffic between VMs on the same host. IPS should also have visibility into traffic passing between VMs on the same host.
- Prevent sprawl and associated data center complexity by adjusting change management processes to include a decision about whether a new VM is necessary. Also, include steps to secure new VM file sets and backup the new VM image post production implementation.