(This blog has been developed in association with Praveen Jain, VP, Engineering of Cisco’s Application Policy Infrastructure Controller, Juan Lage, Principal Engineer and others)
Security is top of mind in today’s data center and cloud deployments and security architectures have continued to evolve even as new threats manifest themselves in the digital world. Today’s security administrator requires a variety of “tools” to deal with the sophisticated attacks. One such tool is the ability to segment the network.
Traditionally network administrators have allocated subnets for different applications and mapped them to VLANs as a means of providing network segmentation, partitioning and isolating domains. This classic approach was relatively easy to implement and facilitated policy definition using Access Control Lists (ACLs) between subnets at the L3 boundary, usually the first hop router or perhaps a physical firewall.
However, this approach led to the undesired mapping of IP subnets to applications. Over time, it also led to an explosion of ACLs when subnet based policies were not sufficient (for instance, by requiring ACLs that match on specific IP Addresses). This in turn made it difficult to perform garbage collection of ACL entries when applications were decommissioned, complicating the ACL management problem.
So, while the broad constructs of segmentation are still relevant, today’s application and security requirements mandate increasingly granular methods that are more secure and operationally simpler.
This has led to the evolution of what we call as “micro-segmentation”. Broadly, the goals of micro-segmentation are as follows
- Programmatically define segments on an increasingly granular basis allowing greater flexibility (e.g. to limit lateral movement of a threat or to quarantine a compromised endpoint in a broader system)
- Leverage programmability to automate segment and policy managent across the entire application lifecycle (instantiation through de-commissioning)
- Enhance security and scale by enabling a Zero-Trust approach for heterogeneous workloads
Micro-segmentation with Cisco’s Application Centric Infrastructure
Cisco’s Application Centric Infrastructure (ACI) takes a very elegant approach to micro-segmentation with policy definition separating segments from the broadcast domain. It uses a new application-aware construct called End-Point Group (or EPG) that allows application designers to define the group of endpoints that belong to the EPG regardless of their IP address or the subnet they belong to. Further, the endpoint can be a physical server, a virtual machine, a Linux container or even legacy mainframes – i.e. the type of endpoint is normalized and therefore irrelevant, thereby offering great simplicity and flexibility in their treatment.
ACI still preserves the traditional segment, now called a Bridge Domain (or BD). IP subnets can still be assigned to Bridge Domains. This approach helps preserve any existing operational models, if required, allowing for creation of Bridge Domains with a single EPG that maps to the concept of a traditional VLAN.
The ACI architecture takes these even further. Multiple EPGs can belong to the same Bridge Domain, and EPGs can be provisioned programmatically (in fact, just like everything else within ACI) via an open API made available through Cisco’s Application Policy Infrastructure Controller (APIC). Simply put, the EPGs in the ACI architecture are “micro-segments” of a Bridge Domain.
The figure below illustrates this approach:
End-point Groups as Micro-segments
Connectivity between EPGs is only allowed as per the policy defined using a model of contracts that work with both white list and black list models. Related EPGs and contracts are all part of an Application Network Profile (ANP), a programmatic construct to define the requirements of an application.
The EPGs defined within the Application Network Profile are hypervisor agnostic and work across physical and virtual deployments. For instance, they are matched by corresponding PortGroups in vCenter, VMnetworks in Hyper-V, etc. For bare metal servers, EPG are mapped to the physical ports connecting them to the fabric.
There are other use cases of micro-segmentation not directly covered by the EPG description above. For instance, storage devices from companies like NetApp and others that may be connected to the fabric as a bare metal box implement virtual servers within the filer. These special bare metal devices require IP/DNS micro-segments as well as policies among these micro-segments, which can be implemented with the ACI architecture.
Attribute-based Micro-segmentation:
The ACI architecture further allows the concept of micro-segmentation to extend to intelligent classification based on “attributes”. For example, we could imagine assigning endpoints to micro-segments based on administrative “tags” or “attributes” that identify an endpoint regardless of its IP address. The attributes can be a VM-name, OS-name, host-name or a fully qualified domain name (FQDN). For instance, this would let an administrator state that all Linux hosts whose hostname contains “prod-web-app1-“should belong to a specific micro-segment. The model above also lends itself well to dynamically assigning endpoints into EPGs. Apart from micro-segmenting the workload while designing the application network profile, a very interesting and practical use case would be to quarantine a compromised or rogue endpoint.
As an example of this idea, imagine that as part of an Application Network Profile, you configure redirecting a copy of the traffic to an IDS system. The moment the IDS detects a host has been compromised, you can select the IP or use a VM attribute to place the endpoint into a separate micro-segment that allows only access to remediation systems.
Managing micro-segments in heterogeneous deployments
Customers who only run vSphere and have no bare metal applications and don’t wish to consider a multi-hypervisor scenario in the future could very well be content with VMware’s NSX-based micro-segmentation.
For customers that are looking towards a comprehensive multi-hypervisor approach and with consistent policy application in a heterogeneous environment, Cisco’s Application Centric Infrastructure would be a more suitable approach. Cisco’s ACI architecture is shines where micro-segments exist across bare metal, VMs running on different hypervisors as well as Linux containers and radically simplifies management.
ACI provides a comprehensive hypervisor agnostic approach for consistent application policy across micro segments, whereby these micro-segments can be created based on IP, FQDN or VM Attributes and apply them consistently across the entire fabric.
In a nutshell,
- Cisco ACI achieves a hypervisor agnostic micro-segmentation by allowing various hypervisors to map their micro-segmentation constructs to EPGs. The same principle applies to containers and bare metal.
- Once the classification is done, policy is applied consistently among micro-segment EPGs irrespective of source VM, VM Type, Bare metal, etc. Policy can be invaluable as a tool for defining and scaling security constructs
- For virtual endpoints within a single host, this policy may be enforced directly at the hypervisor layer. This is accomplished through the use of the open OpFlex protocol to directly push policy into Microsoft Hyper-V, KVM with Open vSwitch and vSphere with the Application Virtual Switch (AVS).
Micro-segmentation with Cisco ACI – What’s available and when?
- Shipping Today
- Micro-Segmentation for VMware using Cisco AVS
- Coming Soon (end of 2015)
- Bare Metal Micro-Segmentation
- Micro-Segmentation for Hyper-V using native Microsoft vSwitch plus ACI extensions via open protocols like OpFlex
- Target 2016
- KVM/Xen Micro-Segmentation
- Micro-Segmentation for Linux Containers
Summary
Cisco ACI is architected to provide a comprehensive and superior approach to micro-segmentation that is hypervisor agnostic and works as well for bare metal and emerging Linux containers. Even for customers that are not running multiple hypervisors, the combination of integrating policies for bare metal servers, legacy mainframes and physical storage devices makes it worth exploring and evaluating the adoption of ACI as it vastly simplifies operations and makes it easier to deliver security consistently for data center and cloud deployments.
While this blog has focused on micro-segmentation, it is but one “tool” in the arsenal of a security or network administrator. Cisco ACI provides several sophisticated security capabilities including a robust service insertion technology to stitch advanced security and threat management systems. A security strategy must consider the attack continuum protection, by covering protection before, during and after an attack allowing for rapid detection, mitigation and analysis.
Clear explanation…true
critically important capabilities
Sounds similar to Trustsec using Secure Group Tagging. Would ACI replace Trustsec or compliment it?
Hi Rich – Trustsec support is down the line. It will be complementary.