ACI Security: Part 1

Now more than ever it is critical to choose the right security architecture to address your organizations requirements.   There is a lot of noise about micro segmentation lately.  Instead of focusing on a sub set of a security architecture wouldn’t it be great to implement a fabric-wide segmentation solution that addresses multi-hypervisor and bare-metal workloads?   Wouldn’t it be valuable to firewall above and beyond L4 and inject not only a virtual security appliance but also the option to use a physical NGFW with deep packet inspection for 10G and 40G performance?  Wouldn’t it be valuable to automate the enforcement of security policies anywhere in the datacenter across the entire application lifecycle and removing security policies when applications components are removed?  Wouldn’t it be valuable to obtain PCI and HIPAA compliance with full auditing capabilities and health scores for how the fabric is handling your application including a health score from the security appliances?

Here are a few ideas to explore when researching a data center security architecture:

1. Focus on use-case: is this about policy automation, service insertion, per application security requirements or compliance
2. Address what is enough from a firewall perspective: port filtering vs. application-level security.
3. Is a NGFW required coupled with service chaining capabilities to an IPS or Web Application FW. 
4. Securing a Netapp NAS or baremetal database?   
5. Is it a broader security architecture (TrustSec/Security Tagging/Policy integration for Campus+Branch+DC, or auditing). 

If you were nodding yes to any of the questions above than ACI is an option for your organization.  ACI provides you an option of deploying a zero trust data center security model by assuming a no default trust between application components regardless of the location of the entity unless there is a whitelist policy explicitly defined to allow connectivity.   Of course, you don’t have to deploy a zero trust model; in fact, you can mix and match based on your security needs.

ACI policies are expressed as contracts that permit, deny, log, or redirect traffic between two end point groups.  Keep in mind no IP addresses are required to implement the security policies.  Imagine two end points belonging to distinct endpoint groups (EPGs) connected to interfaces on the same physical or virtual switch, there is no connectivity between these end points unless there is an explicit whitelist policy tied to a contract to allow communication between these end point groups. This is in comparison to the blacklist model for existing network switches, which allow all traffic unless otherwise specified.

Lets take a look at 2 options available today with ACI for securing between two end point groups.   Keep in mind that your security model with ACI can be a combination of Option 1 and Option 2 depending on what your application security requirements dictate.  

Option 1:  ACI Fabric can direct traffic to centralized or distributed pool of virtual and/or physical Next Generation Firewalls but eliminate the challenges with ACL cleanup on Firewalls by automating the removal of policies, as applications are de-commissioned.

Option 2: As an alternative, an ACI fabric can enforce a semi-stateful firewall at line rate.  ACI checks initial flag for directionality.   In addition, with ACI a distributed firewall security policy no longer needs to be based on IP addresses and layer 4 ports but can be rules based on endpoint group membership and layer 4 ports.  Consider for a moment giving out a single IP Subnet for new three-tier application and being able to secure between tiers not based on the 5 tuples but on EPG membership.  Security becomes part of the fabric and enforced at all leaf nodes in the fabric even as workloads move across the datacenter.  

If it isn’t obvious, ACI integrates with broad set of security eco-system and partner technologies such as Next-Generation Firewalls (Cisco, Checkpoint, Palo-Alto), IDS/IPS (Cisco), DDoS (Radware) and DNS Security (Infoblox) to secure north/south and east/west application traffic. Together with ACI these security integrations guarantee management plane, control plane and data path isolation for any workload across the data center including micro-segmentation use cases and the broader use case of fabric-wide segmentation. 

ACI also supports a L4 Stateful Firewall with AVS as well as endpoint group membership based on VM Attributes.  Remember you have the option to go above and beyond L4 firewalling by redirecting to Next-Generation Firewall for any workload.   Its important to remember that a L4 firewall has its limitations but does help reduce the scope of what is unprotected.    If you need deep application inspection the ideal method is having ACI leverage a service-graph to redirect to a Next-Generation Firewall coupled with a Next-Generation IPS.  In order to protect your assets in the datacenter you need to consider all phases of a security architecture and not just a L4 Firewall on a virtual NIC or IP tables.

 

Over the next few weeks I will provide follow on demonstrations highlighting ACI’s security architecture.  Starting with this blog, I will highlight ACI with AVS.  In the diagram below is a lab setup with an ACI fabric integrated with UCS and a traditional Nexus 5k/2k environment connected.  In the video below I demonstrate the fabric providing EPG (endpoint group) semi-stateful contract enforcement as well as AVS providing L4 stateful FW for traffic that has bypassed the distributed semi-stateful FW.  The demo includes an Avalanche test tool sending 1000s of port 80 flows at test hosts.   The Avalanche traffic will be permitted by the contract allowing port 80 between the two EPGs and in addition you will see state being tracked by AVS.  Lastly, I have an additional test host with nmap installed.  I launched syn and fin floods and port scans at a virtual host within a different EPG.  You will see the fabric deny and log all non port 80 traffic and the syn and fin floods being delivered to AVS where the traffic is dropped by AVS for not being stateful.  Hope you enjoy Part 1 on this topic and look forward to your feedback.  Lastly, I would also like to give credit to Brett Huffman for assistance with the demonstration.

Video is clearer on Youtube:  https://www.youtube.com/watch?v=y-as3bp2mnU&feature=youtu.be