Cisco Secure Firewall Reviews

The primary use case is mainly around perimeter security at the HQ and the branch. This will include using the Next-Generation Intrusion Prevention System (NGIPS), using advanced malware protection for networks on the firewall, and remote access VPN as well as site-to-site VPN.

I work for a Cisco partner and managed service provider. We have a number of customers. Typically, the standard setup that we have is a Firepower Management Center Virtual, running in VMware, with physical FTD appliances (as the firewalls) on-premises.

We work with more mid-size organizations who typically have email security, web security, endpoint security, and perimeter security. In terms of products, that would be:

• Cisco Umbrella
• Cisco Cloud Email Security
• Cisco Secure Endpoint
• Firepower, for the perimeter. 

That would be a typical technology mix. Sometimes, some customers will consume something like Duo Security for multi-factor authentication.

We are primarily running ASA Firewalls with the FTD image. We are also running some Firepower 1000 Series. 

One of the nice things about Firepower is that you can set it to discover the environment. If that is happening, then Firepower is learning about every device, software operating system, and application running inside or across your environment. Then, you can leverage the discovery intelligence to get Firepower to select the most appropriate intrusion prevention rules to use for your environment rather than picking one of the base policies that might have 50,000 IPS rules in it, which can put a lot of overhead on your firewall. If you choose the recommendations, as long as you update them regularly, you might be able to get your rule set down to only 1,000 or 1,500, which is a significant reduction in a base rule set. This means that the firewall will give you better performance because there are less rules being checked unnecessarily. That is really useful. 

Cisco implemented a role-based access control for Firepower, so you can have very granular accounts. For example, a service desk analyst could have read-only access. If we have a security operations team, then they could have access to update IPS vulnerability databases. A network engineer could have access to update ACLs, not rules, which is quite useful. Also, you can selectively push out parts of the policy package based on your role-based access control. So, if you have one job role and work on one part of the configuration, and I work on another job role working on a different part of the configuration, then I could just deploy the changes that I have made without affecting what you are doing (or without pushing out your changes). It is quite nice to be able to do that in that way.

The most valuable feature is the Next-Generation Intrusion Prevention System. For customers who don't have a SIEM platform, Firepower Management Center offers some SIEM-like functionality that clearly categorizes intrusion prevention alerts. So, they are rated with flags, from zero to four. If I see a level 1 flag, then this means that the attempted intrusion, not only relates to a real vulnerability, but we likely have a system in our environment somewhere that could be exploited by that vulnerability. In that sense, it helps us quickly target which intrusions should be investigated versus what is noise. A level 2 flag just identifies where an intrusion relates to a known vulnerability. It doesn't mean that you are vulnerable to it, because you may not have the particular hardware/software combination that the vulnerability relates to. Therefore, being able to quickly determine where to focus your investigation is important.

All Cisco security technologies have API integrations. We have all Cisco security products for all our customers integrated into SecureX for overall visibility of threat detections across all security appliances. Cisco Advanced Malware Protection is a good example. It is not just a product but a capability that has been integrated into multiple products or technologies. We see in Firepower that we can benefit from Advanced Malware Protection at a network level, but that same technology is also available on email security as well as endpoint security. So, if a threat is detected in one place that can be blocked everywhere, almost at the same time, then the integration is very good. 

If we look at something like Cisco Umbrella, then we see Umbrella integrated with Cisco Meraki appliances, both on firewalls and access points. So, there does seem to be a good level of integration.

Integrations are primarily API-driven. You just generate an API. You have an identifier and generate an API key. It is normally five minutes or under to integrate something. Cisco has SecureX, which is their security management platform. They also have Cisco SecureX threat response, which is a threat hunting tool. With both of these tools, they can take the API keys from any Cisco products as well as some third-party products, then you can integrate them in just a couple of minutes. It is pretty easy.

FlexConfig is there as a bridge for features that are not yet natively integrated into Firepower. It is a way of allowing you to be able to configure things that wouldn't otherwise be possible until the development team can add them into Firepower's native capability. There is still some work that needs to be done around FlexConfig. There are still quite a few complex things, like policy-based routing, that have to be done in FlexConfig, and it doesn't always work perfectly. Sometimes, there are some glitches. It is recommended that you configure FlexConfig policies with Cisco TAC. It would be good to see Cisco accelerate some of those configurations that you can only do in FlexConfig into the platform, so that they are there natively.

I have been using it for around 18 months.

The product has significantly improved over the last two years. I am aware that the Cisco product team has made significant strides forward in addressing oversights that may have previously existed in the platform. I don't have that much in the way of improvements now. We are running the latest code, the 6.7 code, on all our environments. It addresses so many issues that previously existed in earlier versions of the code. From 6.6, the code has improved significantly and introduced many feature benefits.

The new code, 6.6 and higher, seems to be very stable. Now, you don't need to deploy the entire policy package every time you make a change. You can just deploy the segment of the configuration that has been changed. This has increased how quickly you can deploy the configuration, which is a good improvement. We seem to have less bugs and glitches in the newer code. I can't think of any real bugs or glitches that I have seen since we have been running 6.6. With 6.5 and earlier, there were some problems. Now, it seems to be very stable.

The thing that restricts the scalability would be Firepower Management Center. It is constrained by how many events it can record. It suits customers who have a smaller number of sites, like a dozen or maybe 20 sites. You can still record your connection and intrusion event history for a significant period of time. But, if you are talking about a customer with hundreds of firewalls, then Firepower Management Center probably is not the right proposition.

If I am a customer with a dozen sites, I probably don't have the money to pay for a dedicated SIEM platform. So, Firepower Management Center is great for me because it is like a mini SIEM from a perimeter security perspective. I can store my connection and intrusion event history. I can get an idea of which IPS intrusions are things I should focus my attention on. These are the things that a SIEM could help you with. I can manage my firewalls from a single management location, which is really good. However, if I am a customer who has hundreds of firewalls, then it is not really scalable because I wouldn't be able to store the amount of intrusion and connection events that I would need for those firewalls.

Cisco Defense Orchestrator would probably be the better option if you had an environment that had hundreds of sites with hundreds of firewalls. Even if you acknowledge that Cisco Defense Orchestrator doesn't store events per se, it just allows you to manage and deploy policies to the firewalls, when you have an environment with hundreds of firewalls, then you will definitely have the budget for a SIEM platform. At that point, you would be scaling by having separate platforms for separate functions rather than one platform to do everything.

Firepower Management Center is great for some customers with whom we work because they don't have hundreds of sites with hundreds of firewalls. They just have somewhere between two and 10 sites. So, it is a good fit for that kind of customer.

Cisco Talos is one of the largest private security, threat hunting, research organizations, but non-governmental. It is quite powerful when we explain to customers the threat intelligence injected into Cisco products. I have attended some Cisco Talos workshops, webinars, etc., and they do seem to be amongst the best in their field. So, I have a high degree of confidence in Cisco Talos, and it is one of the most powerful capabilities that Cisco has as a security vendor. You could have the best features for a product, but if the security intelligence is not good nor current, and if it can't accurately predict new threat trends in a timely way, then it still may not help you.

The technical support is absolutely brilliant. When I call Cisco TAC and have a case, every single engineer that I get assigned to any case is an expert in their field. I feel like they understand the product that we are talking about inside out. I have never raised a case for Firepower and not been able to get a resolution. I have a high degree of confidence in them.

The support may not be one of the features documented in the data sheet, but I have worked with other vendors where their quality of support is not comparable. When you are looking at the total cost of a solution, you need to look at more than what the face value of the product is. You need to look at:

• How complicated is this going to be to configure? 
• How complicated will this be to operate? 
• How long will it take me to get a resolution if I have a problem? 

From my experience with Cisco TAC, the resolution will always be very quick. More often than not, it is within a couple of days, if it is a P3. If it is a P1, then it is the same day. I couldn't ask for better.

I find the initial setup fairly straightforward. I wouldn't say it is simple, but it is not a simple piece of technology. You have different policies for different areas of the system, e.g., you have a policy for access control, NAT, FlexConfig, remote access, VPN, etc. There are a lot of policies that you either have to create or configure. However, it is fairly intuitive. Once you have done it once, you know where everything is.

If we assume the most basic variables, one FMC and one FTD on the same LAN, then the FMC can be provisioned with the policies in a day. The appliance can be imaged and added to the FMC with the policies pushed out on another day. If you add remote access VPN into the mix, especially if you have an Active Directory integration, I would probably add another day. You could probably have a working setup in three to four days, depending on if you have any issues with the licensing portal. 

It is very easy to deploy site-to-site VPN tunnels between Firepowers. I appreciate that Cisco deprecated all legacy cypher standards. This means you need to use the modern, robust cipher standards that cannot be broken right now. This is a good thing. However, if you are using two Firepower devices, then it is easy to set up a site-to-site VPN tunnel and use the strongest cipher standard, which is also good.

We normally always try to pre-stage, spinning up virtual FMC and VMware, then configure as much as possible before adding an appliance in. It can be a bit more challenging if you have a lot of FTDs at different sites because you need to be aware that you may be managing a device on an internal IP address while you are pre-staging, but that address may change when you deploy the solution. You just have to think that through, in terms of how Firepower Management Center will keep its connectivity to the device once you deploy it. So, if Firepower Management Center and appliances are all on the same local area network, then it is straightforward. However, it is when you have multiple appliances at different sites that it can be a bit more tricky to make sure that the connectivity is maintained when you deploy. I think some more guidance around this would be good. We have a process that works for us, but it took a bit of figuring out with Cisco TAC to make sure we were not missing anything. If they could maybe document it a bit better, that would be good.

Normally, someone like myself could set everything up, so you wouldn't need a big team. However, if you are doing integrations with something like Active Directory, then you need the person who administers that system to be involved. Likewise, if you are doing site-to-site VPN tunnels with third-parties, then you probably need someone from that third-party organization involved. Most of the configurations can be done by one person. You do need to let the Firepower discovery run for around two weeks before you then run the recommendations around which IPS rules to apply, but it would be possible to just select one of the base policies and leave it at that.

You could choose to run the network discovery, which you should do anyway because there are added benefits, for two weeks then choose the Firepower recommendations. However, if you didn't have time to do that, or that wasn't an option for some reason, you could just choose one of the base IPS policies, like Security over Connectivity or Balance, and that would work out-of-the-box.

Everyone who uses the platform has felt more confident in their perimeter security. The Firepower platform makes it very easy to keep track of what software revision you are on, what your revision is versus what the latest is. It makes it really easy to schedule tasks to download the latest geolocation and vulnerability updates, automate backups, and copy backups to a remote location. Operationally as well as from a security perspective, everything has been positive in terms of the feedback.

I like the Smart Licensing, because it is more dynamic and easier to keep track of where you are at. If we have a high availability firewall pair and they are deployed in active/standby rather than active/active, I would expect that we would only pay for one set of licenses because you are using only one firewall at any one time. The other is there just for resiliency. The licensing, from a Firepower perspective, still requires you to have two licenses, even if the firewalls are in active/standby, which means that you pay for the two licenses, even though you might only be using one firewall any one time. This is probably not the best way to do it and doesn't represent the best value for money. This could be looked at to see if it could be done in a fairer way. For example, you can only deploy MX firewalls in active/standby. There are no other options. You only need one license for those firewalls because you can only use one at a time. This seems quite fair. They may need to look again at this from a Firepower perspective.

I work for a Cisco partner, so we are very Cisco-focused. Most of our customers consume predominantly all Cisco solutions. We have some customers who may have the odd product that is not Cisco, but a majority of their security suite will be Cisco.

I have some experience with budget firewall platforms, like SonicWall and WatchGuard, but these are not really comparable to Cisco in terms of being direct competitors. It would be like me trying to compare a performance car against a budget economy car. It is not a fair comparison.

I would probably ask, "How long do you want to keep the connection and intrusion events for?" You need to remember that Firepower Management Center can only keep a certain amount of events. I think you need to have that in mind as one criteria to make your decision against. 

You need to look at what hardware platform you are going to be deploying. We have a lot of customers who are running ASAs, but they are running the Firepower Threat Defense image on their ASA. For all intents and purposes, those ASAs act as FTDs. Now, try to remember those ASAs were never designed originally to run the FTD code. Now, they can run the FTD code, but some of the dedicated Firepower appliances have a split architecture. So, they have separate physical resources, CPU, and memory for running the traditional firewalling capabilities versus the next-generation firewall capabilities, like IPS, AMP for Networks, and AVC. Maybe, have a think about the hardware platform, because you need to try to assess what throughput you are trying to put through the firewall and how that will impact the performance of the box.

There is definitely some advantage moving to the dedicated Firepower appliances rather than putting the Firepower code on an ASA. Although, it does allow you to leverage an existing investment if you put the FTD code onto the ASA, but you need to be mindful of the limitations that it has. Also, if you are looking to do SSL decryption, then you need a much bigger firewall than you think you need because this puts a lot of overhead on the appliance. However, this would be the same for any vendor's firewall. It is not Cisco specific.

If 10 is the most secure, then our customers are typically in the middle, like a five, in terms of maturity of their organization’s security implementation. This will be because they won't necessarily have things like Network Access Control, such as Cisco ISE. They also won't necessarily have security analytics for anomaly detection, like Stealthwatch or Darktrace. For some of these more sophisticated security technologies, you need to be a large enterprise to be able to afford or invest in them.

While Firepower provides application visibility and control, we don't use it much simply because we use Cisco Umbrella. Firepower gives you application visibility control on a location-by-location basis. So, if we have a firewall at the head office or a firewall at the branch, then we get application visibility control by firewall. However, because we use Cisco Umbrella, that gives us very similar application and visibility control but on a global level. So, we tend to do application visibility and control more within Cisco Umbrella because we can apply it globally rather than on a site-by-site basis. Sometimes, it is useful to have that granular control for an individual site, but it is not something that we use all the time.

I would rate the solution as a nine out of 10.