Cisco Secure Firewall Reviews

We started using this solution due to challenges with throughput. We needed devices with more quantity of throughput and bandwidth. We use this solution in different locations and different departments and we have around 2000 internal customers.

Cyber security resilience is really important for our organization. It is necessary for all the points for interconnections between LAN networks and WAN networks as we receive daily attacks.

The IP filter configuration for specific political and Static NAT has been most valuable.

The access layer of this solution could be improved in terms of the way the devices interconnect with our network. We need to be able to analyze the traffic between the different interconnections in these areas.

In a future release, we would like to have an IP analyzer to try to identify the specific comportment of the customers.

I have been using this solution for seven years. 

This is a very stable solution. 

This solution would need an adjustment to be scalable. 

Our engineers usually fix the issues we have, depending on the issue. When we reached out to the technical support team, they were attentive and helped us. 

We previously used Palo Alto, Fortinet, and Cisco Firepower. We switched because Cisco is more stable and offers easy deployment for the platform.

This solution requires regular maintenance and I have 10 engineers that manage it.

I would rate this solution a nine out of ten because it is a good product that is more stable than others on the market. 

We have the Cisco 5585-X in our data center for perimeter security, internet protection, and for applications behind Cisco ASA DMZs. The challenges we wanted to address were security and segregating the internal networks and the DMZs.

Security-wise, it's given us the protection that we were looking for. Obviously, we're using an in-depth type of design, but the Cisco ASA has been critical in that stack for security.

The Packet Tracer is a really good tool. If someone calls because they're having problems, you can easily create fake traffic without having to do an extended packet capture. You can see, straight away, if there's a firewall rule allowing that traffic in the direction you're trying to troubleshoot. As a troubleshooting tool, Packet Tracer is one of the things that I like. It comes up in all my interviews. When I want to figure out if someone knows how to use the ASA, I ask them about use cases when they use the Packet Tracer.

One of the challenges we've had with the Cisco ASA is the lack of a strong controller or central management console that is dependable and reliable all the time. There was a time I was using what I think was called CMC, a Cisco product that was supposed to manage other Cisco products, although not the ASA. It wasn't very stable.

The controller is probably the biggest differentiator and why people are choosing other products. I don't see any other reason.

I've used the Cisco ASA going back to the 2014 or 2015 timeframe.

The ASA has been very stable for us. Since I deployed the ASA 5585 in our data center, we've not had to resolve anything and I don't even recall ever calling TAC for an issue. I can't complain about its stability as a product.

Our Cisco ASA deployment is an Active-Standby setup. That offers us resilience. We've never had a case where both of them have gone down. In fact, we have never even had the primary go down. We've mainly used that configuration when we're doing code upgrades or maintenance on the network so that we have full network connectivity. When we're working on the primary, we can switch over to the standby unit. That type of resiliency works well for our architecture.

TAC is good, although we've had junior engineers who were not able to figure things out or fix things but, with escalations, we have eventually gotten to the right person. We also have the option to call our sales rep, but we have never used that option. It seems like things are working.

Neutral

In the old days, we used Check Point. We did an evaluation of the Cisco ASA and we liked it and we brought it on board.

At that time, it was easy for our junior operations engineers to learn about it because they were already familiar with Cisco's other products. It was easier to bring it in and fit it in without a lot of training. Also, the security features that we got were very good.

The one we deployed in the data center was pretty straightforward. I also deployed the Cisco ASA for AnyConnect purposes and VPN. I didn't have to call TAC or any professional services. I did it myself.

We used a Cisco reseller called LookingPoint. I would recommend them. We've done a lot of other projects with them as well.

It's a great investment and there's a lot of value for your money if you're a CSO or a C-leader. As an engineer, personally, I have seen it work great wonders for us. When we're doing code upgrades or other maintenance we are able to keep the business going 100 percent of the time. We have definitely seen return on our investment.

I don't look at the pricing side of things, but from what I hear from people, it's a little pricey.

At the time, we looked at Juniper and at Palo Alto. We didn't get a feeling of confidence with Palo Alto. We didn't feel that it offered the visibility into traffic that we were looking for.

We use Cisco AnyConnect and we've not had any issues with it. During COVID we had to scale up and buy licenses that supported the number of users we had, and we didn't have any problems with it.

For our customers, Firepower is a classic perimeter firewall. Sometimes it's also for branch connections, but for those cases, we prefer Meraki because it's simpler. If a customer has Meraki and requires advanced security features, we will offer Firepower as a perimeter solution for them. Meraki is for SD-WAN and Firepower is for the perimeter.

Firewalls are not a new technology but they have a very distinct role in an enterprise for defending the perimeter. Firepower is for organizations that have traditional infrastructures, rather than those that are heavily utilizing cloud services. For us, the clients are government agencies and ministries, and we have a lot of them as our customers in Latvia.

Most firewalls do the same things, more or less. Because we have to compete with other vendors, it's the things that are different that are important. With Cisco, it's the security intelligence part. It's quite simple to configure and it's very effective. It cuts down on a lot of trouble in the early phases.

IPS and Snort are very important because they also differentiate Cisco from other vendors and competitors.

I also like that, in recent years, they have been developing the solution very quickly and adding a lot of new, cool features. I really love the new web interface of Cisco Secure Firewall Management Center. It looks like a modern web-user interface compared to the previous one. And the recent release, 7.2, provided even more improvements. I like that you have the option to switch between a simplified view and the classic view of firewall policies. That was a good decision.

A major area of improvement would be to have more functionality in public clouds, especially in terms of simplifying it. The high availability doesn't work right now because of the limitations in the cloud. Other vendors find ways to make it work differently than with on-prem solutions.

This is very important because we have customers that build solutions in the cloud that are like what they had on-prem. They have done a lift-and-shift because it's easier for them. They lift their on-prem physical boxes and shift them to the cloud, convert them to virtual, and it continues to work that way. Many times it's not the most efficient or best way to do things, but it's the easiest. The easiest path is probably the way to go.

I have been using Cisco Firepower NGFW Firewalls for four or five years now, but before that, I worked with ASA Firewalls a lot. It was just a transition. I have been using Firepower almost from day one.

We are an integrator and we resell as well as provide professional services. We do everything from A to Z.

There are a lot of things that can be improved. As a Cisco partner, I usually take the first hit if something doesn't work. In recent years, the solution has improved and is more stable. But it has to continue to improve in that direction.

A Firepower firewall is a very important point of exit and entry to a network. It's a critical piece of infrastructure. They should have high availability.

By comparison, I am also a huge fan of Stealthwatch (Cisco Secure Network Analytics) and I use it everywhere. I've been working with that solution for 15 years but it's not mission-critical. If it doesn't work, your boss is not calling you. If it doesn't work, it is not collecting telemetry and it doesn't do its job, but you are not stressed to fix it. With firewalls, it's a little different.

Tech support really depends on how lucky you are. It depends on when you create a TAC case and in which time zone the case is created. That determines which part of TAC takes ownership of your case. I have had a few unpleasant cases but, at the end of the day, they were resolved. I didn't feel like I was alone in the field with an angry customer.

Positive

We made a gradual transition from ASA to Firepower because they first had this as Sourcefire services. That is what we used to install first for our customer base. Then Firepower defense appliances and firmware came out. It was a natural process.

My view may be a little bit biased because I do a lot of Cisco deployments, and I have a lab where I play all the time. But overall the deployment is not too complicated.

The deployment time depends on what type of deployment you have. If it's a physical deployment, it may be a little bit faster because you don't have to set up virtual machines. But I recently had a project in AWS, and I used Terraform Templates and it was easy. I still had to configure some additional things like interfaces, IP addresses, and routing. 

Because I know where everything is in the UI, the deployment is okay. One thing I miss a little bit is being able to configure things, like routing, via the command line, which is how it used to be done with the ASA Firewalls. But I understand why they've taken that ability away.

With ASA Firewalls, even when you were upgrading them, the experience was much better because it didn't have those advanced Snort features and you could usually do an upgrade in the middle of day and no one would notice. You didn't have any drops. With Firepower, that's not always the case.

It's hard to talk about pricing when you compare firewalls because firewall functionality is almost the same, regardless of whether it's a small box or a large box. The difference is just the throughput. Leaving aside things like clustering, what you have to look at are the throughput and the price.

Cisco's pricing is more or less okay. In other areas where we work with Cisco solutions, like other security solutions and networking, Cisco is usually much more expensive than others. But when it comes to firewalls, Cisco is cheaper than Check Point although it is not as cheap as Fortigate. But with the latest improvements in hardware and speed, the pricing is okay.

To me, as a partner, the licensing is quite simple. I'm responsible for providing estimates to my sales guys and, sometimes, as an architect, I create solutions for my customers and give them estimates. There are other Cisco solutions that have much more complicated licensing models than Firepower. In short, the licensing is quite okay.

Not all of our customers use Cisco and that means we have competition inside our company with Check Point. We also made some attempts with Palo Alto Firewalls, long before we became Cisco partners, but somehow it didn't work for us.

I enjoy working with Cisco because it's more of a networking-guy approach. It reminds me a lot of all the other Cisco equipment, like their switches and routers. The experience is similar.

I haven't worked a lot with Checkpoint firewalls, but I like how they look. What I don't really like is the way you configure them because it's very different from what networking guys are used to doing. I'm not saying it's bad, it's just different. It's not for me. Maybe it appeals more to server guys. Cisco has a more network-centric approach.

It's deployed in multiple ways, depending on the use case. Generally speaking, we have them as edge firewalls, but I have some customers who use them as data center firewalls, and some customers who use them as VPN firewalls. And in some places, they're the east-west firewalls, as they would be called in a core network. We do have some that are for cloud firewalling, that we're using in Azure and AWS. But generally speaking, they're deployed as edge firewalls and on-prem.

In some cases that I'm aware of, when moving from specific platforms like Check Point, Firepower has offered a much easier way of working with the platform and deploying changes. For the customer, it's a lot easier in the newer platform than it was in the previous one.

I've done network assessments, where we wanted to get visibility into all flows. I used Firepower boxes for some of those, where we tapped a line and let Firepower see all the traffic. It was incredibly helpful in picking up all of the flows of data. As a result, I was able to give information to the customer, saying, "This is what it's doing and this is what it's seeing in your network." I find it very helpful to get all that type of data. It's got a lot more information than NetFlow-type systems.

There have also been use cases where I'm doing east-west and north-south in the same firewall box. That is possible with SGTs and SD-Access and Firepower. That ability has been critical in some of the designs we've done. A scenario would be that we have an underlay, a corporate network, and a guest network VRF-routed zone; big macro security zones. We are doing micro-segmentation at the edge with SD-Access, but the macro-segmentation between the zones is handled by the firewall. Because we didn't want to split up our east-west and north-south, because there really wasn't a budget for it, they're on the same box. That box is able to do both flows that go towards the internet and flows that go between the different interfaces on the firewall. We're using SGTs in those policies and we're able to extend the logic from the SD-Access environment into the firewall environment, which creates a very unified approach to security.

We're also able to implement dynamic policies for dynamic environments with 7.0. That's becoming more and more important every day. IPs are becoming less important; names and locations and where things live in the cloud mean things are becoming a lot more fluid in the world of security. It's very helpful to have objects and groups that can follow that fluidity along, as opposed to me trying to do it old school and static everything up. No one has time for that. Dynamic policy capabilities enable tight integration with Secure Workload at the application workload level. The IP is less relevant and the application or the VMware tag can be tied to a specific ruleset. It's very helpful to be able to have it be so dynamic now. We're using more and more of those dynamic group concepts.

When it comes to the solution’s tags for dynamic policy implementation in cloud environments, VMware is the primary one I'm seeing these days, but I expect Azure to pick up significantly. The use of these tags for dynamic policy implementation in cloud environments simplifies things. We don't have to have so much static stuff pinned up. We can just have a single rule that says, "If it's this tag, then do this," as opposed to, "If it's this IP and this IP and this other IP, then you're allowed to do this thing." By disconnecting it from the IP address, we've made it very flexible.

It may sound a bit strange, but one of the most valuable features of Firepower 7.0 is the "live log" type feature called Unified Event Viewer. That view has been really good in helping me get to data faster, decreasing the amount of time it takes to find information, and allowing me to fix problems faster. I've found that to be incredibly valuable because it's a lot easier to get to some points of data now.

Also, the new UI is always getting better from version to version. In the beginning, when it came to managing Cisco Secure Firewall, it wasn't always the easiest, but with 6.7 and 7.0, it's gotten easier and easier. It's a pretty easy system to manage. It's especially beneficial for people who are familiar with ASA logic because a lot of the Firepower logic is the same. For those people, they're just relearning where the buttons are, as opposed to having to figure out how to configure things.

I've used the backup VTI tunnel and that's a feature that lets me create some redundancy for my route-based stuff and it works pretty well. I haven't had any issues with it

Firepower 7.0 also has fantastic Dynamic Access Policies that allow me to replicate a lot of the configurations that were missing and that made it difficult to move off the old ASA platform for some customers. The addition of that capability has removed that limitation and has allowed me to move forward with implementing 7.0. 

Snort 3 is one of the biggest points on Firepower 7.0. I've been using Snort 3 for quite a while and, while I don't have a ton of customers on it, I do have some who are running on it and it's worked out pretty well. In their use cases, there wasn't a lot of risk, so that's why we started with it. Snort 3 has some huge advantages when it comes to performance and policy and how it's applying things and processing the flows.

Dynamic Objects have also been really critical. They're very valuable. Version to version, they're adding a lot more features onto Dynamic Objects, and I'm a big fan. 

I've also used the Upgrade Wizard quite a bit to upgrade the firmware. 

And on the management side, there are the health modules. They added a "metric ton" of them to the FMC [Firepower Management Center]. In version 6.7 they released this new health monitor which makes it a lot easier to see data and get to information faster. It's quite nice looking, as opposed to CLI. The new health modules really do stand out as a great way to get to some of that health data quickly—things like interface information, statistics, drops—that were harder to get to before. I can now see them over time, as opposed to at just a point in time. I've used that a lot and it has been very helpful.

In addition, there is the global search for policy and objects. I use that quite a bit in the search bar. It's a great way to get some information faster. Even if I have to pivot away from the screen I'm on, it's still great to be able to get to it very quickly there. 

In a lot of ways, they've addressed some of the biggest complaints, like the "housekeeping" stuff where you have to move around your management system or when it comes to making configuration changes. That has improved from version to version and 7.0 is different. They've added more and have made it easier to get from point A to point B and to consume a lot of that data quickly. That allows me to hop in and do some data validation much faster, without having to search and wait and search and wait. I can get to some of that data quicker to make changes and to fix things. It adds to the overall administrator experience. When operating this technology I'm able to get places faster, rather than it being a type of bottleneck.

There is also the visibility the solution gives you when doing deep packet inspection. It blows up the packet, it matches application types, and it matches web apps. If you're doing SSL decryption it can pinpoint it even further than that. It's able to pull encrypted apps apart and tell me a lot about them. There's a lot of information that 7.0 is bringing to the forefront about flows of data, what it is, and what it's doing. The deep packet inspection and the application visibility portion and Snort are really essential to managing a modern firewall. Firepower does a bang-up job of it, by bringing that data to the forefront.

It's a good box for visibility at the Layer 7 level. If you need Layer 7 visibility, Firepower is going to be able to do that for you. Between VLANs, it does a good job. It's able to look at that Layer 7 data and do some good filtering based on those types of rules.

I'd like to see Cisco continue its approach to making it easier to navigate the UI and FMC and make it easier to get from point A to point B. Generally, the room for improvement is going to be all UI-related. The platform, overall, is solid.

I'd also like them to continue to approach things from a policy-oriented perspective. They are moving more and more in that direction. 

Also, the change-deployment time can always be improved. Even at 50 seconds, it's longer than some of its competitors. I would challenge Cisco to continue to improve in that area. It's very reasonable at 50 seconds, it's not like it used to be in early versions of Firepower, where it was around seven minutes. Still, it could be quicker. The faster we can deploy changes, the faster we can roll back changes if we have messed something in the configuration. Low deploy times are really good to have. 

I would also like to see more features that will help us connect things to the cloud dynamically, and connect things to other sites dynamically. There should be more SD-WAN features in the boxes. If I can use one box to solve cloud connectivity problems, and not have to do stuff so statically, the way I have to do things today on them, that would be helpful.

I am a Cisco partner and reseller and I actually beta test for the Firepower team. I work on Firepower boxes and have done so since the beginning. I have customers on Firepower 7.0 and I have been using Firepower 7.0 since its release.

I haven't really had any major complaints or issues with Firepower 7.0 stability.

It scales, but it depends on the growth rate of the customer and the amount of bandwidth. It's usually a speed and feed problem: Is the firewall box big enough to handle the traffic? Snort 3 has made some improvements there and it's even given some life back to older boxes because of improvements in code and in how Snort processes data. But, overall, the box just has to be big enough for the amount of traffic you're trying to shove through it.

I've been doing this a long time and I don't usually need to call tech support. But when I do need to call TAC, after working with a lot of the other vendors out there, Cisco TAC is still one of the best technical resources in the market. I do like TAC. That's not to say that every TAC engineer is great, but comparatively, they're one of the best support organizations.

Neutral

The initial setup is straightforward, with the caveat that I've been doing this for a long time, so for me it is simple and makes sense. But it is pretty straightforward. You have overall policies that wrap up into your access policy, which is the base policy. You have DNS policies that will roll right up into it. Likewise, platform policies get attached to devices. Generally speaking, it's a lot of working through the logic of the rules: How do you want to block stuff, and how do you want to permit stuff? A lot of that is normal firewalling. When I say the setup is simple, it's because it involves normal firewalling issues. You have to deal with routing, NAT rules, ACLs, and VPNs. It's a matter of just kind of working through those same things that every firewall has to solve.

The deployment time depends on the customer and how many rules. If we're building out all their rule sets, it could range from 40 hours to hundreds of hours. It also depends on what we're coming from. We're not generally walking into environments that are green, meaning there's no box there today. It's almost always that there's something else there that we're replacing. We have to take what we're coming from, convert it, and then put it on Firepower. Small businesses might have a couple of rules, enterprises might have hundreds of rules.

Our implementation strategy is to go in, document the current state of the environment, and then work on a future state. We then work through all the in-between stuff. When we have the old firewall configuration, we determine what it will look like on the new firewall configuration. Does the firewall configuration need to be cleaned up? Are there things that we can optimize and improve or modify? A lot of it involves copying configuration from the old platform to the new one. We're usually not trying to change a ton in a firewall project because it increases the risk of problems arising. Usually, customers' networks are operating when we get into them. We prefer to do a cleanup project after implementation, but sometimes they coincide.

In our company, one person can usually do a firewall cutover. And maintenance of Firepower 7.0 usually requires one person. Maintenance will usually involve a firmware upgrade.

There is a lot of value with SecureX. Other customers struggle to bring all the data back to one place, the way you can with SecureX, across a product portfolio. The value of that capability is incredible. I don't know how to put a monetary value on it, but from an operational perspective, it's very helpful to have it all back in one place because you're not having to hop around to multiple UIs to find the data you're looking for.

With any vendor, prices are often a little bit negotiable. There are things like discounted rates. There's a list price and then, as a partner, we get a discounted rate based on how much product we're purchasing and our relationship with the vendor. 

But on the list-price side of things, there are three big licenses on an FTD [Firepower Threat Defense] box. There are the malware license, the threat license, and the URL filtering license. You can license them in one-year, three-year, and five-year increments. Each license will enable different features on the box. The malware license will enable AMP filtering or AMP detection. The threat detection enables use of the IPS solution, which is really Snort's bread and butter. And the URL filtering enables filtering based on URL categories.

Sometimes we use URL filtering and sometimes we don't. It depends on the customer and on whether they have a different URL filtering strategy, like Umbrella. The two big ones that we sell are malware and threat detection, with threat detection probably being the license we sell the most.

SMARTnet, the technical support component, covers the box. When you purchase the hardware, you buy it with SMARTnet. Licenses cover features, SMARTnet covers support.

We continue to support, integrate, and sell three out of the major four vendors: Palo Alto, Fortinet, and Cisco. Every vendor has been a great partner with us, so I don't want to showcase one firewall platform over another.

Palo Alto is arguably the most mature out of the group when it comes to the firewall in general, but they've also been developing on the same platform for quite a long time.

FortiGate, on the other hand, is great in a lot of use cases.

Cisco's strength is how it integrates with the security portfolio at Cisco. When you have a lot of other security products or integrations, Firepower really stands out above the rest. Palo Alto and Fortinet, although they can integrate with SDA to some degree, they don't integrate to the same depths as Firepower. You really start to see the benefits of Firepower in your organization when you're looking at the Cisco security stack. That's what I would argue is one of the biggest benefits of Cisco in general, that stack of products.

With Cisco, it's not necessarily about a single piece, it's definitely about how they all can communicate and talk to each other, and how information is shared between the components, so that you can create a unified approach to security. Their SecureX product is an integration point. It brings together a lot of that information from different product lines in one place. That's really Cisco's game. Some of the other security vendors struggle to keep up with the breadth and depth of what Cisco is doing in all those different spaces.

In terms of ease of management, Firepower is an enterprise product. While FDM [Firepower Device Manager] is really easy to use, FMC has a lot more knobs to turn. Comparing FortiGate to FMC, a lot of the capabilities of FortiGate are still at the CLI level only. Palo Alto is 100 percent UI-based, not that you can't configure a Palo Alto from CLI, but I don't think anybody does that.

My advice is that you need to know your flows. If you're upgrading to Firepower, you should know what traffic matters and what traffic doesn't matter. If you really want to be successful, you should know all the flows of traffic, how they function, what they do. That way, when you get the box up and running, you know exactly how it should operate.

You can split Firepower users into two buckets: help desk and admin. Help desk will usually be read-only and admin will be read-write. If there's one engineer at a customer, he might have admin rights. If there's a help desk and one senior firewall guy, he might have admin rights where his help desk has read-only. It varies by the size of the customer. Most midsize organizations have one or two firewall guys. When you get into the big enterprises, the number goes up.

Regarding Firepower's Snort 3 IPS allowing you to maintain performance while running more rules, the "book answer" is yes, it's supposed to. We're not really running Snort 3 a ton on those yet because of some of the risk and because some of those customers haven't upgraded to 7.0 yet. Those that are on Snort 3 are just not running policy sets that are large enough that to notice any major or even minor improvements. I have seen an uptick in performance improvements with Snort 3, even on firewalls that are not 100,000-rule firewalls. We are seeing improvements with Snort 3. It's just that Snort 2 performance hasn't really affected the box overall, it just runs a little hotter.

When I mentioned the risk for Snort 3 for our larger clients, what I meant is that with new things come new risks. Snort 3 is one of those new things and we have to evaluate, when we upgrade a customer to it, whether the risk of the upgrade warrants doing it for the customer. In some cases, the answer is no, because of burn-in time. With some of our riskier locations or locations that require 24/7, it makes more sense to run Snort 2, which has been out there since forever on the Firepower platform. It's a lot more stable on Snort 2 and the problems are known problems, from a design perspective. We've mitigated those and worked around them. With Snort 3, there could be new bugs or problems, and in some environments, we want to mitigate that risk.

My expectation is that by 7.1 or 7.2 we will upgrade more generally to Snort 3. It's not that it's far away. It's just that with 7.0 being the first release of Snort 3, and 7.0 only having one or two patches under its belt, we thought it better to remove some risk and just use Snort 2.

Cisco Secure Firewall helps to reduce firewall operational costs, depending on the firewall vendor it's replacing. In some cases, customers are coming from old platforms where the security wasn't nearly at the same level as a next-gen firewall, so the advantage of moving to a next-gen firewall is the increase in security. But that comes with an operational burden no matter the firewall type. There is a lot more visibility and capability out of the NGFW platform, but it comes at a cost. There's more data to work through and more things to configure. Still, in most cases, Cisco Secure Firewall is going to decrease operational usage with the caveat that it has to be an "apples-to-apples" situation, which is very hard to come across these days. 

We are using Firepower for outbound/inbound traffic control and management as well as for our internal security. We are using it for LAN security and VMware network security. It is a hardware device, and it is deployed on-prem.

Our target is to make our network 100% secure from the outside and inside traffic. For that, we are using the latest versions, updates, patches, and licenses. We have security policies to enable ports only based on the requirements. Any unnecessary ports are disabled, which is as per the recommendation from Cisco. For day-to-day activity monitoring and day-to-day traffic vulnerabilities, we have monitoring tools and devices. If there is any vulnerability, we can catch it. We are constantly monitoring and checking our outside and inside traffic. These are the things that we are doing to meet our target of 100% security.

We have a number of security tools. We have the perimeter firewalls and core firewalls. For monitoring, we have many tools such as Tenable, Splunk, etc. We have Cisco Prime for monitoring internal traffic. For malware protection and IPS, we have endpoint security and firewalls. The outside to inside traffic is filtered by the perimeter firewall. After that, it goes to the core firewall, where it gets filtered. It is checked at port-level, website-level, and host-level security.

We have the endpoint security updated on all devices, and this security is managed by our antivirus server. For vulnerabilities, we have a Tenable server that is monitoring all devices. In case of any vulnerability or attacks, we get updated. We are also using Splunk as SIEM. From there, we can check the logs. If any device is attacked, we get to know the hostname or IP address. We can then check our monitoring tool and our database list. We can see how this attack happened. We have configured our network into security zones. We have zone-based security.

It integrates with other Cisco products. We use Cisco ASA and Cisco FTD, and we also use Cisco FMC for monitoring and creating policies. For internal network monitoring purposes, we use Cisco Prime. We also use Cisco ISE. For troubleshooting and monitoring, we can do a deep inspection in Cisco FMC. We can reach the host and website. We can also do web filtering and check at what time an activity happened or browsing was done. We can get information about the host, subnet, timing, source, and destination. We can easily identify these things about a threat and do reporting. We can also troubleshoot site-to-site VPN and client VPN. So, we can easily manage and troubleshoot these things.

Cisco FMC is the management tool that we use to manage our firewalls. It makes it easy to deploy the policies, identify issues, and troubleshoot them. We create policies in Cisco FMC and then deploy them to the firewall. If anything is wrong with the primary FMC, the control is switched to a secondary FMC. It is also disconnected from the firewall, and we can manage the firewall individually for the time being. There is no effect on the firewall and network traffic.

Cisco FMC saves our time in terms of management and troubleshooting. Instead of individually deploying a policy on each firewall, we can easily push a policy to as many firewalls as we want by using Cisco FMC. We just create a policy and then select the firewalls to which we want to push it. Similarly, if we want to upgrade our firewalls, instead of individually logging in to each firewall and taking a backup, we can use Cisco FMC to take a backup of all firewalls. After that, we can do the upgrade. If Cisco FMC or the firewall goes down, we can just upload the backup, and everything in the configuration will just come back. 

We can also see the health status of our network by using Cisco FMC. On one screen, we can see the whole firewall activity. We can see policies, backups, and reports. If our management asks for information about how many rules are there, how many ports are open, how many matching policies are there, and which public IP is there, we can log in to Cisco FMC to see the complete configuration. We can also generate reports.

With Cisco FMC, we can create reports on a daily, weekly, or monthly basis. We can also get information about the high utilization of our internet bandwidth by email. In Cisco FMC, we can configure the option to alert us through email or SMS. It is very easy.

It has a good security level. It is a next-generation firewall. It can protect from different types of attacks. We have enabled IPS and IDS. To make out network fully secure, we have zone-based security and subnets.

It is user-friendly with a lot of features. It has a CLI, which is helpful for troubleshooting. It also has a GUI. It is easy to work with this firewall if you have worked with any Cisco firewall.

With Cisco FMC, we can see the network's health and status. We can create a dashboard to view the network configuration, security policies, and network interfaces that are running or are up or down. We can also see network utilization and bandwidth utilization. We can see if there are any attacks from the outside network to the inside network. We can arrange the icons in the dashboard. For troubleshooting, we can also log in to the FMC CLI, and based on the source and destination, we can ping the firewall and the source. 

I have been using this solution for three to four years.

It is stable, but it also depends on whether it is properly configured or maintained. If you don't apply the proper patches recommended by Cisco, you could face a lot of issues. If the firewall is up to date in terms of patches, it works smoothly and is stable.

There are no issues in terms of the number of users. This is the main firewall for the organization. All users are behind this firewall. So, all departments and teams, such as HR, finance, application team, hardware teams, are behind this firewall. All users have to cross the firewall while accessing applications and websites. They cannot bypass the firewall. 

Their support is good. If we have an issue, we first try to resolve it at our level. If we are not able to resolve an issue, we call customer care or raise a ticket. They investigate and give us the solution. If there is a hardware issue or the device is defective, we will get that part as soon as possible. They replace that immediately. If it is not a hardware issue, they check the logs that we have submitted. Based on the investigation, they give a new patch in case of a bug. They arrange for a technical engineer to come online to guide us and provide instructions remotely. They provide immediate support. I would rate their support a nine out of 10.

We have HA/standby devices. We have almost 70 to 80 access switches, and we have 30 to 40 routers, hubs, and other monitoring tools and devices. We keep one or two devices as a standby. We have a standby for each Cisco tool. We have a standby for the core and distribution switches and firewalls. We have a standby firewall. When there is any hardware issue or other issue, the secondary firewall is used, and the workload moves to the secondary firewall. Meanwhile, we work with Cisco's support to resolve the issue.

For the past four to five years, we have only had Cisco firewalls. However, for some of the branches, we are using Palo Alto firewalls. It depends on a client's requirements, applications, security, etc.

I didn't do the implementation. We have, however, upgraded to a higher version. From the Cisco side, we get the updates or patches using which we upgrade a device and do the configuration. We register the product model and serial number, and after that, we can download a patch. We also can get help from Cisco. It is easy to migrate or upgrade for us.

We have vendor support. They are a partner of Cisco. When we buy the hardware devices, the vendor has the responsibility to do the implementation and configurations. We do coordinate with them in terms of providing the space and network details such as IP addresses, network type, subnets, etc. We also provide logical diagrams. We monitor the configuration, and after the configuration is done, we check how the network is working and performing.

We have an IT department that includes an applications group, a hardware group, and a security group. There are also Network Level 1, Level 2, and Level 3 teams. The Level 1 team only takes care of the network side. The Level 2 and Level 3 teams do almost similar work, but the Level 3 team is a bit at a higher level in IT security. The Level 2 and Level 3 teams take care of firewalls-level and security-level configuration, policy upgrade, etc. They manage all network devices. Overall, we have around 20 members in our department.

For the maintenance of Firepower, two guys are there. A Level 2 engineer takes care of policy creation and deployment for new networks. A Level 3 engineer takes care of a new firewall, upgrades, and network design and architecture.

When we purchased the firewall, we had to take the security license for IPS, malware protection, and VPN. If we are using high availability, we have to take a license for that. We also have to pay for hardware support and technical support. Its licensing is on a yearly basis.

It is a good product. It is easy to manage, but you need to have good experience and good knowledge, and you need to configure it properly.

Cisco FMC only supports Cisco products. If you have a large network with Cisco firewalls and other vendors' firewalls, such as Palo Alto, you can only manage Cisco products through Cisco FMC. Other vendors have their own management tools.

Most of the organizations nowadays are using the Cisco Firepower and Cisco ASA because of the high level of security. Cisco is known for its security. Cisco provides a lot of high-security firewalls such as Cisco ASA, Cisco FTD, Cisco Firepower. Cisco ASA 8500 came out first, and after that, new models such as Cisco FTD came. 

I would rate Cisco Firepower NGFW Firewall a nine out of 10. It is excellent in terms of features, ability, and security. Whoever gets to work on Cisco Firepower, as well as Cisco ASA, will get good experience and understanding of security and will be able to work on other firewalls.

One of the things that we have solved the most with this solution is the P2P connection that we have with different clients. It gives us greater connection security with good management of the configured rules. 

Likewise, it has made it easier for us to have this type of equipment under monitoring, and, since we have implemented them, we have not been presented with any performance problems in the equipment as they have not presented CPU or RAM saturation or that for some reason it fails without any cause. We all have them managed and monitored. We always receive an email notifying us if there's something that the equipment has detected as well.

The ASA firewalls have undoubtedly helped us to improve our infrastructure throughout the corporation and currently we have just over 50 firewalls - all of them in different parts of Mexico. 

This infrastructure has been improved since, in our corporation, we handle the dynamic EIGRP protocol, which Cisco owns, and this solution has given us a geo-redundancy in our company. In case of presenting a problem with a firewall or a link, it performs an immediate convergence where end-users do not detect a failure, helping us to maintain a 99.99% operational level at all times.

I am very happy to use this type of Cisco equipment in my infrastructure. It has given us the most value is the management of dynamic routing, in this case, EIGRP. This protocol, together with a series of additional configurations, has helped us to maintain an automatic redundancy in all our infrastructure, keeping us with very high numbers of operability and without failures that take more than 1 minute or that have not been resolved automatically. With this solution, we only speak with our suppliers either for a link or equipment report, and even if the box or circuit is out of operation, the operation continues to work without problems.

Today, ASA firewalls are leaving the market and are being replaced by firepower equipment - a technology with which I am not very familiar. However, in the training or research, I have done on this new product, I see that it has many additional tools such as centralization of the administration through a single team (in the case the firepower management). It is something that we do not have, yet we are already considering it since this type of technology will help us to have better management and better administration of the equipment through a single platform. The management of additional services with this new module will certainly help us to have the internet network much more secure with connections to the outside.

I've used the solution for more than seven years.

The solution is great in terms of stability.

The scalability is great.

Technical support is great.

We previously used Fortigate.

The initial setup was not complex.

We handled the implementation in-house. 

We've seen an 80% ROI.

Cisco is not cheap, however, it is worth investing in these technologies.

We always evaluate various other options.

We are using it as a firewall for our data center and headquarter. We are also using it for DR. We are using Cisco ASA 5500 Series.

It is a security device, and it is useful for securing our environment. It provides role-based access and other features and helps us in easily securing our environment.

It provides visibility. It has been helpful for packet inspection and logging activities for all kinds of packets, such as routing packets, denied packets, and permitted packets. All these activities are visible on Cisco ASA. There are different commands for logging and visibility.

We use Cisco ASA for the integration of the network. Our company is a financial company, and we are integrating different organizations and banks by using Cisco ASA. We are using role-based access. Any integration, any access, or any configuration is role-based. 

The remote access, VPN, and ACL features are valuable. We are using role-based access for individuals.

IPS is also valuable for intrusion detection and prevention. It is a paid module that can be added. I'm using it for security, VLAN management, segregation management, and so on.

It is easy to use. In our region and our country, Cisco is well known, and most of the companies are using Cisco products. We have been using Cisco devices for a while, and our company primarily has Cisco devices. So, we are familiar with it, which makes it very easy to use for us. Even when we compare it with other products, it is easier to use.

It is easy for us to manage it because it is a familiar product, and it has been a part of our environment. Now, other products are providing free training, free access, and free license, because of which things are changing. So, you can easily become familiar with other products.

Its licensing cost and payment model can be improved. Cisco doesn't provide training and certification for engineers without payments. Other companies, such as Huawei, provide the training for free. Their subscription and licenses are also free and flexible. Other products are breaking the market by providing such features. 

It doesn't support all standard interfaces. It is also not suitable for big companies with high bandwidth traffic. Its capacity should be improved.

Other products are becoming easier to access and configure. They are providing UI interfaces to configure, take backup, synchronize redundant machines, and so on. It is very easy to take backup and upgrade the images in those products. Cisco ASA should have such features. If one redundant machine is getting upgraded, the technology and support should be there to upgrade other redundant machines. In a single window, we should be able to do more in terms of backups, restores, and upgrades.

We have been using this solution for almost eight years.

It is stable. It needs to be configured based on the standards and functionality. We have one device that has been working for more than 10 years, which indicates it is stable, but it requires licenses to upgrade features.

It doesn't have an expansion card. So, it may not scalable for huge buildings. It also lacks a lot of standard interfaces. Other products are providing capacity for a data center. Other technologies are expanding their interface bandwidth from 10 gigs. In my opinion, Cisco ASA doesn't have this capability.

Their support is very good. We have a support license, so their support is very good. They are tracing us and following up with us to solve the problem on time.

Its setup is easy. We are familiar with Cisco ASA and other Cisco products, and they are easy to configure. A lot of resources are available on the internet, so it is easy to set up for anyone with basic training. It is easy in different types of environments, such as universities and colleges.

It generally doesn't take more than a day, but it also depends on the size of the organization. If an organization is very big and if you need a line-by-line configuration for access role and VPN, it can take a bit more time.

Cisco is constantly upgrading and providing features based on current requests. We usually plan deployments at the end of the year and at the beginning of the year. Everyone plans for new products, new configurations, and new expansions based on that.

Any security product provides a return on investment. Any gap in security may cost an organization more.

It is expensive. There is a cost for everything. There is per year license cost and support cost. There is also a cost for any training, any application, and any resource. Things are very costly to do with Cisco.

Other brands are cheaper. They are also more flexible in terms of training, subscription, and licensing. They give lots and lots of years free. They provide more than Cisco.

I would advise understanding its features, advantages, and disadvantages as compared to other solutions. It is simple, but its cost is a negative point. 

I would rate Cisco ASA Firewall an eight out of 10.

We primarily use the solution in order to create access rules. That's what I use it for mostly. Sometimes, if I need to do some mapping, I may also leverage this product.  

In terms of access, the solution is great at making sure that the firewall has the right IPs, or that the right IPs are passing through where they should be. 

The product does a good job of making sure that the connection is one that the user can trust. It keeps everything secure.

From what I've already done with ASA, I've noted that it's a very simple solution. 

It is a very user-friendly product. I started with the GUI version. There are different versions. You could have the CLA, and the GUI version if you like. Both are really user-friendly and they're easy to learn. 

We haven't been working with the product for too long, and therefore I haven't really found any features that are lacking. So far, it's been pretty solid.

One of the things that would make my life easier on ASA, especially for the CLA, is if it had an ASBN feature, specifically for the CLA. This would allow you to be able to see at once where a particular object group is being used without having to copy out all the object groups that have already been created.

I don't have to see all the object groups that have been created on that firewall. That's just something that I would really appreciate on the CLA, even though it already exists on the GUI.

I've been using the solution for six months now. It's been less than a year. It hasn't been too long just yet.

The solution has been quite stable.

Most of the clients that we deal with use this solution. No one has ever complained about having a breach or anything, to the best of my knowledge, even though we see some people combine different firewalls together, and use them alongside Cisco ASA. So far, we've not had any issue with Cisco ASA. It's reliable and keeps our clients safe.

I've never tried to scale the product. I haven't worked with it too long at this point. I wouldn't be able to comment on its scalability potential.

I've never dealt with technical support yet. I can't speak to their level or response or their knowledge of the product.

In the past, I've worked with Check Point and Fortinet as well.

I've been handling the implementation. So far, it's been good, even with no prior knowledge of the solution itself. It's my first time working with it.

On my team, lots of people are working on different aspects, and most of the setup is being done by those that have more knowledge about the firewall than we have. We don't have anything to do with the setup, we just make sure that we implement whatever connections the clients already have. It's already broken down that way, just to avoid as many mistakes as possible.

We already have a process for implementation based on the number of connections. The maximum we normally work on each connection is maybe 20 to 30 minutes. However, the process could be as little as one minute. It depends on how many connections we want to add at a time.

We're handing the implementation via our own in-house team.

I'm just handling the implementation and therefore don't have any insights on the pricing aspect of the solution. I wouldn't be able to say how much the company pays or if the pricing is high or low.

That said, the pricing isn't an issue. It's more about what's best for the customer or the client. We want to give the client the best service, and very good protection. If a client begins to worry about pricing, we can't exactly guarantee the same level of safety.

Our company has a partnership with Cisco.

We have different clients and therefore use different versions of the solution. Nobody wants to use an out-of-date version, and therefore, we work to keep everything updated.

Overall, I would rate the solution at a nine out of ten.