Virtualization is happening, and it's happening fast. Whether it's VMWare's inflated valuation, the recent acquisition of Xen by Citrix, or Microsoft actually shipping their Hyper-X technology EARLY (when was the last time Microsoft shipped anything early?), all you hear about is virtualization. The operational benefits of virtualizing servers are certainly apparent, but we are only now starting to discuss the security impact of having flexible computing resources that decouples the hardware enclosures from the computing environments. To be clear, there is still a lot of disagreement about what the real risks are relative to virtualization, so let me cover a bunch of the potential issues.
The hypervisor is actually another operating system and thus needs to be secured like an operating system. If the hypervisor is owned, which is called hyperjacking, it's game over for all the servers that run on top of the hypervisor and given that virtual machines (VMs) can be moved dynamically between hypervisors running on separate machines, one jacked VM puts your entire data center at risk.
To their credit, VMWare and Xen are saying the right stuff and even spending some money to address the issue, as evidenced by VMWare's acquisition of Determina. But having been in the security business for a long time, I know nothing is totally secure. The good news is that there hasn’t really been a demonstrably successful attack on the hypervisor yet, but I wouldn’t bet that there won’t be. In any case, you need to be prepared for the inevitability of a hypervisor exploit.
The entire industry needs to keep pushing VMWare and the other virtualization players to ensure they have as effective a security research and quick response patching capability as the core operating system vendors.
To be clear, there isn't anything specific to virtualization that needs to be done within the application to make it more secure. But this gives me another opportunity to keep beating the drum for better secure application development practices. So make sure those applications are as tight as they can be because there is a lot more at stake in a virtualized environment. Remember, a vulnerable application running on the hypervisor could allow root access to OS, which in turn allows that VM to launch attacks against other virtual machines.
Virtualization does complicate the software updating and patching process. Why? Becuase you are just dealing with a lot more machines to update as it’s so easy to just spin up another VM at will. So each VM needs to have a standard build, which should include some automated mechanism (meaning some kind of agent) for configuration management and/or patching. Trying to do this stuff manually will be a nightmare.
Virtualization also turns the network vs. host-based intrusion prevention debate on its ear. The reality is that it's hard to really determine what the "network" is in a virtualized environment. VMs running on the same machine will communicate with each other without communicating through the actual "network," so intrusion prevention devices will need to factor that in to remain relevant in an increasingly virtualized world.
One other point I'll make about virtualization security is that noise is going to become deafening in 2008. Every security vendor will be rolling out their virtualization "story" and it will become very confusing for customers. One option is basically to ignore it and that may be the best option. But if you feel compelled to try to understand what is going on, make sure to figure out whether the vendor is just running their stuff on a "virtual appliance" or whether they've done something specific for virtualization. There is a difference.
The bottom line for application developers is that virtualization is very similar to SOA. A lot of the underlying resources that drive applications like data and computing resources are virtual and therefore largely unknown. So part of building applications continues to be relying on "faith" that the data you are calling is the right data and that the requests that you are responding to are authentic and authorized requests. It would be counter-productive to build these security capabilities into the application logic like authentication and authorization because that defeats the purpose of the entire virtualization model.
The reality is regardless of whether the application is running on a real or "virtual" server, it needs to be built with proper input validation and protection against cross-site scripting and SQL Injection attacks. So from that standpoint, virtualization is more of the same, only a lot more (in terms of machines) and a lot faster.