Software Defined Security (SDSec) with vArmour

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.

• 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