Strongedge.io

Cisco ACI was built from the ground up with security in mind. Whether it is protection of the fabric itself, whitelist policies and segmentation, or chaining of advanced security services, it is the most flexible system at scale to support a consistent security policy for bare metal, virtualized, private, and public clouds. The dynamic nature of the service graph and multiple ways to insert advanced services creates a network which is reflexive to security policy, rather than creating constraints requiring compensating controls. The purpose of this blog will be to discuss the various ways security services can be stitched into an applications communication path, and the values each can bring to the table.

There are three primary methods to insert security services that we’ll be evaluating in this blog. The first is native insertion of a security device into an endpoint group. This is how networking has traditionally been done. If you want a security device between a bridged or routed domain, you put one interface from that device into each respective domain. The second option is to leverage the service graph to redirect traffic to the security devices while retaining existing security provisioning tools. This uses advanced service chaining techniques while retaining existing process around security policy provisioning. The third option is to leverage the fabric to do both the provisioning of an applications service chaining as well as the corresponding security policy. Regardless of the approach taken, an important consideration is that the network no longer has a strong preference for physical location of the security devices within the fabric. Whereas historically physical co residency and topological dependence mandated security services to be inserted at specific points in the topology, the fabric’s decoupling of location from identity and advanced policy allows security services to be placed in the fabric where it makes sense for the business.

The stateless filtering capabilities of the ACI fabric are even more valuable when considering coupling with a stateful device. Ethernet economics has driven the cost of a 100g link to the price point of where a 10g link was 5 years ago. The costs per bit have come down exponentially. When you couple this with a stateful device where a cost premium is paid for advanced L4-7 services, it makes financial sense to leverage the fabric to keep “noise” off you stateful devices. For example, if your firewall only allows 10 applications between 50 endpoints, why send traffic to the firewall that is only going to be dropped, when the fabric is possible of doing this all state fully and with a level of visibility commensurate with advanced security devices? The amount of money that can be saved in stateful devices through leveraging the fabric native capabilities to block and log on “noise”, and focusing your stateful resources on traffic that it was purchased to protect.

Option 1 : Native L2 Stitching.

The first option is the most similar to traditional modes for inserting security services. Whether via Layer vlan or physical port, we leverage the mechanics of layer 2 networking to control the flow of the data through the security apparatus. The security device, quite simply, just has an interface (physical/virtual), inside the endpoint groups it is controlling policy for. And the traffic between these segments, only occurs via the security device. The provisioning of security policy and operational monitoring is all done using traditional tools.

While this is “how its always been done”, and does not account for some unique capabilities we can achieve via service graph and dynamic policy creation/deletion, there are use cases where it just makes sense in the context of reducing complexity. The first is if your particular firewall has traffic flowing in a many to many pattern between multiple (> 3) zones. In this use case, you have Security zone A, which talks directly to B, and C, and D. This “meshiness” of security policy is already a level of complexity being managed on the firewall. To create corresponding contracts in the service graph would add dilutive return on value as the amount interfaces increase. In some cases, the “multiple zones” may have existed due to physical appliance location requirements, but if you cannot reduce the amount of security zones per firewall instance down to possibly 3 (Trust1, Trust2, and vzAny (everything else)), it may make sense to use native L2 stitching.

Option 2 : Dynamically Provisioned Fabric with Existing Security Tools

The second option is to leverage the fabric to dynamically provision connectivity for the security devices. At the same time, existing OAM and provisioning tools used by the security operations group remain unchanged. This is a sweet spot where you can get the full features of all your security tools, using existing process and procedures, while getting the full benefit of the fabric from a connectivity perspective. There are multiple benefits to the dynamic creation of the service graph

1. Security is fully inserted to the Application, as the service graph is an extension of the contract in the Application Profile. This provides for defense in depth.
2. Granular way to send traffic to the Security Service using the contract. This enables you to send only interesting traffic to the Firewall enabling trusted flow bypass (high speed backups, or replication, for example). This scales expensive inspection resources for non critical traffic.
3. Configuration Templates enable application templates to be used to dynamically create the service graph as an application is deployed.
4. Statistics and health score automatically collected for the services. When a leaf switch or transient condition occurs, you can show back impact to the applications in question.
5. Dynamic update of the ACLs based on End point discovery in the EPG. This provisioning of stateless services enables automated creation for defense in depth.
6. Insert several services seamlessly with Service Chaining. In addition to security services, application profiles that stitch in load balancing can be created such that the entire stack is provisioned at application instantiation.

Option 3 : Full integration with Device Package

The third option creates the greatest amount of automation in enabling the provisioning of not only the connectivity and stateless services required for defense in depth security. This leverages the open capabilities of the APIC controller to import a device package which enables ACI to speak to the security devices in the language they understand.

Some key benefits of this is the ability not only to instantiate, but to destroy legacy security policy (or de-provision it, more specifically). This association of security configuration with application lifecycle reduces configuration drift and creep in the network, improving the ability to audit and maintain, and solving a key operational challenge facing organizations in maintaining legacy configurations.

This summary of the different options for inserting Security services into Cisco ACI will be expanded upon in a future blog about segmentation as well as analytical capabilities of the ACI fabric.