Cisco Secure Firewall Reviews

Our primary use case is whatever is best for our customer. I'm the service provider. The customer's main purpose is to use the malware services protection and the firewall itself, as well as the application awareness feature.

My client company is Cisco Oriented. They wanted to leverage something which is equivalent that can give them the next gen features like application awareness and intrusion protection. That is a major reason they were looking forward to this. The original ASA firewall did not have these features. This was the major reason the customer moved on to Cisco Firepower Threat Defense (FTD). Now they can go ahead and leverage those functionalities.

Firepower is an okay product. However, it is better as a firewall than the IPS or other services it provides.

I was trying to learn how this product actually operates and one thing that I see from internal processing is that it does fire-walling and then sends it to the IPS model and any other model that needs to be performed. For example, content checking or filtering will be done in a field processing manner. That is something that causes delays in the network, from a security perspective. That is something that can be improved upon. Palo Alto already has implemented this as a pilot passed processing. They put the same stream of data across multiple modules at the same time and see if it is giving a positive result by using an XR function. Something similar can be done in Cisco Firepower. Instead of single processing or in a sequential manner, they can do something similar to pile processing. An internal function that is something that they can improve upon.

They can also improve on cost because Cisco is normally expensive and that's the reason customers do not buy them.

Also, if they could provide integration with Cisco Umbrella, that would actually improve the store next level. Integration is one thing that I would definitely want.

From a technical perspective, maybe they could simplify the CLI. That is one thing that I would like to be implemented because Cisco ASA or Cisco, in general, is usually good at simple CLIs. That is one thing that I saw lacking in FTD. Maybe because they got it from another vendor. They're trying to integrate the product.

Two years

From a stability diagnosis, once I did the deployment it did not give me any issue for at least six to eight months. Once it went to a stable support, I did not see major problems. I don't think there were issues with stability.

However, the core upgrades frequently come in, so you need to be carefully devising that support management. From a stability perspective, if you are happy with your current stuff and you do not require past updates it would be very stable. If you're using an IPS, the only challenge would be past management. With Cisco having cloud integration and just firing one command and getting things done, it is still okay. It is a good stable product.

We have only one or two firewalls as a site data center firewall.

From what I have studied, they are scalable. You can have eight firewalls integrated with the FTP devices. I don't think scalability would be an issue but I do not have a first-hand answer on that.

There are approximately 2,500 customer base users using Cisco Firepower. It's a data center firewall, so all the sites integrate for one data center.

You do not need extra staff to maintain Firepower. One field technician engineer, FTE would be sufficient and should not be a problem. I don't think extra staff would be needed. For support, for instance, you need one person.

They have very good documentation, so there's a small chance you will actually need technical support. I would give kudos to the Cisco documentation. That would be the answer.

I have not tried the support because most of it has been solved with the documentation. Nevertheless, Cisco support has typically been a pleasant experience. I don't think that would be a problem with this.

We did previously use a different solution. They had two different solutions. One was Cisco ASA itself and before that, they used Check Point.

We are a Cisco company and that's the reason they are moving from one Cisco product to another Cisco product, which was better than the previous one. So, that was a major reason for the switch. I would say the other vendors are improving. This company was just Cisco oriented so they wanted something Cisco.

The initial setup is a bit difficult. Other vendors are doing the app integration solution. The initial setup was medium in complexity.

You need to install the Firepower CLI. You need to log into that and then you'll need to sit down to connect to the ASA and configure the ASA level services. You also need a Firepower management station for it to work appropriately. The setup is serious and a bit complex.

In my scenario, because I had to learn the entire technology over there and then apply it, it took me around two weeks time to do it. Then the integration, improvisation, and stuff that normally happens took some extra time. You can safely say around two to four weeks period is what it normally takes for deployment. This is based on how the company evaluates the product. It depends on how much you know at that point.

Usually, for the deployment, the company works with Cisco, so they only use Cisco products. I am a DIY person, I did the deployment myself.

We normally license on a yearly basis.

The hardware procurement cost should be considered. If you're virtual maybe that cost is eradicated and just the licensing cost is applied. If you have hardware the cost must be covered by you. 

All the shipping charges will be paid by you also.

I don't think there are any other hidden charges though.

We gave them Palo Alto as an alternative option. I think they were more into Cisco. They did not evaluate the Palo Alto though, they just opted for Cisco.

If you're really looking into Cisco Firepower, they have a good product, but I would say study hard and look around. If you want an easier product, you can always use Palo Alto. If you are a Cisco guy and you want to be with Cisco, you'll need to get an integration service engineer from the Cisco side. That will actually help you out a lot. Alternatively, maybe you can go for Palo Alto. That would be the best thing to do.

If you are not worried about the technical integration part and learning how it works and how well it can go with the environment, I would recommend you go ahead and take an integration engineer with you. Doing a POC could be troublesome for you. We have professional services. You can leverage that.

If you do not want to invest much money on all that stuff you can go ahead and hire someone who's already aware. Or if not, you can use any other vendor like Palo Alto.

The primary use case of for Cisco firewalls is to segment our network. We're using them on the perimeter network for traffic filtering. Since deploying them, we have seen a maturing of the security in our organization. 

We're using both the FTD 2100 and 4100. We have about 40 sites that are using our approximately 80 FTDs. We have about 2,000 users.

It has helped us to solve some problems regarding auditor recommendations. We used to have some audit recommendations that we were not able to comply with. With FTD deployed we have been able to be in compliance around our 36 remote sites.

Before deploying them we had a lot of incidents of internet slowness and issues with site access, as well as computers that had vulnerabilities. But as soon as we deployed them we were able to track these things. It has helped the user-experience regarding connectivity and security. 

In addition, it is giving us a better view regarding the traffic profile and traffic path. And we can categorize applications by utilization, by users, etc.

The solution has, overall, made us twice as productive and, in terms of response time for resolving issues or to identify root causes, we are three times more effective and efficient.

We can easily track unauthorized users and see where traffic is going. It is very useful.

FTD is also fully integrated with Talos. We are in the process of acquiring it and we will integrate it. That way we will have everything from Talos to do correlations.

We would like to see improvement in recovery. If there is an issue that forces us to do recovery, we have to restart or reboot. In addition, sometimes we have downtime during the maintenance windows. If Cisco could enhance this, so that upgrades would not necessarily require downtime, that would be helpful.

We would also like to have a solution on the cloud, where we could manage the configuration. CDO is in the ASA mode. If Cisco could do it in full FTD — the configuration, the administration, and everything — it would be very good, and easy.

The solution is stable. Last year, we deployed it in more 32 countries and it has been stable since the deployment. We haven't had any issues with the firewall. If we have any issues, it is usually due to the power. The solution itself is stable.

It's scalable.

Tech support is able to resolve 70 percent of the issues. In case of an emergency, we can open a case because we have a contract for Smart Net support on the devices. In case of an issue, we open a case and we get assistance.

Before FirePOWER we were using the ASA.

At the beginning, it was complex, but we were able to develop a step-by-step implementation. Now, we can deploy one in about two hours, including integration testing, physical testing, configuration, and applying the rules.

We have in-house engineers for the deployment. We haven't used external, third-parties. We are a big institution, based in 36 countries. The team that is focused on this deployment is a team of five. The person who is handling the implementation will be in contact with a local engineer at the remote site, and will assist him, remotely, to do the testing and follow the steps to deploy.

The one-time cost is affordable, but the maintenance cost and the Smart Net costs need to be reduced. They're too high. A company like ours, that has about 80 firewalls, has to multiple the maintenance cost per device by 80. Cisco should find a way to provide some kind of enterprise support. We don't want to buy support per unit of equipment. It would be easier for everybody.

We are using about ten different security tools, including analytics, monitoring, threat management, and email security. What we have integrated is the ISE and FTD but the third-party solutions are not fully integrated.

Currently, we have 16 remote sites. Some of them are sales offices and some of them are industrial plants. And we have a centralized IT department here in Brazil. The business asked me to support those remote sites. We started using the Firepower Threat Defense, which is one of the versions of next-gen firewalls from Cisco, at some of the sites. We have them operating at five sites, and we are deploying at a sixth site, in Mexico, with the same architecture. That architecture has the firewall running on the site's router, and we manage them all from here in Brazil.

Overall, I would summarize Firepower NGFW's effect on our company's security position by saying that, until now, we haven't had any major security incidents. The investment we made, and the investment we are still making in that platform, have worked because they are protecting us from any risks we are exposed to, having all these remote sites and using the internet as the way to connect those sites. They are doing what they promised and they are doing what we paid for.

For us, the main feature is due to the fact that we have internet connections for all these sites, and we use the internet to communicate with our data center using VPN. So the VPN support in these boxes is one of the most valuable features.

Also, with the firewall itself, the protection and security features, like URL filtering, the inspection, and the IPS feature, are also very valuable for us. We don't have IT staff at most of the sites so for us it's important to have a robust firewall at those sites, to support the business and give us peace of mind. If we do have an incident, since we don't have any IT personnel there for support, we need to do everything remotely.

It provides us with application visibility and control. We can see, on the dashboard, all the applications that are most used and which are under some sort of risk or vulnerability. From my perspective, which is more related to the network itself and the infrastructure, not the security aspect, it helps a lot when we need to check some situation or issue that could be related to any attack or any violation. We can see that there are one or two or three applications that are the top-consuming applications. We can use this information to analyze if there is a deviation or if it's something that we need to consider as normal behavior and increase the bandwidth on the site. It's very important to have this analytic view of what's happening. That's especially true for us, since we have information on all these remote sites but we don't have IT resources on-premises. Having this view of all the sites in the same pane of glass is very important.

It's not just the visibility of things, but the management of application behavior is very important. If I see that, for example, Facebook is consuming too much bandwidth, I can make a policy on the console here and deploy it to our remote offices. So the application visibility feature is one of the key parts of the solution.

NGFW's ability to provide visibility into threats is also one of the important features. Although we have several applications that are based on-premises — we have databases and file servers that only exist inside the company or inside those remote sites — we see more traffic going to and coming from the internet every day. It's not optional anymore to have visibility into all this traffic. More and more, we are moving things to Office 365 or other SaaS platforms which are hosted on the internet. We need to see this traffic crossing our network. It's a top priority for us.

When it comes to Talos, I recognized the importance of it before they were even calling it Cisco Talos. As a user of the URL filtering product, the IronPort appliances, for six or seven years, perhaps or more, I was introduced, at that time, to a community that was called SenderBase.org, which was like the father of the Cisco Talos. Knowing them from that time, and now, the work they do is very important. It provides knowledge of what is happening in the security space. The information they can collect from all the hardware and software they have deployed with their customers is great. But the intelligence they also have to analyze and provide fixes for things like Zero-day attacks, for example, is crucial. They are able to map and categorize risks. They're unbeatable, currently. Although we know that other vendors have tried to replicate this service or feature, the history they have and the way they do their work, make it unbeatable currently.

Some products supersede others within Cisco. I have three platforms and some of the features are the same in two products. It's not clear for us, as a  customer, if Cisco intends to have just one platform for security in the future or if they will offer one product for a particular segment, such as one product for the big companies, one product for the financial segment, another product for enterprise, and another product for small business.

Sometimes, Cisco itself has two products which are doing the same things in some areas. That is something they could make clearer for customers: the position of each product or the roadmap for having just one product. 

For example, I have a management console for the next-gen firewalls we are deploying. But the SD-WAN also has some security features and I would have to use another management console. I don't have integration between the products. Having this integration or a roadmap would help. I don't know if there will be one product only in the future, but at least having better integration between their own products is one area for improvement.

Also, the user interface for the Firepower management console is a little bit different from traditional Cisco management tools. If you look at products we already use, like Cisco Prime or other products that are cloud-based, they have a more modern user interface for managing the products. For Firepower, the user interface is not very user-friendly. It's a little bit confusing sometimes. This is another area where they could improve.

We have been using Cisco NGFWs for about for two years.

The stability is okay. It's robust enough to support the business we have. We haven't had any major issues with the product itself. Of course, we don't touch them frequently because it's a security deployment so it's not the type of thing where we make changes every day. Once we deploy them, and deploy the policies, we don't touch them frequently.

We have one issue at one of the sites, at times. There is a power outage at the site and the virtual machine itself crashes. We have to recover from the crash and reinstall the backup. It's something that is not related to the product itself. It's more that our infrastructure has a problem with power which led to a firewall problem, but the product itself is not the root cause.

It is scalable in our scenario. It is scalable the way we deploy it. It's the same template or architecture, and that was our intention, for all our remote sites. From this point of view, the scalability is okay. But if one of those remote sites increases in demand, in the number of users or in traffic, we don't have too much space to increase the firewall itself inside that deployment. We would probably need to replace or buy a new, more robust appliance. So the scalability for the architecture is fine. It's one of the major requirements for our distributed architecture. But scalability for the appliance itself, for the platform itself, could be a problem if we grow too much in a short period of time.

I don't know how to measure how extensively we use it, but it's very important because without it, we can't have VPN and we can't communicate with our headquarters. We have SAP as our ERP software and it's located in our data center here at our headquarters. If we can't communicate with the data center, we lose the ability to communicate with SAP. So if we don't have the firewall running on those remote sites, it is a major problem for us. We must have it running. Otherwise, our operations at these remote sites will be compromised. In terms of volume, 40 percent of our sites are deployed and we still have plans to deploy the other 60 percent, this year and next year.

Regarding future demands, if we create new business, like we are doing now in Mexico, our basic template has this next-gen firewall as part of it. So any other new, remote sites we deploy in the future, would use the same architecture and the same next-gen firewall.

For our remote sites we didn't use a specific security platform. We had the Cisco router itself and the protection that the Cisco router offers. But of course you can't compare that with a next-gen firewall. But here in our headquarters, we currently use Palo Alto for our main firewall solution. And before Palo Alto, we used Check Point.

The decision to use Cisco was because Cisco could offer us an integrated platform. We could have only one router at our remote sites which could support switch routing with acceleration, for IP telephony and for security. In the future we also intend to use SD-WAN in the same Cisco box. So the main advantage of using Cisco, aside from the fact that Cisco is, course, well-positioned between the most important players in this segment, is that Cisco could offer this solution in a single box. For us, not having IT resources at those remote sites, it was important to have a simple solution, meaning we don't have several boxes at the site. Once we can converge to a single box to support several features, including security, it's better for us.

The main aspect here is that if we had Fortinet or Check Point or Palo Alto, we would need another appliance just to manage security, and it wouldn't be integrated with what we have. Things like that would make the remote site more complex.

We don't currently have a big Cisco firewall to compare to our Palo Alto. But one thing that is totally different is the fact that Cisco can coexist with the router we have.

I participated in the first deployment. I know it's not hard to do, but it's also not easy. It requires some knowledge, the way we deploy it. We use next-gen firewalls inside the Cisco router. It's virtualized inside the Cisco router. So you need to set settings on the router itself to allow the traffic that comes to the router to go to the firewall and return to the router to. So it's not an easy setup but it's not very complex. It requires some knowledge, not only of security, but also of routing and related things. It's in the middle between complex and simple.

Once you have the templates for it, it's easier. It can take a day or two to deploy, or about 20 hours for the whole configuration.

The name of the local partner we use here in Brazil is InfraTI.

For the first deployment we had to understand how to do it because of the constraints. We have the router and we have the next-gen firewalls running inside the router. Until we decided how to deploy, it took a little while. But now we have the knowledge to do that more easily. They are able to deploy it satisfactorily. We are happy with them.

For deployment and maintenance of the solution, it requires two people and our partner. On our side there is an engineer to discuss the details, and then there is the person who does the deployment itself.

You must know exactly what features are important for you, and how you can manage all this infrastructure in the future. Sometimes you can have a product that is superior but it might demand an increase in manpower to manage all the software or platforms. Another point to consider is how good the integration is between products? You should check what features you need, what features you can have, and the integration with other products.

In terms of the maturity of our security implementation, we have had security appliances, software or hardware, for more than 15 years. So we have a long history of using security products. We started using Cisco competitors in the past and we still use them for our headquarters, where I am. Our main firewall is not currently Cisco, although we are in the process of evaluation and we will replace this firewall soon. Cisco is one of the brands being evaluated for that.

In the past, while it's not a next-gen firewall, we also used a Cisco product for URL filtering, up until this year.

We are moving to the cloud. We are starting to use Office 365, so we are moving email, for example, from on-premises to the cloud. But until June of this year, we mainly used security from Cisco. But we also have antivirus for endpoint protection. We also had Cisco IPS in the past, which was a dedicated appliance for that, but that was discontinued about two years ago. Those are the major products we use currently. In addition — although it's not specifically a security product — we use Cisco ISE here to support our guest network for authentication. We plan, in the near future, to increase the use of Cisco Identity Services Engine. When we start to use that to manage policies and the like, we will probably increase the integration. I know that both products can be integrated and that will be useful for us.

There's one other product which we use along with Cisco next-gen which is a SIEM from Splunk. Currently, that is the only integration we have with Cisco. We send logs from next-gen firewalls to the Splunk machine to be analyzed and correlated. 

Although I'm not involved on a daily basis in operations, I helped in the process of integrating it. It was very easy to integrate and it's a very valuable integration, because we can analyze and correlate all the events from the next-gens from Cisco, along with all the other logs we are collecting in our infrastructure. For example, we also collect logs from the Windows machine that we use to authenticate users. Having those logs correlated on the Splunk box is very valuable. The integration is very easy. I don't know who built what, but there's a kind of add-on on the Splunk that is made for connection to firewalls, or vice versa. The integration is very simple. You just point to the name of the server and a user name to integrate both.

We had legacy Sourcefire Sensors and ASA state full firewalls.

Cisco offered the FTD NGFW solution, but the implementation of the two systems was not successful.

The firepower sensors have been great; they do a good job of dropping unwanted traffic.

The VDB updates run on schedule, so less hands-on configuration is needed.

The software was very buggy, to the point it had to be removed.

We are moving completely away from Cisco NGFW.  The product was pushed out before it was ready.

We are a reseller and system integrator, and this is one of the solutions that we provide for our end users. We have experience with many firewall products from different vendors.

The specific use case depends on the customer and their environment. They design the firewalls, and we supply the appropriate equipment.

The majority of deployments are on private networks.

The most valuable feature of the Firepower solution is FireSIGHT, which can be easily managed and is user-friendly.

The performance and the level of throughput need to be improved. This would make things easier for us.

I would like to see the inclusion of more advanced antivirus features in the next release of this solution.

Adding internet accounting features would also be a good improvement.

This solution is completely stable, and we have not had any issues.

Scalability of this solution is ok. They have the IPS (Intrusion Prevention System), online updates, and signature updates.

One customer might have, for example, two hundred and fifty users, whereas another might have one hundred users. There are different models for different numbers of end-users.

Technical support is ok, and we have had no problem with them.

The initial setup of this solution is straightforward.

The price of this solution is not good or bad. It is ok.

This is a solution that I recommend.

The biggest lesson that I have learned from working with this solution is to always update the firewall. If you do not have the latest updates then it will not function well, so always keep it up to date.

I would rate this solution an eight out of ten.

Our primary use case of this program is network protection.

Up until now we haven't been down due to issues with the internet connection or denial of service, so the program does what it claims to do.

The firewalls of this program protects my internet from dangerous internet sites. For us, Cisco is the number one in firewall protection. We are seeking to buy another UTM solution for band management.

The program is very expensive.

We haven't had any problems with the stability so far.

We have 500 users working on the solution and I believe it may increase, so I believe the program is scalable.

The technical support from the company is very good. They are always available when we have problems.

We did use another UTM solution before for firewall, URL and band management. We didn't switch, we just have two layers now. If we want to use Cisco for band management or URL safety, we have to pay a license fee and it is very expensive.

The initial setup was straightforward and it took the company about a day to deploy the firewalls.

The licensing is very expensive.

In the future, I would like to see friendlier configuration and only one license because everything needs a license. You need a URL license, security license, everything is based on a license. I would like to have one license that covers everything. But I am really impressed by the program and my rating is nine out of ten.

We primarily use the solution for internet access firewalls.

The solution allows you to be more agile and react faster.

The Sourcefire stuff itself is the most valuable feature. Signature detection, intrusion detection, IDS, and IPS are all very good. AMP is very useful. I like that you can put it onto devices as well.  The aggregated views in FMC that you get when you're a global shop which is centralized, and then offers gateways per region. In Europe, America and APAC, you have all the data coming together in the FMC. That's quite nice.

The FMC could be a little bit faster.

It will be nice if they had what you traditionally would use a web application scanner for. If the solution could take a deeper look into HTTP and HTTPS traffic, that would be nice.

The stability of the solution is very good. We can see that it gets even better with every release.

For us, the scalability is good, because we sized everything right, right from the beginning. If you size it right, it's very good. We don't plan on adding more firewalls, unless we suddenly grow exponentially, which we're not expecting to do at this point.

We only contacted technical support during initial implementation and that was all handled by the consultant. I have a lot of other Cisco related tickets open, so we're used to the process.

I would say, however, that we're also using Meraki, and the Meraki support is way better, in my opinion. 

Cisco support tends to take longer, and I mean really long given the fact that subject matter is sometimes also more complicated, so it really depends. When you compare that directly to Meraki, Meraki answers the same day, and I cannot say that about the legacy Cisco support items. I can understand that the market for the legacy service is so much bigger for Cisco, so I can see why it takes longer.

The initial setup was complex because we had to migrate old ASA firewalls. The ACLs, or rather the policies, are very different now, and way more elaborate, so that that took some tweaking, and some consulting and some time. 

Deployment took two months. We had to make sure that our old ACL base settings from the ASAs were correctly translated and implemented into the new FTD setups.

We used a consultant to assist with implementation.

We've looked at a few options, but we have an internal policy that says, unless noted otherwise, network equipment has to be Cisco based. We had to go with a Cisco product.

We are using the on-premises deployment model.

My advice for those considering the solution is this: if you want to migrate something, plan enough time for testing before you come over to the solution. You should also watch as many webinars as you can about that solution, or get a consultant and do a proper lab set up and go through the whole thing with them. It's is definitely worthwhile, given the complexity of the whole product.

I would rate the solution nine out of ten.

A lot of companies have a lot of vulnerabilities and lots of exploitations that are going inside their network that the IT staff are not aware of. You actually need a security device like a next-generation firewall to protect your network.

Once we installed the Firepower system, we started looking at the evidence, and we found a lot of exploitations and a lot of bad things that are in the network. These things were invisible to IT, they were unaware of any of them.

The Firepower Management Center is an easy way to manage the devices centrally. I guess this is something that all vendors provide so it's nothing special. I like the way Firepower presents the data. It gives you two classifications for the evidence, something based on the priority of the evidence and another classification based on the impact of the evidence in your environment. This makes it very easy to spot the evidence that is most impactful to my environment. Instead of having to go through all the evidence based on that priority, I can focus on the evidence that has the most impact on my environment.

Sometimes you might have a high priority event but it has nothing to do with your environment. You have a vulnerability. You don't have to treat a vulnerability as an attack. Since you're not vulnerable, it's not impactful to your environment so you don't have to focus on it. This is something that other products don't provide. 

It is very flexible. You can have the next generation firewall work as a physical connection or as a Layer 2 device. You can have a combination of Layer 2 and Layer 3, which is really good. 

There are quite a few things that can be improved. Firepower is an acquisition from another company, Cisco's trying to put it together. Their previous ASA code with the source file code that they have acquired a few years ago still has some features that are not fully supported.

Also, they have a Firepower source file that I can work on the ASA device and on Firepower devices. A problem here lies in the way that you manage these devices. Some devices do not support the FMC, and some devices have to be managed through ASDM, and others have to be managed through FMC.

Most of the high-end devices do not support Onboard management. The Onboard management is only supported on the 2100 IP at the 1050 Firepower and on select ASA devices that bear the Firepower image.

It would be very nice if the Onboard management integrated with all the devices. Log key loading for the evidence at the logs, because clearly you only have loading on the remote on the FMP, you cannot store the logs located on the device.

We have several thousand employees at the company.

Their technical support is good. 

The initial setup was straightforward. 

The pricing is overrated. Prices for Cisco equipment are always a little bit higher than other vendors. Customers are always complaining about the high prices of Cisco equipment, so it would be very good if these prices can be lowered down, but that's how it is. Cisco equipment usually has higher prices than its competitors.

I would recommend this solution to someone considering it. I would recommend to study and know what the requirements are exactly. One of the things that might be a problem, or might be a complex thing to do is to go through Cisco Firepower, because Firepower is a software that's complex to explain to somebody. There is the previous ASA code that Cisco had and there is the source file that they acquired. Cisco started to send it as ASA Firepower services. Then they combined the two codes together and they started to send a new code called the Firepower Threat Defense, FTD.

Any customer who wants to buy it needs to understand all of these options and what the limitations of each option are, the pros and cons. Any customer who wants to deploy Firepower needs to understand what Cisco has to offer so he can choose correctly.

I would rate it a seven out of ten.