Currently in Migration - Jason Edelman's Old Blog
  • Home
  • About
  • Contact

Software Defined Security (SDSec) with vArmour

11/5/2013

0 Comments

 
SDSec – have you heard that one before?  This is actually what startup vArmour is preaching – Software Defined Security.  I had the opportunity to talk with one of their guys at ONUG to learn a little bit more about them.  Here is what I found out.
Picture
  • vArmour is developing an end to end Data Center Security Fabric 
  • Solution includes Security (FW) Application, OpenFlow controller, and security appliances (enforcement points)
  • Policy is enforced on inline devices, i.e. primarily virtual appliances (although they do have some physical appliances as well)
  • Standard OpenFlow architecture being used – first packet goes to controller, policy is checked, and flow rules are sent down to the network enforcement point.  Actually, they are sending the first few packets.
  • vArmour is a stateful solution as they are leveraging appliances as their enforcement devices that have stateful inspection engines compared to stateless ACLs that can be deployed proactively in a traditional OpenFlow architecture that use switches as their enforcement points
  • If a packet is traversing multiple vArmour appliances, the policy (packet to controller) look up only happens once --- on the ingress appliance (each way)
  • They did talk about having a physical appliance, but didn’t get details on this.  
  • I talked with vArmour at the second ONS in April 2012 and their story has change a little bit if you’ve been following them.   At that point, they were a security application riding on top of various OpenFlow controllers.  Now they are a full blown security solution that just happens to be leveraging an OpenFlow controller architecture.
  • A single FW policy is created and managed across the enforcement points (fabric). Pretty cool to keep that OpEx down.
  • If I heard correctly, you can deploy multiple FWs per segment and the controller will handle which flows get directed to which FW appliance.  If this is the case, this is slick, and can provide a nice scale out architecture.
  • It’s kind of similar to Cisco’s Virtual Security Gateway (VSG) in that the initial packets are sent to a look up engine to verify the policy that should be dynamically pushed down and enforced.  Note: only first packet is sent for VSG.  
  • But, it’s different than the VSG in that the VSG redirects and intercepts packets using vPath since it is not inline and enforces on the 1000V VEM.  vArmour fabric doesn’t have to intercept since it is inline (controller should be managing ARP for the FW appliances) and enforces on the vArmour appliances.
  • No integration with off the shelf OpenFlow fabric controllers (Big Switch, NEC, etc.) that could be used for traffic interception and not require vArmour to be inline.  This would mean 3rd party controller to vArmour controller integration.  They did not say this was or was not roadmap.

I really like the single FW policy for the data center with the distributed policy enforcement.  Since it is a “fabric,” appliances should be able to be added on demand.  When asked about how this may compare with distributed policy enforcement in the kernel by the likes of NSX, it seems the counter may be about having the same vendor for L2/L3 vs. L4-L7 Security and that vArmour can be overlaid on top of any network --- not requiring network virtualization or any particular hypervisor.  That is also pretty cool.  So, yes, there is another FW vendor out there.  Like Embrane, you have to wonder, what is more valuable --- a completely new “good enough” feature set or the underlying architecture they are developing, and if the architecture could be leveraged by existing FW vendors at some point.  BTW, I am only saying “good enough” because that is becoming common with companies like VMware, PLUMgrid, Embrane, etc. developing their own load balancers and FWs.  We’ll have to wait and see what features vArmour support before we start comparing them to a Palo Alto, Cisco, Checkpoint, and Juniper.

I only spent a few minutes with vArmour, so I may have this completely wrong.  If that happens to be the case, please comment below or write in privately to correct me and I’ll get the updates out ASAP!

Thanks,

Jason

Twitter: @jedelman8

0 Comments



Leave a Reply.

    Author

    Jason Edelman, Founder of Network to Code, focused on training and services for emerging network technologies. CCIE 15394.  VCDX-NV 167.


    Enter your email address:

    Delivered by FeedBurner


    Top Posts

    The Future of Networking and the Network Engineer

    OpenFlow, vPath, and SDN

    Network Virtualization vs. SDN

    Nexus 7000 FAQ

    Possibilities of OpenFlow/SDN Applications 

    Loved, Hated, but Never Ignored #OpenFlow #SDN

    Software Defined Networking: Cisco Domination to Market Education

    OpenFlow, SDN, and Meraki

    CAPWAP and OpenFlow - thinking outside the box

    Introduction to OpenFlow...for Network Engineers


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    RSS Feed


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video