This is the first in a series of posts on Cisco’s Firepower solution. Over the course of the series I’ll be looking to provide you with some basic (and more advanced) configuration steps and things to watch out for in real world deployments.

This article is just going to run over some of the basics and give you a taste of what Firepower is all about!

What is Firepower?

Firepower is the name of Cisco’s Next-Generation Firewall (NGFW)/Next-Generation Intrusion Prevention System (NGIPS) solution. The product was added to Cisco’s security portfolio after they acquired Sourcefire back in 2013. The underlying IPS engine is based on the open-source Snort software, however Firepower adds a bunch of additional features on top of this as you’d expect.

Firepower can run on a number of different platforms, including:

  • ASA-X – Firepower can run as a software module to complement ASA software on compatible devices. This deployment approach is known as Firepower services
  • ASA-X or Threat Defence Appliance – Firepower can run as a dedicated firewall solution on specific hardware appliances or on compatible ASA-X firewalls. This deployment approach is known as Firepower Threat Defence (FTD)
  • Virtual Machine – There are virtual options to allow you to run Firepower as a NGFW or NGIPS in your chosen virtual environment
  • Integrated Service Routers (ISR) – Firepower can also run on certain models of ISR

This series of articles will mainly be focusing on ASA-X with Firepower services and Firepower Threat Defence. That being said, many of the things you will learn are the same across all the options anyway.

Firepower Services vs Firepower Threat Defence

As you’ll notice from above, ASA-X firewalls can run Firepower as “Firepower Services” or “Firepower Threat Defence” (FTD). What exactly are the differences and which should you use?

Firepower services runs as a separate software module on the ASA-X – it is totally de-coupled from the ASA code. In order to have traffic inspected by Firepower you have to punt it to the module with a service-policy. This would typically look something like:

access-list FIREPOWER_ACL extended permit ip any any
!
class-map FIREPOWER_CLASS
  match access-list FIREPOWER-ACL
!
policy-map global_policy
  class FIREPOWER_CLASS
    sfr fail-open

This approach makes it a great solution for organisations that already have ASAs in place. There is no need to necessarily rip-and-replace your existing firewalls to take advantage of the platform. Instead, Firepower can be integrated with the existing rule base to provide enhanced functionality. The downside of course is there are effectively two separate management systems – one for ASA and one for Firepower.

Firepower Threat Defence more tightly integrates the ASA and Firepower code. Notice I used the word more rather than fully. Poke around under the hood and you’ll soon see that they are actually still quite separate! From a management perspective though, everything is taken care of through the relevant Firepower management tool (be that on box or via a dedicated management centre). There is no more ASDM or CLI for making configuration changes (on the whole anyway). All firewall rules and associated policies are now taken care of through the Firepower management interface via a web browser or API calls. Any changes to the underlying “ASA code” are taken care of by Firepower auto-magically.

Management options

There are three main options that you’ll come across for managing Firepower devices.

  1. Firepower Management Centre (FMC) – A separate physical or virtual appliance that can manage one or more Firepower devices (both Firepower services and Firepower Threat Defence)
  2. On-box ASDM – If you’re running ASA-X with Firepower services this can be managed via ASDM directly
  3. On-box Firepower Device Manager (FDM) – If you’re running certain physical versions of FTD you can utilise the on-box FDM manager

Options two and three have a number of limitations to go along with them. You do not get all the features you would when managing with Firepower Management Centre. I’d always recommend clients to use FMC wherever possible – even for a single Firepower device. Fortunately this tends to be the view that clients take as well. I’ve only come across one, maybe two clients who aren’t using FMC.

Main features and components

The rest of this post is going to give you a breakdown of the main features and components that combine to make up the bulk Firepower. This isn’t everything Firepower can do and some of the more advanced features/settings will be covered in a later article. At a high-level I’m going to look at the following:

  • Access Policies
  • Intrusion Policies
  • Network Discovery
  • Malware and File Policies
  • DNS Policies
  • Identity Policies
  • SSL Policies
  • Security Intelligence

Access policies

Access policies are where you define your firewall rule base and associated actions. It is also the component that glues together most of the other policies we will look at. For example, if you create an access rule that you want to apply IPS to, you add the IPS policy under the “inspection” option of the rule itself. Without binding the various policies to the access-policy they are mostly useless!

The firewall rules you can add in Firepower are more advanced than the old port-based rules you may be used to seeing. You can now include applications (not just ports), user identity, zones, URLs and many other things in your rules. How does an application rule work? The firewall will let through the initial TCP handshake and enough application traffic until it can identify what the application is. Even if you choose not to firewall based on an “application” though, you still get this level of visibility in the reporting which is great.

Lets have a look at the options when adding a typical access-policy rule:

Screenshot of Firepower Access Policy

You can see lots of different tabs which give you a lot of flexibility when defining match criteria. I just want to take a moment to clarify how they interact with each other when evaluating a connection. This is important as it tends to be something people get confused with initially.

  • When evaluating conditions WITHIN a tab, multiple selections are treated as an OR
  • When evaluating conditions BETWEEN tabs it is considered as an AND

So as an example take a look at these two screenshots…

Screenshot of application tab of access policy

Screenshot of port tab of access policy

As you can see I’ve defined “HTTP” (application inspection) under the application tab and “HTTP” (a named object for TCP port 80) under the port tab. This means this rule will only be matched if the application is actually HTTP AND it is running over port 80. So if someone tries to tunnel another application over port 80 it will not match this rule. If I’d have wanted to I could have configured the rule to allow HTTP over any port. Firepower would then have been firewalling solely based on application.

Now as good as application firewalling can be, I typically recommend clients to migrate from existing solutions using TCP/UDP based rules to start with. Then over time applications can be integrated into the rules to enhance security. This is purely to minimise the risk of any problems during a migration. If of course you are setting up a greenfield site you may want to look at firewalling with applications in your rules from the outset.

You can use any number of the above fields when defining a rule. Each tab defaults to “any” unless you override it with a value. There really are no hard and fast rules on how to define them – it is how it will best fit your organisation and the policies you need to define. If you want to apply a general rule you may choose to leave the zones or networks blank. Alternatively you may want to be really specific and define something in every tab! Just remember as with all firewalls, it operates on a first rule match basis so you need to be careful with rule ordering and definition.

Intrusion policies

As the name alludes to, the intrusion policy is where you setup and configure your Intrusion Prevention/Detection policies. Under the hood IPS is based on Snort and like other similar systems it is a signature-based protection mechanism. Out of the box Firepower comes with a number of pre-defined base policies:

Screenshot of port IPS policy creation

  • Security over Connectivity – Enables more signatures and will catch more attacks, but also increases your likelihood of false positives which could impact on day-to-day operation
  • Connectivity over Security – Fewer signatures are enabled which decreases the number of attacks that can be caught, but this base policy is a lot less likely to create false positives
  • Balanced Security and Connectivity – Somewhere in the middle of the two above!
  • Maximum Detection – Enables the rules that will overall provide maximum detection of attacks. I’ve seen Cisco recommendations not to use this in production before, so not sure why they continue to include the option! I think this is primarily used during product tests when comparing the detection rate of different vendor’s products
  • No Rules Active – Pretty obvious from the name I think! Only reason you’d ever use this is if you wanted to start off with no rules enabled and go through and enable them manually. Never come across anyone using it, but it has its uses

If your organisation doesn’t have any strict preferences then I’d recommend starting with the balanced option and see how you get on. Notice the little “Drop when inline” tickbox above? Don’t forget to untick it. I’d always recommend deploying Firepower IPS in a non-blocking mode initially. In my time working with the solution I haven’t seen a huge number of false positives (certainly none that would have caused major issues), but it is always best to err on the side of caution. No one is going to thank you for breaking production systems, even if you had the best intentions!

If you’ve ever worked with IPS systems in the past you’re probably more than aware that they can take a lot of tuning. This is where Firepower starts to shine. When Firepower is used in conjunction with FMC it can automatically tune your IPS rules based on information it learns. If there are no Linux servers in the network, why have Linux based IPS signatures enabled? It is worth setting up a scheduled task to periodically apply recommendations or manually apply them after any significant changes to the devices in the network.

Network discovery

As mentioned above, FMC has the ability to learn about the network and build up a picture of the devices and applications in use. This information is combined into something known as a host profile. A host profile is basically a snapshot of the information Firepower has learned for a specific endpoint. This includes information such as:

  • Operating system
  • Client applications
  • Server applications
  • Logged in users
  • Indications of compromise
  • and much more…

The host profile helps Firepower to tune IPS signatures and map specific vulnerabilities to devices. That way it can determine if an attack is relevant or not. For example, Firepower may observe traffic that matches a signature for an IIS attack, but if it is against a Linux server running Apache is it really that relevant? Should the admin jump up and investigate that immediately? Probably not – they are probably better focusing on other more relevant alerts. Operating system information is passively fingerprinted, so it isn’t always 100%, but it is still extremely useful. Firepower also supports NMAP scans for more accurate fingerprinting of devices.

The network discovery settings allow you to control which networks FMC will monitor to build up these host profiles. By default this is set to any network but you want to change this to your internal networks. There’s not much point building up a picture of remote Internet hosts you aren’t interested in protecting. Each host also contributes to your total licensed host count for FMC, so you definitely want to change this.

Screenshot of network discovery settings

Network discovery also allows you to define if Firepower will discover users or not. This particular setting only relates to passive discovery of users whereby Firepower will look for usernames in clear text traffic such as LDAP and FTP. There are other methods of user identification which I will touch on in a bit.

Malware and file policies

Malware and File policies allow you to perform two main tasks. Firstly, you can control the flow of files through the network and secondly you can check these for malware using Cisco’s Advanced Malware Protection (AMP) feature.

File control can be based on file type, protocol and direction. If you wanted to prevent users downloading exe files over FTP then this can be achieved with a file policy.

Screenshot of file policy

AMP checks files for malware before passing files through the firewall. It does this by creating a SHA256 hash of the file and sending this to Cisco’s AMP service for a verdict (referred to in Firepower lingo as a file’s “disposition”). There are one of three responses you’ll get back from AMP:

  • Clean – the file was known about by AMP and is considered to be clean
  • Unknown – the file has not yet been seen by AMP and is unknown. Often the case with zero-day exploits
  • Malware – the file is known by AMP and is malicious

There are also technically some local dispositions that don’t come from the AMP service:

  • A clean file list (i.e. a whitelist of files to override AMP)
  • A custom detection list (i.e. a custom file blacklist)

If the file is flagged as malware then the solution has the option to block it to prevent it ever reaching the end user. Clean files pass through as you’d expect, but what about an unknown file?

A file with an unknown disposition hasn’t got a positive or negative verdict from Cisco yet. It may be the first time it has been seen. If a file returns an unknown disposition then it will be allowed through the firewall, but you can optionally uploaded it automatically to Cisco’s Threat Grid service for dynamic analysis (if it is a supported file type). Once in threat grid the file will be run/opened in a sandbox environment and analysed to try and determine if it is malicious or not.

If threat grid determines that an unknown file is malicious, it will return a retrospective alert to your Firepower solution to say “Hey, that unknown file you downloaded – it’s actually malicious”. On receiving this Firepower can generate alerts to administrators and flag the host as having an indication of compromise. So whilst the file may have gotten past the firewall you can at least take action to minimise its potential impact soon after the event.

Keep in mind that with both file control and AMP Firepower can only control what it can see. If a file is downloaded over a secure protocol (such as HTTPS) then you my not be able to block it (unless your decrypting – we will come to that).

DNS policy

What do a lot of malicious connections have in common? They probably use DNS to resolve names to IP addresses. So if you can block a connection at the DNS layer before it has chance to establish, you can help to prevent hosts from being compromised or downloading a malicious file in the first place. Given the firewall sits between your internal and external networks, it is well placed to inspect DNS and drop any requests for known malicious domains. This is done using a DNS policy.

Screenshot of DNS policy rule

DNS policies allow you to statically whitelist and blacklist FQDNs as well as to take advantage of dynamically maintained Cisco feeds. Actions you can take with a DNS are:

  • Whitelist – allow the request through the firewall
  • Monitor – allow the request through the firewall, but log the request as well
  • Domain not found – return a “NXDOMAIN” record back to the client to prevent them resolving and connecting to the FQDN
  • Drop – silently drop the DNS request and don’t return anything
  • Sinkhole – return a specific IP address to the DNS request that forces traffic through the firewall

That last option warrants a little explanation. In your typical enterprise environment, your internal devices probably send their DNS requests to an internal DNS server. This in turn forwards unknown queries to an external resolver. From Firepower’s perspective, all DNS requests are sourced from that one DNS server. This setup doesn’t allow Firepower to tell you which endpoint actually requested the malicious domain, which can be handy when looking at indications of compromise. The sinkhole option returns a dummy IP address back to the originating client which forces traffic to route through the firewall. Firepower will then monitor this address for any traffic and drop it. If it sees a host trying to connect to the sinkhole IP address then it can be confident that something isn’t quite right and the device may be compromised.

From experience, you are usually best setting malicious domains to either “Domain not found” or “sinkhole” depending upon your requirements.

Identity policy

Firepower has the ability to integrate with user identities. This is useful if you want usernames in your logs or if you want to tie certain rules to specific users/groups. An identity policy ties a firewall ruleset back to a “realm” (Firepower lingo for a specific Active Directory/LDAP environment). In general there are two ways of obtaining user identity in Firepower:

  • Passively – Firepower learns IP to user mappings from an external source. This is typically either via a special agent running on a domain server or from a source such as Cisco Identity Services Engine via a framework called pxGRID
  • Actively – Firepower can actively provide a login page to users to enter their credentials for authentication against a backend AD/LDAP server

Screenshot of identity policy rule

Passive is usually the preferred method for obvious reasons – it is transparent to users. The Firepower agent solution works by monitoring logon events in Active Directory audit logs. Each time you log on to a domain computer, you generate a logon audit log (assuming your domain controllers are setup to do so). Firepower then receives this information and maps IP address “x” to “user a”. ISE being the central authentication point of the network can also provide this information if you have 802.1x deployed on your network.

Active authentication is typically used a lot less than passive. One option it could be useful for is if you are trying to control non-domain joined machines. Perhaps you have a BYOD network, but you still want to control based on AD groups. You could still let people use their iPads etc. but then just present a login page prior to letting their traffic through the firewall.

SSL policy

Firepower has the ability to decrypt SSL traffic (or to be more accurate – TLS). Be careful with this – depending on the platform you are running this could significantly impact performance of the device. There are also various legal/privacy implications you need to think of. As an intro I’d suggest going and having a read of my previous article – To Decrypt or not to Decrypt

If you choose to implement TLS decryption, this is done using an SSL policy. The policy is made up with rules much like the access-policy reviewed earlier. Again, conditions within a tab are a logical OR and between tabs a logical AND. There are a few different actions you have when it comes to an SSL rule:

  • Decrypt – Resign – This is used when you want to decrypt sessions for sites which you don’t own the private key. In other words, when accessing any external Internet site. This uses an internal CA certificate/key to spoof certificates on the fly. Take a read through the blog post I linked above for a better understanding of how this works
  • Decrypt – Known Key – This is used when you do own the private key. This would be used for example if you want to decrypt traffic going to a DMZ webserver. You have the private key so can upload this to Firepower to decrypt and inspect prior to reaching the webserver.

Because you have flexibility in defining rules for the traffic you decrypt, it is not an all or nothing feature. Take the screenshots below as an example. You could have one rule that specifically excludes “financial services” to ensure you don’t decrypt banking details, and a second that enables decryption only on a couple of categories. This allows you to choose what you inspect and build up slowly if you’re concerned about the performance impact.

Screenshot of SSL Financial exclusion

Screenshot of SSL Decryption Rule

Security intelligence

The final thing I want to talk about is Security Intelligence (SI). SI allows Firepower to take feed information in from Cisco and use it to help defend the network. If Cisco detects a range of IPs are being used to host malicious sites, it can automatically be pushed to your solution and prevent your clients from connecting. This is a great feature and you want to be using it. When defining a security intelligence policy you have two types of object you can add to a whitelist or blacklist:

  • Networks – There are a bunch of different categories defined by Cisco that you can add to your blacklist as necessary
  • URLs – Similar to above but based on URL rather than IP

Typically for most clients I add all Cisco defined categories into the blacklist for highest levels of protection. In some larger networks I will do this initially in a “monitor mode” where I will change the action from the default of “drop” to just monitor. This allows me to review any false positives before transitioning to blocking mode. I haven’t come across many false positives during deployments though and would add this is a good feature to get into blocking as early as possible.

Screenshot of Security Intel

Summary

Hopefully this post has given you a good idea of what Cisco Firepower has to offer. Keep your eyes peeled for the posts to follow, where I will start diving into some step-by-step tutorials on getting Firepower up and running in your environment as well as some things to watch out for.

Please follow me on Twitter, LinkedIn or my RSS feed to receive updates when the new articles go live!