Cisco Secure Firewall Reviews

We primarily use it for our clients. We have one or more at each client site - or multiple locations if they have multiple locations.

Typically our clients are up to about 500 users. Most of them are smaller than that, but they go as large as 500. They're using the solution for the full next-gen firewall stacks - intrusion protection, URL filtering, advanced malware protection, or so-called AMP. Those are the three subscription services that Cisco sells. All of our clients have those subscription services enabled at their main location. Typically, they're just protecting users that are behind the firewall. We also use it for site-to-site VPN, and we use it for client-to-site VPN.

In terms of our clients, security is one of those things that, ideally, nobody notices. It improves the functioning in the sense that you don't get hacked. However, from a noticeable, management point of view, the URL filtering is a pretty significant enhancement. People are able to block access to various websites by category. It isn't revolutionary. Lots of products do this. However, it's a nice sort of add-on to a firewall product.

At the end of the day, the solution offers good productivity enhancement to a company.

Cisco's support is great. 

For experienced users, they are pretty much able do anything they want in the interface with few restrictions.

The command-line interface is really useful for us. We script basic installations and modifications through the command-line, which is considered sort of old school, and yet it allows us to fully document the changes that we're making due to the fact that we can save the exact script that was applied and say, "Here are the changes that we made." 

We can have less experienced people do initial takes on an install. They can edit a template, and we can have a more experienced person review the template, and then apply it, and we don't have to worry about whether anyone inexperienced went into certain corners of the interface and made changes or whatever.

Everything is all documented in the file or in the command line script that gets uploaded to the device. It gives us great visibility.

I would say that in inexperienced hands, the interface can be kind of overwhelming. There are just a lot of options. It's too much if you don't know what you are looking for or trying to do.  

The GUI still uses Java, which feels out of date today. That said, it's an excellent GUI.

The biggest downside is that Cisco has multiple firewall lines. The ASA line which is what we sell, and we sell most of the latest versions of it, are kind of two families. One is a little older, one's a little newer. We mostly sell the newer family. Cisco is kind of de-emphasizing this particular line of products in their firewall stable. That's unfortunate. 

They have the ASA line, Meraki, which is a company they bought some years ago where all the management is sort of cloud interface that they provide rather than a kind of interface that you manage right on the box. They also bought Snort and they integrated the Snort intrusion detection into the ASA boxes. In the last couple of years, they've come out with a sort-of replacement to Snort, a line of firewalls that don't use IOS.

It's always been that the intrusion prevention and the based firewalling features had separate interfaces within IOS. They've eliminated IOS in this new product line and built it from the ground up. We haven't started using that product yet. They have higher performance numbers on that line, and that's clearly the future for them, but it hasn't reached feature parity yet with the ASA. 

The main downside is that it feels a little bit like a dead end at this point. One needs to decide to move to one of these other Cisco lines or a non-Cisco line, at some point. We haven't done the research or made the plunge yet.

What I would like to see is a more inexpensive logging solution. They should offer either the ability to maintain longer-term logs right on the firewall or an inexpensive server-based logging solution. Cisco has logging solutions, however, they're very high end.

We've been using the solution for 20 or more years. It's been well over two decades at this point.

The solution is solid. It's a big advantage of choosing Cisco. There are no worries about stability at all.

The scalability of the solution is good. Within our customer base, it is absolutely scalable. You can go very large with it. However, if you really want the highest speeds, you have to move off of the IOS ASA line and onto the newer stuff.

Typically our clients cap out at 500 employees.

Technical support is excellent. They are extremely knowledgeable and responsive. It'd rate the ten out of ten. We're quite satisfied with the level of support Cisco provides.

We did use Juniper's NetScreen product on and off for a while. We stopped using it about ten years ago now.

We had previous experience with the Cisco gear, so we were comfortable with it, and Juniper bought the NetScreen product and sunsetted it. You had to move into a different firewall product that was based on their equivalent of IOS, something called Juno OS, and we didn't like those products. Therefore, when they sunsetted the Juniper products, we looked around and settled on Cisco.

Due to the fact that we're experienced with it and we've scripted the command line, it's extremely simple for us. That said, I think it's complex for somebody that doesn't know the IOS platform.

We're Cisco resellers.

We're always on the latest version. I don't actually keep track of the version numbers myself, however, part of what the service that we provide for our clients is updating their firewalls to the latest version.

We use multiple deployment models. We use both on-premises and cloud versions. They are also all different sizes, according to the requirements of the company.

I'd advise other companies considering Cisco to be sure to factor in the cost of the ongoing security subscriptions and the ongoing SmartNet into the purchase price. Those things, over the years, represent more than the cost of the firewall itself - significantly more. However, I'd advise others to get the security subscriptions due to the fact that it really dramatically increases the security of the solution overall.

On a scale from one to ten, I'd rate them at an eight. We love the product, however, we feel like it's not Cisco's future direction, which is the only reason I would downgrade its score. To bring it up to a 10, they'd have to make it their main product line again, which they aren't going to do.

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.

ASA5585-SSP-60 was deployed after a migration from Juniper SRX5600. The solution is used for the protection of the mobile data network. It is protecting 3G/4G Internet customers and the Private APN.

So far, we are not satisfied by the move. The precedent solution is much more adapted to the Telco environment, although Cisco recommended this platform. Cisco ASA also brought our network down several times due to a memory leakage bug, which is still not resolved.

All features provided by the platform are quite the same for all other platforms. We rather missed some features we were used to, such as virtual routers

• VPN creation with Cisco is quite difficult: Some DH groups are not supported (compared to Juniper).
• Expected to see the enablement of virtual routing, which is key in a Telco environment. We need to provide this in LAN to LAN services with shared platforms (DNS, proxies, etc.).
• Application visibility 

Yes, a memory leakage issue which literally freeze the nodes (we have an HA environment). The issue is still not solved and the only recommendation from Cisco is to reboot the node.

Yes, the throughput highlighted on the datasheet (10Gbps) should be reviewed. This throughput is only for a UDP running environment, which you will never find in the real world. Rather consider a multiprotocol throughput.

Experience with technical support was mitigated. 

Technically, they denied any issues on the node and call the memory leak issue, "A cosmetic issue." They were stating that memory disappearance reported by SNMP was an error and will have no impact on the traffic. They have reviewed this since we have recorded several blackouts during the year.

We were using Juniper SRX5600. The switch was more a strategic decision than a technical one.

We are also using a 5520 for seven years in our datacenter and we are satisfied by this version.

The initial setup was very complex. Migration from Juniper (with wide usage of VR) to Cisco is complex and you should make sure to master all the flows on the node. Also, Juniper is more permissive on asymmetric traffic, which Cisco will deny by default. 

Implementation was performed by a Cisco recommended local partner. 

We were not satisfied at all (from the pre to post implementation). Their level of expertise was zero.

I do not know.

Nothing to highlight at this level. 

We did an evaluation with Check Point.

It is definitely not for Telco.

We use them for site-to-site VPN solutions as well as other VPN activities, and for general application security.

We needed a good VPN solution and, as our network grew, we had more applications that were virtualized and that can be spun up. We needed a solution that would keep us ahead.

Cisco ASA provides great security for our applications.

One of the best features is the ease of use. It's also easy to teach new engineers to use the ASA CLI. When I first started learning firewalls, Cisco was the first one that was taught to me and it was pretty easy to grasp. When I'm teaching other engineers to use Cisco ASAs, the results of their learning are immediate.

It needs to provide the next-generation firewall features that other vendors provide, like data analytics, telemetry, and deep packet inspection.

Also, the ASAs need to be improved a little bit to keep up with the demand for high bandwidth and session count applications.

I've been using Cisco ASAs for about 11 years.

It's reliable. It doesn't have all the features of some of the newer firewalls, but it's very reliable. It doesn't break. It's pretty rock-solid.

We have at least a pair in every one of our data centers. We gateway our applications around the firewall system, meaning all application data goes through firewalls.

We have good support from Cisco for the ASAs. That helps us out a lot. Some of our ASAs are pretty old and technically not supported anymore, but TAC always helps us out.

The initial one, for me, was a little bit complex because I hadn't done it before. It was inline and an active/standby pair, so it involved a little bit more than just deploying one firewall. 

We had some documentation written and we tested it in the lab and then the deployment took about four hours.

We deployed it alongside different solutions and then we cut over to it when it wouldn't impact the customers.

The maintenance involves doing code upgrades periodically to keep up with the security environment requirements. One person handles that.

We deployed with a consultant from Cisco support. Our experience with them was good. They provided a lot of documentation ahead of time to help us with our configuration.

From our side there were two people involved. One was doing the configuration and the other person was checking to make sure there were no errors, looking at IPs and the like.

The licensing is straightforward and simple, so we don't have to keep relicensing every year as we do with other applications.

We use Juniper as well.

We use the solution to secure our external software application and user access through different ports.

URL filtering is valuable.

The virtualization aspect has room for improvement.

The scalability has room for improvement.

I have been using the solution for three and a half years.

The solution is stable.

I give the scalability a one out of ten.

The initial setup is straightforward.

The price is good.

I give the solution a nine out of ten.

We use it for perimeter and internal firewalls. We wanted a firewall with traffic inspection, packet analysis, and decryption.

Our deployment is on-prem and hybrid. We don't use it in the cloud as we use other vendors for that.

I'm not sure the firewall has improved our organization because a firewall is a must. It's something that you pick up and then trust. It just works for us.

Cisco is still catching up with its Firepower Next-Generation firewalls. It's naturally growing and getting better.

I've been using Cisco ASA Firewalls for 15 years.

It's stable.

It's used around the world. We have 20 data centers and each data center handles six offices. We have Cisco in every single location. If something new comes up, we'll increase our usage of the product.

Cisco's technical support is good.

Positive

We're a multi-vendor shop when it comes to firewalls, and we use Check Point and Palo Alto in addition to Cisco. We used to have Fortinet but that amounted to too many vendors.

When the Cisco product changed from legacy traffic inspection to the new Firepower it became a next-generation firewall. It was just a new product. That's why we decided to try it and stay with Cisco. It's like two different products: the legacy product and the new one. The legacy product was much simpler and the new one is, obviously, more complex.

I'm a designer, so I don't do racking and stacking, but I'm hands-on when it comes to configuration. I have used this product for years, so for me, it's not like adding a brand new product. It is just a matter of adding features, a hardware refresh. I wouldn't call it a challenge.

For maintenance, we have two to three network engineers involved.

The pricing of Cisco firewalls, in the security market, is fair. Their pricing of other products is questionable, but for firewalls, it's fine.

Compare Cisco ASA with other vendors' products and compare the features one-on-one. Pay special attention to the security portion, such as traffic inspection. That's probably the most important aspect. And then look at performance.

We use it for basic firewalling, building VPN tunnels, and for some remote VPN connections.

We have two ASAs servicing external remote connectivity sessions for about 300 users.

It has definitely improved our organization. It gives us remote connectivity, helps workers connect remotely, and also gives us good connectivity to our other branches.

It would be nice if it had the client to actually access the firewall. Though, web-based access over HTTPS is actually a lot nicer than having to put on a client just to access the device.

For Firepower Threat Defense and ASAs, I would like it if there was a centralized way to manage policies, then sticking with the network functions on the actual devices. That is probably the thing that frustrates me the most. I want a way that you can manage multiple policies at several different locations, all at one site. You then don't have to worry about the connectivity piece, in case you are troubleshooting because connectivity is down.

I have been using ASA for about three years.

It is stable.

We just run updates on them. I don't know if we have had to do any hardware maintenance, which is good.

We have been just using ASAs for a smaller environment.

I don't know if I have ever worked with ASA in a highly scalable environment.

I haven't really gotten involved with the technical support for ASAs.

I work with a lot of different companies and a number of different firewalls. A lot of times it is really about the price point and their specific needs. 

This solution was present when I showed up.

The pricing is pretty standard. 

I wish there was an easier way to license the product in closed environments. I have worked in a number of closed environments, then it is a lot of head scratching. I know that we could put servers in these networks and that would help with the licensing. I have never been in a situation where we connected multiple networks, i.e., having an external network as well as an internal network, as those kinds of solutions are not always the best. I think licensing is always a headache for everyone, and I don't know if there is a simple solution.

We can build GRE tunnels. Whereas, Firepower can't route traffic nor do a bit more traffic engineering within the VPN tunnels. This is what I like about using ASAs over Firepower.

Firepower Threat Defense has a mode where you can manage multiple firewalls through a single device. 

I really like how Palo Alto does a much better job separating the network functions from the firewalling functions.

I would consider if there is a need to centralize all the configurations. If you have many locations and want to centrally manage it, I would use the ASA to connect to a small number of occasions. As that grew, I would look for a solution where I could centrally manage the policies, then have a little more autonomous control over the networking piece of it.

Know specifically what you want out of the firewall. If you are looking for something that will build the GRE tunnel so you can route between different sites, I would go with ASA over Firepower Threat Defense.

I like the ASA. I would probably rate it as eight or nine out of 10, as far as the firewalls that I have worked with.

We use it as a security solution. It is our firewall.

We run three data centers and have three ASAs at each data center.

It is pretty user-friendly and straightforward to use.

It is secure and very reliable.

I like the heartbeat between the two devices that we have. Because if something fails, it immediately fails over.

I have been using ASAs for 15 years at two different companies.

Cybersecurity resilience has been outstanding because it is very stable. There are not a whole lot of upgrades that we need to do for the firmware.

Four engineers support it. From time to time, there are firmware upgrades that we need to keep up to date with. Sometimes, we need to run debugs to figure out what's going on with it, and if it needs a patch, then we will figure it out. Usually, Cisco has been really good about getting us that.

Scalability is actually pretty exponential. In the grand scheme of things, we are a small network. We only have 15,000 subscribers. However, if we need to expand, it is reasonable.

The TAC is always very helpful. We pay for Tier 1 support, so we get whatever we need from them. They always give us a solution. If they can't give us an answer that day, they get back to us within at least 24 hours with a solution or fix. I have never had a problem with the TAC. I would rate them as 10 out of 10.

Positive

We haven't really used anything different. The only thing that we run inline with Cisco ASAs is Barracuda Networks. We kind of run that in tandem with this firewall, and it works really well.

We wanted to integrate Firepower with our solution, but it didn't have the capability to accommodate our bandwidth since they only had two 10 gig interfaces on the box. We run way more than that through our network because we are a service provider, providing Internet to our customers.

Do your homework and know what you are doing. Know how to use your product, stay current, and hire smart people.

I would rate the solution as eight out of 10.