Cisco Secure Firewall Reviews

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. 

Telindus, our company, is an integrator. We sell Firepower and we do use it ourselves. I use all the different versions of the product. 

We either replace our customers' other brands of firewalls with Firepower, or we upgrade their old Cisco ASA Firewalls to the new Firepower firewalls. The type of device we advise them to install depends on the customer's requirements and the throughputs needed.

Our primary use case for Firepower is for big networks.

The most important feature is the intensive way you can troubleshoot Cisco Firepower Firewalls. You can go to the bit level to see why traffic is not handled in the correct way, and the majority of the time it's a networking issue and not a firewall issue. You can solve any problem without Cisco TAC help, because you can go very deeply under the hood to find out how traffic is flowing and whether it is not flowing as expected. That is something I have never seen with other brands. That is why, when people move from another brand to Cisco, they never leave Cisco. They see that advantage.

Something I like about Firepower, in general, is that it still relies on the old ASA code. That's something customers really like because when they go into the CLI, they remember, "Oh, that's the ASA, that I am familiar with," but it's enriched with all the next-gen features of Snort. When a customer has knowledge of the ASA codes, they can do intensive troubleshooting because they know the device.

Customers also like Talos, which is the intelligence behind all of Cisco's security products, including Firepower. Talos is very good and is actually the most important part of a security product. It's important that you have something in the background that is continuously enriching intelligence so that you get information about upcoming threats on time. That keeps you protected as soon as possible when a Zero-day happens. Something that customers like about Cisco Firepower, in combination with Talos intelligence, is that full-time people are working in the background to provide information to Cisco security products.

Customers really want visibility into their networks. For example, they want identity management and that is something you can use Firepower for. With it, in addition to an IP address going somewhere, you can also see the username. That's a big advantage of Firepower, and can be set up quite easily.

Also, in very large networks, our customers use Cisco DNA Center. They have automation orchestration for their access network and that works seamlessly with Cisco Firepower firewalls. Security Group Tags can be used from DNA to an edge Firepower firewall. That way, they have microsegmentation within their access network for DNA. And they can extend that to their firewall rules for Firepower. 

Our customers also use Cisco ISE to get user information. ISE is connected to DNA Center. That is something that Firepower works seamlessly with, and we do sell it a lot. We sell a lot of Cisco's other security equipment, and they all send their information to SecureX. Having more Cisco security products means your security information is becoming enriched within the SecureX platform. The integration among these Cisco products is more than easy. Cisco documents everything, in detail, when it comes to how to integrate the different parts. I've never had an issue with integrating Cisco security products with each other.

And for smaller networks, like those our government customers have, what they like about Cisco Firepower, and why they purchase it nine out of 10 times, is its ease of use and the reporting in Firepower Management Center. That is something they really like. They can look up things themselves and they like the SecureX integration.

The Firepower FTD code is missing some old ASA firewalls codes. It's a small thing. But Firepower software isn't missing things that are essential, anymore.

I've been using Cisco Firepower NGFW Firewall since it came out; from the time Cisco started to use the name Firepower and they bought Snort. That's when they put in the next-generation features. 

Firepower is rock-stable. So far, I have not seen any failed firewall. The only thing that was not quite stable in the past was Firepower Management Center, but since version 6.6 that has also been rock-stable. I haven't had any failed components in the last couple of years. I did have them two years ago and further in the past, where firewalls were not functioning and needed a reboot, but since 6.6, the stability is very good. We don't have priority-one tickets anymore.

In the Netherlands, where I work, we don't have very big customers requiring very high throughput. So I cannot say anything about clustering where you can pile different ASAs or Firepower devices together to increase performance when you require it. 

But scalability, in general, is pretty hard. Competition-wise, sometimes it's hard to sell Cisco security products because, in my opinion, Cisco is quite honest about the real throughput they are able to provide. Other vendors may be giving figures that are a little bit "too perfect." Sometimes it's hard for us to sell Cisco firewalls because a customer says, "Well, when I go to other brands they say they have double the throughput for half the price." Well, that's great on paper, but... 

In general, after we have installed Cisco firewalls, our customers are very pleased by the performance. They also like that they can tweak settings to get more performance out of the firewall by enabling specific policies for specific traffic, and by disabling inspection for very internal data center traffic. That provides a big boost to the overall firewall performance. When a customer complains that we didn't scale it correctly, and they say it's not performing as well as they expected, I'm always able to tweak things so that it performs the way the customer requires.

I have interacted with Cisco's technical support many times. Nowadays, it sometimes takes a while to get to the person with the correct knowledge, but that is happening in the world in general. First-line people are common around the world and they are trying to figure out if an issue is actually a second-or third-line issue. But when you do reach the correct department, and they know that you are knowledgeable and that you are really facing a high-priority issue or a strange behavior, Cisco's support does everything it can to help you fix things, including involving the development department. I'm very happy with their tech support.

Most of the time we replace Sophos, Check Point, SonicWall, and Fortinet firewalls with Cisco firewalls. Customers really like the overall integration with SecureX. They see the advantage of having more security products from Cisco to get more visibility into their security. We also replace old, non-next-generation firewalls from Cisco; old ASAs.

The initial deployment of Firepower is a straightforward process. For me, it's pretty easy. If you have never worked with it, I can imagine it might be complex. 

Cisco makes it easier all the time. You can now deploy a remote branch by managing the device on an external interface. In the beginning, with previous software versions, that was hard. You needed to configure the file as a remote branch, but for that you needed the central Firepower Management Center to configure it and you didn't have a connection yet. It was a big issue to set up an initial firewall remotely when there was no connection to the Management Center. But that's been fixed.

In general, you just put down some management IP addresses and configure things so that the devices see each other and it starts to work. It's far from complex.

Generally, the initial setup takes four hours. The implementation strategy depends on the customer. I always have a conversation with the customer upfront. I explain how the connectivity works for Cisco Firepower, and then I say that I want to be in a specific subnet field. Then I start configuring the basics, and that is the part that takes about four hours, for Firepower Management Center and two firewalls in HA. Then, I start to configure the firewalls themselves, the policies, et cetera.

I have experience with SonicWall, Fortinet, Juniper, and Sophos firewalls, among others. We work with Fortinet and Palo Alto. It's not that we only do Cisco. But I can say from my experience that I am really more convinced about Cisco products.

What customers really like about Cisco, the number-one thing that they are really happy about within Firepower—and it was also in the old ASA code, but it's even more a feature in Firepower—is that the configuration is in modules. It's modular. You have different policies for the different functions within your firewall, so that your access control policy is only for your access lists and that's it. You have a different network address translation policy. It's all separated into different policies, so a customer knows exactly where to look to configure something, to change something, or to look at something which is not working properly.

Also, with Cisco, when a customer is not totally certain about a change he's going to make, he can make a copy of the specific access control policy or the NAT policy. If something doesn't go right, he can assign the copied policy back to the device and everything is back to the way it was. 

These are the biggest advantages our customers see. When a customer doesn't have any knowledge about firewalls, I can explain the basics in a couple of hours and they have enough familiarity to start working with it. They see the different modules and they know how to make a backup of a specific module so that they can go back to the previous state if something goes wrong.

My advice is "buy it." A lot of people prefer a specific brand and it's fairly hard to convince them that something else, like Cisco, is not bad, as well. They are so convinced about their existing firewall that they want to keep that brand because they are familiar with it and they won't need to learn a new firewall. It's hard for a customer to learn how a firewall works in the first place.

But my advice is that people should read about how Cisco security, in general, is set up and how it is trying to protect them with Talos. They need to understand that Cisco security is very good at what it does. They shouldn't blindly believe in what they have at the moment. I always hear, "My firewalls are good enough. I don't need Cisco. I will just buy the same ones, but new." Cisco Firepower is superior to other firewalls and people should not be afraid to dive in. By educating themselves about the firewall, they will be fine in managing it.

Practically speaking, Cisco firewalls are easier to manage than the firewalls they have at the moment, but they need to make the leap and try something else. That is the hardest part. When I do show them what they are capable of, and how you can configure all kinds of different things, they start to understand.

We don't have many customers that use other vendors' security products together with Firepower. We convince nine out of 10 customers to go over to Cisco fully. We do have customers who don't do that, and then we try to find a way to get the solutions to work together. For example, we try to integrate other brands' switches or firewalls with Cisco security products, but most of the time that is pretty hard. It's not the fault of Cisco. It requires that the other brands speak a protocol language that will support integration, but in the end, it's not perfect and the integration does not work very well. The majority of the time, we are not able to integrate into other security products. Cisco is using standard protocols, but the other vendor is abusing some sort of protocol and then it doesn't work well.

I don't prefer using applications in firewall rules, but our customers do use the application visibility and control, and it works perfectly. Firepower is very good at recognizing the application and is very good at showing you the kind of application that has been recognized. Customers use that in their access control policy rules, and I have never heard bad things about it. Cisco Firepower works very well in recognizing applications.

I get questions from customers because they do not understand threat messages generated by Firepower. Sometimes, it's hard to read what exactly the message is saying. In my opinion, that is not something that is specific to Cisco security or Firepower, rather it is an issue with security in general. Most networking people get these fancy firewalls and they get fancy security events. It's hard for some of them to understand what is meant, and what the severity level is of the message. It's more that a networking guy is trying to read security events. Firepower is doing a good job, but customers sometimes have problems understanding it and then they stop looking at it because they don't understand it. They assume that Firepower is taking the correct actions for them.

Firepower is not a fire-and-forget box. It is something you actually do have to take a look at. What I tell customers is, "Please enable Impact-One and Impact-Two messages in your mailbox, and if it's really something that you cannot understand, just forward it to me and I will take a look for you. Most of the time they are not very high-impact messages. There are only one or two high-impact messages per month.

There are customers who say, "We want you to review the messages in Firepower once a week." I have a look at them when I have time. We try to help the customer check security events once a week or so. That's not great, but it's always a question of finding a good balance between the money a customer can spend and the security aspects. When we do monitor all the events, 24/7, for a customer, you can imagine that it is quite expensive.

I configure every customer's automatic tweaking of IPS policies so that the IPS policy is enabled for the devices seen by Firepower, for recognition of what kinds of clients and hosts are in the network. Other than that, we do not do a lot of automation within Firepower.

Since 7.0, I don't have a lot of things to complain about. If I do have suggestions for improvements, I will give them during the beta programs. The speed of the FMC is very good. The deployment time is much better. They added the policy deployment rollback. That was something I really missed, because if I destroyed something I was able to undo that. Now, for me, it's actually almost perfect.

We are specifically using 7.0 Firepower in several different areas. We have them as an IPS within the core, IPS on the edge, and we're also using the AnyConnect Client as our basis for VPN connection into corporate and other applications.

Firepower NGFW has improved my organization in several ways. Before, we were trying to stamp out security threats and issues, it was a one-off type of way to attack it. I spent a lot of manpower trying to track down the individual issues or flare-ups that we would see. With Cisco's Firepower Management, we're able to have that push up to basically one monitor and one UI and be able to track that and stop threats immediately. It also gives us a little more granularity on what those threats might be. 

We were able to stop hundreds of threats. For killing threats, we were able to get several hundred now in comparison to the one-off that we used to be able to do.

Dynamic policies are very important for us because we do not have the manpower to really look at everything all the time. So having a dynamic way of really registering, looking at, and having certain actions tied to that are incredibly effective for us in slowing any kind of threat.

We're getting there as far as using the application, using it to go to the application level, we're at the infancy of that. We're looking at definitely tying that into our critical applications so that we can see exactly what they're doing, when they're doing it, and being able to track that.

Firepower's Snort 3.0 IPS allows us to maintain performance while running more rules with the advent of 3.0 comparatively to 2X, we have seen at least a 10 to 15% increase in speed where it seems to be more effective. The updates seem to be more effective in finding malicious information. We've definitely seen at least a 10 to 15% increase on tying policy to 3.0.

The features that we find the biggest bang for the buck are for Firepower overall. We're looking at AnyConnect, which is one of the big features. The other valuable features are IPS along with the Geotagging and the Geosync features, and of course the firewall, the basic subset of firewall infrastructure and policy management.

We've looked at other vendors, but Cisco by far has taken the lead with a holistic approach where we don't have to manage multiple different edges at one time. We can actually push policy out from our core out to the edge. The policy can be as granular as we need it to be. So the administration, also the upgradability of the edge is for us because we need to have it 24/7. The upgradability is also another piece of management, logging, and all the other little aspects of the monitoring part.

Using deep packet inspection, especially with 7.0, since it's just come out in 7.0, we're able to see much more granularly into the packet where before we could actually give a general overview using NetFlow. This gives us much more granularity into what is exactly happening on our network and snapping in the Cisco StealthWatch piece gives us the end-to-end way of monitoring our network and making sure that it's secure.

The overall ease of use when it comes to managing Cisco Secure Firewall is one of the reasons that we ended up going with Cisco because the ease of use, basically having one UI to be able to control all of our end devices, policy, geolocation, AnyConnect, all the different pieces of that in one area has been phenomenal.

Cisco Secure Firewall helped to reduce our firewall operational costs because previously if we were not using Cisco's Firepower, we would have had either Cisco ASA or another manufacturer, and we would have had those everywhere. We would have had still two at every site, several within our infrastructure, and the management of those is much more difficult because it's done by one-off.

As far as saving Adventist Health money, I would have to say that it's not necessarily the actual physical product, but the time, labor that we would have had to have to be able to monitor and administer that, and also the time to find malicious issues and security areas that we were unable to see before. So, it's tough to put a cost on that, but it would probably be several hundred thousand dollars overall if you're looking at whether we got hit with malware or with some of the other issues that we're seeing, especially within healthcare. If we were hacked, that would cost us millions.

One of the few things that are brought up is that for the overall management, it would be great to have a cloud instance of that. And not only just a cloud instance, but one of the areas that we've looked at is using an HA type of cloud. To have the ability to have a device file within a cloud. If we had an issue with one, the other one would pick up automatically.

The other part of that is that applying policy still takes longer than we expect. Every version that comes out, the speed is actually increased, but I would love to see that, even a little more as far as when we're actually deploying policy.

We have been using Firepower's series for at least the last six years.

We're staggered right now. The Firepower Management Console is at 7.0 and most of our Firepower units are at 6.6.

We have two areas for deployment. We have them as an edge at our markets, we term our hospitals as markets, but each one of the hospitals will have an HA Pair of the Firepower model. And we also have them in our core, within the ACI infrastructure. We use them as a core firewall along with an Edge firewall.

We've been using Firepower, the Threat Defense, and the Management Console for about six and a half years and I think we've had maybe two issues with it. And most of those were due to either our policy settings or something that we messed up. We've never had to return a box and we've never run into any major bugs that have actually hindered the actual security of the system.

Scalability so far has been fantastic because we started with four Firepower Threat Defense boxes, but really after that, now we have 14 and we're going to be pushing that to 44 to 46 devices. The implementation has been pretty seamless and pretty easy. It's been great.

We use it exclusively for edge and core for firewall and for policy and for IPS and AnyConnect. We plan on continuing to integrate that tighter. So in the future, we probably will not grow that many physical devices, but we plan on actually integrating those tighter into the system, tighter with integration, with Cisco's ISE, and tighter integration with our ACI infrastructure. So at the end of the day, we don't see us going any further away from using Firepower as our core security edge device.

My company has been using Cisco for many years. One of the huge pieces for us is, of course, the supportability and ongoing update, maintenance, and care. We've had a great relationship with Cisco. The tech is outstanding. Typically, we will open a tech case and they will know exactly what the issue is within two to three hours if it's a very difficult one. Typically they even know what it is when we actually open the case.

We've actually had a fantastic relationship working with Cisco. They've had a fast turnaround, great tech support, and we have not run into any issues thus far with the Firepower overall.

Prior to actually using Firepower, we were still a Cisco shop. We used Cisco ASA exclusively, and it was fantastic. But with the advent of Firepower, being able to manage, monitor, and upgrade has really cut back our time on those processes by less than half of what we had before. We were using the good old ASA for many years.

We found that the initial setup using Firepower products was actually very simple. The initial configuration for the Management Console was very straightforward. Adding devices usually takes a few minutes. And then once you've got them physically set up in your Management Console, it's streamlined. It's actually very simple.

One of the great features of having the Cisco Firepower Management Console is having the ability to group. So we have each one of our hospitals as a group, so we can actually do any device configuration within a group. They're HA so that when we do an upgrade, it is seamless because when it fires off the upgrade, it will actually force the HA over automatically as part of the upgrade. And the other part of that is policy management. We have several policies, but specifically, one for the general use at our hospitals has been phenomenal because you build out one policy and you can push that out to all of your end nodes with one push.

We require two staff members to actually implement and devise the initial configuration.

At my company, you have to be at least a senior or an architect in order to manage any type of firewalling, whether that's the IPS, the actual firewall itself, or AnyConnect. So we have senior network engineers that are assigned for that task.

We typically have one person that will actually rotate through the group for the maintenance. There's a senior network engineer that will maintain that on a daily basis. Typically, it doesn't take maintenance every day. The biggest maintenance for us comes to updating policy, verifying the geolocation information is correct, and any upgrades in the future. So typically that takes about one to two people.

We did not actually use any external authority as far as setting up, maintenance, and configuration. It all comes directly from Cisco because of our partnership with Cisco, we have had a fantastic cast of system engineers and techs when needed. We haven't had to go out of our partnership with Cisco to actually implement these, to upgrade, or update.

Cisco's pricing is actually pretty good. We get a decent discount, but when you look across the board, if you're looking at a Cisco firewall, Firepower device, a Palo Alto device, or a Juniper device, they're going to be pretty comparable. A lot of people say, "Oh, Cisco is so expensive." But when you boil it down, when you look at the licensing structure for Firepower, you look at the actual device cost and how much that costs over time, they pretty much are right in line, if not less, depending on what you're buying for Firepower. So we've actually had a great run with that, and we feel confident that we're getting the best price. I haven't seen anything better than the supportability of that.

We actually did look at another vendor when we were looking at initially grabbing Firepower, to bring in as our corporate firewall and our main inspection engine. So we did look at Palo Alto and we also looked at Juniper SRX series, but both of those didn't really have the overall manageability and tightness with the Cisco infrastructure as we would want it to. So there was nothing necessarily security-wise wrong with them, but they were not a good fit for our environment.

The biggest lesson that we've learned is in a couple of different ways. One is how to keep your policy clean. We've learned that we've really had to keep that from overextending what we want to do. It also has great feedback as you're building that out so that you can look at it and you figure out how you are going to be able to really implement this in a way that won't break something or that won't overshadow some other policy that you have. That's probably one of the biggest things that we've learned. The way that you build out your policy and the way that you use that on a daily basis is very intuitive. And it also gives you a lot of feedback as you're building that out.

The advice that I would give anybody looking at Firepower is to look at it from an overall standpoint. If you want something that you can monitor and administer well, that you can update very quickly, and that gives you all of the security aspects that anybody else can on the market, it's going to be really hard to beat because of the Management Console. With this, you've got one tool that you can actually do the device updates, device configuration and all the policy management in one area. So I would say, definitely take a look at it. It's got a great UI that is very straightforward to use. It is very intuitive and it works really well out-of-the-box. And it does not take math science to be able to implement it.

I would rate Firepower a nine out of ten. I can't think of anything that would be a 10. It's mature, it's effective and it's usable.

We have two devices in Active-Active mode, acting as a perimeter firewall. It is the main firewall that filters traffic in and out of our organization. This is where there are many rules and the mapping is done to the outside world. We use it as a next-generation firewall, for intrusion detection and prevention.

It's also linked also to Firepower, the software for network policies that acts as our network access control. 

I find it very useful when we're publishing some of our on-prem servers to the public. I am able to easily do the NATing so that they are published. It also comes in very handy for aspects of configuration. It has made things easy, especially for me, as at the time I first started to use it I was a novice.

I have also added new requirements that have come into our organization. For example, we integrated with a server that was sitting in an airport because we needed to display the flight schedule to our customers. We needed to create the access rules so that the server in our organization and the server in the other organization could communicate, almost like creating a VPN tunnel. That experience wasn't as painful as I thought it would be. It was quite dynamic. If we had not been able to do that, if the firewall didn't have that feature, linking the two would have been quite painful.

In addition, we have two devices configured in an Active-Active configuration. That way, it's able to load balance in case one firewall is overloaded. We've tested it where, if we turn off one, the other appliance is able to seamlessly pick up and handle the traffic. It depends on how you deploy the solution. Because we are responsible for very critical, national infrastructure, we had to ensure we have two appliances in high-availability mode.

I love the ASDM (Adaptive Security Device Manager) which is the management suite. It's a GUI and you're able to see everything at a glance without using the command line. There are those who love the CLI, but with ASDM it is easier to see where everything is going and where the problems are.

The ASDM makes it very easy to navigate and manage the firewall. You can commit changes with it or apply them before you save them to be sure that you're doing the right thing. You can perform backups easily from it.

It also has a built-in Packet Tracer tool, ping, and traceroute, all in a graphical display. We are really able to troubleshoot very quickly when there are issues. With the Packet Tracer, you're able to define which packet you're tracing, from which interface to which other one, and you're able to see an animation that shows where the traffic is either blocked or allowed. 

In addition, it has a monitoring module, which also is a very good tool for troubleshooting. When you fill in the fields, you can see all the related items that you're looking for. In that sense, it gives you deep packet inspection. I am happy with what it gives me.

It also has a dashboard when you log in, and that gives you a snapshot of all the interfaces, whether they're up or down, at a glance. You don't need to spend a lot of time trying to figure out issues.

Our setup is quite interesting. We have a Sophos firewall that sits as a bridge behind the Cisco ASA. Once traffic gets in, it's taken to the Sophos and it does what it does before the traffic is allowed into the LAN, and it is a bridge out from the LAN to the Cisco firewall. The setup may not be ideal, but it was deployed to try to leverage and maximize what we already have. So far, so good; it has worked.

The Cisco doesn't come with SD-WAN capabilities which would allow me to load balance two or three ISPs. You can only configure a backup ISP, not necessarily an Active-Active, where it's able to load balance and shift traffic from one interface to the other.

When I joined the organization, we only had one ISP. We've recently added a second one for redundancy. The best scenario would be to load balance. We plan to create different traffic for different kinds of users. It's capable of doing that, but it would have been best if it could have done that by itself, in the way that Sophos or Cisco Meraki or even Fortigate can.

A feature that would allow me to load balance among multiple ISPs, especially since we have deployed it as a perimeter firewall, would be a great addition. While I'm able to configure it as a backup, the reality is that in a modern workplace, you can't rely on one service provider for the internet and your device should be able to give you optimal service by load balancing all the connections, all the IPSs you have, and giving you the best output.

I know Cisco has deployed other devices that are now capable of SD-WAN, but that would have been great on the 5516 as well. It has been an issue for us.

I have been using Cisco ASA Firewalls since November 2019.

Cisco products are quite resilient. We've had problems due to power failures and our UPSs not being maintained and their batteries being drained. With the intermittent on and off, the Cisco ASAs, surprisingly, didn't have any issue at all. The devices really stood on their own. We didn't even have any issue in terms of losing configs. I'm pretty satisfied with that.

I've had experience with some of the new Cisco devices and they're quite sensitive to power fluctuations. The power supply units can really get messed up. But the ASA 5516 is pretty resilient. We've deployed in a cluster, but even heating up, over-clocking, or freezing, has not happened.

We also have the Sophos as a bridge, although it's only a single device, it is not in a cluster or in availability mode, but we've had issues with it freezing. We have had to reboot it.

It's easy to scale it up and extend it to other operations. When we merged with another company, we were able to extend its usage to serve the other company. It became the main firewall for them as well. It works and it's scalable.

It's the main perimeter firewall for all traffic. Our organization has around 1,000 users spread across the country. It's also our MPLS solution for the traffic for branch networks. It's able to handle at least 1,000 connections simultaneously, give or take.

Prior to my joining the organization, there was a ransomware attack that encrypted data. It necessitated management to invest in network security.

When I joined the project to upgrade the network security infrastructure in our organization, I found that there was a legacy ASA that had been decommissioned, and was being replaced by the 5516. Being a type-for-type, it was easy to pick up the configs and apply them to the new one.

When I joined this organization, the solution had just been deployed. I was tasked with administrating and managing it. Managing it has been quite a learning curve. Prior to that, I had not interacted with ASAs at all. It was a deep-dive for me. But it has been easy to understand and learn. It has a help feature, a floating window where you can type in whatever you're looking for and it takes you right there.

We had a subsidiary that reverted back to our organization. That occurred just after I started using the 5516 and I needed to configure the integration with the subsidiary. That was what I would consider to be experience in terms of deployment because we had to integrate with Meraki, which is what the subsidiary was using.

The process wasn't bad. It was relatively easy to integrate, deploy, and extend the configurations to the other side, add "new" VLANs, et cetera. It wasn't really difficult. The ASDM is a great feature. It was easy to navigate, manage, and deploy. As long as you take your backups, it's good.

It was quite a big project. We had multiple solutions, including Citrix ADC and ESA email security among others. The entire project from delivery of equipment to commissioning of the equipment took from July to November. That includes the physical setup and racking.

Two personnel are handling the day-to-day maintenance.

We have seen ROI with the Cisco ASA, especially because we've just come to the end of the three-year subscription. We are now renewing it. We've not had any major security incident that was a result of the firewall not being able to detect or prevent something. That's a good return on investment.

Our device, the 5516, has been declared end-of-life. The cost of upgrading is almost equivalent to deploying a new appliance. But having had it for three years, it has served its purpose.

As with any security solution, the return on investment must be looked at in terms of what could happen. If you have a disaster or a cyber attack, that is when you can really see the cost of not having this. 

Cost-wise, it's in the same range as its competitors. It's likely cheaper than Palo Alto. Cisco is affordable for a large organization of 500 to 1,000 users and above.

You need a Cisco sales partner or engineer to explain to you the licensing aspects. Out-of-the-box, Firepower is the module that you use to handle your network access policy for the end-user. It's a separate module that you need to include, it's not bundled. You need to ensure you have that subscription.

A Cisco presales agent is key for you to know what you need. Once they understand your use cases, they'll be able to advise you about all the licenses you need. You need guidance. I wouldn't call it straightforward.

With any Cisco product, you need a service level agreement and an active contract to maximize the support and the features. We have not had an active service contract. We just had the initial, post-implementation support.

As a result, we've wasted a bit of time in terms of figuring out how best to troubleshoot things here and there. It would be best to ensure you are running an active contract with SLAs, at least with a Cisco partner. 

Also, we were not able to use its remote VPN capabilities, Cisco AnyConnect, because of a licensing limitation.

I would encourage people to go for the newer version of Cisco ASA. 

When you are procuring that device, be sure to look at the use cases you want it for. Are you also going to use it to serve as your remote VPN and, in that case, do you need more than the out-of-the-box licenses it comes with? How many concurrent users will you need? That is a big consideration when you're purchasing the device. Get a higher version, something that is at least three years ahead of being declared end-of-life or end-of-support.

We helped a customer to configure a new data center network. We provided the core firewalling. Between virtual routing instances, or virtual networks, we had two Firepower 2130s in HA. We did the routing and firewalling between the VRS and, in the same data center, we have an internet edge firewall also set in HA that provided the routing and firewalling to the internet and to Azure. In the same data center we had two ASAs for out-of-band management. If an error occurred in the data center, we could VPN into the ASA and troubleshoot the routing issues in the data center.

I have customers that have migrated from Cisco ASA to Cisco Firepower. They have benefited from the change because they have much more visibility into the network. An ASA is often used as a Layer 3 to 4 firewall. We allow networks and ports. But a Firepower firewall has the default intrusion prevention engine, so you can allow it to https on port 443, but it can also look into the packet, with deep packet inspection, and see if there is malicious code that is trying to be pushed into your system. It's a much more secure product than just having a Layer 3 to 4 firewall. It is a Layer 3 to 7 firewall.

We also use Cisco Talos, and when we configure a Firepower, we set the automatic update to get the latest vulnerabilities and databases, Snort rules, geolocation database, and security intelligence from Talos. Our customers aren't benefiting directly from Cisco Talos, but they are benefiting from having a product like Firepower that has connections to Talos.

The dynamic access policy functionality, and the fact that in Firepower 7.0 the feature has one-to-backward compatibility with the Cisco ASA Firewall, is a game-changer. Our customers have begun to transition from Cisco ASA to Cisco Firepower and because they get this capability, there are more and more VPN features. And when they shift from ASA to Firepower, they go from Layer 3 to Layer 7 visibility, instead of only going from Layer 3 to 4. They gain through the visibility they get from a next-generation firewall. They get more visibility and a more secure solution.

For Firepower the most important features are the intrusion prevention engine and the application visibility and control. The Snort feature in Firepower is also valuable.

For ASA, the most valuable feature is definitely the remote access VPN solution. The AnyConnect solution is very scalable and stable—there are no errors or flaws—which is necessary in today's world when we're all working remotely. The remote access VPN for ASA is very good.

When it comes to application visibility and control, both ASA and Firepower can provide them but the AVC feature is mostly used in Firepower. You can allow or disallow many applications through Firepower, through the access control policy.

If you configure Firepower correctly, it is good when it comes to threat visibility. It is proficient. It is the state of the art when it comes to blocking threats, network-wise. If you use it with an SSO encryption, and use your own features, blacklists, security intelligence, intrusion prevention, and access control points—if you are using it with every feature—Firepower can block most threats on your network. But it can't stand alone. It is necessary for the clients to have AMP for Endpoints, Cisco Umbrella, and Cisco ISE. If you're using Firepower as a standalone device, it can block, say, 20 or 30 percent more than the ASA can. But if you're using all of the security features from Cisco, you get much more security. It's like an onion's layers. The more layers you have, the more protection you have.

The ease of use with the new version of Firepower is more or less the same when compared to other versions of Firepower. But the dashboard has received a refresh and it's easier to use now than before. Overall, the ease of use has been increased.

On the VPN side, Firepower could be better. It needs more monitoring on VPNs. Right now, it's not that good. You can set up a VPN in Firepower, but you can't monitor it. 

Firepower Management Center is slow. It could be better. And the Firepower Device Manager doesn't have all the features that the ASA has, and that's despite the fact that it's almost the same product. Cisco could use many more features from ASA in Firepower Device Manager.

I have used Firepower for two years and I have worked with all Firepower models: Firepower 1000 Series, 2000 Series, Firepower 4000. I have never had my hands on a Firepower 9300, but it's mostly the same as the 4000 and 9000 Series. I have also used Firepower Management Center, virtual, the 1000 Series, and the 1600. I have also used Firepower virtual devices, the Firepower Next-Generation Firewall Virtual (NGFWv).

I was using Firepower 7.0 for around 10 weeks on a beta program. I was using it more or less every other day. I have been using it quite a lot.

If you stay on the recommended releases, Firepower is very stable. Cisco has had a lot of trouble and issues with Firepower since they acquired Sourcefire, and some of the issues or problems are still there. But if you stay on the recommended releases you shouldn't hit that many errors or bugs. It can be stable, but it can also be very unstable if you jump on the newest release every time.

Firepower scales well if you have the 4100 Series or 9300 Series. They can scale and you can cluster the devices. Otherwise, you can only add one device, but that's more for the small customers. But if you get up to the high-end series of Firepower, it scales very well. 

We have customers that have 100 or 200 clients but we also have customers that have 20,000 endpoints. They are using several different appliances. Two devices for internet edge, two devices for core infrastructure, and two devices for VPN. We help customers of all sizes.

First you have to configure the Firepower Device Manager, or Firepower Management Center. When you bootstrap it or do the initial config, you type in the IP address, host name, and DNS. When you have the IP configuration in place, you can log in to the Firepower Management Center and start building policies that suit your needs. When you have all the policies, you can add or join Firepower devices to the Firepower Management Center. After adding the devices to the Firepower Management Center, you can then apply the policies that you built in the first place, through the devices, and that will affect the behavior on the devices.

ASA is best for VPN solutions, site to site, remote access VPN. It's for everything that is connected with VPN solutions. For every other feature, Firepower is better. While Firepower is getting better for VPN, it's not where it should be yet.

I have tried configuring Zyxel firewalls. I have never logged in to Check Point or Palo Alto. From my point of view, Firepower is better than Xyxel when it comes to application visibility and control.

I did use competitive solutions many years ago, so things might have changed with them. But I would say that Cisco Firepower is a bit more complicated if you are an inexperienced user. If you are setting up a firewall for the first time, other vendors have an approach that makes it easier. Cisco Firepower it's more detailed and you can do more complicated configurations than you can with some competitors. It is easier for us to approach customers with Cisco Firepower, because we can do more detailed configurations compared to what customers can get from other vendors.

With SecureX, you can get more value out of the product, especially if you're using all the security features from Cisco. In that situation, you will definitely get more out of SecureX. When you do that you can integrate all of your Cisco products into SecureX and you can correlate all the data in one place, with a single pane of glass. In that way, you get a lot more value for money with Cisco Firepower and SecureX. You will get the full value if you combine it with other products, but if you only have Cisco Firepower then SecureX will not provide that much added value.

Have a plan. Find out how much bandwidth and throughput you need before you implement it because if you don't scale it well from the start, it can slow down your environment. Keep in mind that it adds so much security that the total data throughput can take a hit. 

We have many customers, but in general, many of our customers are using all the tools they can to secure their infrastructure, such as AMP, Umbrella, and Firepower. Many companies are doing what they can to secure their network and their infrastructure. But there are also customers that only have a firewall. In today's world that's not enough to secure the network at all, but that's a decision the customer has to live with. We have tried to push them in the right direction. But the majority of our customers have a secure infrastructure.

The other Cisco products or services our customers are using in conjunction with their firewall include AMP, AnyConnect, cloud mail Email Security Appliances, Cisco ISE, and Web Security Appliances. We are only a Cisco partner. We don't do HP or Check Point or Palo Alto, so our customers do have a lot of Cisco features. For regular use, the integration among these Cisco products is pretty easy, but I have also worked with these products a lot. But it's easy to implement a firewall solution on Firepower and you can tweak it as much as you like. ASA is also easy to set up and configure, in my opinion, but I'm a security professional. For a regular user, both products can be pretty cumbersome.

Firepower 7.0 gives you visibility into how it inspects the packets, but it's tough to say how deep or how much visibility you get. However, if you have a Layer 4 firewall, it is clear that a Layer 7 firewall gives you more visibility, and you can see the packets that the application connection is using, meaning which application is using them. It's not how much visibility you get but, rather, the fact that you get Layer 7 visibility.

Cisco Secure Firewall has reduced our operational costs because it is faster to deploy configurations to firewalls. But when using it, it's more or less the same as it was before 7.0. The amount of time it saves when deploying configurations depends on how often you deploy policies or how many changes you have. But if you compare 7.0 to earlier versions, deployment time has been reduced from five to 10 minutes down to two to five minutes. If you make all the changes at once and only do one deployment, the time saved is not that big of a deal. But if you do one change and deploy, and another change and deploy, and another change and deploy, you will save more time.

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.

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.

I'm a solution architect specializing in IT infrastructure designs. I create solutions for clients using Cisco and other products. I've developed solutions with various Cisco Firewall models. I may use an entry-level solution for smaller businesses, like the Cisco 555 Series or 5500. If it's a large enterprise, I may use the 4000 Series, or an ISR router integrated with a firewall for a branch office, and maybe an ISR router, which is integrated with the firewall.

I work with businesses of all sizes, but I see Cisco more often in medium-sized companies or large enterprises. Small businesses often pick Sophos or FortiGate because of the pricing. Large enterprises use Cisco and other products like Palo Alto or Check Point, especially for managing cloud architectures like GCP and AWS. 

If the customer only needs a plain firewall, Cisco ASA is sufficient. It can compete with FortiGate or Sophos. When I talk about a next-gen firewall, the basics include malware protection, instruction prevention, URL filtering, etc. Firepower is integrated to address these next-gen requirements. 

I may use the tabs for dynamic policy implementation in cloud environments depending on the clients' needs, but not typically VMware. I might get a false positive with the VMware operator and platform layer. If I stop some surveys, my production will stop. In such cases, I cannot just go by dynamic classification blindly. It would be better for the application layer, not the platform layer.

I don't have any metrics about how ASA has improved operations for my clients, but I can look at their market share relative to Check Point and other competitors. Cisco has a decent footprint today, and it reduced my customers' CapEx. I don't have the numbers. I'm just speaking relatively. Cisco can reduce operational expenditures by around 40 percent. I'm just giving a vague estimate, but I don't have any specific metrics.

Cisco offers two architectures. I can choose the Meraki track if I want an OpEx model or the traditional track, which is a CapEx model. Due to Cisco's tech acquisitions, I have various feature options within the same product. The DNA of Cisco combines the traditional Cisco architecture with the next-generation firewall.

Segmentation can be helpful for some clients. Let's use a financial organization as an example. We have traffic moving through the branch to the core banking. This is where we can employ segmentation. We can do security policy restrictions for branch employees to prevent them from accessing certain financial reporting systems. We can limit them to the branch level. 

I can enforce certain policies to prevent all branch traffic from reaching one layer of a particular segment by minimizing the overall traffic on the network. I can always control the traffic when I segment it. This set of capabilities is beneficial when a lot of financial algorithms are done.

ASA integrates with Firepower, IPS functionality, malware filtering, etc. This functionality wasn't there in the past. With its cloud architecture, Cisco can filter traffic at the engine layer. Evasive encryptions can be entered into the application, like BitTorrent or Skype. This wasn't possible to control through a traditional firewall. 

Deep Packet Inspection looks at the header information and inspects the contents of a particular packet. We can also look at traffic management. It can control end-user applications, and we can check device performance when we do this type of regression on our resources. This is what we look at with a DPI. It can help us reduce the overall OpEx and CapEx.

Traditionally, we needed multiple software and hardware tools. With these features, we can snoop into our network and understand each packet at a header level. That's called the service control engine.

Within Cisco's Service Control Engine Architecture, there's something called the Preferred Architecture, which has a supervisor engine. It's more of a network management tool. Cisco makes it more convenient to manage our resources. It has a nice UI, or we can go into the command-line level. 

Cisco's micro-segmentation features are helpful for access control layers and virtual LAN policy enforcement. That's how we segregate it. Micro-segmentation is focused on the application layer. When we design a policy that is more automated or granular, and we have a specific business requirement, we get into micro-segmentation. Otherwise, the majority of the implementation will be generic network segmentation.

Dynamic classification is also essential given the current security risks and the attacks. We cannot wait for it to tell us if it's a false positive or a real threat. In those cases, dynamic classification is essential, especially at a MAC level.
When using WiFi, we may have a suspicious guest, and we cannot wait for someone to stop it manually. The firewall needs to at least block the traffic and send an alert.

In cases like these, integration with Cisco ISE is handy. If the firewall alone doesn't help, you must redesign your architecture to include various associated products as you increase your requirements. For example, you may have to get into multiple servers, so you'll need an ISE for identity management. 

As you start scaling up your requirements, you go beyond a firewall. You start from an L1 layer and go to the L7 sitting at the organization's gateway. When you talk about dynamic policy implementation, that's where you start to get serious about your operations and can change things suddenly when an attack is happening.

With ISE integration, you get another dynamic classification if an endpoint connects immediately. ISE has a lot of authorization rules, so it applies a filter. The dynamic policy capabilities enable tighter integration at the application workload level. Snort 3 IPS enables you to run more rules without sacrificing performance, and IPS puts you one step ahead of any threats to the organization.

There are some limitations with SSL. Regarding the security assessment for the ISO 27000 standard, there are certain features that Cisco needs to scale up. Not all products support it, so we need to be slightly careful, especially on the site track. 

We face challenges with Cisco when implementing some security vulnerability assessments, including the algorithms and implementing SSL 3.0. I may change the entire product line because traditional product lines don't support that.

Integration isn't typically a problem because the network is compatible, but Cisco could upgrade the threat database. They could integrate the threat database of the on-premise firewall with the cloud. Check Point has cloud integration with a market database of all the vulnerabilities. Cisco could add this to its roadmap to make the product more effective.

I have been working with firewalls for about 20 to 25 years, but I've been using Cisco for around 12 to 15 years.

Cisco ASA Firewall is reliable, especially in the Indian context. For example, I had a couple of banks with around 5,000 branches and ATMs. It was easy to deploy remotely or send it to each branch. 

Cisco ASA Firewall is scalable to a certain extent.

Cisco support is okay, but not great. I rate Cisco support five out of ten. The response time is too long. We need an instant response to security issues. They follow some legacy processes.

In some cases, I think they're good, but they have hundreds of questions and steps to go through before the ticket is escalated. The local partner adds a lot of value in that case.

Neutral

The standard setup is straightforward and takes around four hours. You can also do more customization and adjustments to deploy it in a particular environment.
I design a custom implementation strategy for each customer. It depends on whether I'm migrating an existing environment or doing a fresh deployment. I try to understand the customer's security footprint and all the issues I need to address before installation. 

I think Cisco's price is in the right space now. They have discounts for customers at various levels. I think they're in the right spot. However, Cisco can be expensive when you factor in these additional features. 

If you add SecureX, Cisco's cost will definitely jump. We started with the standard ASA, then we added segmentation and micro-segmentation, and now we're talking about automation and unified architecture. SecureX is an integrated security portfolio. It gives a vertical and 360-degree algorithm with an open, integrated platform that can scale.

In most next-generation products, the UA itself will manage a lot of things, but it's easier to find people with expertise. If you put 10 firewall experts in the room, six will be talking about Cisco, but you can hardly find one or two people talking about Check Point or Palo Alto. Others would be more talking about Sophos, FortiGate, etc.

I rate Cisco ASA Firewall seven out of ten. If you're implementing a Cisco firewall, you must be crystal clear about your business requirements and how a Cisco ASA firewall will address your problem. You need to understand whether this product line contains all the features you need. 

Can it pass a security audit? Does it integrate with your network device? How scalable is it? Will this solution you're implementing today be adequate in the next three years? These are the questions that you should ask.