Security in a “Virtual” Reality

Today, every business tries to cut costs in order to be competitive in tomorrow’s market. Sometimes, this is done by outsourcing IT, HR or other non-core services. In other organizations, cost reduction is achieved by consolidating its IT environment by using Virtualization.
By creating multiple virtual machines which share resources such as CPU, memory, hard drive, network devices, etc. organizations are able to reduce the cost of management of server operation. This includes the hardware, maintenance and human resources needed to manage, operate and administer these servers on a daily basis.
Furthermore, in regard to Disaster Recovery Planning (DRP), virtualization can also enhance the security level by providing means to faster, more flexible, and more reliable disaster recovery at a lower cost. It also significantly reduces planned and unplanned downtimes.
This demand created many software vendors who would be happy to sell you their product. Examples include OpenVZ, Xen, VirtualBox, Virtual Iron, Virtual PC, VMware, QEMU, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro, z/VM, and more.
However, failure to configure and harden your Virtual server might have very unpleasant results, especially when implemented without security considerations. In a number of cases we witnessed a hacker bringing down an entire virtual infrastructure because of a memory leak flaw on one of the servers. By exploiting this flaw, the hacker was able to consume all the available memory to a point where the entire system crashed.
The saying “Start Secure – Stay Secure” is a simple slogan used by Comsec to emphasize that security has to begin from the very first stages of design and integration, and should be integrated into every following step.
So, how do we secure a virtual environment?

Design a Secure Virtual Environment
Each solution has its own approach, which does not always suits the organizational needs. Some of these solutions completely separate each OS while others create separate “zones” with a shared kernel. Organizations need to determine security requirements that should correlate with the organizational security policy. A Security Architect should be involved in this stage in order to define parameters such as access control to server consol, design of virtual network architecture, design of virtual machines, communication protocols, etc.

Firewall
When implementing a virtual environment, some of the communication can relay on an internal, virtual network. For example, when a virtual web server communicates with a virtual database, the packets traverse through a virtual network only. A traditional firewall will not be able to filter this communication if needed.
There are a number of possible solutions. One of them is to use a firewall integrated into a virtual server application. The second option is to configure the virtual machines to route all the communication through an external firewall by connecting virtual machines to separate physical network cards. A third option is to use a “virtual” firewall which usually comes in the form of a virtual appliance. These appliances function as “traditional” firewall devices and can perform functions such as “Deep Packet Inspection”, session based rules, filtering, etc.

Hardening Virtual “Guest” Servers
In most cases we can assume that each virtual machine is fully isolated from another virtual machine running on the same server. These servers need to be hardened and tested periodically as their “physical” counterparts. Security vulnerabilities existing on one of the virtual machines could allow an attacker to skip from that machine to another in the network.

Hardening Virtual “Host” Server
“Host” servers are responsible for allocating memory and CPU to “Guest” servers, as well as providing access to storage and network devices. By receiving access to file systems on the “Host” server, an attacker will gain access to files stored on virtual machines. It is also possible to shut down the "Host" server which will result in DoS on each of the hosted "virtual" machines. These are only a few of the possible scenarios.
The “Host” server should be hardened and should undergo very strict access control. Only administrators and dedicated operators should have access to consol and virtual server management interfaces. The server should be updated with the latest security patches and it should be configured in a secure fashion.

(Security) Policies… Policies… Policies…
Every security decision should be backed up by an existing and approved policy. These policies should include:

• Password Policy (expiration, password length, etc.)
• Authentication Policy (Token, LDAP, local / etc/passd, etc.)
• Access Control Policy
• Network Connectivity Policy (such as separation to VLANs, firewall rules, etc.)

It is important to review these policies at least annually to make sure that they are updated with new standards and best practices.

Security Auditing
Security auditing should be performed on a periodic basis. Auditing should include:

• Security testing of “Guest” servers’ operating system and services
• Security testing of “Host” servers’ operating system
• Security testing of “Host” server virtualization application
• Relevant network equipment (switches, firewalls, routers, etc.)

This auditing is important in order to discover security issues such as new vulnerabilities, redundant services, outdated firewall rules and routing tables, etc.

Conclusions
Virtualization technology offers many operational and financial advantages. It even provides some security benefits. Nevertheless, this concept introduces several security weaknesses. The associated vulnerabilities include potential denial of service, data leakage and others.
With a proper and professional security approach towards the virtualization concept, one could achieve secure and reliable environment.
This approach should include proper secure design, secure configuration of the environment, secure maintenance, and proper periodical security audits.

Published under Comsec Consulting UK