As I said before, there is plenty of hype and confusion about how to properly secure virtual infrastructures and the state of the netsec industry relative to the growth of virtualization. I would like to step up and take a few swings at the issues in an effort to dispel some of the myths and hype. (I also thought that I would publish my blog picked up earlier at Seeking Alpha.)
For example, some netsec experts argue that nothing changes with virtualization. They’ll be using their existing firewall and IPS technologies in a combination with restrictive policies in an attempt to secure these highly-fluid, mutating environments. Lot’s of luck. While this may be the end-game promoted by mainstream security vendors, it will end up restricting virtualization to a level where the payoff is minimized.
The “Inflexibility Policy” Myth
Imagine investing in a virtual environment then hamstringing it with all of the inflexibility, manual labor and kluge of the infrastructure it replaced. The inflexibility policy myth means that policies and procedures could be used to make virtual infrastructures behave like physical ones. In short, effective security would mean ineffectual virtualization.
That delusion is bound to eventually cost a few jobs, either on the ops team or the netsec team… depending on who gets blamed for the decision. If the netsec team is figuring that policies to limit flexibility (prohibit offline/online/VMotion or snapshot/revert) are the best approach to compensating for netsec hardware shortcomings, you may want to educate them about why you’re virtualizing in the first place.
Flexibility is one of the key drivers of the payoff. You might also want to advise them that “inflexibility policies” will be harder to enforce in a virtual infrastructure that delivers… unprecedented flexibility.
The NetSec Hardware Myth
Some netsec pros might also think that their existing firewalls and intrusion prevention systems will be up to the task, despite expert advice to the contrary, including the recent Gartner report on virtsec firewall limitations covered in Network World. Most existing perimeter security appliances will not be able to see or secure inter-VM traffic. They were never architected with the level of protocol fluency to understand the traffic flows, and their form factors will continue to require specialized hardware, a flashback to the recently departed past.
So until netsec solutions transform themselves into software only form factors that can accurately inspect and correct traffic without false alarms and fat footprints, leading vendors depending on product strengths for revenue might as well plan an HQ move to a lower labor cost country.
Netsec hardware is about to be commoditized by the coming virtualization of its shrinking habitat. No more pipes. No more custom hardware. No more false alarms. No more services revenue stemming from the noise and mayhem that these older systems generate looking for suspicious patterns and permutations.
Virtualization represents a sea change for the network hardware business, not unlike the impact that the emergence of the desktop OS had on the mainframe. Yes, we still have mainframes. Yes, virtualization is a kind of return to the days of hold. If you’re thinking about emailing me that there are still mainframes or that virtualization is really a return to the mainframe (and therefore nothing new) you’re not getting my point.
The hardware infrastructure that emerged with the rise of desktop computing and the internet is about to collapse back into the server. That model is infinitely more scalable, more dynamic and more flexible than the world of pipes, racks and screwdrivers. That is why virtualization will win out over daisy chains of specialized hardware.
The Hypervisor Attack Vector Myth
Some deep security experts suggest that there are new hypervisor-specific attacks that pose real, catastrophic threats. As I commented while on an InformationWeek panel last month, the hypervisor is modern code with a very lean attack surface. Compare that lean hypervisor code to the layers of code and sizable population of known vulnerabilities in any leading operating system or application/database. Then look at the rate of change now possible in a virtual infrastructure.
The risks related to VM state changes, sprawl and even VM theft (using existing attacks against existing vulnerabilities) are much higher than an attack against the hypervisor itself. Existing vulnerabilities in a fluid environment are the real issue. Existing netsec hardware wasn’t ever intended to defend this kind of environment, and most solutions are exploit-centric and protocol/application unaware. They cannot stop an attack that they cannot see. They cannot see traffic between VMs. And in the meantime they could generate exponential increases in false alarms as suspicious traffic ripples through interconnected, fluid VM meshes as they architect “klugeworks” into VM traffic meshes.
So let’s move on from denial and the “I can get my virtual infrastructure to be as inflexible as my physical one” type of discussions and step up to a discussion about what’s different, what’s the same, and where we go from here. No more hypothetical, abstract discussions about whether a physical or virtual infrastructure is more secure.
Let’s use the hypervisor layer to deliver improved security. After all, it is a standardized inflection point that can scale with the servers and the traffic- as long as it is protocol fluent. Earlier this week I mentioned the Gartner webcast. Feel free to take a look. You won’t have to register and you can click through as fast as you want.