Gartner Blog Network

RSA and Virtualization Security

by Neil MacDonald  |  April 23, 2009  |  2 Comments

When I called this “virtualization security” week, I wasn’t kidding. There were at least a dozen different session on the topic this week at the RSA conference in San Francisco. I’ve been researching the issue for several years, so it is exciting to see ideas and recommendations I have been giving in research, inquires and presentations to clients for years now becoming mainstream.

Most of the sessions focused on the issues and best practices for virtualization security. The biggest misconception is that we don’t need to do anything different than what we are doing today to secure physical environments. The logic goes like this: “I already know how to secure operating systems and I know how to secure physical servers, so I don’t need to do anything different.” Of course, this ignores the fact that we have introduced a new IT platform in the form of a new software layer between the operating systems and the hardware, it ignores the use of internal virtual switches and VLANs within the server for routing traffic between VMs, and it ignores separation of duties issues created when multiple physical boxes, networks and potentially security controls are all crammed together in a single box. And that’s just scratching the surface. There are a bunch of other issues and considerations you should be thinking about as well that I’d be glad to chat with you about.

A session today got into a philosophical debate between Simon Crosby of Citrix and Steve Herrod of VMware on the VMsafe set of APIs that VMware is introducing with vSphere. As I have discussed, VMsafe is cool, but it’s not a panacea. Simon’s major issue was that the VMsafe APIs haven’t yet been opened up for public scrutiny and inspection. I agree. Security through obfuscation doesn’t work. VMware (and any hypervisor/VMM platform provider) must assume that the bad guys will get access to the APIs. What can be used for good things can be used for bad things as well. VMware should put this issue to rest by documenting the APIs and their usage for public inspection. VMware should also go further by using mandatory access controls on the APIs as well providing infrastructure that supports the use of digitally signed code for vendors that use the APIs.

Philosophical arguments aside, the status quo for information security isn’t working. VMsafe is an innovative approach to deliver security functionality in a radically different and improved way than we do today in our physical infrastructure.

It was a shame that a good chunk of the session was spent on this topic when most of the people in the audience just want to get a better understanding of what they can do today to improve their virtualization security posture. Here’s two out of dozens in my research:

  • Extend your existing vulnerability and configuration management processes to address this new IT platform.
  • Proactively engage in a discussion of the security risks of virtualization with the IT Operations teams deploying virtualization. In some cases, you’ll need to modify your processes, for some you might need compensating controls, for some you might need to buy a point solution to reduce the risk and in others you may acknowledge and accept the risk. The important point is to have the discussion now and not wait until something bad happens

Category: virtualization-security  

Tags: best-practices  virtualization-security  vmware  

Neil MacDonald
VP & Gartner Fellow
15 years at Gartner
25 years IT industry

Neil MacDonald is a vice president, distinguished analyst and Gartner Fellow in Gartner Research. Mr. MacDonald is a member of Gartner's information security and privacy research team, focusing on operating system and application-level security strategies. Specific research areas include Windows security…Read Full Bio

Thoughts on RSA and Virtualization Security

  1. Neil,
    This blog seems like a great “connect the no-brainer” dots together opportunity. Here’s a recap of your Security No-Brainers (SNB) so far:

    • SNB #1: We Need a Global Industry-wide Application Whitelist
    • SNB #2: Use whitelisting in the hypervisor/VMM (especially in the “parent” or Dom0 partition) to prevent the execution of unauthorized code in this security-sensitive layer.
    • SNB #3: Root of Trust Measurements for Hypervisors

    (Relating to SNB #1 – check that one off. We did publicly announce our working relationship with Microsoft in the area of software whitelisting at the RSA show. A key element of that announcement is the standards for whitelist exchange using a Standard Whitelist Schema Definition – or Data Exchange Format. So an important sub-text SNB is: We need standards in method, protocol and exchange).

    So against the backdrop of the RSA events, this blog heading, and staying within the limits of several NDA’s that we (SignaCert) are bound by – let posit a connect the SNB dots:

    It seems the goal in both the P (physical) and V (virtual) world are ultimately the same; that is to instantiate a software stack on a hardware platform that is secure, reliable, safe and trusted. This larger stack (hardware plus software) now becomes one of the cogs of a business process (A *Service* in ITIL parlance).

    All of the cogs of any completed service should ideally be “trusted” right? Not just a point of instantiation, but all the way thru the point of de-instantiation (There are some interesting compliance issues here to, but that is for later).

    1. So the root of trust for measurement (RTM) should be established in the hardware in some fashion, say with a Trusted Platform Key, and establish RTM for HV/VMM (SNB #3)
    2. And the Trusted Platform Key should be passed and used to request and validate (attest) the HV/VMM in the Dom0/parent layer (SNB #2)
    3. And once we have a “known/trusted” parent environment (and hopefully a way to keep it that way), we pass our “trust baton” up the stack.
    4. We then need the HV/VMM to instantiate *the rest of the software stack* with positive attestation methods provided by the Global Industry-wide Application (software) Database (supported now with ISV-sourced software “measurements” aka SNB #1)

    And we need some way to make sure what we have instantiated with a proactive statement of platform/image trust, and that it stays that way and we can “prove it”. We might also want a way for that service process stack to offer its “platform trust credentials” to other members of the broader business/service process both in and out of the physical domain that it may reside in (to a partner service process for example).

    (public disclaimer on this one too: we have two US patents issued on the precise method of Stack/Platform Trust derived from element trust scores)

    To make all of this really work, the platform players must work with closely with the virtualization players, and those player should work closely with the whitelist eco-system folks. And all of the players should work well with the systems management vendors/solutions.

    By the way, in our experience one of the trickiest parts relates to #4 above. That is:

    How do we manage multiple complex heterogeneous V and P stacks? How do we create and express broader trust credentials across a matrix of dynamic business/service processes?

    And another design tenet that we must undertake are persistent and non-persistent connect scenarios. We need to carefully address the prospective circular loop issue of “we need a connection to attest trust credentials – but can’t get a connection because we don’t have trust attestation”.

    Cooperation with our eco-system partners is required to pull this one off.


    We agree. We need to think and act differently. The “old” P security methods are running out of gas already, so let’s use the virtualization transition to bake trust and security in as we stand up the V ecosystem.


    A parting P.S. Does Security drive Trust, or Does Trust drive Security?

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.