-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/708/dark-reading-on-virtualization-security/ -
Subscribe
All Comments -
Community
-
Top Commenters
-
Press Controls
3 comments · 2 points
-
ChrisMtso
12 comments · 1 points
-
Eric Monti
11 comments · 1 points
-
StatlerAndWaldorf
12 comments · 3 points
-
Dave G.
7 comments · 1 points
-
-
Popular Threads
Hypervisor IPS sits in, above, or alongside your conventional hypervisor, and attempts to intercept attacks on the hypervisor, thus ostensibly preventing guest-to-guest attacks. There will be, I predict, 6 of these types of vulnerabilities in VMWare ESX over the next 8 years. Of them, 1 will be detectable by a shipping "Hypervisor IPS" within 6 months of the attack's disclosure on Bugtraq. You tell me whether it's worth it.
Hypervisor IPS will have no play vs. Hypervisor Malware; by the time you've cracked ring -1, you're already implicitly past any IPS installed on the machine.
The key factor for securing virtual servers behind the hypervisor will be a shield layer (within the hypervisor) that decodes protocols, etc. The idea of signatures for virtual server protection is dead:
http://alwayson.goingon.com/permalink/post/9944
G
http://www.bluelane.com/lib/pdfs/SecuringVirtua...
To insert Andreas into the discussion... I think there will be at least two panels in Vegas during Interop week on this topic. I think Andreas is moderating one of the panels (Interop Data Center Summitt; Art Wittmann the other(Interop). FYI
G
I think there's a decent claim to be made for "the network security device that will sit between VMs because it's hard to filter between VMs".
Of course, I also think modern enterprises are so far from having reasonable access control between the VLANs they already use without virtualization that it's not a "next 18 month" priority to install them.
I think there's no claim to be made for the need to protect OS's from malware that will attack either hypervisors or kernel-level security products.
After-market hypervisor security products introduce exactly the same types of security problems that after-market kernel security products do.
We'll talk to you soon. That way we can give you a clearer picture of what we're doing and where.
Nate:
http://www.bluelane.com FYI- emulating the security functionality of the patch isn't patch replacement, except in the case of impossible to patch systems. In the case of hard to patch, it allows for a saner, lower risk schedule. I provided a link to our website.
http://www.securityfocus.com/archive/1/461489/3...
Repeat after me: there is no silver bullet.
And so my firewall is even better since it handles 0-day neither approach can predict.
If it was the case (no difference between the block and the patch correction) then I'm assuming that your team doesn't patch... because there is a perception that IPS sig, etc blocking and firewalls settings have everything covered. Our position... patch on your schedule because we've applied the patch's security characteristics (multi-facted correction).
The point of my earlier posts is that virtualization is inevitable and WILL change the security requirements for the network: complexity will mushroom; server counts will escalate and processing power/apps will be more mobile than ever, eroding the value proposition of security tech tied to physical location. The homerun is that with the right technology/practices in place virtual environments can be MORE secure than their physical environment counterparts. But it will require new thinking.
G
@nate: attack behavior does not necessarily imply that the source of traffic is the real attacker, sometimes tearing down sessions -even if they are clearly part of an attack- could have unwanted consequences somewhere back/up-stream towards the traffic's source. I don't want some stupid thing reseting TCP sessions because it 'knows' an attack is going on and making some other stupid thing upstream blackhole the dst or src net because something is 'miss-behaving', let the transport layer be IFF you can deal with the issues at the app layer. That is a huge IFF and i'm yet to see this so called virtual-patching dealing with it and if it really is any different than an IPS
@greg: Would you elaborate on the last comment? It seems obvious that with the right technology/practices anything can be more secure than something else without them but how is it that virtual environments are inherently more secure than their physical counterparts? a virtualized solaris still runs telnetd and Mitchell's "we" (or "they") can still own it with -fbin.
Again, the virtual processor pool WILL require new thinking, new approaches... that are not tied to physical location, etc. As I wrote in my Always On blog referenced earlier I think it is the beginning of the end of static security.