<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Matasano Chargen - Latest Comments in Dark Reading on Virtualization Security</title><link>http://matasanochargen.disqus.com/</link><description></description><language>en</language><lastBuildDate>Fri, 02 Mar 2007 14:15:02 -0000</lastBuildDate><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321639</link><description>Mitchell: The fluid nature of virtual environments meet scans can be rendered obsolete in the blink of an electron.  The only way to stretch the time value of a scan is to set up policies that make virtualization less flexible... limit server creation and mobility capabilities to a predictable schedule.  But who would virtualize only to try to run the virtual environment in the same way as the physical world?  Does that really make sense?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Fri, 02 Mar 2007 14:15:02 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321638</link><description>The hypervisor clear text layer is a point of profound control/leverage over what goes on behind the hypervisor.  While virtualization brings heightened mobility, complexity and quantity issues, it introduces a powerful point of leverage for protecting pools of processing power, with one off and group policies, corrections, access, etc.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Fri, 02 Mar 2007 14:12:01 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321637</link><description>@mitchell: I did not understand a word of your comment. Who are "they" and who are "we"? What's a VAM scanner? what's that stratathing IPS? are you talking about VMM security or running a surreptitious marketing campaign on security blogs? "nipping the malware bud before it hits your network"?! whoah! did you come up with that phrase yourself?  do not worry, *we* are adding DMA-capable devirtualization agents with hypermophic payloads (tm) in on upcoming release RSN, it will roll up your NAC thing and smoke it for breakfast! &lt;br&gt;@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&lt;br&gt;@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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">ivan</dc:creator><pubDate>Thu, 01 Mar 2007 22:54:48 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321636</link><description>Mitchell, I don't understand what you mean by "hypervisor detection".</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Thu, 01 Mar 2007 20:43:56 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321635</link><description>Patches don't typically (merely) drop connections because availability is of prime importance.  They correct the traffic in a multitude of ways.  Dropping connections does work some time, but it isn't a "silver bullet" either.  Blocking needs to be highly accurate for starters (operational consequences) and there are cases where even accurate session interrupts can enable denial of service attacks. &lt;br&gt;&lt;br&gt;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).&lt;br&gt;&lt;br&gt;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.&lt;br&gt;G</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Thu, 01 Mar 2007 15:39:39 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321634</link><description>I don't see the difference between 1. dropping a connection when there's an attempt to exploit a known flaw (IPS) and 2. "emulating" a patch when someone tries to exploit a known flaw (you).  Do you really want to try to keep providing service to a clear attacker?&lt;br&gt;&lt;br&gt;And so my firewall is even better since it handles 0-day neither approach can predict.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Nate</dc:creator><pubDate>Thu, 01 Mar 2007 13:04:20 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321633</link><description>No matter what new technology they come up with, there will be room for scanning and detecting products like my VAM scanner and Strataguard IPS.   Regardless of the hyporvisor we can still scan the guest OS and detect mallicious code and vulnerabilities.   It also doesn't stop out Safe Access NAC product which is equally effective at nipping the malware bud before it hits your network.  We're also adding hypervisor detection in the next version of safe access.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mitchel Ashley</dc:creator><pubDate>Wed, 28 Feb 2007 19:58:26 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321632</link><description>There is no silver bullet.  Probably never will be a silver bullet.  Virtualization WILL erode the efficacy of static security solutions; and the best approach will be data center-centric vs trying to secure specific apps or tune signatures or play the hardware assist arms race.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Wed, 28 Feb 2007 17:50:50 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321631</link><description>Also see the recent bugtraq post about xbox360 hypervisor privelege escalation vulnerability which allowed for running unsigned code (this is different from DVD firmware patching which has allowed for pirated signed code to run since about a month after the xbox release):&lt;br&gt;&lt;br&gt;&lt;a href="http://www.securityfocus.com/archive/1/461489/30/0/threaded" rel="nofollow"&gt;http://www.securityfocus.com/archive/1/461489/3...&lt;/a&gt;&lt;br&gt;&lt;br&gt;Repeat after me: there is no silver bullet.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">grey</dc:creator><pubDate>Wed, 28 Feb 2007 15:25:36 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321630</link><description>Thomas:&lt;br&gt;&lt;br&gt;We'll talk to you soon.  That way we can give you a clearer picture of what we're doing and where.&lt;br&gt;&lt;br&gt;Nate:&lt;br&gt;&lt;br&gt;&lt;a href="http://www.bluelane.com" rel="nofollow"&gt;http://www.bluelane.com&lt;/a&gt;  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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Tue, 27 Feb 2007 20:03:41 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321629</link><description>Wasn't Blue Lane the company selling "no patching" IPS?  So I guess the marketing message is "protect the OS^H^Hhypervisor".  Isn't my firewall really a "no patching" Windows SMB appliance?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Nate</dc:creator><pubDate>Tue, 27 Feb 2007 16:21:01 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321628</link><description>I hope Andreas came cheap. "Virtual Shield" is a Blue Lane brand; it's a bit of a tip-off when your independent analyst puts your brand in the title of his paper.&lt;br&gt;&lt;br&gt;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".&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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. &lt;br&gt;After-market hypervisor security products introduce exactly the same types of security problems that after-market kernel security products do.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Tue, 27 Feb 2007 14:27:31 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321627</link><description>A Nemertes Issue Paper: Securing Virtualized Infrastructures&lt;br&gt;&lt;br&gt;&lt;a href="http://www.bluelane.com/lib/pdfs/SecuringVirtualizedInfrastructure.pdf" rel="nofollow"&gt;http://www.bluelane.com/lib/pdfs/SecuringVirtua...&lt;/a&gt;&lt;br&gt;&lt;br&gt;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&lt;br&gt;&lt;br&gt;G</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Tue, 27 Feb 2007 14:16:38 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321626</link><description>Thomas:&lt;br&gt;&lt;br&gt;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:&lt;br&gt;&lt;br&gt;&lt;a href="http://alwayson.goingon.com/permalink/post/9944" rel="nofollow"&gt;http://alwayson.goingon.com/permalink/post/9944&lt;/a&gt;&lt;br&gt;&lt;br&gt;G</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Greg Ness</dc:creator><pubDate>Tue, 27 Feb 2007 13:30:26 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321625</link><description>just a minor additional point: everyone in the 'security through virtualization debate' seems to be taking for granted that all guest to guest and guest to host communications and data/code context switches WILL be effectively mediated by the hypervisor. That is not necessarily so.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">ivan</dc:creator><pubDate>Mon, 26 Feb 2007 22:42:17 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321624</link><description>Er, yes. Thank you. =)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Mon, 26 Feb 2007 22:37:14 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321623</link><description>Was &lt;a href="http://www.darkreading.com/document.asp?doc_id=117908" rel="nofollow"&gt;this&lt;/a&gt; the article you meant the first link to go to?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Mike Myers</dc:creator><pubDate>Mon, 26 Feb 2007 21:19:16 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321622</link><description>Larry, I think you're conflating AV with IPS. Hypervisor AV has some value, albeit minimal (there are two hypervisor rootkits I know of and both are proof-of-concept and we own one of them). I predict Norton AV and McAfee will both have this checkbox by 2008. &lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Thomas Ptacek</dc:creator><pubDate>Mon, 26 Feb 2007 20:39:09 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321621</link><description>how about hypervisor IDS i.e. xenaccess?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dre</dc:creator><pubDate>Mon, 26 Feb 2007 19:20:04 -0000</pubDate></item><item><title>Re: Dark Reading on Virtualization Security</title><link>http://www.matasano.com/log/708/dark-reading-on-virtualization-security/#comment-2321620</link><description>Isn't it your hypervisor IPS that's likely to find your hypervisor malware? How can you ignore both?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">lseltzer</dc:creator><pubDate>Mon, 26 Feb 2007 18:27:37 -0000</pubDate></item></channel></rss>