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