Rapid Threat Containment Using Cisco ISE and Cisco Firepower

This article will be a brief overview of Rapid Threat Containment using Cisco ISE and Cisco Firepower. Cisco ISE is used to authenticate and authorize users at the network level. It works great and is becoming pretty much mandatory in any corporate network. Cisco Firepower is a next-generation firewall which means that in addition to legacy firewall stuff, it is also much smarter than it used to be. Firepower can detect and block threats such as malicious websites, known malicious traffic patterns (IPS), Malware, and more!


The Problem We Are Fixing

The use of Rapid Threat Containment solves many problems. In this section, we will just go through a few. For now, let us assume ISE is up and running, and Firepower is protecting the network edge.


Problem #1

Bob likes to go home in the evenings with his work laptop and see how many links he can click in a single night. Bob’s nuts, but we still have to protect our network. The next day, Bob comes into the office and plugs his laptop in.


Firepower will pick up many different threats, of course, but that does not do us any good for our internal traffic. This is really the case even if you have Firepower in-between segments as Bob can still wreak havoc on the segment, he is in.


ISE does not block threats by default and if Bob has valid credentials, he gets network access.

Problem #2

Bob likes to switch to your unprotected guest network or his mobile hotspot at lunch. From there he likes to test his laptop security by downloading as much malware as possible.

When Bob comes back on the corporate network and tries to send the malware, Firepower will detect it and block it. That’s great, but you are really only protecting every Internet user on the planet from Bob, but you are not protecting your users at all.

Problem #3

Bob innocently downloads a file from the Internet and Firepower does not have enough information to determine if it is Malware or not. Thus, it lets it through. A few days later Firepower gained enough information to determine the file was in fact Malware. This is a great feature that is built into Firepower, but the only thing it can do is log it and block all subsequent attempts to transfer the file. There are many more use cases, but these three are enough to help you understand why Rapid Threat Containment fills the gaps.

Rapid Threat Containment High-Level

At a basic level, Rapid Threat Containment allows security tools, in this case Firepower, to talk to ISE. The conversation goes like this:

Firepower: "Say ISE, I’m getting critical security alerts from Bob."

ISE: "No worries, I’m going to bounce him off the network."


Done!


ISE can drop Bob from the network at the switchport level. Thus, there is no lateral movement, no infecting other segments, and the entire threat that Bob poses goes away within5 seconds. This process is 100% automated.


Quarantine Criteria

The first question that usually comes up is what criteria must be met before we take the automated action. The answer is it can be virtually whatever you want it to be. In addition, it does not necessarily have to be a single condition. There are far too many options to cover in a single article or even a single class, but we’ll go through a few examples.


A security alert is a good place to start. At a basic level, the system can take action based on an IPS or Malware event. However, typically you would want to add additional criteria to make sure the system is only responding to severe threats.


I’m going to write out a few “logical” rules, just to give you a feel for what is possible. The rules are essentially written as “if-then-else” statements.


Example #1

If a new user is detected and there is an IPS Alert for that user and the IPS impact flag is set to vulnerable tell ISE to bounce the user.


In other words, if a brand-new user comes on the network for the first time and begins sending/receiving traffic that matches an IPS signature, it is probably a good idea to block the user at the switchport level.

Example #2

If a user begins sending 50% more traffic than usual and has a Malware event, then tell ISE to bounce them.

So, we have two data points here, the traffic patterns do not match a typical day and we know the endpoint has security alerts.

Example #3

If an endpoint comes on the network that has not been seen before and the endpoint sends over 100MB of data to the Internet and the destination country is Sweden or Canada and the protocol is FTP then tell ISE to bounce the endpoint.

Actual Quarantine

The actual quarantine does not have to be a bounce or shut off the switchport. It can be pretty much anything you want it to be as well.

  • Bounce Endpoint: Certainty thorough, ISE can simply shut down the port the endpoint is plugged into.

  • Change VLANs: ISE can place the user in a restricted or quarantine VLAN.

  • Apply DACL: ISE can apply and enforce a restricted ACL. Perhaps only blocking critical systems on the network while the issue is investigated.

Remove from Quarantine

To remove an endpoint from quarantine, you are also only limited by your imagination. The first option is to make it a manual process. The security engineer cleans the endpoint and then manually tells ISE to take it out of the quarantine.

The second option is to automatically remove the endpoint from quarantine after the user completes a specific task. This may be something like a scan of the endpoint. You can write the rule to include the URL of the “success” page of the online scanner.

This article only scratched the surface of what Rapid Threat Containment can do. There are several compatible products that can work together to completely automate your security response which will help eliminate errors and result in a much more secure environment.