Home > Virtualization, VMware > Clarification from Catbird’s CTO on HypervisorShield…

Clarification from Catbird’s CTO on HypervisorShield…

February 19th, 2008 Leave a comment Go to comments

Catbird_logo
Last week I posted about a press release announcing a new product from Catbird called HypervisorShield.

I was having difficulty understanding some of the points raised in the press release/product brief, so I reached out to Michael Berman, Catbird’s CTO (also a blogger,) for a little clarification. 

Michael was kind enough to respond  to the points in my blog posting.

Rather than repost the entire blog entry, I have paraphrased the points Michael responded to and left his comments intact.  I think some of them invite further clarification and I’ll be following up with a Take5 interview shortly.  Some of the answers just beg for a little more digging…

Just to ground us all, here’s the skinny on HypervisorShield:

Catbird, provider of the only comprehensive security solution for virtual and physical networks, and developer of the V-Agent™ virtual appliance, today announced the launch of HypervisorShield™, the industry’s first dedicated comprehensive security solution specifically designed to guard against unauthorized hypervisor network access and attack.

Here are my points and Michael’s responses:

  1. Hoff: The press release speaks to HypervisorShield’s ability to protect both the hypervisor and the "hypervisor management network" which I assume is actually referring to the the virtual interface of the management functions like VMware’s service console? Are we talking about protecting the service console or the network functions provided by the vKernel?

    Berman: We’ve built a monitor function that uses VMware APIs to watch for changes to/management of the virtual machines. We also have signature templates and customizable policies for network connections to the service console and the host.
     

  2. Hoff: The press release makes it sound like protecting the hypervisor is accomplished via an IPS function that isolates VM’s from one another like Reflex and Blue Lane?

    Berman: With all due respect to our colleagues in this space, intrusion detection and protection is one element.  Catbird combines several technologies to extend separation of duties, dual control and strict change control to the virtual infrastructure. Deploying a signature for VMSA-2008-0001 is nice, but detection or prevention of a rogue virtual center administrator from pulling off a Societe Generale hack is priceless.
     

  3. Hoff: What exactly does Catbird do (in partnering with IPS companies like SourceFire) that folks like Reflex and BlueLane? don’t already do.

    Berman: Rather than talk about the differences, let’s talk about the most important similarity.  I think I speak for all of us when I say that it’s like we are in a time warp to 1996 and I am explaining why you need a firewall for your DMZ.  Customers have little appreciation for the magnitude of the threats facing their virtual infrastructure.  Once we get past that, then we can talk about why Catbird is the best. (hint: we’re smarter, faster and stronger)
     

  4. Hoff: How do you monitor the Hypervisor?

    Berman: We deploy a virtual machine that hooks into the vSwitch environment and that also monitors the ESX hypervisor via the VI API.
     

  5. Hoff: You say in the press release that "hypervisor exploits have grown 35% in the last several years."  Which hypervisor exploits, exactly? You mean exploits against the big, fat, Linux-based service console from VMware? That’s not the hypervisor!

    Berman: I believe that the real threat to the virtual infrastructure comes from the collapse of separation of duties and the breakdown in implicit and explicit security controls within the virtual data center.  That being said, the hypervisor management application is probably the most significant area of the attack surface. If I can own the management GUI I own the hypervisor. If I can pull a stack smash against the ESX web server I own the hypervisor. If some poor shlemozzle configures Samba and NFS for the storage network then they become part of the attack surface too. You can blame us for some hyperbole, but the stat came from the CVE database. Gartner/451/Edison report that virtual infrastructure (VI) is less secure than physical and we have private data that shows people are deploying VI with no network security at all – this is just wrong.  I also think that writing about, or writing off the only risk as being some sort of red pill/blue pill hack is also wrong.

Thanks again to Michael for responding.  Look for a follow-on Take5 shortly to dig a little deeper.

/Hoff

Categories: Virtualization, VMware Tags:
  1. February 19th, 2008 at 08:35 | #1

    Very nice, and thanks to Berman for the clarifications, but he really should use the proper spelling of schlimazl. Also, he probably means schlemiel rather than schlimazl, as it is the schlemiel whose actions create the bad luck.
    I don't know the Yiddish for hypervisor, though, so I can't comment there.

  2. February 20th, 2008 at 13:13 | #2

    Blue Lane is server/VM focused. Thats a critical difference.
    Blue Lane is a layer 7 app/protocol context aware architecture that does not use signatures, tuning, etc. It sees and understands the traffic flows and therefore produces an extremely low instance of false positives and negatives. Traditional network security appliances either tune back their sig libraries or disarm protection (detection mode only) because of accuracy and latency (tradeoff) issues. Most Blue Lane (if not all) customers deploy in full protect mode. Because Blue Lane operates at layer seven it can detect a variety of attacks that can evade traditional deep packet (layer 4) inspection / pattern matching architectures, including: layer 2-3 evasions like IP fragmentation; SQL injection; mutating bots (zero day exploits) and database exploits.
    Blue Lane has very broad server vulnerability coverage across all leading data center OS/app/database vulnerabilities.
    The Blue Lane architecture was developed between 2003 and 2005, when hackers were moving out from their parents and becoming more difficult to spot with suspicious patterns/anomalies… the team developed a more advanced architecture and has more IP related to software vulnerabilities and more flow intelligence than older layer 4 architectures.
    Greg

  3. February 20th, 2008 at 23:58 | #3

    Greg:
    OSI does not cut it here, security within the virtual data center is mostly a people and politics problem. Privileged insiders have been, and always will be the greatest threat*cost.
    Therefore it is not about false positives, it's about "unobserved emboldening" and honest mistakes — if all you deal with are worms and hackers then you miss 98% of the problem we are trying to solve.
    Shrdlu:
    Thanks for the spelling pointer, I went with the NYT spelling, a mistake. My Nonie told me it was the schlimazl who get's into trouble because they are not using their head and the schlemiel causes trouble because they have bad intent (actually she put it more colorfully).

  4. Walter Williams
    February 22nd, 2008 at 04:00 | #4

    How ironic that just a few days after you ask the question what vmware exploits we get:
    CVE numbers
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    and you just gotta know that somewhere there are exploits which have been taking advantage…….

  5. Walter Williams
    February 22nd, 2008 at 04:01 | #5

    How ironic that just a few days after you ask the question what vmware exploits we get:
    CVE numbers
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    ~ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    and you just gotta know that somewhere there are exploits which have been taking advantage…….

  6. February 22nd, 2008 at 07:00 | #6

    Hoff,
    You mentioned that Reflex and Blue Lane provide VM isolation. I know this is not true with Reflex, and doubt its true with Blue Lane. Could you please confirm this is accurate?
    -John Peterson

  7. February 22nd, 2008 at 09:38 | #7

    Hey John:
    Again, this is an issue of context. You'll notice the sentence that includes the statement I made regarding VM "isolation" of BL/Reflex applies within the construct of an IPS function intercepting network traffic through the vSwitch.
    That was my point — that assuming you can force traffic through a security layer (internal to the host or external) it's still basically an IDP function that isn't much different than anyone else; the notion that there is access to the "hypervisor" is not accurate.
    Sorry if this was confusing; my point was to try to "un-confuse" things not vicey versey.
    /Hoff

  8. March 21st, 2008 at 12:38 | #8

    News coming from Blue Lane on inter-VM policy enforcement. :)
    Greg

  1. No trackbacks yet.