Virtualization and Security: What is real and what is FUD?

There seems to be a lot of discussion about virtualization, and rightly so. Virtualization promises dramatic, immediate benefits for many customers.  The purpose of this post is not to reiterate those benefits; a tremendous amount of information already exists.  However, as a security professional, I am concerned with the sensationalizing of virtualized security and how it is proposed as an entirely new sector of security within a virtualized environment.  With a few quick Internet searches, we are met with a barrage of articles from proposed consulting expertise to unique virtual appliances promising a solution to a yet-to-be explained virtual problem (pun intended).

The first question I always ask is, “how is virtualized security different than traditional security?”  The resounding response I most often hear when I ask industry peers is that virtual security is a way to secure virtual server environments (obviously).  When I dig a little deeper, I get the response of, “if a virtual server has been compromised (lets say a virus/worm), it will be able to cross-infect all of the other virtual servers co-residing within the same physical server hardware.  Therefore customers need to provide a virtual security layer between each of the virtual servers.”  Sounds like a logical conclusion – if you follow this argument.

While I feel there is some validation to that argument, I am concerned that there is a lot of misinformation and FUD (fear, uncertainty, doubt) being spread based on a lack of understanding of the technology and potential security threats focused on virtualization.  Consider a classic data center before virtualization appeared.  The design often consisted of a server farm front-ended by a load-balancer / application accelerator, which often lies behind a layer of security solutions (firewall, web content filtering, antivirus filtering, IPS etc.).  In a traditional design, the servers were optimized for performance by the application acceleration layer and the security layer protected the overall infrastructure from the threatscape.  In reality, this physical server farm infrastructure is prone to the same potential fate as its virtualized counterpart – co-resident physical servers can just as easily infect each other if compromised, but that doesn’t mean we implement  additional security layers between every server, it just meant that we strengthened the policies and security measures surrounding the server infrastructure.

By comparing the virtualized server farm and the physical server farm, the security concerns are indeed similar.  But currently we are told that we need to implement another approach to securing our virtualized server farm just because it has been virtualized?  Why is this the focus?  Can’t we follow the traditional architectures?  If you were of the higher-security model and you had each server compartmentalized behind a dedicated security device, you can still achieve the same with virtualization by only allowing each virtual server to communicate via an external security device – which will also provide increased visibility into the communications between each server.

I will agree that virtualization provides a tremendous amount of flexibility that is difficult to achieve with traditional server infrastructures, and yes, with flexibility comes potential security concerns opening up the door for new security measures. However, by rethinking traditional security solutions we can surely adapt to secure this new frontier of virtualization.

My argument is not with virtualization, as I wrote above I do believe it provides immediate tangible benefits for many customers.  However I am concerned that a lot of vendors are trying to ride the wave of the virtualization success by manufacturing concepts and concerns that are not 100 percent accurate, or worse, not in the best interest of the customers.