Cisco Secure Firewall Reviews

Remote access through the VPN wasn't available in the old firewall that we used, so that was a value-add. That's one way Cisco ASA has impacted our company. Also, from an administrator's perspective, newcomers have a shorter learning curve working with the ASA firewalls.

Also, when we deployed it on the data center firewalls, we did some microsegmentation using different subnets for the whole environment, including UAT and production. We didn't have segmentation before, but with the growing security needs, we segmented the servers. For each of the subnets we made different gateways on the firewall. That helped us achieve the requirements of the latest standards.

Thanks to the IPS, the malicious traffic has dropped. Initially, when we deployed the IPS, it gave us some problems. But after a week or two, it worked very well. I used a balanced security policy when I integrated it with the FMC server. On the FMC, the GUI gives me a very good, extensive view of what traffic is getting dropped and at what time. It gives me all the visibility that I need.

• The normal firewalling features are very good. You can easily create objects and work with them. 
• The AnyConnect software for remote VPN is an added feature on the firewall that works very well in our environment.
• The IPS is another important feature that I use. It doesn't impact the overall performance of the ASAs.

All of these features work fine.

Cisco ASA works very nicely from an administration perspective. The management of the device is very nice. The ASDM (Adaptive Security Device Manager) is the software that we use and it is very easy to configure using the GUI. If you are familiar with the ASDM software, it's very easy for anyone to handle. The CLI isn't different from other Cisco CLIs, so that makes it easy as well.

Also, the visibility when doing packet inspection on the ASA, using the ASDM GUI, works well. You can go to the monitoring part and see the live logs, the syslogs. All the traffic events are displayed in the syslog. You can filter on whatever event you are interested in and it is visible to you in no time. It provides a real-time display of the traffic. Troubleshooting issues is very easy using ASDM. 

In addition, if you want to do some captures at the interface level, there's a packet tracer, a tool within the ASDM and the ASA, which is available on both the GUI and the CLI. That is on the newer firewalls as well and it's very nice. It shows you the life cycle of a packet within the firewall, from entry to the exit, and how many steps it goes through. It really helps while troubleshooting. I'm very satisfied with that.

The operation of the ASA is good but the problem is that whenever you require an upgrade, there are multiple pieces of software that you have to upgrade. Extensive planning is required, because if you upgrade one piece of the software it has to be compatible with the others as well. You always need to check the compatibility metrics.

For example, if the ASA Firewall's software has to be upgraded, it has to be compatible with the IPS software—the FireSIGHT software. So that has to be upgraded as well, in addition to the ASDM software that you use to manage the firewall using the GUI. Besides that, if you are using the remote VPN part of the firewall, there is the AnyConnect hidden software that also requires an update.

So upgrading is a very extensive exercise, both when you're planning it and when you are doing it. The upgrades are very lengthy. Then Cisco introduced FTD as a unified approach, and that was a leap forward, but it has its own issues.

I've been working as a Cisco partner for about four years. Before that, I was using Cisco firewalls as a network admin. I've been engaged with Cisco firewalls since 2015.

On the FTD (Firepower Threat Defense) model, I've been working with version 6.7. I haven't tried the latest 7.0 version.

The robustness of the ASA is very good. Whenever you upgrade it, it does very well. There are no hiccups or hitches, post-upgrade.

Cisco's TAC provides very good support. If you have any issues, you can contact them and they provide assistance. You need a subscription for that. The subscription comes with a notable cost but you get great value from it. I'm very satisfied with it. 

The tech support of Cisco is unparalleled if I compare it to any other product that I have used. I've been using Citrix, Juniper, and even Palo Alto, but the support that I get from Cisco is very good. It's easy to get support and the engineers get engaged. Sometimes they provide more than you need. For example, if there are design-level issues, they will tell you that it isn't implemented well and that there are things that need to be corrected. That's not their responsibility but they'll provide that feedback.

I consider Cisco support to be the industry standard.

I've seen Cisco deployed for five to seven years. The product life cycle is good and they're continuing to support things. If you add more features and utilize it to the maximum, using the remote VPN and the like, it becomes more cost-effective. 

Having the IPS part within one box also saves you on costs. Back in 2015, the IPS was a different box that had to be deployed separately. At that time, it cost more if I had to buy another IPS and a box.

Before ASA, we were using Juniper. It had a GUI, but the CLI part of Juniper was difficult. The network administrators required a little bit of a different type of expertise. Juniper was very good, but its CLI wasn't as simple as Cisco's. When somebody new comes into the company to work on the firewall, the Cisco learning curve is relatively short and easy.

Nowadays, everybody is working with Cisco. Juniper has almost been phased out. Some people use Juniper for certain reasons, but there's a very specific clientele for it.

We went with Cisco because it is very easy to operate. It provided next-generation firewalling when it came out with ASA plus Sourcefire IPS. That was very effective at that time, compared to the others.

These days, Palo Alto is matching Cisco and, in some ways, Palo Alto is better. From 2015 to 2018/19, Cisco was considered to be the best. The security leaders are always preferred and Cisco was a leader. That's why we preferred it.

We were also always happy with Cisco support. It was very convenient to get to Cisco support, and it was very prompt and effective. They really solved our problems.

The Nextgen firewalls have a good IPS, but that IPS part wasn't very configurable using the ASDM. Later, they introduced the FMC (Firewall Management Center) and we could integrate the ASA with the FMC and get the IPS configured from the FMC GUI. That was good, but you needed two things to monitor one box. For the IPS you needed an FMC server, and for the firewalls, you needed the ASDM or the CLI.

In terms of integration with other solutions, it is a simple firewall that is integrated with the syslog servers and the SNMP monitoring from the NMS. Those types of simple things work very well. I haven't worked with much integration beyond that. You can't attach that many feeds to it. That's more a function of the Next-Generation Firewall with the IPS and FMC.

SecureX is a relatively new cloud-based solution. It's been around for one or two years. It's offered for free if you have any Cisco security solution. It encompasses ADR and NDR. The clients I work with in Pakistan are mostly financial institutions. Because it's a cloud-based security solution, they are not interested. They want on-prem solutions.

It is the primary data firewall for our organization and our data centers.

We have faced multiple issues regarding bugs with Cisco Firepower products. A running product is hit with bugs most of the time, and we had a lot of challenges in using the Cisco Firepower product, actually. In the future, we are planning to replace it, or at least use it instead as a secondary firewall.

The content filtering is good. 

The maturity needs to be better. The product is not yet mature. A running product is hit with the software bugs most of the time, and whenever we then log a case with the tech team, they're sometimes helpless with that. They have to involve the software development team to fix that bug in the next release. It's not ideal. Being an enterprise product, it should be mature enough to handle these types of issues.

I've been using the solution for the last three years. 

The performance is okay, however, the product is not stable. It is all hit with CVL software bugs routinely. That portion requires attention from Cisco and the tech support in this area is somewhat delayed. An open ticket can sometimes take more than two to three months to resolve. For the production setup, it is tough to rely on the tech team alone for the closure of the case.

The solution is very scalable. 

Cisco support is always available. However, multiple times, it has been tough for them to fix the software bugs in the product. They have to then deploy their development team for the same ticket.

Earlier we used the Cisco ASA Firewall. Now, it has been phased out. Firepower is categorized as the next-generation firewall, however, we haven't found the utility of that level in this product. It lacks maturity at many levels.

We have two data centers at two geographical locations. We have two firewalls - one in one data center, at the perimeter, and another at a different location.

The initial setup was okay. We had more of an in-between partner doing the installation part since the product was also new to us. The product was part of my overall product solution. We procured a firewall and another ACL fabric portion for the data center. Overall, the solution installation took over seven to eight months.

We had two people assist with the deployment process. 

We used an integrator for deployment. Overall, the experience was positive. 

There is no ROI. It is functioning as a normal firewall, as a data center perimeter, however, we expected much more than that. At times, there has been downtime with the firewall, and our custom modifications have won at a very high level. The product has to be mature when it is being used at the enterprise level.

The solution offers mid-range pricing. We can get a cheaper product like Fortinet, and we can get a costlier product like Palo Alto, and these are all in the same category.

There's only one license based on the support. Cisco Firepower is priced on the support of the product that we require: with SSL and without SSL. Currently, we are not doing any SSL inspection. We have an ATP report firewall.

When we were looking for a product, we put it through tender and we put out specifications of the product that we required. Cisco had the lowest price. We evaluated the L1 after it was technically qualifying. That is how we acquired it.

We looked at Palo Alto, however, it was far too costly.

We are a customer and an end-user. 

It was earlier named Sourcefire. Cisco acquired that company and rebranded it as Firepower.

We are actually a public cloud provider. We offer data center services to clients.

I'd advise others considering the solution that, for implementation, the product needs some stability and maturity to be offered as a next-generation firewall at an enterprise level. If a company is in need of an enterprise-level solution, they need to be aware of this.

I'd rate the solution a five out of ten. 

The product needs maturity in terms of running without hitting a bug. We have used other products also. A running product is never hit with a bug. It is normally some vulnerability or something that needs to be attended to, however, a running product is seldom hit with a bug and the operation gets stalled. We rarely find this kind of thing in an enterprise scenario. That is what we ask from Cisco, to build a stable product before offering it to customers.

We have multiple use cases for Cisco Firepower. We have two types of use cases:

• Protect the perimeter of the enterprise.
• Inter-VRF zoning and routing. 

The goal is to have some Firewall protection with a Layer 7 features, like URL filtering, IPS, malware at the perimeter level as well as inspecting the traffic going through that firewall, because all traffic is encrypted. We want visibility, ensuring that we can protect ourselves as much as we can.

In production, I am currently using Cisco Firepower version 6.7 with the latest patch, and we are starting to roll out version 7.0.

I have multiple customers who are running Cisco Firepower on-prem. Increasingly, customers are going through the cloud, using Cisco Firepower on AWS and Azure.

We are implementing Cisco Firepower at the Inter-VRF level so we can have some segmentation. For example, between ACI and all the Inter-VRF being done through Firepower, we are able to inspect local east-west traffic. It is great to use Cisco Firepower for segmentation, because on the Firepower, we now have a feature called VRF. So, you can also expand the VRF that you have locally on your network back to the firewall and do some more tweaking and segmentation. Whereas, everything was coming into a single bucket previously and you had to play around with some features to make sure that the leaking of the prefixes was not advertised. Now, we are really working towards segmentation in terms of routing in Firepower.

The integration of network and workload micro-segmentation helps a lot to provide unified segmentation policies across east-west and north-south traffic. One concrete example is with Cisco ACI for the data center. Not only are we doing what is called a service graph on the ACI to make sure that we can filter traffic east-west between two endpoints in the same network, but when we go north-south or east-west, we can then leverage what we have on the network with SGTs on Cisco ISE. Once you build your matrix, it is very easy to filter in and out on east-west or north-south traffic.

Since SecureX was released, this has been a big advantage for Cisco Firepower. You can give a tool to a customer to do some analysis, where before they were doing it manually. So, this is a very big advantage. 

The IPS is one of the top features that I love.

The dashboard of the Firepower Management Center (FMC) has improved. The UI has been updated to look like a 2021 UI, instead of what it was before. It is easy to use and navigate. In the beginning, the push of the config was very slow. Now, we are able to push away some conflicts very quickly. We are also getting new features with each release. For example, when you are applying something and have a bad configuration, then you can quickly roll back to when it was not there. So, there have been a lot of improvements in terms of UI and configuration.

We saw a lot of improvements on Cisco Firepower when Snort 3 came along. Before, with Snort 2, we were able to do some stuff, but the bandwidth was impacted. With Snort 3, we now have much better performance.

I would like to see improvement when you create policies on Snort 3 IPS on Cisco Firepower. On Snort 2, it was more like a UI page where you had some multiple choices where you could tweak your config. On Snort 3, the idea is more to build some rules on the text file or JSON file, then push it. So, I would like to see a lot of improvements here.

I have been using Cisco Firepower for multiple years, around four to five years.

In terms of Firepower's stability, we had some issues with Snort 2 CPUs when using older versions in the past. However, since using version 6.4 until now, I haven't seen any big issues. We have had some issues, just like any other vendor, but not in terms of stability. We have had a few bugs, but stability is something that is rock-solid in terms of Firepower.

Cisco Firepower scalability is something that can be done easily if you respect the best practices and don't have any specific use cases. If I take the example of one of my customers moving to the cloud, there is one FMC and he is popping new Firepower devices on the cloud, just attaching them to the existing policy and knots. This is done in a few minutes. It is very easy to do.

When you open a ticket with Cisco tech support for Cisco FMC, you can be quite confident. Right away, the engineer onboarding is someone skilled and can help you out very quickly and easily. This is something that is true 90% of the time. For sure, you always have 10% of the time where you are fighting to get the right guy. But, most of the time, the guy who does the onboarding can right away help you out.

The initial setup and implementation of Cisco Firepower is very easy. I am working with a lot more vendors of firewalls, and Cisco Firepower is one of the best today. It is one of the easiest to set up.

The minimum deployment time depends on really what you want to do. If you just want to initiate a quick setup with some IPS and have already deployed FMC, then it takes less than one hour. It is very easy. 

What takes more time is deploying the OVA of Cisco Firepower Management Center and doing all the cabling stuff. All the rest, it is very easy. 

If you are working without a Firepower Management Center and using Firepower Device Manager with Cisco on the cloud, then it is even easier. It is like the Meraki setup, where you just plug and play everything and everything will be connected to the cloud. It is very easy.

If you configure Cisco Firepower, it has to be based on Cisco's recommendations. You can view all the traffic and have full visibility in terms of applications, support, URL categorization, and inspect malware or whatever file is being exchanged. We also love to interconnect Cisco Firepower with some Cisco ISE appliances so we can do some kind of threat containment. If something is seen as a virus coming in from a user, we can directly tell Cisco ISE to block that user right away.

I am working for a Cisco Professional Services Partner. We have only one guy deploying the devices. We don't require a big team to deploy it. In terms of configuration, it takes more people based on each person's skills because you have multiple areas: firewalls, IPS, knots, and routing. So, it depends on which skills will be required the most.

For maintenance on an average small to medium customer, it takes one to two people. When it is a big customer with multiple sites, you should have a small team of four to five people. This is because it is mostly not about creating the rules, but more about checking and analyzing the logs coming through Cisco Firepower Manager Center.

Whether Cisco Firepower reduces costs depends on the architecture that you are on. I had some of my customers answer, "Totally, yes," but for some of them that is not really true.

When we are fighting against other competitors for customers, whether it is a small or big business, we feel very comfortable with the price that Firepower has today.

I have worked with Palo Alto, Fortinet, and Sophos. I work a lot more with Palo Alto and Cisco Firepower. I find them to be very easy in terms of management operations. Fortinet is also a vendor where we see the ease of use, but in terms of troubleshooting, it is more complex than Firepower and Palo Alto. Sophos is the hardest one for me to use.

I love the IPS more on the Cisco Firepower, where you can do more tweaking compared to the other solutions. Where I love Palo Alto and Fortinet more compared to Firepower is that you still have CLI access to some configs instead of going through the UI and pushing some configs. When you are in big trouble, sometimes the command line is easier to push a lot more configs than doing some clicks and pushing them through the UI.

Compared to the other vendors, Firepower requires more deep dive skills on the IPS stuff to make it work and ensure that you are protected. If you go with the basic one in the package, you will be protected, but not so much. So, you need to have more deep dive knowledge on the IPS to be sure that you can tweak it and you can protect yourself.

Another Cisco Firepower advantage would be the Talos database. That is a big advantage compared to other solutions.

In terms of threat defense, we have a feature of TLS 1.3 that is free where we can see applications without doing any SSL inspection, which can increase the performance of the firewall without doing some deep dive inspection. At the same time, we keep some visibility of what application is going through. Therefore, we have a win-win situation if one wants to protect against some specific applications.

Do not just look at the data sheet that vendors are publishing. Sometimes, they make sense. But, in reality, these documents are made based on specific use cases. Just do a proof of concept and test every single feature. You will find out that Cisco Firepower is much better and more tweakable than other solutions.

When you start using Cisco Firepower Management Center, you need a few days to get used to it. Once you know all the menus, it is kind of easy to find your way out and analyze traffic, not only in terms of the firewall but also in terms of IPS or SSL decryption. Different users are split away who can help you to troubleshoot what you want to troubleshoot, not having everything in one view.

Today, the only use cases that we have for dynamic policies are leveraging the API on Cisco FMC to push some config or change the config. There isn't a feature built automatically on the FMC to build a new policy, so we are leveraging APIs.

I would rate Cisco Firepower between eight and nine. The only reason that I am not giving a full nine is because of the Snort 3 operations, where there is a need for improvement.

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using it for around 18 months.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our use for Cisco Secure is for the firewall. 

Network segmentation is the most valuable feature.

The dashboard can be improved. 

I have been using Cisco Secure Firewall for seven years. 

It is stable.

It is scalable. A thousand-plus users are using the solution in my company. 

The initial setup is straightforward. 

Pricing is high.

Overall, I rate the product an eight out of ten. 

I use the solution in my company for some internal testing purposes, so I don't use it in a real environment. I use it in my dummy lab environment.

The product's user interface is an area with certain shortcomings where improvements are required.

From an improvement perspective, the product's price needs to be lowered.

I have been using Cisco Secure Firewall for three years. I am a customer of Cisco.

I have faced no issues with the stability of the product. Stability-wise, I rate the solution an eight out of ten.

The product offers good scalability.

I rate the technical support a nine out of ten.

Positive

I have experience with Sophos.

The product's initial setup phase is a little difficult.

The product's deployment phase is a good and easy process.

The solution is deployed on the cloud.

The product is expensive.

I can't describe a particular scenario where the product has improved security, but I can say that the devices from Cisco are much more trustworthy and reliable compared to other devices in the market.

The most effective feature of the product for threat prevention stems from the granularity of the control that the devices from Cisco provide to its users.

The product offers great integration capabilities.

For our company's daily operations, the user interface provided by Sophos is much better and interactive compared to the one offered by Cisco.

You can choose Sophos if you want a low-budget or budget-friendly product. You can choose Cisco if you want a high-end and highly scalable tool with great integration capabilities, especially if budget is not an issue.

I rate the overall tool an eight out of ten.

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 Cisco Secure Firewall for remote VPN.

Cisco Secure Firewall played a crucial role in enabling all our users to establish remote connections from their homes.

Cisco Secure Firewalls' application visibility and control are beneficial because they provide a management console that allows us to view logging and sessions.

It enhances our organization's cybersecurity resilience by enabling us to deploy multiple instances of it both in Azure and on-premises. This redundancy ensures that in the event of an outage or any other issues, we can seamlessly switch to alternative locations.

Cisco Secure Firewall is reliable, which is why we opted for it during the pandemic for our remote users.

The cloud does not precisely mimic what is on-premises. There are some new challenges with the features in Azure. Due to Azure limitations, we cannot synchronize configurations between an active standby. This aspect makes it difficult to perform such tasks in the cloud, requiring manual intervention.

I have been using Cisco Secure Firewall ASA for ten years.

In my current role, I have not encountered any stability issues.

Cisco Secure Firewall is scalable.

Cisco's technical support is excellent, and its personnel are knowledgeable. I consistently receive prompt and satisfactory responses from them. However, there are occasions when we need to reach out to them for feedback follow-up.

Positive

We encountered some issues with the deployment because we run on Azure now. 

Although I am not directly involved in dealing with the pricing aspect of the Cisco Secure Firewall, I know that the licensing has improved over the years.

I rate Cisco Secure Firewall a nine out of ten.

The Cisco Secure Firewall is not a remediation tool but rather designed for secure remote sessions.

We use the same ASAs for firewall functionality as we do for VPN functionality.

Our organization is currently considering Palo Alto as an alternative to Cisco. However, I am not involved in the decision-making process.