How Does Virtualization Change Your
Approach to Enterprise Security and
Compliance?
Seven Steps to a Virtual‐aware Security Strategy.
® Michael Baum Co‐founder Chief Corporate & Business Development Officer Scott Shepard CISSP, CISM Principal ConsultantSeven Steps to a Virtual‐aware Security Strategy
Virtualization is a disruptive new technology that can greatly improve IT operational effectiveness while reducing overall costs, making it a critical initiative for IT Directors charged to “do more with less.” Virtualization has the potential to transform every layer of the enterprise IT stack, bringing consolidation and increased utilization of physical assets, version control of entire operating systems and applications, and instant virtualization as one of the fastest‐growing emerging technologies. Estimates are that the server virtualization software market will grow at a compound annual rate of 28% from 2008 through 2013 (from $1.8 billion to $6.2 billion). However, as virtualization adoption continues to increase, it has opened a heated debate in the market over the security and compliance of virtual environments. On one side, many virtualization product vendors argue that implementing virtualization increases security by isolating functions into their own environments. However, many security product vendors counter that virtualization introduces new risks including novel points of attack, the ability for virtual resources to easily evade policy and the volatility of critical security and compliance data. Who is right? There are core truths in both arguments. As with any new technology, in order to achieve a secure implementation, it is necessary to augment existing polices and practices with an understanding of how virtualization works. Rather than dwell on the debate, the focus should be on enabling a “virtual‐aware” security and compliance strategy ‐‐ adapting best practices to the unique characteristics of a virtual environment. Enabling a virtual‐ aware security and compliance strategy requires accounting for not only the technology aspects of the implementation, but also the people, process and policy components. This white paper outlines seven steps to establishing a virtual‐aware security and compliance strategy. Although VMware is cited for illustrating and explaining concepts within this document, the recommendations are applicable to any virtual environment regardless of the vendor or products used.
1. Align Your Security Strategy with Your Business Risk Tolerance
As the use of virtualization has grown, there has been a wave of products and solutions, including vendors, Altor, Catbird, and Reflex, introduced in the market to address different aspects of security in virtual environments. But, indiscriminately implementing security technologies can leave gaps in protection and impact the performance of your virtualized environments. In order to make business appropriate decisions on security measures and solutions to implement, you must start by identifying your business risk tolerance. This is defined as the balance between the security measures implemented and the amount of risk you are willing to take in conducting business. Security measures should always be implemented within the framework of a defined security strategy and that strategy must align with key business drivers and the business risk appetite.
The first step in identifying risk tolerance and building your security strategy is to understand and identify your business drivers for a specific virtualization environment and the organization as a whole. When considering virtualization, business drivers may include reducing IT infrastructure costs, improving service failover capabilities or a greater return on, and utilization of, the investment you have already made in IT assets. This should be followed with a security risk assessment in order to gain an understanding of your current or baseline risk profile. This will provide the inputs for defining an initial security policy that is designed to protect critical assets while achieving the identified business drivers. Keep in mind that the policy must meet applicable laws and compliance mandates relevant to your industry and organization as
well as remediate the critical vulnerabilities identified during the risk assessment process. Understanding the business drivers and risk tolerance for specific virtualization initiatives will help you balance the security measures required to meet both your business and security objectives. Consider the case where your media studio is using virtualization in a cloud service provider environment to apply extra compute resources and speed up projects. In this example, your risk tolerance may be fairly high and the security measures you apply at a minimum. Contrast this with your CRM system that manages critical sales, marketing, support and customer account information. Your risk tolerance for this application is likely very low and the security measures applied will be significant.
Figure 1: Virtual Environment Risk Tolerance
The next step is to identify the control points and technologies that can be applied to address the appropriate security measures. Control points identify where to place security monitoring and control technologies to implement the given security measures and policies. Control points are typically placed on the user, network, system, application, or the data. Some control points, for example, network control points, may change drastically when moving from a physical to virtual environment. In a physical environment monitoring messages, logs, configurations and packets can be accomplished in a fairly straightforward manner using any number of tools. In a virtual environment, virtual machines (VMs) have the ability to abstract the network through virtual switches and some of the traditional network control points may have moved inside the hypervisor itself. For example, since inter‐VM communication stays within the hypervisor, the information may not be able to be easily collected and monitored with traditional physical network security control points like firewalls, log managers or intrusion detection systems (IDS). Your virtual security and compliance strategy will need to account for any changes in control points and ensure that your security solution is appropriate and effective within a virtualized environment. Traditional security products don’t typically provide the same level of security when virtualized as they did in the physical environment due to physical limitations. For example, physical IDS and firewalls are not always capable of handling the jumbo frames (larger packet sizes) that are used to transfer data within a virtual switch and physical monitoring and log management solutions may not be capable of collecting the necessary information from the hypervisor itself, for example.
Figure 2: Changing Control Points
Finally, after the security measures and associated control points in the form of processes and technologies have been implemented, the last step is to perform a risk and vulnerability assessment in order to verify that the security policy and business objectives have been met. In order to remain effective, the security strategy needs regular validation by conducting periodic security assessments against the implemented security measures, the current security policy and the business drivers. Expect the security strategy to change over time. The output of the risk assessment is used to tune and adjust the security measures as necessary. The end result will be a secure virtual environment and strategy that is in line with the business risk tolerance for each environment and the organization as a whole.
2. Secure Virtual Machines Like Physical Machines
There is a common misconception that VMs do not require the same protective measures as physical ones. The misconception stems from the abstraction and hiding of the VM on a virtual network behind or inside physical hardware though Network Address Translation (NAT). This may give the impression that since the VM is not a physical entity, it cannot be seen by the outside world. However, the VM has its own IP address and must provide a service port to accept communication from the outside world leaving it open to the same vulnerabilities and threats as a separate physical machine. There is no additional security that is inherited just by deploying virtualization. Therefore, VMs need the all of the same controls and protective measures, including but not limited to: software patches, antivirus, change management, and intrusion prevention. An additional misconception is that the VMs are somehow hidden behind the host operating system or hypervisor. Most VMs will need to be exposed in order to provide clients with access to the applications and services on the VM. Even if the VMs are “hidden” behind Network Address Translation (NAT), and not directly reachable, they are almost certainly offering a service, such as email, Web, or a database, that is forwarded to them through that protective layer. Those services can still be attacked through the hypervisor. Application attacks, particularly to Web applications, are an increasingly common attack vector. Simply put, the VMs must comply with and maintain the same level of security as the physical system on the network and a virtualized application is as vulnerable to exploit as a non‐virtual one.Figure 3: Virtual Resources Behave Like Physical Resources on the Network
Not only does the VM need to be secured, but also so does the host operating system or virtualization layer (in many cases the hypervisor replaces the host operating system with a bare metal virtualization OS). It is best to use a hardened, thin host operating system or hypervisor, similar to VMware ESXi. These thin operating systems already have most of their unnecessary services and applications disabled and removed to reduce the chance of a vulnerability exposure. When implementing a thin host operating system consider what services could be re‐enabled through unsupported features. For example, an administrator with console access to an ESXi server can enable remote SSH connections, or other services, simply by accessing a root level command prompt and then enabling the features in the network configuration file. Make sure to perform a security assessment of the host operating system, using appropriate tools that are designed for virtual environments, to ensure that the enabled system services meet the security policy.Figure 4: Securing Host OS/Virtualization OS
3. Virtual Machine Isolation
When discussing virtualization, most security professionals first identify security concerns over how the VMs are isolated from each other and from the host operating system. Initial vendor security strategies focused on ways to isolate the virtualized operating systems so that a compromised VM could not gain access to the other guest systems in the virtual environment. Additionally, VMware and other vendors go into great detail discussing how to isolate the management interfaces.
However, in February of 2008, VMware introduced VMsafe, which allows access to the same internal applications VMware uses to manage the virtual infrastructure. With this capability, a special VM with promiscuous‐mode forwarding enabled can monitor the traffic of all VMs on the virtual switch. Besides network, the special VM can be configured to monitor other virtualized components (i.e. process, memory, or disk). VMsafe was introduced to improve performance of similar activities in all VMs. For example, why run anti‐virus in each VM, when a single VM can run anti‐virus and perform file scanning for all VMs? However, this capability violates the fundamental philosophy of virtual machine isolation.
Figure 5: Violating VM Isolation
At this point, move forward cautiously with VMsafe or similar solutions until this technology matures. VM isolation should be retained and each VM should maintain security within the virtual environment and not rely on VMsafe. Virtual security policy should require that all VM traffic crossing a network boundary route outside of the virtual environment pass through physical networking security measures in the form of firewalls, intrusion detection sensors, data loss prevention, and other network protective and monitoring technologies. Once the technology matures, VMsafe will likely prove quite beneficial in improving the security of all VMs in the environment.4. Limit and Monitor Administrative Access
The introduction of the hypervisor requires additional management software. This raises security concerns because the management software grants administrative access to multiple VMs. To address this issue, establish role‐based access controls for the individual VMs through the vCenter to mirror the physical access controls that had been established before virtualization. Additionally, establish network‐based firewall controls to limit network access to administrative interfaces. Severely restrict the number of administrators that have console/root level access to the host operating system. This access, as well as all administrativeactivities, must be logged to a centralized log management server (see section on security monitoring). In addition to access controls, utilize encryption and monitoring software (SSH and sudo, respectively) to avoid the sniffing of administrator credentials and to monitor for abuse of administrator privileges.
Figure 6: Limiting Administrative Access
In addition to protection of the management software, protecting the virtual files that make up the VM is critical. Utilize best practices to encrypt them when not in use, and limit administrative access to these files. When VMotion or similar technology is used to transfer these files between virtual environments, employ encrypted channels or out of band administrative channels.5. Protect Virtual Machine Resources
Virtualization offers the flexibility to leverage under‐utilized computing power within the virtual environment. What happens when multiple VMs in the virtualized environment come under a denial‐of‐ service attack? In a traditional, physically separated environment, the systems, which are not under attack, are not affected. However, in a virtual environment the underlying physical infrastructure and all VMs may be affected. For example, in a 4GHz physical infrastructure, if four VMs were each allocated 2GHz of virtual processing power, a denial of service attack on two VMs would adversely impact the performance of the remaining two VMs even though they are not under a denial of service attack. Expanding this example, assume there are four VMs spread across multiple network boundaries in a DMZ (“demilitarized zone” ‐ the buffer zone that separates the Internet and your private LAN). Two of the VMs make up a Web cluster that is accessible from the Internet. The other two VMs are on the internal network and are not directly accessible from the Internet. Using the example configuration, where each of the four VMs are allocated 2GHz, a denial of service attack on the Web cluster will have a performance impact on the two internal network VMs. The end result is that the service availability of all four VMs would be degraded.
Figure 7: Physical Host Partitioning
Figure 8: Resource Load Balancing
To maintain the desired level of service availability across all VMs, resource (processor and memory) allocation should be managed based on the desired service levels for the VMs, and not solely on the business driver in reduction of physical servers. Establishing reservations, shares, and limits, will ensure stability and availability of critical VMs if multiple VMs come under denial of service attack. Additionally, these settings should be monitored and adjusted over time as the virtual environment evolves. This can be done manually or through VMware DRS (Distributed Resource Scheduler), which allocates and balances computing capacity for virtual environments on multiple ESX hosts.
6. Enforce Virtual Machine Configuration and Patch Management Policies
In a physical environment, configuration and patch management are mandatory for maintaining a secure environment. This same principle applies equally to the virtual environment. All virtual systems should fall under the same configuration and patch management process. With virtualization, however, there is one notable difference. How do you address configuration and patch management for off‐line VMs? Utilizing server endpoint protection to ensure any off‐line VMs are brought into security compliance before they go online can solve this. Additionally, all VMs used for disaster recovery planning must be brought online periodically to ensure that they are compliant with current security policy, and ensure immediate activation during an emergency.Figure 9: Enforcing Configuration Policies
With a virtual environment, configuration and patch management of the host operating system is a must. Vulnerabilities and poor configurations, if exploited, can impact the entire virtualized infrastructure. In some cases additional processes need to be created to handle “bare metal” host operating systems that are hardened and stripped‐down. Since these are reduced operating systems, patching and configuration tools may not be capable of applying the same patches to the host operating system. A customized patch management and configuration process must be established for patching the host OS. Ideally, the customized process should leverage virtualization’s high availability capabilities that move critical VMs from one virtual environment to another while the underlying host operating system is patched. Less critical VMs can go offline while the host OS is being patched. In both cases, ensure the customized process includes notifications to all users, administrators, and owners of these VMs.7. Security Monitoring
Today’s IT computing environment is complex, with business requirements driving an infrastructure that is made up of a wide variety of applications, systems, devices and technologies. The threats and vulnerabilities inherent within today’s environments make maintenance and security a constant concern. A simple change to a single component can have a rippling effect on many other applications and systems across the enterprise. Industry best practices dictate the need for monitoring and reporting on the security and compliance state of your environment.
Adding a new technology, such as virtualization, to an already complex environment magnifies the security issues. Deploying virtualization requires additional security monitoring of the administration activities, the virtualization management interface, and access to the virtual machine logs, messages and events. Much of this data will also need to be retained for security investigations and compliance reporting. Effective monitoring and reporting across a virtual environment can be tricky as virtual resources and their associated security and compliance data migrate between physical systems and potentially disappear all together.
Figure 10: Virtualization Security Monitoring and Reporting
Security monitoring and reporting can be achieved by first performing an inventory of the security and compliance data your physical and virtual resources generate including the location (memory, file system, network port) and the best way to access the data. Often accessing the logs and messages from a virtualized environment can be tricky, as many virtualization vendors haven’t designed very robust, scalable APIs or data forwarding mechanisms. Capturing data in near real time is important given the migration and volatility of virtual resources and data. Once identified the data sources and collection mechanism, you’ll need to deploy a security event management and reporting solution to correlate all the different types of events and technologies in your virtual stack (applications, operating system, network, storage, access control).
Best practice is not to deploy security monitoring and reporting solutions as part of the virtualized environment, as administrators have the ability to remove traces of their own activity. Once your data is consolidated, the logs, events and message can be correlated to provide actionable alerts, enable comprehensive security investigations, speed troubleshooting of complex problems and archived to meet compliance retention and reporting requirements.
Getting Ahead of the Game
Taking advantage of new technologies need not be a risky proposition. By combining security best practices and an understanding of how the technology works, companies can efficiently and securely implement the promised benefits. By utilizing the recommendations outlined in this paper you can define the appropriate risk‐based security policies and implement necessary controls to achieve a secure virtual environment. • Develop a well thought out “virtual‐aware” security strategy. • Assess and understand your vulnerabilities • Enhance existing security measures, control points and monitoring to address virtualization gaps. • Balance acceptable risk with business drives to achieve the benefits of virtualization.References
• “Security Design of the VMware Infrastructure 3 Architecture” by Charu Chaubal, VMware
• “Security Considerations and Best Practices for Securing Virtual Machines” by Neil MacDonald, Gartner, 6 March 2007
• “ESX SERVER SECURITY TECHNICAL IMPLEMENTATION GUIDE Version 1, Release 1” Developed by Defense Information Systems Agency for the Department of Defense, 28 April 2008
• “Dataquest Insight: Virtualization Market Size Driven by Cost Reduction, Resource Utilization and Management Advantages” by Gartner, 5 January 2009 • “The Guide to IT Search” by Splunk, January 2008 • “The Business Model Ontology a Proposition in a Design Science Approach” by Alexander Osterwalder, UNIVERSITE DE LAUSANNE, 2004
