An Overview of Network Security Considerations for Cisco ACI Deployments

Security continues to be top of mind with our customers and frequently comes up with customers who are evaluating new architectures. I have been in the networking industry for over two decades involved in multi-billion dollar product lines like Catalyst 5K/6K, MDS-9000, Nexus-7K, UCS, and now with Application Centric Infrastructure (ACI). I don’t claim to be a security expert by any means, but have gained good insight into what’s important based on numerous conversations with customers over the years thereby allowing me to write about it with some degree of authority.

That said, security is a very broad topic and there are myriad products in the industry to deal with the various types of attacks that infrastructure and applications are exposed to today. For purposes of this blog, I will focus on the network security aspects and how they intersect with Cisco ACI.

Accordingly, I will touch upon the four pillars as shown in the image below.

1. Isolation-based Security

Isolation is one of the most fundamental building blocks of security. Virtual Routing and Forwarding (VRF) a.k.a tenants allow private address space and the ACI fabric guarantees separation of traffic among these VRFs. Similarly Bridge Domains (BDs) allow separation of broadcast traffic. The ACI fabric places emphasis on optimization and efficiency. It does not flood unknown packets and instead forwards it based on its station table. However the “flood mode” is still preserved as an option for legacy needs.

The concept of tenants also allows for shared services in a very elegant manner. Let’s assume a hosting provider wants to provide DNS, Active Directory services for it’s tenants.  The ACI architecture allows these infrastructure services to be hosted in a separate tenant – say “service hoster” and these can be made available to selected tenants by use of  explicit ‘contracts’.  This is achieved by stitching routes across VRFs along with contracts/filters. The ACI architecture is designed to maintain strict isolation in all these scenarios.

2. Stateless Contracts

The concept of stateless contracts is made possible by the ACI architecture that allows for the abstraction of policy definition from the state of the underlying infrastructure. This helps in scaling the system considerably, but also reducing operational complexity and manual errors that have manifested themselves during the definition and enforcement of traditional Access Control Lists (ACLs)

For anyone who’s been involved in networks and security over the last decade or so, Access Control Lists (ACLs) with the standard <5 tuple, flag> match in packet header must sound familiar.  Based on the subnetting design, we either use /32 causing an explosion of ACLs or use prefixes. With the concept of workload mobility the traditional subnet boundaries are rapidly dissolving.

The concept of ACI ‘contracts’ addresses both of these issues by defining application tiers a.k.a End-point Groups (EPGs) and filters among them. In other words a TCAM entry like <src epg, dst epg, proto, src port, dst port, flags> allows full portability and mobility of the IP address anywhere while substantially reducing TCAM space and management complexities. Further, EPG filters prevent an explosion of Access Control Lists (ACL) entries drastically simplifying the operational aspects of security definition and governance.

EPG/Micro-segments as well as attribute-based security are covered in the blog posted by Shashi Kiran and myself here.

3. Stateful Firewalls

Stateful firewalls are a very well known concept. Cisco ASA and many of the L4-7 partners in the ACI eocosytem have exceptional products in this space.

4. Deep Packet Inspection and Analysis

I will not dwell on this. Deep Packet Inspection and Analysis is again a very mature subject. Cisco’s ASA and firePOWER product lines as well as those of other L4-7 partners are very well suited to this space.

 

Considerations for Deploying ACI Security Pillars

Another consideration in the network security with ACI is layering of these pillars such that the unintended and malicious traffic is filtered out at every level; providing a  scalable security implementation. For example, a L4 port scan, which is a constant problem in networks today, can be blocked by stateless contracts or by stateful firewall. But by ACI blocking it at line rate in hardware, the firewall receive lesser malicious traffic and further prevents stateful nature of attacks. Similarly, on detecting say a malware attack by our eco-system partner products, and through API integration, ACI blocks it at hardware speed by placing the rogue hosts in quarantine EPG; preventing further propagation through the network.

It is important to note that each of the above pillars are important to ensure that the overall security posture is maintained and continually strengthened. Your security team is in best position to evaluate combinations of these ACI network capabilities along with application level security products and further determine what to apply for north-south vs east-west traffic.

The role of the Application Policy Infrastructure Controller (APIC)

The APIC automates the process across all the four pillars that I described above. As the application life-cycle changes, APIC automatically adjusts steering of traffic through these pillars and modifies security policies on the ACI fabric and L4-L7 devices. Our customers have a choice of customizing and leveraging all or some of these pillars for the most optimal security deployment.

Finally, I believe that breaking security is harder at the infrastructure layer than closer to the application where vulnerabilities can quickly amplify.  I would therefore recommend not to just rely on network security implemented inside a guest VM/compute by using linux IPTables/Conntracker/Windows firewall or other means. Any intruder getting unauthorized access to guest VM/compute could compromise that. However these methods can be supplemented with infrastructure network security as described in this blog.