Cisco Rapid Threat Containment quickly detects, removes infected end points

Many of the readers of this blog are aware that ever since Cisco acquired SourceFire, and cybersecurity industry legends such as Marty Roesch took leadership roles within the company, Cisco’s initiative is for all security products to be open and to interoperate with other products.

Another very large acquisition was OpenDNS, and the CEO from OpenDNS now leads all of the security business at Cisco. The culture is all about Cisco products, as well as non-Cisco products, working better together. 

+ Also on Network World: Cisco ONE simplifies security purchasing +

For many, it’s shocking to think about Cisco as a vendor pushing for openness and standards. I’m not sure why because Cisco has spent its life creating networking protocols and then helping them to become standards available to all. But I digress.

Examples of this open behavior can be found all over the APIs that exist and are being added to many of the security products, but it can also be seen in the developing standards of things such as pxGrid for secure data (context) sharing, open sourcing the TrustSec Secure group eXchange Protocol (SXP) and the adoption of existing standards, including Structured Threat Information Expression (STIX), Common Vulnerability Scoring System (CVSS), and Trusted Automator eXchange of Indicator Information (TAXII). 

A great example of an open system for integration can be the Rapid Threat Containment solution set. There are many Rapid Threat Containment integrations, such as Rapid Threat Containment with Cisco Firepower Management Center and Identity Services Engine. Here is a great system with a very long-winded name. I’m sorry, but I have to shorten it to RTC w/ FMC & ISE otherwise it’s just too darn long to fit in a slide and takes too long to read on a page. 🙂  

RTC w/ FMC & ISE is the ability for the FMC to quarantine end points through ISE. So, when the FMC sees some indicators of compromise, certain Snort IPS signatures are fired, or malware is discovered through AMP, the FMC can trigger actions to occur through ISE. ISE, in turn, can determine what to do when that trigger occurs. ISE could kick the user off the network or change the context of the user and endpoint so that different actions are taken within the network infrastructure. Very cool, right?

Figure 1 illustrates this process.

While RTC is mainly marketed between Cisco devices, it is not limited to Cisco products only. The Adaptive Network Control (ANC) function in ISE is open to anyone who wishes to integrate to ISE via pxGrid or even via the RESTful API. When integrating with pxGrid, the subscribing application is able to receive contextual information from ISE to make their product more useful and trigger actions through ANC. 

Yet when integrating with the API, any custom application can trigger those ANC assignments—even if they are not part of Cisco’s DevNet partner community. We’ll come back to that.

Within ISE, the ANC policies are created under Operations > Adaptive Network Control > Policy List. ANC policies are not what you think they are. They can simply be thought of as name-spaces or classifications. An end point can be classified (assigned) to an ANC name-space (policy), and when that classification occurs, a Change of Authorization (CoA) will be sent to the network. But no change of authorization will occur unless you specify in the authorization policy what result should be assigned, such as limiting access, denying access or applying specific TrustSec tags.

Figure 2 shows an example set of ANC Policies, while Figure 3 shows the use of those ANC assignments in the authorization policy.

You can see that by leveraging the ANC classification in an authorization rule at the top of your authorization policy or in the exception area, you will assign a specific authorization result for that classification. You can theoretically assign a different authorization rule per ANC classification type.

That authorization result can affect network policy throughout your environment. By assigning a simple TrustSec TAG, you can change the behavior of the end point traffic as it passes through an ASA, a Firepower appliance, Cisco network infrastructure, perhaps decrypt the SSL traffic as it goes through a web security appliance, or even influence the firewall policy within a Checkpoint firewall. Yes, you read that correctly.

To illustrate the assignment of an end point to an ANC classification, we will leverage the RESTful API and use the a simple REST tool to do the work for us. This will simulate what a client application should do or what you can do with your own custom integration.

Figure 4 shows the use of the PostMan tool to query the REST API to get the list of ANC policies, while Figure 5 shows the assignment of an endpoint into one of those ANC policies (aka, classifications).

Your choices are practically limitless.