Manage Learn to apply best practices and optimize your operations.

A six-step virtualization risk assessment process

Learn how to perform a risk assessment on your virtual environments.

To properly evaluate the risks present within their virtual environments, security professionals will need to perform...

a thorough risk assessment on a regular basis, likely working with both operations and auditing teams in the process. Many teams may not know the best approach to take, or how to get started with performing this kind of specialized risk assessment. The good news is the overall process doesn’t change much from more traditional risk assessment approaches. However, there are certainly specific issues to pay attention to, and we’ll cover those in this six-step virtualization risk assessment process:

1.      Identify virtualized assets and categorize data storage associated with virtualization. With virtual environments, unfortunately, this can be a very difficult step. Leverage management tools like VMware vCenter and Microsoft’s System Center Virtual Machine Manager (SCVMM) to identify virtual machines, VM storage and hypervisor platforms, and use native storage management tools from vendors like EMC Corp. and NetApp Inc. to keep track of where disk files are located. These disk files should be located on SAN or NAS partitions appropriate to the sensitivity of the data they contain, as with any data classification effort.

2.      Identify and characterize threats to the virtual environment. Any operating system or application will have the “normal” threats to contend with, such as known exploits and attack scenarios. However, you’ll also need to include threats to the virtualization components themselves, such as virtualization-aware malware, virtual machine “escape” (where an attack affects the hypervisor from inside a VM), and chipset exploits and attacks that are being researched by groups like Invisible Things Labs, which specializes in cutting-edge research in virtualization security, among other areas.

3.      Take stock of vulnerabilities in the various architecture components. Every major virtualization platform has had a number of vulnerabilities made public, and some are extremely severe. It’s important to know what kinds of issues could affect your systems, and the best sources of information include well-known vulnerability disclosure sources, such as Secunia and CERT, as well as the vendors themselves. Keep in mind that many virtualization platforms have included open source components (such as VMware ESX’s service console), and these can have vulnerabilities that then affect the hypervisor and other virtualization technologies.

4.      Determine the likelihood of successful attack or exploitation, as well as the possible mitigation measures that could be taken to prevent or at the least deter the threat. For virtualization platforms, this will typically include a range of options: Traditional network and host-based controls like IPS and antimalware software, as well as virtualization-specific controls like Juniper’s vGW Virtual Firewall and VMware vShield products that protect virtual networks, virtualized applications and the VMs themselves.

5.      Determine overall risk. Once the threats, vulnerabilities and attack likelihood have been evaluated, and potential mitigation measures identified, the overall virtualization risk can be determined. The overall risk will stem from a combination of:

  • Asset and data value: Virtualized or not, the systems, applications and data being evaluated should largely determine priority for considering threats, potential attacks and  mitigation efforts.
  • Threats and vulnerabilities: How vulnerable are virtual systems and architecture components? What are the most viable threats to the systems, and what is the likelihood of those threats actually manifesting? For example, Joanna Rutkowska’s “Blue Pill” attack implemented a thin hypervisor in the chipset of a system (thus creating a virtual rootkit), and caused a great deal of consternation in the security community in 2006. However, the practicality of the attack was so minimal that it was largely relegated to being hypothetical or theoretical in nature.
  • Ease of mitigation: Can the threats be nullified or largely mitigated by implementing a variety of technical or procedural controls?
  • Exposure level: The exposure level of the virtual systems or components plays a significant role in determining the overall risk. VMs and hypervisor platforms in the DMZ are much more exposed than management servers in a tightly controlled management network segment, for example. This should factor into the attack likelihood analysis.

6.      Document and test. Unfortunately, the final step in your virtualization risk assessment process is one that’s often overlooked or glossed over: documentation and testing. A risk assessment methodology, as well as its results, should be considered a “living document,” and keeping this up-to-date should be a priority for information security and audit teams. This will help to ensure the risk methodology is adequate and effective over time, especially given the rapid pace of change in virtualization technology.

About the author:

Dave Shackleford is a founder and principal consultant with Voodoo Security and also a certified SANS instructor

This was last published in July 2011

Dig Deeper on Cloud Computing Virtualization: Secure Multitenancy - Hypervisor Protection

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSecurity

SearchCloudComputing

SearchAWS

SearchCloudApplications

SearchServerVirtualization

SearchVMware

ComputerWeekly.com

Close