Another Virtualized Solution for VM Security…

I got an email reminder from my buddy Grant Bourzikas today pointing me to another virtualized security solution for servers from Reflex Security called Reflex VSA.  VSA stands for Virtual Security Appliance and the premise appears to be that you deploy this software within each guest VM and it provides what looks a lot like host-based intrusion prevention functionality per VM.

The functionality is defined thusly:

Reflex VSA solves the problem that traditional network security such as
IPS and firewall appliances currently can not solve: detecting and preventing attacks within a virtual server. Because Reflex VSA runs as virtualized
application inside the virtualized environment, it can detect and mitigate
        threats between virtual hosts and networks.

Reflex VSA Features:
        • Access firewall for permission enforcement for intra-host and external network
        • Intrusion Prevention with inline blocking and filtering for virtualized networks
        • Anomaly, signature, and rate-based threat detection capability
        • Network Discovery to discover and map all virtual machines and applications
        • Reflex Command Center, providing a centralized configuration and management
           console, comprehensive reporting tools, and real-time event aggregation and

It does not appear to wrap around or plug-in to the HyperVisor natively, so I’m a little confused as to the difference between deploying VSA and whatever HIPS/NIPS agent a customer might already have deployed on "physical" server instantiations.

Blue Lane’s product addresses this at the HyperVisor layer and it would be interesting to me to have the pundits/experts argue the pros/cons of each approach. {Ed. This is incorrect.  Blue Lane’s product runs as a VM/virtual appliance also.  With the exposure via API of the hypervisor/virtual switches, products like Blue Lane and Reflex would take advantage to be more flexible, effective and higher performing.}

I’m surprised most of the other "security configuration management" folks haven’t already re-branded their agents as being "Virtualization Compliant" to attack this nascent marketspace. < :rolleyes here: >

It’s good to see that folks are at least owning up to the fact that intra-VM communications via virtual switches are going to drive a spin on risk models, detection and mitigation tools and techniques.  This is what I was getting at in this blog entry here.

I would enjoy speaking to someone from Reflex to understand their positioning and differentiation better, but isn’t this just HIPS per VM?  How’s that different than firewall, AV, etc. per VM?


  1. March 19th, 2007 at 14:22 | #1

    I think the key challenge for static signature solutions is the rise of the polymorphic attack:

  2. March 19th, 2007 at 15:39 | #2

    I don't have a clue how it is different, but I do like the picture of the lady with the sign. Is she a friend or relative of yours?

  3. March 19th, 2007 at 15:57 | #3

    While I am on here. Now that I placed second in the prestigious or infamous fighting 59, I assume the market value of my blog far exceeds the couple of thousand dollars you have raised for your little acquisition spree. As such an official letter withdrawing your offer is I think in order.

  4. March 20th, 2007 at 09:09 | #4

    Hello all,
    I can speak to your questions regarding Reflex's VSA, I'm in charge of the Product line at Reflex.
    Our virtual IPS platform functions as a network based Intrusion Prevention System and not as a Host Based Intrusion Prevention System. We do not run "INSIDE" the "Virtual Machine" and admitedly our marketing literature may have been a bit confusing. We run "BETWEEN" "Virtual Switches" to prevent infected Virtual Machines from spreading to other Virtual Machines.
    This is no different than on a physical LAN segment. You may want to place an IPS sensor between the Sales/Marketing and Research & Development segment of an enterprise. This helps contain attacks. Another idea is to deploy the Virtual IPS at the "Perimeter" of the Virtual Machine, right before the phsyical NIC card.
    The purpose of doing all of this "inside, virtually" is to add another layer of defense in a "defense in depth" deployment strategy. An attack could get past your physical IPS's if it came in over an encrypted channel, or via sneakernet, etc. etc.
    John Peterson
    Vice President of Product Mgt
    Reflex Security

  5. March 20th, 2007 at 09:50 | #5

    Looks more like a NIPS implementation than HIPS to me. The only benefit of their solution over tradition NIPS would be the isolation between virtual switches.

  6. March 20th, 2007 at 10:40 | #6

    Hi John.
    Thanks for the update. It better articulates the positioning; it was a little unclear from the website.
    I'd also like to understand how VSA integrates with the blades on the MG5/MG10.

  7. August 26th, 2007 at 12:50 | #7

    Sorry its been a while since I visited you're site. To answer you're last question Christofer, the MG5/MG10 integrates with VSA in a number of different ways.
    We believe that in order to provide the best method of security a defense in depth approach needs to be taken which calls for physical security devices as well as virtual security devices. We also believe that in order to solve the security performance problems within the virtual environment certain inspection tasks can be offloaded onto dedicated hardware platforms. This is where the MG5 and MG10 come in.
    The way the MG5/MG10 product can integraet with VSA is by securely tagging packets that have already been inspected by the MG5/MG10's that may already exist in the physical environment. Once packets then make their way into the virtual environment it doesnt make sense wasting compute cycles by inspecting that traffic yet another time. So, VSA can detect these securely tagged packets and bypass inspection only for traffic previously inspected by MG's. This ultimately saves CPU cycles for intra VM communication.
    Lastly because the MG10 has a port density of 92 ports it is possible to plug ESX servers directly into the MG system which allows for physical security between ESX servers. Sort of like you're "Top of Rack Switch" but now one with secure ports.
    This whole strategy delivers something I call "Inside – Out Security".
    John Peterson
    Chief Product Officer
    Reflex Security

  8. August 26th, 2007 at 13:42 | #8

    Interesting. There are a couple of companies that you'd be familiar with that take the notion of "switch(ed) IPS" with
    switch IPS communication protocols to enforce policy. This is
    another good example, with a very cool virtualization twist.
    Now that I'm no longer at Crossbeam (not technically a competitor
    but the boxes look alike 😉 would you be interested in letting me
    profile the solution for the blog? I've highlighted the VSA
    solution previously here and in some presentations, but would like to give it a more informed shake.

  9. Mike Wronski
    November 21st, 2007 at 08:19 | #9

    You may want to look a little deeper into Blue Lane's website. They are not hooked into the VMware hypervisor in anyway. Their site is slightly misleading in that area. The bluelane deployment model is identical to the Reflex one from the virtual appliance perspective.

  10. November 22nd, 2007 at 07:30 | #10

    You're right, Mike. The models ARE the same from the virtual appliance model.
    I corrected this in a later post on the topic where I made the same mistake (and Blue Lane actually contacted me to correct it,) but didn't come back and strike it out here…I'll do that.

  1. No trackbacks yet.