Cisco Secure Firewall Reviews

We mainly use it for policy-based VPNs to IPSec one of the businesses. We also use it as a firewall solution for remote VPN users. We have vendors who have access to our VPN solution, and they get a dedicated network.

We can automate the VPN. The build process and how we've standardized it makes it very easy for us to focus on other tasks. We know that an end user can push a button, and the VPN will get built. They only bring us in for troubleshooting or higher-level issues with the other vendor. Because of that program, the ability to use Cisco ASA every time, in the same way, makes our job easy.

Once we started standardizing and using the same solution, we've been able to correlate that so we know what we are doing. We can train even less experienced and newer guys to do the tasks that in turn frees up the higher-level engineers. It has cut out the VPN work for higher-level engineers. They may have been spending ten hours a week previously, and now they may spend ten hours in the quarter.

It has improved our cybersecurity resilience. It has allowed us to see some differences with partners using weaker ciphers, which allows us to validate what we're using and reevaluate it. We put exceptions in cases where we have to. The security risk team is as well aware of those, and they can essentially go back on a buy-in or see if the vendor has upgraded to plug in a security hole. It has given us that visibility to see where we are weak with our vendors.

Being able to use it as a policy-based VPN is valuable. It's very easy to understand. 

It's very easy to troubleshoot. It may be because I'm comfortable with it or because I've used it for so long, but it's easy to use for me. I don't have any problems with how to set it up or use it.

For what we use it for, it ends up being the perfect product for us, but it would help if they could expand it into some of the other areas and other use cases working with speeding up and the reliability of the pushes from the policy manager.

We've been using Cisco ASA at least for the last six years. That's how long I've been in this organization, but my organization has been using it longer. 

We don't open bugs for it. It just works for what we've used it for. The last time we opened up an ASA bug would have probably been three years ago. From a reliability standpoint of what we're using it for, it's fantastic.

We've had no problems with scaling our business. We went from using probably 200 active VPNs an hour to over 600 VPNs without blinking an eye at that.

I enjoy Cisco's tech support. Just like any tech support out there, you could get a great or fantastic engineer, or you may get somebody who has just learned, so you just have to work with it. However, working with Cisco TAC, you find less of that than you do with other companies. 

Just to give them a shout-out, whenever we hit the Australian TAC, they're absolutely fantastic. Sometimes I feel that we should wait our hours when we open a ticket just so that we get one of them. They know their stuff. They absolutely do, so whoever they're hiring there, they got to keep that up and spread that out. I'd rate them a nine out of ten.

I've worked with Check Point's firewall, and I've worked with Palo Alto's firewall. Things like packet capturing and packet tracing that I can manipulate to pretend I'm doing traffic through the firewall are a lot easier to do with ASAs than with other products.

We have other firewalls in our environment. We still use Palo Alto. We do have a little bit of a mix with Palo Alto in our environment, but in terms of VPN specifically, the way that Palo Alto does route-based VPN by default doesn't flow well with most people out there. It works great with cloud providers. Cisco can do route-based VPNs too. We have a route-based VPN solution with Cisco as well. We just use an ISR for that instead of a firewall.

I've been part of the deployment. Specifically, how NATTING and the firewalls work, that part is not difficult at all, but there are some challenges when you take any product and manipulate the order of operations, but that's not a Cisco challenge. You're pairing different information. There are some tools that usually try to help with those conversions, but most of the time, I find it just easier to develop what you need and just build it from scratch.

We implemented it on our own.

We've seen an ROI in terms of our high-level engineers having to work less on the product. I've been able to provide it to the NOC because of the use of the solution. They see value in that.

Pricing is more for my leadership, but I give them the quotes, and if they approve, they're happy. They've never wavered, so I wouldn't say it's out of the realm where they're considering another product. It must be in the direct price range for our leadership to not blink an eye when we give it to them.

To those evaluating this solution, I'd say that it's a solid product. It works. It does what we need. It gives us peace of mind to sleep at night. I'd definitely put it up there with some of the other firewalls to consider.

I'd rate Cisco ASA a nine out of ten.

I use the solution mostly to separate internal networks.

Being able to create and apply new policies to the firewall has been helpful. It is an object-oriented way of doing things that helps a lot because we can build and apply new policies. We can also test it and revert to the old one if it doesn't work.

The monitoring dashboard is valuable to us for troubleshooting. It lets us see if the packets get from the source to the destination correctly.

With the new FTD, there is a little bit of a learning curve. The learning curve could probably be simplified a little bit. I've come around that learning curve, and I'm able to get around it.

I have been using the solution for 15 years.

Cisco is known for its general stability.

The solution’s scalability is excellent. I don't know if the scalability has a downside or even a limit.

The support is really good. I have a good team that supports us, and I'm able to always reach out to them. It's nice to have somebody on the cell phone and just be able to reach out to them.

Positive

Years ago, I used different firewalls like Juniper, but mostly, it's been fixed to ASA and FTD. We switched to Cisco because our customers were using Cisco.

The initial setup had a little bit of a learning curve, especially because I came from ASA. I needed some help from Cisco. However, I knew what I was doing once it was set up, especially with FMC and Firepower.

We used Cisco’s support to deploy the product.

In general, we have seen an ROI on the product. Using it, applying policies, setting it up, and leaving it alone is helpful. It helps save resources.

I don't use the product for application visibility and control. I tend to worry more about blocking or allowing certain things versus looking deep into the servers and applications and how they work.

The product is great for securing our infrastructure from end to end. I'd like to be able to test out some of the other products, like dashboards and IPS/IDS, that work with it. For the most part, I set up a firewall, and I set up the rules. If things don't work, I monitor it through the monitoring dashboard and try to figure it out.

Cisco Secure Firewall has helped free up a lot of time for our IT staff. Apart from monitoring, unless somebody needs a firewall rule change or anything like that, there's no need to mess with it. Once we set it up, it just runs.

The solution has helped our organization to improve its cybersecurity resilience. Being a firewall, by definition of the term, the product has improved our organization’s security.

People should always evaluate other products. If you’re looking for a solid firewall, Cisco makes the choice so much simpler, especially now with FMC. We are able to apply policies easily and control different firewalls at the same time.

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

We have some in our DMZ. We have some located in several locations throughout our state. Then we have our local Egress and VPN firewalls that we use.

The VPN is our most widely used feature for Cisco Secure Firewall. Since we were forced into a hybrid working situation by COVID a few years back, VPN is the widely used feature because everybody is working remotely for our agency. So it came in very handy.

Cisco Secure Firewall’s customer support could be improved.

I have been using Cisco Secure Firewall for 20 years.

Cisco Secure Firewall is a very stable solution.

We bought scalable products, and we're in a good position.

With Cisco Secure Firewall's technical support, it's always hard to get somebody that knows what they're doing on the line. However, when you finally get somebody on the line, it's pretty good. Having to deal with the licensing and be able to open a TAT case based on the serial numbers was very difficult. The individuals we get support from are pretty good, but the solution's support is two out of ten because of the process of having to get to that point to get support.

Negative

I have previously used Juniper. Our company decided to go with Cisco Secure Firewall because of the cost and ease of use. Also, the people in our team knew Cisco versus other solutions.

Cisco Secure Firewall's initial setup was pretty straightforward. They have a wizard, which helped in some instances, but there's also a lot of documentation online that helps a lot.

We have a reseller that we go through, and they helped implement Cisco Secure Firewall for us.

The application visibility and control with Cisco Secure Firewall is pretty great. We have the FTD, the firewall threat defense, and FMC, the management console we use, and we have great visibility using that product.

Cisco Secure Firewall's ability to secure our infrastructure from end to end is really good. We always find things and or block things before they even happen. So it's great, especially with Talos.

Cisco Secure Firewall has helped free up our IT staff for other projects to a certain degree. We still have to review logs in the firewall, and hopefully, someday, we'll have AI to help do that for us too. The solution has probably saved our organization about ten hours a week.

We use Talos, among other threat advice tools, and it's very good. Talos automatically updates us on the threats out there, and we can deploy those to our devices if we deem it fit to deploy them.

Cisco Secure Firewall has helped our organization improve its cybersecurity resilience. We've used Cisco for so long, and we've never had a data breach up to this point.

Overall, I rate Cisco Secure Firewall ten out of ten.

I'm a design consultant. We primarily use the product to secure various client networks, major infrastructure, highways, and urban surveillance.

The solution is pretty easy to deploy. It is pretty ubiquitous too, so it is easy to get. It pretty much does the job we need it to do.

I would like to see an IE version of the solution where it is ruggedized. Most of what we do is infrastructure based on highways. Now that the product has a hardened switch, the only thing left in our hubs that isn't hardened is probably the firewall. It would be nice to pull the air conditioners out of the hubs.

I have been using the solution for 20 years.

I've never had a stability problem with firewalls.

The solution seems to be very scalable. I probably don't have much experience with scalability because, by the nature of how our networks work, we don't scale them; we just add another one.

Support is very good. I've never had a problem with any form of support.

Positive

I used only a couple of other products over the years due to client preference. In general, Cisco Secure Firewall is easier to deploy mostly because of the depth of personnel trained in it. Every other product seems to be a niche thing that two people know, but Cisco once again seems ubiquitous throughout the industry. Our customers choose Cisco for various reasons, from cost to a preference for Cisco. It meets the task that they need to meet. It's really the spectrum.

The deployment is pretty straightforward. It's the same as deploying any other Cisco equipment. If you know what you're doing, it's not a huge deal.

I believe our clients have seen an ROI. Their networks are more secure. Various agencies have tested a few of them to prove it, and they've proven okay. Since they weren't attacked, they have received an ROI.

The licensing is not so bad. The solution’s pricing could be lower. It's not horrible, though.

The application visibility and control are pretty good. It seems to do everything we've ever needed it to do. I've never asked the product to do something that it couldn't do. The solution has been pretty successful at securing our infrastructure from end to end. Most of our client’s staff have reported that the product is not as maintenance intensive as they would like. They never had to deal with maintenance before, but now they do. We deploy new systems for our clients.

I haven't had much experience with Cisco Talos directly. I know it's there, but I haven't really been involved. I haven't experienced it, which I believe is a good thing. It's doing its job if I don't have to get involved with it. The product has definitely helped improve our organization’s cybersecurity resilience. We weren't secure at all before, and we are a known target since we’re based in infrastructure. The solution has been very helpful in providing security.

It is a good product. I would definitely look into it. There is great value in going to a partner to a reseller to deploy the product. They understand the equipment and have expertise. Normally, they're local, so local knowledge is always useful. They have done deployments before, so sometimes they know tips or tricks that aren't in the manuals.

People evaluating the solution should give it a look. Definitely, it is worth taking a look at it.

Overall, I rate the product a nine out of ten.

We are one of our Swedish municipalities. We use this solution to support our environment and keep it safe and secure.

At the moment, Cisco SecureX is just for the monitoring part. We are migrating servers from an old infrastructure to a new one. It monitors how they're behaving on the network.

We have 500 sites using it. It's a mix of remote sites and connected sites. We have a lot of devices. We are a Swedish municipality, so we do everything from healthcare to taking care of the roads. We have a wide spectrum of users, so we have to supply everyone with what they need. So, we have a lot of devices in our network.

Cisco SecureX is doing a good job for us in terms of securing our infrastructure from end to end so that we can detect and remediate threats. It's detecting what we want it to detect, and it's protecting us from what we want to be protected against. So, it does its job. That's our need at the moment.

It has saved us time. Attackers are constantly trying to get hold of our environment. We've had around 20 to 30 breach attempts to get ahold of our environment. It protects us from that. It also protects us when an attempt is underway. We can see them starting to get into our network, so we can prevent it in time. The time saved varies. It can be days of work.

Its efficiency and security are the most important. We are more efficient and more secure.

We use Cisco switches and firewalls, Cisco DNA, and Cisco SecureX. The integration between various Cisco products is working very well. It's quite seamless for us.

There should be more integration with Microsoft Identity.

We get customer support through ITEA for a bunch of solutions. We get the help we need. I'd rate them a nine out of ten. You can always do better.

We haven't used any other solution for a long time. We have been a Cisco customer for a long period.

I was involved in its design. Some parts of the initial setup were quite easy and some parts were quite complex. We were quite early adopters of some parts of the Cisco brand, so we had some challenges, but overall, it was quite straightforward.

For some parts, we took the help of a third party called ITEA. Our experience with them was good.

We haven't calculated the overall ROI. There are different areas we use it for. For some management areas, we can calculate ROI, but in some areas, we can't.

You get what you pay for. It's always priced based on what you get and what it can handle. It's acceptable.

To those evaluating this solution, I'd advise finding out what you want to use it for. Our usage is quite basic. Overall, I am quite satisfied with what we are using it for.

Overall, I'd rate it a nine out of ten.

Our primary use case is filtering as we have a filtering strategy. We are trying to filter a destination and do not have a centralized filtering strategy. So we have MX and on the other end filtering on the firewalls, but not in the middle. This means that both ends of the connectivity do all the security on the firewalls.

The most valuable MX features are the ease of deployment and a great dashboard. The most valuable Cisco Secure Firewall features are options, features, and ease of deployment because it's an appliance.

Cisco Secure Firewall's integration with cloud providers has room for improvement. We could do more in terms of integration, for example, if we had a tag on an instance. 

I would also like to see tag rules with cloud objects. This would be a great improvement for Cisco Secure Firewall. 

As far as MX is concerned, I would like to see more interconnection. We would also like to be able to do BGP.

Our organization has been using this solution for about 10 years.

We had MX when it was launched initially and it was not as stable as it is now. The stability of the solution has improved. 

I would rate the stability of this solution three years ago a 3 and today's stability an eight, on a scale from one to 10, with one being the worst and 10 being the best.

I think that their tech support is quite good. I would rate them an eight, on a scale from one to 10, with one being the worst and 10 being the best.

Positive

We have used different types of solutions. We had Cisco ASA for about 10 years, and then we switched to an on-site firewall to MX from Meraki, Cisco. For our cloud, we have Cisco Services Routers.

The migration to the cloud has been a lot of work. Not all of our systems were compliant with being on the cloud so we had to work on some applications and delete some of them. For the old systems, we had to do extra work but for the newer systems, it was fine. The migration took around 18 months to migrate 99%.

We had more than 2,000 on-prem firewall sites.

Cisco helped with the migration to the cloud with the migration tool. Migrating MX was really easy and the tools helped us to migrate from the old ASA we had to the new MX. The cloud, firewalling, and CSR helped us from the data center on-premise approach to the cloud because at the time we didn't have a lot of experience with the cloud. It was easy to use the Cisco appliances in that space.

I think that this solution has saved our IT staff time because of the ease of deployment. When I first started as a network engineer, it took a whole day to configure a firewall because of all the particularities you could potentially have at a site.

I think that this solution saved our organization's time because security saves money because. At the end of the day, firewalls block threats.

This solution helped with the consolidation of tools as we had all the observability tools in the solutions. Some 10 years ago we all had third-party solutions doing the observability. Now, we have the whole package and not only the firewall.

We choose Cisco 10 or 20 years ago mostly because it was a market-leading solution. I also think it's because of MX's user-friendly solution that you can get on board easily. As far as CSA goes, I believe it's because you have a lot of features on the firewalls and it's the stability of course.

We use ASA Firewall to protect 250 to 300 devices, including workspaces and servers.

All the rules are secure and we haven't had a significant malware attack in the five years that we've been using ASA Firewall. It is a tremendous improvement for our network. However, I can't quantify the benefits in monetary terms. 

I like the ease of administration and the overall speed of processing web traffic. The modules help protect and administer web traffic. ASA Firewall's deep packet inspection gives me visibility regardless of whether I have the agent installed on all the workstations. I can see incoming web traffic and control access to suspicious or dangerous sites. I can apply a filter or make rules to restrict categories of websites.

Setting firewall network rules should be more straightforward with a clearer graphical representation. The rule-setting method seems old-fashioned. The firewall and network rules are separate from the Firepower and web access rules. You can access the firewall rules through the Cisco ASDM application, not the web client. I'm using an older version, and I'm sure this issue will improve in the next edition.

Micro-segmentation is somewhat complex. It's not easy, but it's not too difficult, either, so it's somewhere in the middle. I used micro-segmentation for 10 or 15 VLANs, and ASA Firewall acts as a router for those VLANs. The visibility offered by micro-segmentation is pretty poor. It's not deep enough. 

I have been using ASA Firewall for five years.

ASA Firewall is a stable solution.

I don't think ASA Firewall is very scalable. It depends on the models and the license. However, it's pretty simple to update and upgrade the models, so I would say it's moderately scalable. 

I worked with Cisco's technical support from the beginning and it was excellent. I rate Cisco support 10 out of 10. 

Positive

Previously, I used some Linux Servers with a software firewall for 20 years.
It was a Microsoft firewall, but I don't remember the name. It was a server that I had to install on the gateway.

Deploying ASA Firewall was complex because I needed to install an ESXi machine to implement the Firepower module. That was relatively complicated, and it took two or three days to complete the installation and verification.

I worked with a consultant who sold me the product and helped me with minor issues as needed. 

In the past, the company experienced multiple ransomware attacks, but we haven't seen any since installing ASA Firewall. It was a huge improvement. It's hard to quantify that in financial terms, but we had 40 or 50 machines damaged. 

I'm not sure precisely how much ASA Firewall costs, but I know it's a little more expensive than other solutions. I rate it seven out of ten for affordability. 

I learned about Fortinet and Palo Alto firewalls. I think FortiGate is easier to set up and manage. At the same time, Cisco firewalls are pretty secure and reliable. I think the ASA Firewall is in the top five.

I rate Cisco ASA Firewall eight out of ten. 

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.