Cisco Secure Firewall Reviews

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

It is for defense, protecting workloads from a distributed type of an environment. On-premises, we are hosting several different distributed user session type environments. In our case, it is remote desktop services, which enable users to go out and browse the Internet, in some cases to do legitimate services, and in other cases, it is more of a personal browsing session. In this case, the primary purpose is to protect those user sessions when they are accessing the Internet. The secondary use case is to protect these services and applications from inbound threats, e.g., Internet scanning, Internet exploit attempts, any sort of attack, reconnaissance, or anything of that nature coming from the public Internet.

Firepower is an add-on to Cisco ASAs that enables intrusion prevention detection and some additional advanced functionalities. We have both.

We have two on-premise data centers where Firepower is deployed.

In terms of logging, that has been a big benefit because it is a fairly straightforward and easy process to log results. We stream through a folder and that information goes out to Splunk. It delivers immediate value. While Firepower reporting is generally pretty good, there is some delay, as far as when information shows up and updates the internal Firepower reporting mechanism. What we found is if this information is streamed into a SIEM, then it can immediately apply additional enrichment on top of it and build slightly more relevant, near real-time reporting, in comparison to doing it directly from Firepower. In terms of value for Firepower data, the ability to stream that out as a log, then characterize and enrich it within the SIEM that is where we gain the most value from a security perspective.

The solution’s ability to provide visibility into threats is good. Combined with Cisco's own trend intelligence characterization as well as the creation and application of that sort of tag into the stream of data that Firepower detects, that immediately tells us which threat type it is: 

• Does it belong to a threat group? 
• Is it an IP block list?
• Is it a URL block list? 
• Is it a known threat? 
• Which threat list does it belong to?

All this additional information is definitely useful. We treat it personally as set and forget because we are in the block mode - intrusion prevention mode. We don't let threats in. We err on the side of being overly protective. This is opposed to letting in threats, then detecting, identifying, and taking action on stuff that got through. Instead, we just block it. In our day-to-day operations, normally what was blocked is generally useful, but it's not operationally important.

It is set up to automatically apply the blocks and use the threat intelligence delivered by Talos as well as the intrusion prevention rules. All of that is entirely automated.

It has improved our organization's security posture dramatically. It has definitely given us modern protection and peace of mind in terms of attacks against our infrastructure from known or emerging threats, so we can be protected against them.

Intrusion prevention is its most valuable feature because of its effectiveness. Cisco is the largest security company and one of the largest threat intelligence services with Talos. Cisco can identify and immediately apply any new threat information into signature sets for their Intrusion Prevention tools, including endpoint. In our case, we are talking about Firepower. That scope is what results in is an almost immediate application of application prevention signatures against any upcoming network attacks. So, if there is a new vulnerability, some sort of high critical value globally, the Cisco team is typically able to identify and write corresponding detection or prevention signatures, then apply them across their toolset.

It is one of the fastest solutions, if not the fastest, in the security technology space. This gives us peace of mind knowing that as soon as a new attack comes online that we will be protected in short order. From that perspective, no one really comes close now to Firepower, which is hugely valuable to us from an upcoming new attack prevention perspective.

We are using Cisco Cloud Email Security and DNS security from Cisco as well as endpoint protection. The integration between these products is pretty good. The benefit is the ability of all these disparate tools to talk to each other and be able to take action, sort of feeding each other with newly intelligent detection mechanisms and passing that information on to the next tool, then taking action on that next tool based on information identified on the first tool. That is really the biggest benefit of using the ecosystem. So, we've optimized it. We leveraged Cisco's tech response, which connects with each of these tools. We definitely find value every day.

It was very easy to integrate with the SIEM, which is really our primary use case. Besides the Cisco ecosystem, it is integrating with a standalone separate SIEM solution, which is Splunk in our case. This was an easy, simple approach to accomplish. We had no issues or problems with that.

Try to understand if there is a need, e.g., if there is a need to log this information, get these logs out, and forward to some sort of a SIEM technology or perhaps a data store that you could keep it for later. There is limited data storage on the appliance itself. So, you need to ship it out elsewhere in order for you to store it. The only point of consideration is around that area, basically limited storage on the machine and appliance. Consider logging it elsewhere or pushing it out to a SIEM to get better controls and manipulation over the data to generate additional metrics and visibility.

In some cases, I could see how SIEM is not an option for certain companies, perhaps they either cannot afford it, or they do not have the resources to dedicate a security analyst/engineer who could deploy, then manage the SIEM. In most cases, Firepower is a useful tool that a network engineer can help set up and manage, as opposed to a security engineer. To make the solution more effective and appealing, Cisco could continue to improve some of the reporting that is generated within the Firepower Management Console. Overall, that would give a suitable alternative to a full-fledged SIEM, at least on a network detection side, application identification side, and endpoint identification and attribution side. Potentially, a security analyst or network engineer could then simply access the Firepower Management Console, giving them the visibility and data needed to understand what is going on in their environment. If Cisco continues to improve anything, then I would suggest continuing to improve the dashboarding and relevant operational metrics present within the platform, as opposed to taking those logs and shipping them elsewhere.

About four years.

Once it is deployed, not much staff is required as long as the intrusion rules are specifically configured to automatically update. That is the primary thing. Then, the continuous periodic updates from Cisco apply operating system patches just to make sure that critical vulnerabilities are patched and operating system optimization is applied routinely. Strategy-wise, I would patch quarterly unless there was a critical vulnerability that Cisco would discover, then apply a patch against it. At which point, we would then patch our appliance.

The stability is very good. As far as I can tell, we don't have any issues with availability or stability.

Cisco accounts for scalability by having different hardware recommendations, depending on what the throughput is, the required coverage is in terms of number of devices, the amount of traffic, etc. In our case, I don't see any issues. We are appropriately sized, but I could see how if someone's environment doubles, then someone should account for that by either procuring another appliance and separating some of the traffic flows or getting a bigger, more powerful system that can handle increase in throughput.

We try fitting to an ecosystem mentality. For example, we have four different Cisco products, which is technically a single ecosystem. If you were to think of it that way, then it is four different tools from Cisco. Then, there are two additional ones on the network, which makes six. There are additional two or three for an endpoint, plus another two or three for email, and another two or three for identities. So, I would say there are probably around 20 security solutions total.

The network team as well as the security team use it. Combined, that is approximately six people.

We are perfectly sized. I don't think there will be a need to increase the footprint or anything like that, at least for a while.

I know that people typically say TAC is hit or miss. In my case, it was always a good experience. Whether it was Firepower related for licensing questions or email, I have never had any issues with Cisco TAC.

Cisco Talos is very good. They are very well-regarded and well-known. I respect the team. They know what they are doing. They are one of the best overall. They are probably the best threat intelligence organization out there. Their visibility is unparalleled, because the data that Cisco has access to and the telemetry that it's able to gather are quite amazing.

Almost all networks globally in the world are built with the Cisco products. The telemetry that it generates gives Cisco unparalleled visibility, and Talos steps into that. They are able to apply their analytics over that data and identify emerging threats before practically anyone else, but Microsoft. From that perspective, my organization appreciates what Talos is able to do. Cisco's intelligence is delivered through Talos, applying it to other products that are not Cisco, but we haven't gone down that path yet.

We started with Firepower. It was one of the first products that helped secure our organization. We are close to sort of an advanced maturity, primarily compliance-driven. We are not there yet, but we are close to it. We are somewhere sort of in the high to middle area. We have sort of a high compliance-driven security and close to the compliance-driven area, but still slightly below it. We are still fine-tuning and implementing some security technologies. Then, within a year's time, these will be simply managed and audited.

In my current place, I did not help set it up, but I did set it up previously as a dedicated intrusion detection and prevention tool with another security engineer. Honestly, the setup was pretty straightforward. This was a couple of versions behind. It definitely has well-understood requirements from a virtual machine and resources required perspective. No questions that came up.

For the dedicated intrusion appliance, we needed to identify where the most benefit would come from, so we identified the network space. The sort of choke point where we could apply the Firepower appliance in order to inspect the most traffic. In terms of efficiencies, the primary goal was to identify how to maximize the visibility using Firepower. We deployed it in a choke point and ensured that most of the traffic for the company goes through this intrusion appliance and the initial deployment occurred in a visibility mode only - No blocking, intrusion detection only. Then, with time, as we got comfortable with all the traffic that was being seen with a signature application across the traffic and understood the chances for false positives were low to none. At that point, we put it into prevention.

If we needed to address something with Cisco directly regarding Firepower support, that was also addressed fairly quickly with no issues.

The automated policy application and enforcement saves us at least a third of an FTE per day. In terms of time, that is about 30 percent per day. By deploying the solution, we are saving $600 a week, which is significant.

In some cases, resources, like a security engineer, are actually hard to come by because they are expensive. Substituting some of that engineering time with an effective technology, like Firepower, is probably a good strategy.

I know that licensing for some of the advanced solutions, like Intrusion Prevention and Secure Malware Analytics, are nominal costs. 

I have used one of Cisco's competitors and am fairly familiar with it: Palo Alto. I am also familiar with the Barracuda solution. I would say Palo is comparable with Firepower to some degree. The Barracuda solutions that I've used are nowhere near as close in terms of capability, metrics, user interface, or anything like that to Cisco.

Palo Alto and Cisco are about the same in terms of application visibility, user assignments, and attributions. They are comparable. On the threat side is where I think Firepower is better. It's able to identify and characterize better. It's also able to deliver metrics around that information in a clearer fashion. As an example, it is easier to extract fields and values in the log. It seems that the design of the appliance was focused around security, which is evident in how that information is being presented, both in the Firepower Management Console as well as in the log.

On the IT infrastructure side, we are using Cisco hardware for the network. Then, as a security team, we are looking at adding Cisco's incident response solution, but we have not done it yet.

Firepower provides us with application visibility and control. We don't utilize it to the fullest extent. We rely on some additional tools like DNS, to identify applications being used across our endpoints. However, the Firepower deployment primarily protects the servers. So, on the servers, it is a controlled environment. Therefore, we do know the applications and services being used and deployed out of the servers.

Applying something like this to protect yourself from the Internet, which is where most of the threats come from, besides email. It guarantees that you are able to refocus your energy on internal processes: endpoints, people, etc. Intrusion Prevention is effective because it helps security teams refocus their efforts to build out other components, such as security pillars of the organization.

The solution is effective. My initial exposure to Cisco started through Firepower, since then I have understood that Cisco is moving towards an ecosystem approach. Basically, Firepower represents what I think Cisco stands for.

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

It does what it needs to do and does it great with a good sense of confidence, allowing the team and me to focus on other things. If needed, we can always leverage that data to derive different values from it.

I've deployed them in a number of different use cases. I've deployed them at the internet edge. I've used those VPN concentrators, and I've deployed them at the data center core, segmenting VLANs.

We've seen a lot of improvements in terms of cybersecurity resilience and securing our infrastructure from end to end so that we can detect and remediate threats. The visibility with FMC is excellent. Being able to have, for instance, a data center core firewall, an internet edge firewall, and a VPN concentrator device managed by the same FMC and being able to take all of that information and see it in one place is very beneficial from the security posture standpoint. It's a time saver because it makes things easy. I can log in and very easily see what my detected threats are, what's been happening over the last 24 hours, or if there's anything I need to be concerned about. Being able to see who's logging into the VPN, but also what traffic are they sending, what are they bringing back, and being able to have all that in one place is really nice. The integration between the FMC and endpoints is a nice feature and a big time saver in terms of remediating threats and remediating malware and other malicious software.

FMC is very good in terms of giving a lot of visibility into what the firewall is seeing, what it's stopping, and what it's letting through. It lets the administrator have a little bit of knowledge of what's coming in or out of the device. It's excellent.

The policies module in FMC specifically isn't the most user-friendly. Coming from Cisco ASA, Cisco ASA is a little bit easier to use. When you get into particularly complex deployments where you have a lot of different interfaces and all that kind of stuff, it's a little bit tricky. Some usability improvements there would be nice. 

For scalability, they could support a little bit more diverse deployments around clustering and high availability. Currently, it's very active standby, and being able to do a three firewall cluster or four or five firewall cluster would suit some of my deployments a little bit better. It would also help to keep the cost down for the customer because you're buying smaller devices and clustering them versus larger devices.

I've been using Cisco firewalls for fifteen years at least. I've been using them in some form or another, such as from ASAs and now FTDs and Firepower.

Its stability is excellent. In the last six months, I've probably deployed about 14 Cisco Secure Firewall devices, and I am yet to get a callback. I deploy them, and then the customer takes ownership of the device, and they're off to the races and ready to go. They've been stable, which is good. I don't like devices that break the week after I install them and make me look bad.

I've implemented them anywhere from a 500 MB throughput device up to a 20 GB throughput device. Particularly around scalability, some improvements in terms of clustering would be good.

I've called Cisco TAC many times throughout my career, and I never hesitate to do it. They've always been fantastic for me. I'd rate them a ten out of ten.

Positive

I've used a number of other competitive devices. I've customers running SonicWall, I've customers running Palo Alto, and I've customers running Fortinet. Cisco Secure Firewalls are excellent.

Cisco is at a really good place, especially with a lot of the recent updates that have happened. Compared to Palo Alto and Fortinet specifically, I find FMC is way easier to use. Specifically in the realm of cybersecurity resilience, it's for sure a much more effective tool than Palo Alto. Having come from Palo Alto, the way FMC surfaces threats and enables response to set threats is vastly easier for me and my team to work with, so we're seeing a lot more resiliency. We're seeing a lot quicker response to threats. We're seeing a lot quicker identification of threats. From that perspective, it's far and away better.

Cisco Secure Firewall is the best in the market right now. Palo Alto is okay, but Cisco is better. In terms of resiliency and providing actionable intelligence to a security team, I find Cisco products to be way better. Fortinet is also fairly easy to use. They have a lot of the same strengths. However, Fortinet's technical support is terrible. Cisco has a nice package of devices. It's easy to use. It's easy to integrate for the security team. It gives you a lot of actionable intelligence in your network. Having that kind of company and technical support to be able to back that up and be able to support the customers is very useful.

I've deployed them countless times, and I find it very easy. I did a high availability pair of internet edge firewalls for a 2,000 users organization migrating from Palo Alto, and I moved them over with AnyConnect, Umbrella, and Duo from Palo Alto in a week and a half with no downtime. I do a lot on-prem just because of my verticals. I work a lot in law enforcement. I work a lot in government, and those end up being very on-prem heavy. 

It's pretty competitive. If they could make it cheaper, it would be great. You always want cheaper, but relative to the performance capabilities of the firewall and relative to what you get, it's fair.

It's not the cheapest in the world, but you get an excellent product for that price. The onus is on us as a customer to look at what we're buying and establish not just the price but the value. You need to look at what you're getting for your dollars there. Cisco has a very good proposition there.

Its licensing is pretty good. It's not very complex. There are not a million different SKUs. I had a Palo Alto deployment where the customer had asked for a license for integration with their Cortex XDR, and they didn't include it. It was eight more SKUs and eighty thousand dollars more. It was a real disaster, and it can put a customer off from using Palo Alto. Cisco's licensing model is easy to understand whether it's apps or VPN. The way that they handle the subscriptions is very easy to understand. It's very fair.

To someone researching this solution who wants to improve cybersecurity in their organization, I'd say that the main thing to look for is usability. Find something that you can understand and that provides you with actionable intelligence because a security device that's not administered and monitored properly isn't going to do much for you. It's not going to be very effective. So, you want a device that's easy to use and that gives you a lot of that visibility and makes your job as a security administrator easy. It should make identifying and responding to threats as seamless as humanly possible because the quicker you can respond, the more security you're able to keep in your organization.

Cisco Talos is an excellent product. I've been using Cisco Talos since Cisco introduced it. In fact, I was a Sourcefire customer before Cisco acquired them, so I'm very familiar with the roots of that team and where it's from. I've been all in on them since day one.

Overall, I'd rate Cisco Secure Firewall a nine out of ten. There's always room for improvement, especially in security because the security world is changing on a daily basis. We're always looking for what can we do better and how can we improve, but what Cisco has done since the Sourcefire acquisition and where they've taken it, I'm very excited for the future.

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.

I am a system engineer, and I've been looking for some details and competitive information regarding the standards of this firewall and similar technologies.

There is a good relationship between real throughput, meaning the root performance, and the data sheet performance. When comparing it to other vendors, the data sheet performance is often more than expected and more than the real performance. It includes features like IPS, malware protection, and other security features.

The management usability and security of Cisco Firewall are based on Firepower Management Center, which is quite out of date compared to other vendors.

I have used this solution for more than ten years.

The SLA is great, and the escalation process is also great. For example, if I have a priority one case, I am able to call the manager to raise the severity, etc. So the SLA is very good.

Neutral

When compared with other competitors like Palo Alto or Fortinet, Cisco stands in a good position regarding the firewall environment. Compared to Fortinet, Cisco is a bit higher. When comparing with Palata and Juniper, Cisco has the same price level.

I am well prepared, and it is quite easy. Cisco has really great documentation, like a deployment guide and a quick start guide, etc.

If engineers are well prepared, it is good to note that Cisco has really great documentation. I have been working with AI features in the Cisco environment with Cisco Firewall, etc. I have been hearing and reading a lot about the integration of AI capabilities into Cisco devices, but I have not worked with that yet.

Overall, I would rate this an eight out of ten.

We use them for perimeter defense and for VPN, and we also do web filtering.

We're using ASAs at the moment. Going forward, we'll probably look at the FirePOWERs. We currently have anywhere from low end to the mid-range, starting with 5506s all the way up to 5555s. Everything is on-prem.

We have a total of five different security tools in our organization. A couple of them complement each other so that's one of the reasons that we have so many, instead of just having one. For an organization like ours, it works out pretty well.

We are a utility owned by a municipality, with a little over 200 employees in multiple locations.

Our response time has improved considerably. Rather than getting an alert from an antivirus which could be instantaneous or missed, we can take a look at the console of the Sourcefire Defense Center and identify the device. We can peek into it and see the reason it was tagged, what kind of event it encountered. We can then determine if it was something legit — a false positive — or a positive.

It has improved the time it takes to do mediation on end-user devices. Instead of it being anywhere from ten to 15 to 30 minutes, we can potentially do it within about five minutes or under, at this point. In some cases, it can even be under a minute from when the event happens. By the time end-user gets a message popping up on their screen, a warning about a virus or something similar from one of the anti-malware solutions that we have, within under a minute or so they are isolated from the network and no longer able to access any resources.

For us, the most valuable features are the IPX and the Sourcefire Defense Center module. That gives us visibility into the traffic coming in and going out and gives us the heads-up if there is a potential outbreak or potential malicious user who is trying to access the site. It also helps us see traffic generated by an end device trying to reach out to the world. 

Sourcefire is coupled with Talos and that provides us good insight. It gives us a pretty good heads-up. Talos is tied to the Sourcefire Defense Center. Sourcefire Defense Center, which is also known as the management console, periodically checks all the packets that come and go with the Talos, to make sure traffic coming and going from IP addresses, or anything coming from email, is not coming from something that has already been tagged in Talos.

We also use ESA and IronPort firewalls. The integration between those on the Next-Gen Firewalls is good. They are coupled together. If the client reports that there is a potential for a file or something trying to access the internet to download content, there are mediation steps that are in place. We don't have anything in the cloud so we're not looking for Umbrella at this point.

We've seen, for a while, that the upcoming revisions are not supported on some of 5506 firewalls, which had some impact on our environment as some of our remote sites, with a handful of users, have them. 

We were also not too thrilled when Cisco announced that in the upcoming new-gen ASA, iOS was not going to be supported, or if you install them, they will not be able to be managed through the Sourcefire. However, it seems like Cisco is moving away from the ASA iOS to the Sourcefire FireSIGHT firmware for the ASA. We haven't had a chance to test it out. I would like to test it out and see what kind of improvements in performance it has, or at least what capabilities the Sourcefire FireSIGHT firmware is on the ASA and how well it works.

With the main firewall we haven't had many issues. It's been pretty stable. I would rate it at 99.999 percent. Although I think it's very well known in the industry that there was a clock issue with the 5506 and the 5512 models. Their reliability has been far less. I wouldn't give those five-nine's. I would drop it down to 99 percent. Overall, we find the product quite stable.

We are a very small environment. Based on our scale, it's been perfect for our environment.

Their tech support has been pretty good. If the need arises, I contact them directly. Usually, our issues get resolved within 30 minutes to an hour. For us, that's pretty good.

We were using multiple products in the past. Now, we have it all centralized on one product. We can do our content filtering and our firewall functions in the same place. The ASAs replaced two of the security tools we used to use. One was Barracuda and the other was the because of tools built into the ASAs, with IPX, etc.

When we switched from the Barracuda, familiarity was one of the biggest reasons. The other organizations I've worked in were pretty much doing Cisco. I'm not going to deride the Barracuda. I found it to be pretty close, performance-wise. In some cases, it was pretty simple to use versus the Sourcefire management console. However, when you went into the nitty gritty of things, getting down to the micro level, Sourcefire was far ahead of Barracuda.

We found the initial setup to be pretty straightforward the way we did it. We ended up doing one-on-one replacement. But as the environment grew and the needs grew, we ended up branching it off into different segmentations.

Going from two devices to five devices took us a little over a year. That was all at one location though. We branched it off, each one handling a different environment. 

For the first one, since it was new to us and there were some features we weren't familiar with, we had a partner help us out. Including configuring, install, bringing it into production, and going through a learning process — in monitoring mode — it took us about two to three days. Then, we went straight into protective mode. Within three years we had a Sourcefire ruleset on all that configured and deployed.

It was done in parallel with our existing infrastructure and it was done in-line. That way, the existing one did all the work while this one just learned and we watched what kind of traffic was flowing through and what we needed to allow in to build a ruleset.

It took three of us to do the implementation. And now, we normally have two people maintain the firewalls, a primary and a secondary.

We use JKS Systems. We've been with them for 16-plus years, so our experience with them has been pretty good. They help with our networking needs.

On the engineering side we have definitely seen ROI. So far, we haven't had much downtime in our environment.

Pricing varies on the model and the features we are using. It could be anywhere from $600 to $1000 to up to $7,000 per year, depending on what model and what feature sets are available to us.

The only additional cost is Smart NET. That also depends on whether you're doing gold or silver, 24/7 or 8/5, etc.

The biggest lesson I've learned so far from using the next-gen firewall is that it has visibility up to Layer 7. Traditionally, it was IP or port, TCP or any protocol we were looking for. But now we can go all the way up to Layer 7, and make sure STTP traffic is not a bit torn. That was something that we did not have before on the up-to-Layer-3 firewall.

Do your research, do your homework, so you know what you're looking for, what you're trying to protect, and how much you can manage. Use that to narrow down the devices out there. So far, in our environment, we haven't had any issues with the ASA firewalls.

From the first-gen, we have seen that they are pretty good. We are pretty content and happy with them.

The solution can help with the application visibility and control but that is one portion we have really not dived into. That's one of the things we are looking forward to. As a small utility, a small organization, with our number of employees available, we can only stretch things so far. It has helped us to identify and highlight things to management. Hopefully, as our staff grows, we'll be able to devote more towards application visibility and all the stuff we really want to do with it.

Similarly, when it comes to automated policy application and enforcement, we don't use it as much as we would like to. We're a small enough environment that we can do most of that manually. I'm still a little hesitant about it, because I've talked to people where an incident has happened and quite a bit of their devices were locked out. That is something we try to avoid. But as we grow, and there are more IoT things and more devices get on the network, that is something we'll definitely have to do. As DevNet gets going and we get more involved with it, I'm pretty sure more automation on the ASA, on the network side and security side, will take place on our end.

We do find most of the features we are looking on the ASA. Between the ASA firewall and the Sourcefire management console, we have pretty much all the features that we need in this environment.

In terms of how the solution future-proofs our organization, that depends. I'm waiting to find out from Cisco what their roadmap is. They're still saying they're going to stick with ASA 55 series. We're also looking at the Sourcefire FireSIGHT product that they have for the firewalls. It depends. Are they going to continue to stick with the 55s or are they going to migrate all that into one product? Based on that, we'll have to adjust our needs and strategize.

If I include some of the hiccups we had with the 5506 models, which was a sad event, I would give the ASAs a nine out of ten.

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.

These are our primary edge firewalls at two data centers.

Today I was able to quickly identify that SSH was being blocked from one server to another, and that was impacting our ability to back up that particular server, because it uses SFTP to back up. I saw that it was blocking rule 22, and one of the things I was able to do very quickly was to take an existing application rule that says 22, or SSH, is allowed. I copied that rule, pasted it into the ruleset and edited it so that it applied to the new IPs — the new to and from. I was able to analyze, diagnose, and deploy the fix in about five minutes.

That illustrates the ability to utilize the product as a single pane of glass. I did the troubleshooting, the figuring out why it was a problem, and the fix, all from the same console. In the past, that would have been a combination of changes that I would have had to make both on the ASDM side of things, using ASDM to manage the ASA rules, as well as having to allow them in the FMC and to the FirePOWER.

Overall, as a result of the solution, our company's security posture is a lot better now.

With the FMC and the FirePOWERs, the ability to quickly replace a piece of hardware without having to have a network outage is useful. Also, the ability to replace a piece of equipment and deploy the config that the previous piece of equipment had is pretty useful. 

The administration is a little easier on the FirePOWER appliances because we're not using two separate products. For example, in the ASAs with FirePOWER Services, we were using the FMC to manage the FirePOWER Services, but we were still using ASDM for the traditional Layer 2 and Layer 3 rulesets. That is all combined in FMC for the FirePOWER devices.

Our particular version includes application visibility and control. Most next-gen firewalls do. The product is maturing with what they call FirePOWER Threat Defense, which is the code that runs on the firewalls themselves. The FirePOWER Threat Defense software has matured somewhat. There were some issues with some older versions where they didn't handle things in a predictable manner. Applications that we didn't have a specific rule for may have been allowed through until it could identify them as a threat. We reorganized our rules, because of that "feature," in a different way so that those extra packets weren't getting through and we weren't having to wait so long for the assessment of whether they should be allowed or not. We took a different approach for those unknowns and basically created a whitelist/blacklist model where applications on the list were allowed through.

Then, as you progressed into the ruleset, some of those features became more relevant and we stopped this. We looked at it as "leaky" because it was allowing some packets in that we didn't want in, while it made the determination of whether or not those applications were dangerous. Our mindset was to assume they're dangerous before letting them in so we had to adjust our ruleset for that. As the product matures, they've come out with better best practices related to it. Initially, there wasn't a lot of best-practice information for these. We may have been a little early in deploying the FirePOWER appliances versus continuing on with the adaptive security appliances, the old PIX/ASA model of firewalls. Cisco proposed this newer model and our VAR agreed it would be a benefit to us.

There was a bit of a transition. The way they handle the processing of applications is different between the ASAs and the FirePOWERs. There were growing pains for us with that. But ultimately, the ability to have this configured to the point where I could choose a specific user and create a rule which says this user can use this application, and they'll be able to do it from whatever system they want to, has been advantageous for our functionality and our ability to deliver services more quickly.

There haven't been a lot of specific use cases for that, other than troubleshooting things for myself. But having the knowledge that that functionality is there, is helpful. Certainly, we do have quite a few rules now which are based on "this application is allowed, this whole set of applications is blocked." It does make that easier because, in the past, you generally did that by saying, "This port is allowed, this port is blocked." Now we can say, not the ports; we're doing it by the services, or instead of by the services we're doing it by the applications. It makes it a little bit easier. And Cisco has taken the step of categorizing applications as well, so we can block an entire group of applications that fall under a particular category.

For the most part, it's very good for giving us visibility into the network, in conjunction with other products that give us visibility into users as well as remote items. It's really good at tracking internal things, really good at tracking people, and really good at giving us visibility as to what's hitting us, in most situations.

In general, Cisco is doing a pretty good job. Since we started the deploy process, they've increased the number of best-practice and configuration-guidance webinars they do. Once a month they'll have one where they show how we can fix certain things and a better way to run certain things. 

The product continues to improve as well. Some of the features that were missing from the product line when it was first deployed — I was using it when it was 6.2 — are in 6.4. We had some of them in ASDM and they were helpful for troubleshooting, but they did not exist on the FirePOWER side of things. They've slowly been adding some of those features. They have also been improving the integration with ISE and some of the other products that utilize those resources. It's getting better.

Regarding the solution's ability to provide visibility into threats, I'm not as positive about that one. We had an event recently where we had inbound traffic for SIP and we experienced an attack against our SIP endpoint, such that they were able to successfully make calls out. There is no NAT for that. So we opened a case with the vendor asking how this was possible? They had to get several people on the line to explain to us that there was an invisible, hidden NAT and that is how that traffic was getting in, and that this was by design. That was rather frustrating because as far as the troubleshooting goes, I saw no traffic.

Both CTR, which is gathering data from multiple solutions that the vendor provides, as well as the FMC events connection, did not show any of those connections because there wasn't a NAT inbound which said either allow it or deny it. There just wasn't a rule that said traffic outside on SIP should be allowed into this system. They explained to us that, because we had an outbound PAT rule for SIP, it creates a NAT inbound for us. I've yet to find it documented anywhere. So I was blamed for an inbound event that was caused because a NAT that was not described anywhere in the configuration was being used to allow that traffic in. That relates to the behavior differences between the ASAs and the FirePOWERs and the maturity. That was one of those situations where I was a little disappointed. 

Most of the time it's very good for giving me visibility into the network. But in that particular scenario, it was not reporting the traffic at all. I had multiple systems that were saying, "Yeah, this is not a problem, because I see no traffic. I don't know what you're talking about." When I would ask, "Why are we having these outbound calls that shouldn't be happening?" there was nothing. Eventually, Cisco found another rule in our code and they said, "Oh, it's because you have this rule, that inbound NAT was able to be taken advantage of." Once again I said, "But we don't have an inbound NAT. You just decided to create one and didn't tell us."

We had some costs associated with those outbound SIP calls that were considered to be an incident.

For the most part, my impression of Cisco Talos is good. But again, I searched Cisco Talos for these people who were making these SIP calls and they were identified as legitimate networks. They had been flagged as utilized for viral campaigns in the past, but they weren't flagged at the time as being SIP attackers or SIP hijackers, and that was wrong. Obviously Talos didn't have the correct information in that scenario. When I requested that they update it based on the fact that we had experienced SIP attacks for those networks, Talos declined. They said no, these networks are fine. They should not be considered bad actors. It seemed that Talos didn't care that those particular addresses were used to attack us.

It would have protected other people if they'd adjusted those to be people who are actively carrying out SIP attacks against us currently. Generally speaking, they're top-of-the-game as far as security intelligence goes, but in this one scenario, the whole process seemed to fail us from end to end. Their basic contention was that it was my fault, not theirs. That didn't help me as a customer and, as an employee of the credit union, it certainly hurt me.

We've been using the FMC for about five years. We've only been using the FTD or FirePOWER appliances for about a year.

The stability is pretty good. We went through several code revisions from being on the ASAs on 6.2, all the way through the new FirePOWERs, moving them to 6.4.

Unfortunately, we had the misfortune of using a particular set of code that later was identified as a problem and we had a bit of an upgrade issue. We were trying to get off of 6.3.0 on to 6.3.0.3. The whole system fell apart and I had to rebuild it. I had to break HA. We ended up having to RMA one of our two FMCs. I'm only now, a couple of months later, getting that resolved.

That said, I've had six or seven upgrades that went smoothly with no issues.

The scalability is awesome. That's one of those features that this product adds. Not only does it scale so that we can add more firewalls and have more areas of deployment and get more functionality done, but we have the ability that we could replace a small-to-medium, enterprise firewall with a large enterprise firewall, with very little pain and effort. That's because that code is re-appliable across multiple FirePOWER solutions. So should a need for more bandwidth arise, we could easily replace the products and deploy the same rulesets. The protections we have in place would carry forward.

We hairpin all of our internet traffic through the data centers. Our branch offices have Cisco's Meraki product and use the firewall for things that we allow outbound at that location. Most of that is member WiFi traffic which goes out through the local connections and out through those firewalls. We don't really want all of the member Facebook traffic coming through our main firewalls. I don't foresee that changing. I don't see us moving to a scenario where we're not hairpinning all of our business-relevant internet traffic through the data centers. 

I don't foresee us adding another data center in the near future, but that is always an option. I do foresee us increasing our bandwidth requirements and, potentially, requiring an additional device or an increase in the device size. We have FirePOWER 2100s and we might have to go to something bigger to support our bandwidth requirements.

The previous usage was with an ASA that had FirePOWER services installed.

The transition from the ASA platform to the FirePOWER platform was a little difficult. It took some effort and there were some road bumps along the way. After the fact, they were certainly running all over themselves to assist us. But during the actual events, all they were trying to do was point out how it wasn't their fault, which wasn't very helpful. I wasn't interested in who was to blame, I was interested in how we could fix this. They wanted to spend all their time figuring out how they could blame somebody else. That was rather frustrating for me while going through the process. It wasn't as smooth as it should have been. It could have been a much easier process with better support from the vendor.

It took about a month per site. We have two data centers and we tackled them one at a time.

We set up the appliances and got them configured on the network and connected to the FirePOWER Management console. At that point we had the ability to deploy to the units, and they had the ability to get their code updates. At that point we utilized the Firewall Migration Tool that allowed us to migrate the code from an ASA to a FirePOWER. It was well supported. I had a couple of tickets I had to open and they had very good support for it. We were able to transition the code from the ASAs to the FirePOWERs.

It deployed very well, but again, some of these things that were being protected on the ASA side were allowed on the FirePOWER side; specifically, that SIP traffic. We didn't have any special rules in the ASA about SIP and that got copied over. The lack of a specific rule saying only allow from these sites and block from these countries, is what we had to do to fix the problem. We had to say, "This country and that country and that country are not allowed to SIP-traffic us." That fixed the problem. There is a certain amount missing in that migration, but it was fairly easy to use the toolkit to migrate the code.

Then, it was just that lack of knowledge about an invisible NAT and the lack of documentation regarding that kind of thing. As time has gone by, they've increased the documentation. The leaky packets I mentioned have since been added as, "This is the behavior of the product." Now you can Google that and it will show you that a few packets getting through is expected behavior until the engine makes a determination, and then it'll react retroactively, to say that that traffic should be blocked.

Certainly, it's expected behavior that a few packets get through. If we'd known that, we might have reacted differently. Not knowing that we should have expected that traffic made for a little bit of concern, especially from the security team. They had third-party products reporting this as a problem, but when I'd go into the console, it would say that traffic was blocked. But it wasn't blocked at first, it was only blocked now, because that decision had been made. All I saw is that it was blocked. From their point of view, they were able to see, "Oh, well initially it was allowed and then it got blocked." We were a little concerned that it wasn't functioning correctly. When you have two products reporting two different things, it becomes a bit of a concern.

We have probably not seen ROI yet. These are licensed under Cisco ONE and you usually don't see a return on investment until the second set of hardware. We're still on our first set of hardware under this licensing.

That said, our ASAs were ready to go end-of-life. The return on investment there is that we don't have end-of-life hardware in our data center. That return was pretty immediate.

The biggest lesson I have learned from using this solution is that you can't always trust that console. In the particular case of the traffic which I was used to seeing identified in CTR, not seeing that traffic but knowing that it was actually occurring was a little bit of a concern. It wasn't until we actually put rules in that said "block that traffic" that I started to see the traffic in the console and in the CTR. Overall, my confidence in Cisco as a whole was shaken by that series of events. I have a little bit less trust in the brand, but so far I've been happy with the results. Ultimately we got what we wanted out of it. We expected certain capabilities and we received those capabilities. We may have been early adopters — maybe a little bit too early. If we had waited a little bit, we might've seen more about these SIP issues that weren't just happening to us. They've happened other people as well.

The maturity of our company's security implementation is beyond the nascent stage but we're not what I would call fully matured. We're somewhere in the middle. "Fully matured" would be having a lot more automation and response capabilities. At this point, to a large extent, the information security team doesn't even have a grasp on what devices are connected to the network, let alone the ability to stop a new device from being added or quarantined in an automated fashion. From my point of view, posture control from our ISE system, where it would pass the SGTs to the FirePOWER system so that we could do user-based access and also automated quarantining, would go a long way towards our maturity. In the NISK model, we're still at the beginning stages, about a year into the process.

Most of our tools have some security element to them. From the Cisco product line, I can think of about ten that are currently deployed. We have a few extras that are not Cisco branded, three or four other items that are vulnerability-scanning or SIEM or machine-learning and automation of threat detection.

The stuff that we have licensed includes the AMP for Networks, URL filtering, ITS updates and automation to the rule updates, as well as vulnerability updates that the product provides. Additionally, we have other services that are part of Cisco's threat-centric defense, including Umbrella and AMP for Endpoints. We use Cisco Threat Response, or CTR, to get a big-picture view from all these different services. There's a certain amount of StealthWatch included in the product, as well as some of the other advantages of having the Cisco Talos security intelligence.

The integration among these products is definitely better than among the non-Cisco products. It's much better than trying to integrate it with non-Cisco functionality. That is probably by design, by Cisco. Because they can work on both ends of, for example, integrating our AMP for Endpoints into our FirePOWER Management Console, they can troubleshoot from both ends. That probably makes for a better integration whereas, when we're trying to troubleshoot the integration with, say, Microsoft Intune, it's very hard to get Cisco to work together with Microsoft to figure out where the problem is. When you have the same people working on both sides of the equation, it makes it a little easier. 

Additionally, as our service needs have progressed and the number of products we have from Cisco has increased, they've put us onto a managed security product-support model. When I call in, they don't only know how to work on the product I'm calling in on. Take FMC, for example. They also know how to work on some of those other products that they know we have, such as the Cisco Voice system or Jabber or the WebEx Teams configurations, and some of those integrations as well. So, their troubleshooting doesn't end with the firewall and then they pass us off to another support functionality. On that first call, they usually have in-house resources who are knowledgeable about all those different aspects of the Threat Centric defenses, as well as about routine routing and switching stuff, and some of the hardware knowledge as well. We're a heavy Cisco shop and it helps in troubleshooting things when the person I'm talking to doesn't know only about firewalls. That's been beneficial. It's a newer model that they've been deploying because they do have so many customers with multiple products which they want to work together.

In most cases, this number of tools improves our security operations, but recent events indicate that, to a large extent, the tools and their utilization, beyond the people who deployed them, weren't very helpful in identifying and isolating a particular issue that we had recently. Ultimately, it ended up taking Cisco and a TAC case to identify the problems. Even though the security team has all these other tools that they utilize, apparently they don't know how to use them because they weren't able to utilize them to do more than provide info that we already had.

We have other vendors' products as well. To a large extent, they're monitoring solutions and they're not really designed to integrate. The functionality which some of these other products provide is usually a replication of a functionality that's already within the Cisco product, but it may or may not be to the extent or capacity that the information security team prefers. My functionality is largely the security hardware and Cisco-related products, and their functionality is more on the monitoring side and providing the policies. From their point of view, they wanted specific products that they prefer for their monitoring. So it wasn't surprising that they found the Cisco products deficient, because they didn't want the Cisco products in the first place. And that's not saying they didn't desire the Cisco benefits. It's just they have their preference. They'd rather see Rapid7's vulnerability scan than ISE's. They'd rather see the connection events from Darktrace rather than relying on the FMC. And I agree, it's a good idea to have two viewpoints into this kind of stuff, especially if there's a disagreement between the two products. It never hurts to have two products doing the same thing if you can afford it. The best thing that can happen is when the two products disagree. You can utilize both products to figure out where the deficiency lies. That's another advantage.

For deployment, upgrades, and maintenance, it's just me.

We were PIX customers when they were software-based, so we've been using that product line for some time, other than the Meraki MXs that we're using for the branch offices. The Merakis are pretty good firewalls as well.

We also have access here at our primary data centers, but they're configured differently and do different things. The MXs we have at our data centers are more about the LAN functionality and the ability to fail from site to site and to take the VPN connections from the branch offices. For remote access VPN, we primarily used the firewalls. For our site-to-site VPNs, we primarily use these firewalls. For our public-facing traffic, or what is traditionally referred to as DMZ traffic, we're primarily relying on these firewalls. So, they have a lot of functionality here at the credit union. Almost all of our internet bound traffic travels through those in some way, unless we're talking about our members' WiFi traffic.