Cisco Secure Firewall Reviews

Our primary use case is as a data center firewall for internet firewalls and also as a VPN concentrator. I'm the chief technology officer and we are partners of Cisco. 

In terms of features there hasn't been much improvement but it's a very stable solution and a very good firewall with almost all of the features required for next generation firewall purposes. Almost all the firewalls on the market have the same features available, but if you take into account the integrations and reporting of Cisco, it's a little better than the others. In particular, the briefing reporting is better. With Fortinet we would probably have to use FortiAnalyzer as a separate reporting module for Fortinet, but here the reporting is good.

There needs to be an improvement in the time it takes to deploy the configurations. It normally takes two to four minutes and they need to reduce this. The deployment for any configuration should be minimal. It's possibly improved on the very latest version. 

An additional feature I would like to have in Firepower would be for them to give us the data from the firewall - Cisco is probably working on that. 

I've been using this solution for close to five years. 

The scalability is very good. 

We generally provide support but if we're not able to resolve an issue, we escalate it to Cisco and they're great. They are one of the best support services I've used and it's one of the reasons Cisco is doing so well in the market. 

I also work with Fortinet and Palo Alto. Fortinet is also a really good product but Cisco is a leader in next generation firewalls and now that they are catching up to Fortinet, they have provided a lot of features and flexibility. I personally see Cisco as being good for large enterprise companies and Fortinet is better for families as well as small and medium size businesses. When it comes to Palo Alto, the high price point is one thing that is an issue, some companies are unable to afford it. Palo Alto is good but Cisco is catching up to them and I believe in a year or two, Cisco will probably match Palo Alto as well and be much better. 

The initial setup is not too complex, but as with Fortinet, they have some detailed steps required which adds to the flexibility also. With flexibility comes a bit of complexity, but it's not too bad. Deployment time takes a few minutes. I am responsible for implementation and maintenance for our clients. We were previously deploying only for medium or large enterprise companies but Cisco has come up with the 1000 and 1100 series firewalls for smaller companies which is pretty good. They're a cost-effective solution and competitive in the market. 

Cisco falls somewhere in the middle in terms of pricing, it's not very expensive and it's not very cheap. There is an additional accessory fee associated with Cisco but normally they have a separate subscription cost for different types of security to protect the firewall. There are separate bundles available inside the pricing and that's probably true for all of the firewalls. 

Cisco is a large, good and reliable firewall. They are working on advanced features and catching up with the leaders in the market. I believe that's a score for them. A yearly subscription is cheaper than Palo Alto and Fortinet offer. They provide good support and once it's loaded, it doesn't give a lot of problems, that's very important.

I would rate this solution an eight out of 10. 

We primarily use the solution for the various firewalls.

Cisco is powerful when it comes to detecting intrusions. It's better than, for example, Fortinet.

Cisco has multiple products - not just firewalls. The integration between other items provides a powerful end-to-end solution. It's nice and easy. There is one management system and visibility into all of the features. Using the same product is more powerful than using multiple systems. Cisco is known by most customers due to the fact that at least they have switches. However, when clients say "we need an end-to-end option" Cisco is there.

The stability is very good.

Technical support services are excellent.

Before an ASA, it was a live log. It was easy and comfortable to work with. After the next-generation firewall, Firepower, the live log became really slow. I cannot reach the information easily or quickly. This has only been the case since we migrated to next-generation firewalls.

There is some delay between the log itself. It's not really real-time. Let's say there's a delay of more than 20 seconds. If they had a monitoring system, something to minimize this delay, it would be good.

It would be ideal if I could give more bandwidth to certain sites, such as Youtube.

I work with Fortinet also, and I find that Fortinet is easier now. Before it was Cisco that was easier. Now Fortinet is simpler to work with.

On firewall features, Fortinet is better. Cisco needs to become more competitive and add more features or meet Fortinet's offering.

I've been using the solution since about 2003, when I originally implemented it.

The solution is extremely stable. We don't have any issues whatsoever. It doesn't have bugs or glitches. It works well. Occasionally, it may need patches, however, there's very little downtime.

The scalability of the solution is very good. We have no trouble expanding the solution.

They have multiple products that fit in multiple areas. They also have virtual firewalls, which are working well in virtualization systems. They have the data center firewalls feature for data centers. It's scalable enough to cover most of the use cases that might arise.

Cisco offers excellent technical support.  They're useful and very responsive - depending on the situation itself. Sometimes we require the support of agents and we've found Cisco to have one of the best support systems in the market.

I also work with Fortinet, and it's my sense that, while Fortinet is getting easier to use, Cisco is getting harder to deal with.

The initial setup is not complex at all. It's pretty straightforward.

A full deployment takes between two and three days. It's pretty quick to set up.

The pricing is neither cheap nor expensive. It's somewhere in the middle. If you compare it to Fortinet or Palo Alto, Fortinet is low and Palo Alto is very high. Cisco falls in the middle between the two.

As far as deployment options go, they often have more wiggle-room with discounts, especially for larger deployments. Therefore, in general, it ranges closer to Fortinet's pricing.

We're partners with Cisco, Fortinet, and Palo Alto.

I work with on-premises deployments and virtual firewalls, however, I don't use the cloud.

The solution works well for medium-sized enterprises.

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

I'd recommend users to layer in solutions. At the perimeter, if they have two tiers, I'd recommend Palo Alto as the first and then Cisco ASA as the second. Cisco can work on the data center or Fortinet. In the case of Fortinet, they have the best backline throughput from all of the other products.

I like them mostly because they don't break and they have great diagnostics. If something is awry, you can generally figure it out. And of course, everybody has a VPN, but I like the security of their VPN.

They should improve their interface and ensure that people actually know what they're doing before they start programming; that would make me happy. But that's never going to happen — it's a total pipe dream.

Some of the next-generation stuff that Cisco is doing now allows you to add web filtering and provides more security inside the device. That's why we were looking at the Next-Generation Firewall.

I have been using this solution since they developed it.

I've had a couple of issues. Way back, they had a power supply that had to be changed out. They also had some issues with the 5500 series. Other than that, they're pretty rock-solid.

Within their limitations, yes, they're scalable. You don't want to put a 5506 in when you need a 5525 — you'll never get it there. If properly sized, they're scalable, but you can't make a 5506 a 5525 — there're different processors and everything. You have to know where you're going. You have to know your customer first.

The tech support is good. The documentation is verbose almost to the point of being confusing if you don't know what it is you're looking for.

It's only confusing if you have somebody who is not familiar with it. They give you every option in great detail, so you can spend time searching through a manual that you might not otherwise. Here's an example: take Sophos or SonicWall — let's say the manual for SonicWall is 25 to 30 pages; that same Cisco documentation is going to be three times that size or more.

It's not that it needs to be simplified, the people using it need to be knowledgeable. It is not a novice box, we'll put it that way.

We've been with Cisco for a long time. We've used their routers and gadgets for years and years.

The initial setup is quite straightforward.

I would guess that the market value of Cisco is going to be towards the higher-end. I don't know that it's the highest, but feature for feature, I'd say it's probably well-priced.

Cisco ASA Firewall Is not as much of a plug and play solution as some of the others. You just need to make sure that you do your research.

On a scale from one to ten, I would give Cisco ASA Firewall a rating of nine.

My primary use case with Cisco Firepower NGFW is implementing, configuring, maintaining, and troubleshooting lab and customer devices in both lab and production environments.

Using best practices for configuration, as well as fine-tuning intrusion policies and utilizing as many of the features that the firewall has to offer, which are feasible in said environment.

Overall, I am confident to say that I have worked with every flavor of Cisco Firepower NGFW, be it their older IPS-only sensors, ASA with Firepower services, as well as the FTD sensor itself.

Cisco Firepower NGFW has improved our organization by giving us the opportunity to protect both our network and our customer's environments. Being able to work with the device in a lab environment and utilizing the whole feature set is really easy with the Evaluation licenses of 90 days on the FMC. The only thing that you need is an environment with enough resources to virtualize both the FMC and FTD sensors.

I would like to emphasize the easy-to-use evaluation period of the Cisco Firepower NGFW because many other firewall vendors lack this and it is a real pain having to test everything in production environments because you cannot build a good lab environment without paying for licenses.

The most valuable feature that Cisco Firepower NGFW provides for us is the Intrusion policy. 

Again, with that being said, I cannot shy away from giving kudos to all of the other features such as AVC (Application Visibility and Control), SSL Decryption, Identity policy, Correlation policy, REST API, and more.

All of the features that are incorporated in the Cisco Firepower NGFW are awesome and easy to configure if you know what you are doing. Things almost always work, unless you hit a bug, which is fixed with a simple software update.

I believe that the current feature set of the device is very good and the only thing that Cisco should work on is improving the user experience with the device. 

Also, they need to ensure that all of the implemented features are working as they should, and able to integrate with more third-party software in an easier manner.

As it stands currently, Cisco is doing this, but I am not confident enough to say that their QA team is doing as good a job as they should as there have been software releases that were immediately pulled back the same day as they were released.

I have been working with Cisco NGFW for almost five years as of 2020.

I have seen devices working without any issues and/or without a reboot of the device for many years (although I do not recommend this) running on base versions of the software, and I have seen an out-of-the-box fresh install having many stability issues. However, overall my impression is that the most recent software versions are very stable without any evident underlying issues.

Keep your software up-to-date and the solution should be stable.

Cisco Firepower NGFW has a large variety of devices that are able to accommodate every company's needs, be they small or large. Overall, the scalability of the devices is very good.

Experience with Cisco TAC has been awesome almost always. The SLAs are kept every time, which is very hard to get from any of the other firewall vendors. I have not seen any other vendor get you a proficient engineer on the phone within 15 minutes.

Cisco ASA and Firepower NGFW is the first firewall solution that I have and am still using.

Once you deploy a few of these devices, the initial setup is really straightforward and easy to do unless the position of the firewall on the network needs you to do some connectivity magic in order for it to work.

All of the implementations that we have done are with in-house teams, so I have no overview of the vendor team.

Cisco, as we all know, is expensive, but for the money you are paying, you know that you are also getting top-notch documentation as well as support if needed. In some cases, this may save you a lot of money or stress, which is why everyone who uses Cisco solutions loves them.

I have worked with many other firewall vendors in both production and lab environments such as CheckPoint, Palo Alto, Fortinet, Juniper, but to be honest I find Cisco's firewall solutions and Palo Alto's firewall solution to be the best.

I believe that Cisco Firepower NGFW is the future leader in NGFW, with only maybe Palo Alto being the main competitor. This is very good, as we all know that having a rival is good for us, the users :) 

We primarily use it for our clients. We have one or more at each client site - or multiple locations if they have multiple locations.

Typically our clients are up to about 500 users. Most of them are smaller than that, but they go as large as 500. They're using the solution for the full next-gen firewall stacks - intrusion protection, URL filtering, advanced malware protection, or so-called AMP. Those are the three subscription services that Cisco sells. All of our clients have those subscription services enabled at their main location. Typically, they're just protecting users that are behind the firewall. We also use it for site-to-site VPN, and we use it for client-to-site VPN.

In terms of our clients, security is one of those things that, ideally, nobody notices. It improves the functioning in the sense that you don't get hacked. However, from a noticeable, management point of view, the URL filtering is a pretty significant enhancement. People are able to block access to various websites by category. It isn't revolutionary. Lots of products do this. However, it's a nice sort of add-on to a firewall product.

At the end of the day, the solution offers good productivity enhancement to a company.

Cisco's support is great. 

For experienced users, they are pretty much able do anything they want in the interface with few restrictions.

The command-line interface is really useful for us. We script basic installations and modifications through the command-line, which is considered sort of old school, and yet it allows us to fully document the changes that we're making due to the fact that we can save the exact script that was applied and say, "Here are the changes that we made." 

We can have less experienced people do initial takes on an install. They can edit a template, and we can have a more experienced person review the template, and then apply it, and we don't have to worry about whether anyone inexperienced went into certain corners of the interface and made changes or whatever.

Everything is all documented in the file or in the command line script that gets uploaded to the device. It gives us great visibility.

I would say that in inexperienced hands, the interface can be kind of overwhelming. There are just a lot of options. It's too much if you don't know what you are looking for or trying to do.  

The GUI still uses Java, which feels out of date today. That said, it's an excellent GUI.

The biggest downside is that Cisco has multiple firewall lines. The ASA line which is what we sell, and we sell most of the latest versions of it, are kind of two families. One is a little older, one's a little newer. We mostly sell the newer family. Cisco is kind of de-emphasizing this particular line of products in their firewall stable. That's unfortunate. 

They have the ASA line, Meraki, which is a company they bought some years ago where all the management is sort of cloud interface that they provide rather than a kind of interface that you manage right on the box. They also bought Snort and they integrated the Snort intrusion detection into the ASA boxes. In the last couple of years, they've come out with a sort-of replacement to Snort, a line of firewalls that don't use IOS.

It's always been that the intrusion prevention and the based firewalling features had separate interfaces within IOS. They've eliminated IOS in this new product line and built it from the ground up. We haven't started using that product yet. They have higher performance numbers on that line, and that's clearly the future for them, but it hasn't reached feature parity yet with the ASA. 

The main downside is that it feels a little bit like a dead end at this point. One needs to decide to move to one of these other Cisco lines or a non-Cisco line, at some point. We haven't done the research or made the plunge yet.

What I would like to see is a more inexpensive logging solution. They should offer either the ability to maintain longer-term logs right on the firewall or an inexpensive server-based logging solution. Cisco has logging solutions, however, they're very high end.

We've been using the solution for 20 or more years. It's been well over two decades at this point.

The solution is solid. It's a big advantage of choosing Cisco. There are no worries about stability at all.

The scalability of the solution is good. Within our customer base, it is absolutely scalable. You can go very large with it. However, if you really want the highest speeds, you have to move off of the IOS ASA line and onto the newer stuff.

Typically our clients cap out at 500 employees.

Technical support is excellent. They are extremely knowledgeable and responsive. It'd rate the ten out of ten. We're quite satisfied with the level of support Cisco provides.

We did use Juniper's NetScreen product on and off for a while. We stopped using it about ten years ago now.

We had previous experience with the Cisco gear, so we were comfortable with it, and Juniper bought the NetScreen product and sunsetted it. You had to move into a different firewall product that was based on their equivalent of IOS, something called Juno OS, and we didn't like those products. Therefore, when they sunsetted the Juniper products, we looked around and settled on Cisco.

Due to the fact that we're experienced with it and we've scripted the command line, it's extremely simple for us. That said, I think it's complex for somebody that doesn't know the IOS platform.

We're Cisco resellers.

We're always on the latest version. I don't actually keep track of the version numbers myself, however, part of what the service that we provide for our clients is updating their firewalls to the latest version.

We use multiple deployment models. We use both on-premises and cloud versions. They are also all different sizes, according to the requirements of the company.

I'd advise other companies considering Cisco to be sure to factor in the cost of the ongoing security subscriptions and the ongoing SmartNet into the purchase price. Those things, over the years, represent more than the cost of the firewall itself - significantly more. However, I'd advise others to get the security subscriptions due to the fact that it really dramatically increases the security of the solution overall.

On a scale from one to ten, I'd rate them at an eight. We love the product, however, we feel like it's not Cisco's future direction, which is the only reason I would downgrade its score. To bring it up to a 10, they'd have to make it their main product line again, which they aren't going to do.

Our primary use case for this solution is to improve network security. 

The maturity of our company's security implementation depends on our clients. Some of our clients really need a lot of work but some of them are advantaged. We are major implementors for Cisco. 

We implement it for our clients and we also use it internally. Our security maturity is advanced. We have been in IT business for over 75 years. We have major netowrk firewall experts in the company, so we know what to do. 

Our company uses more than thirty security tools. Ideally, we would use an end to end unified tool. But network security is far from that so we need to use multiple tools. 

Firepower has been used for quite a few enterprise clients. Most of our clients are Fortune 500 and Firepower is used to improve their end to end firewall functionality. 

The most valuable feature is the intelligence. It sends a warning for a potential attack, a zero-day attack. It sends us an advanced warning. We really like this feature. 

We use other Cisco tools for switches, routers, and AppDynamics. We also use their wireless tool. We are Cisco's biggest partner, so we use the majority of their solutions. This is one of the reasons people become a Cisco-shop, because of the integration. 

The integration between these products isn't perfect. 

Firepower provides us with application visibility and control. We have a standard evaluation procedure with around 136 criteria. We have a team that does the evaluation and there were viruses reported.

In terms of its ability to provide visibility into threats, we put a different application to be tested. We check how much we can see. What kind of network traffic goes through different devices. We know what's going on. If something went wrong, we see the attack, we know where and which attack. We put it into our testing center. You can never get 100% visibility. Sometimes we can't detect until the damage is done. That is the danger of being in the firewall business. You never know what kinds of tricks a hacker will use. It's endless work.

Talos is pretty decent. It offers smart intelligence. It helps my team detect what is going on. Without it, the ability of the power stations would be much less. Talos is one of the reasons that we go with Cisco. It is a big advantage.

We use automated policy application and enforcement. Any of the networks are very complex. It has freed up a lot of our time. Now, it's much better but it's still far from enough. We have saved 90% of our time due to the automation. 

Firepower has improved our enterprise defense ability by a lot. 

We use the whole suite of Cisco device management options. Compared to ten years ago, I have seen a lot of improvement, but it's still far from enough. I wish the intelligence will be improved. There is a big learning curve now. If a new gear comes into place, then the first three months aren't so accurate. With machine learning, it is getting better. The intelligence should be there from day one. But it will still need to learn the environment and which attack is the most common.

We are still trying to figure out the best practices for harmonizing policies and enforcement across heterogeneous networks. It's something new. More and more applications are going onto the cloud and we need the hybrid Firepower ability. 

The intelligence has room for improvement. There are some hackers that we haven't seen before and its ability to detect those types of attacks needs to be improved.

There is a bit of an overlap in their offerings. Which causes clients to overpay for whatever they end up selecting. 

I have been using Firepower for 3 years. 

I see a lot of improvement in terms of stability but it's still not 100%. We still have bugs and things will go wrong that will cause the system to not function and we will have to reboot and restart. That is something that Cisco should fix. 

The scalability is reasonable and okay. 

One of the clients we have has 21,000,000 node. 

We use their support a lot. In my view, they need a lot of improvement. A lot of the representatives are far away and they don't have a lot of knowledge. You need to get to level two or three for them to be able to help. My team is very experienced so it takes a lot for us to make a call to technical support. We need to talk to the right person to work out the issue. The support structure is not able to reach the right level right away. This is a problem that Cisco needs to work a lot to improve one. 

We also use Palo Alto, Check Point, Fortinet, Juniper, and Microsoft. 

Cisco came into firewalls much later. I would say they're top ten but they're not number one yet. They need to do more work. Cisco does better than the smaller players. 

The best firewall option is Palo Alto. 

Considering the expertise and the way they detect an advanced attack, Palo Alto is better than Cisco. 

Compared to many years ago, the configuration is much more simplified. It is still not one button to get it all done. It's not easy enough. It hasn't reached the level where a junior staff member can get the job done. 

For my enterprise environment, the deployment goes wave by wave. It can take six to eight weeks. We do a rolling upgrade. It's not something that can be done in one action because the network is so huge and complex. 

We have a uniform implementation strategy. We have a standard upgrading proceeding. We do testing and verify and then we put it into production.  

We are the integrators and consultant team. 

18 months

Be careful

Yes

Get your homework done. Get to know in-depth what Cisco can do and compare it with Palo Alto. If you're happy with Cisco, go for it but Palo Alto is the safer choice. 

I would rate it an eight out of ten. 

We are a Cisco partner and we implement solutions for our customers who are generally in the banking sector and other private sectors.

They are using it as a data center firewall and to secure their internet connections. Our customers usually integrate the firewall with ISE, with a Firepower module for IPS, and there are some NAC solutions.

The solution enhances the performance of the network. It blocks most of the threats and it updates attack signatures so it protects customer data better. The loss of data would be a crisis for any customer. With the deep inspection and analysis and the threat updates, it gives you more protection and safety.

Our clients use automated policy application and enforcement. For example, when you have a very big deployment or a bank needs to deploy more branches, this saves a lot of time when doing the implementation. Similarly, when you add more users or you add more devices, when you create a profile of the policies, they will be available in a matter of minutes, regardless of the number of branches or users or applications. It reduces the time involved in that by 75 percent.

The traffic inspection and the Firepower engine are the most valuable features. It gives you full details, application details, traffic monitoring, and the threats. It gives you all the containers the user is using, especially at the application level. The solution also provides application visibility and control.

The integration between the ASA and Cisco ISE is very easy because they are from the same vendor. We don't face any integration problems. This is one of the valuable points of Cisco firewalls. They can be easily integrated with different Cisco security products.

Our clients also use other products with Cisco ASA, such as Aruba ClearPass and different NAC solutions. The integration of these other products is also easy with Cisco. 

It integrates with email security and Firepower. For example, if you have an attached file infected or you have attacks through email, the traffic will be forwarded to the email security and it will be blocked by the firewall. It gives you a clear view of the file and it can be blocked at every stage, protecting your network from this threat.

One of the best parts is the traffic management and the inspection of the traffic packets. The Device Manager is easy to use to supervise things, and the Firepower application gives you clear threat detection and blocking of all threats. Cisco also provides a better analysis of the traffic.

In addition, Talos is an enhancement to Cisco firewalls, and provides a better view.

The device management options, such as Firepower Device Manager (FDM), Cisco Firepower Management Center (FMC), or Cisco Defense Orchestrator (CDO) add a lot of enhancements in the initial deployment and configuration. In migrating, they can help to create the migration configuration and they help in managing encryption and automation. They add a lot enhancements to the device. They make things easier. In the past, you had to use the CLI and you could not control all this. Now you have a GUI which provides visibility and you can easily integrate and make changes.

When I deal with other firewalls like Palo Alto or Fortinet, I think there is some room for performance tuning and enhancement of the ASA. I'm not saying there is a performance issue with the product, but when compared to others, it seems the others perform a little bit better.

There could be enhancements to the cloud part of the solution. It's good now, but more enhancements would be helpful.

Finally, security generally requires integration with many devices, and the management side of that process could be enhanced somewhat. It would help if there was a clear view of the integrations and what the easiest way to do them is.

I have been using Cisco ASA NGFW for more than 10 years.

The ASA is stable. There may be some small stability issues, when compared to others, but it is a stable product. There could be enhancements to the ASA in this area when compared to other vendors, but it is not a problem with the product.

It is scalable, with virtualization and other features.

In terms of future-proofing our customers' security, we recommend the ASA. We have tested it in large environments and it's working well. The lesson I have learned from using Cisco ASA is that Cisco's research is continuous. They provide enhancements every day. It's a product for the future.

Technical support is a very strong point in Cisco's favor. I would rate it very highly. The support is excellent.

The setup is of medium difficulty. It is not very complex. Generally, when working in the security field, things are a little bit complex because you are integrating with many vendors and you are defending against a lot of different kinds of attacks.

The amount of time it takes to deploy the ASA depends on the complexity of the site where it is being set up. On average, it can take about a week. It could be that there are many policies that need to be migrated, and it depends on the integration. For the initial setup, it takes one day but the amount of time it takes beyond that depends on the security environment.

Our customers definitely see return on investment with Cisco ASA because when you protect your network there is ROI. If you lose your data you have a big loss. The ROI is in the security level and the protection of data.

The value of the pricing needs to be enhanced from Cisco because there are a lot of competitors in the market. There is room for improvement in the pricing when compared to the market. Although, when you compare the benefits of support from Cisco, you can adjust the value and it becomes comparable, because you usually need very good support. So you gain value there with this device.

My advice is to take care of and monitor your policies and be aware of the threats. You also have to be careful when changing policies. When you do, don't leave unused policies around, because that will affect performance. You should have audits of your firewall and its policies and follow the recommendations from Cisco support.

Among the things I have learned from using Cisco ASA is that integration is easy, especially with Cisco products. And the support helps you to integrate with anything, so you can integrate with products outside of the Cisco family as well.

We have an offshore development center with around 1,400 users (in one location) where we have deployed this firewall.

The maturity of our organization’s security implementation is a four out of five (with five being high). We do have NOC and SOC environments along with in-built access to our systems. 

We use Acunetix as one of our major tools. We do have some open source. There are a couple of networks where we are using the Tenable tool. We have implemented an SIEM along with a Kaspersky at the cloud level. In the Cisco firewall, we installed Kaspersky in the firewall logs which upload to Kaspersky for us to review back.

Being able to determine our active users vs inactive users has led us to increased productivity through visibility. Also, if an issue was happening with our throughput, then we wouldn't know without research. Now, notifications are more proactively happening.

The advance malware protection (AMP) is valuable because we didn't previously have this when we had an enterprise gateway. Depending on the end user, they could have EDR or antivirus. Now, we have enabled Cisco AMP, which give us more protection at the gateway level. 

The application visibility is also valuable. Previously, with each application, we would prepare and develop a report based on our knowledge. E.g., there are a couple business units using the SAS application, but we lacked visibility into the application layer and usage. We use to have to configure the IP or URL to give us information about usage. Now, we have visibility into concurrent SAS/Oracle sessions. This solution gives us more visibility into the inbound/outbound traffic being managed. This application visibility is something new for us and very effective because we are using Office 365 predominantly as our productivity tool. Therefore, when users are accessing any of the Office 365 apps, this is directly identified and we can see the usage pattern. It gives us more visibility into our operations, as I can see information in real-time on the dashboards.

The solution has positively affected our organization’s security posture. I would rate the effects as an eight (out of 10). There is still concern about the engagement between Cisco Firepower and Cisco ASA, which we have in other offices. We are missing the visibility between these two products.

We would like more application visibility and an anti-malware protection system, because we don't have this at the enterprise level.

The central management tool is not comfortable to use. You need to have a specific skill set. This is an important improvement for management because I would like to log into Firepower, see the dashboard, and generate a real-time report, then I question my team.

Nearly a year.

So far, it has been stable.

We have around 32 people for maintenance. Our NOC team works 24/7. They are the team who manages the solution.

Scalability is one of our major business requirements. We are seeing 20 percent growth year-over-year. The plan is to keep this product for another four years.

We contacted Cisco directly when issues happened during the implementation, e.g., the management console was hacked.

We used Fortinet and that product was coming to end of life. We had been using it continuously for seven years, then we started to experience maintenance issues.

Also, we previously struggled to determine who were all our active users, especially since many were VPN users. We would have to manually determine who was an inactive user, where now the process is more automated. It also had difficult handling our load.

The initial setup was complex. We engaged NTT Dimension Data as there were a couple things that needed to be done for our requirements and validation. This took time to get signed off on by quality team. However, the configuration/implementation of the system did not take much time. It was a vanilla implementation.

We did face performance issues with the console during implementation. The console was hacked and we needed to reinstall the console in the virtual environment. 

We were engaged with a local vendor, NTT Dimension Data, who is a Cisco partner. They were more involved on the implementation and migration of the firewall. Some channels were reconfigured, along with some URL filtering and other policies that we used for configuration or migration to the new server.

Our experience with NTT Dimension Data has been good. We have been using them these past four to five years.

We have seen ROI. Our productivity has increased.

The change to Cisco Firepower has reduced the time it takes for our network guy to generate our monthly report. It use to take him many hours where he can now have it done in an hour.

Cisco pricing is premium. However, they gave us a 50 to 60 percent discount.

There are additional implementation and validation costs.

We also evaluated Check Point, Palo Alto, Sophos, and Cisco ASA. In the beginning, we thought about going for Cisco ASA but were told that Firepower was the newest solution. We met with Cisco and they told us that they were giving more attention going forward to Firepower than the ASA product.

We did a small POC running in parallel with Fortinet. We evaluated reports, capability, and the people involved. Palo Alto was one of the closest competitors because they have threat intelligence report in their dashboard. However, we decided not to go with Palo Alto because of the price and support.

We are using Cisco at a global level. We have internally integrated this solution with Cisco Unified Communications Manager in a master and slave type of environment that we built. It uses a country code for each extension. Also, there is Jabber, which our laptop users utilize when connecting from home. They call through Jabber to connect with customers. Another tool that we use is Cisco Meraki. This is our all time favorite product for the office WiFi environment. However, we are not currently integrating our entire stack because then we would have to change everything. We may integrate the Cisco stack in the future. It should not be difficult to integrate since everything is a Cisco product. The only issue may be compliance since we have offices in the US and Europe.

We are now using a NGFW which helps us deep dive versus using a normal firewall.

Overall, I would rate Cisco Firepower as an eight (out of 10).

The ASAs are a defense solution for companies. Many of them use the AnyConnect or the VPN licenses. They also use it to have a next-generation firewall and to be compliant with GDPR.

The majority of our usage of the solution is on-prem or hybrid. The culture, here in Portugal — even knowing that the future is full cloud, in my opinion — is to only be on the way to full cloud.

All the features are very valuable. 

Among them is the integration for remote users, with AnyConnect, to the infrastructure. All the security through that is wonderful and it's very easy. You connect and you are inside your company network via VPN. Everything is encrypted and it's a very good solution. This is a wonderful feature. You need to make sure your machine has the profile requested by the company. That means having the patches updated. Optionally, you should have the antivirus updated, but you can decide whatever you would like in order to enable acceptance of the end-device in the enterprise network. That can be done with AnyConnect for remote/satellite users, or with ISE for local users.

The intrusion prevention system, the intrusion detection, is perfect. But you can also integrate Cisco with an IPS solution from another vendor, and just use the ASA with AnyConnect and as a firewall. You can choose from among many other vendors' products that the ASA will integrate with. Now, with Cisco SecureX, it's much easier than before. Cisco used to be completely blocked from other vendors but with SecureX they are open to other vendors. That was a massive improvement that Cisco probably should have made 10 years ago or seven years ago. They only released SecureX three or four months ago. 

Cisco ASA also provides application control. You can block or prevent people from going to certain applications or certain content. But the ASA only acts as a "bodyguard." It doesn't provide full visibility of the network. For that, there are other solutions from Cisco, such as ISE, although that is more for identity. Stealthwatch or TrustSec is what you need for visibility. They are both for monitoring and providing full visibility of the network, and they integrate with ASA.

Also, all of Cisco's security products are supported with Talos. Talos is in the background, handling all the improvements, all the updates. If something happens in Australia, for example, Talos will be aware of it and it will update the worldwide Talos network for all Cisco products. Within two minutes or three minutes, worldwide, Cisco products will be aware of that threat. Talos belongs to Cisco. It's like a Cisco research center.

My concern in the 21st century, with ASA, is the front-end. I think Cisco missed the mark with all the configuration steps. They are a pain and, when doing them, it looks as if we're using a very old technology — yet the technology itself is not old, it's very good. But the front-end configuration is very tough. They probably still make a good profit even with the front-end being difficult, but it's not easy. It's not user-friendly. All the configuration procedures are not user-friendly.

Also, they launched the 1000 series for SMBs. They have all the same features as the enterprise solutions, but the throughput is less and, obviously, the price is less as well. It's a very nice appliance. However, imagine you buy one, take it out of the box to connect it and the device needs one hour or two hours to start up. That is a pain and that is not appropriate for the 21st century. They should solve that issue.

Another issue is that when you integrate different Cisco solutions with each other, there is an overlap of features and you need to turn some of them off, and that is not very good.  If you don't, and you have overlap, you will have problems. Disabling the overlap can be done manually or the solution can identify that there is already a process running, and will tell you to please disable that function.

For today's threats, for today's reality, you need to add solutions to the ASA, either from Cisco or from other vendors, to have a full security solution in an enterprise company.

I've been using Cisco ASA NGFW for almost two years.

The stability of the ASA is perfect. There is no downtime. And you can have redundancy as well. You can have two ASAs working in Active-Passive or load balancing. If the product needs a restart, you don't have downtime because you use the other one. From that point of view it's very robust.

You can go for other models for scalability and sort it out that way.

My suggestion is to think about scalability and about your tomorrow — whether you'll increase or not — and already think about the next step from the beginning.

Cisco's technical support for ASA is very good. I have dealt with them many times. They are very well prepared. If you have a Smart Account, they will change your device by the next business day. That is a very good point about Cisco. You have to pay for a Smart Account, but it's very useful.

The initial setup is very complex. You need to set a load of settings, whether from the CLI or the GUI. It's not an easy process and it should be. That is one of the reasons why many retailers don't go for Cisco. They know Cisco is very good. They know Cisco does ensure security, that it is one of the top-three security vendors, but because of the work involved in the implementation, they decide to go with other solutions.

There are two possibilities in terms of deployment. If we go to a client who is the ASA purchaser and they give us all their policies, all their permissions, and everything is organized, we can deploy, with testing, in one full day. But many times they don't know the policies or what they would like to allow and block. In that scenario, it will take ages. That's not from the Cisco side but because of the customer.

One person, who knows the solutions well, is enough for an ASA deployment. I have done it alone many times. After it's deployed, the number of people needed to maintain the solution depends on their expertise. One expert could do everything involved with the maintenance.

When it comes to security, pricing should not be an issue, but we know, of course, that it is. Why is an Aston Martin or a Rolls Royce very expensive? It's expensive because the support is there at all times. Replacement parts are available at all times. They offer a lot of opportunities and customer services that others don't come close to offering. 

Cisco is expensive but it's a highly rated company. It's one of the top-three security companies worldwide.

I can see the differences between Cisco and Check Point. 

Cisco has a solution called Umbrella which was called OpenDNS before, and from my point of view, Umbrella can reduce 60 percent of the attack surface because it checks the validity of the DNS. It will check all the links you click on to see if they are real or fake, using the signature link. If any of them are unknown, they will go straight to the sandbox. Those features do not exist with Check Point.

Cisco ASA is a very robust solution. It does its job and it has all the top features. If you have a solution that is creating a script and you need to deploy many implementations, you can create a script in the device and it will be the same for all. After that, you just have to do the fine tuning. It lacks when it comes to the configuration steps and the pain that that process is. You need to spend loads of time with it at setup. Overall, it does everything they say it does.

It's a very good solution but don't only go with the ASA. Go for Cisco Umbrella and join them together. If you have remote employees, go for AnyConnect to be more than secure in your infrastructure.

You cannot do everything with Cisco Defense Orchestrator. You have a few options with it but cannot do everything from the cloud if you are connected with the console of a device. You don't have all the same options, you only have some options with it. For example, you can manage the security policies, all of them, from the cloud. However, not all the settings and all the things you can do when in front of the device are available with CDO. What you see is what you get.

Most companies using ASA are big companies. They are not SMB companies. There are very few SMB companies using it. There are the banks and consulting companies, the huge ones. Usually the ASAs are for massive companies.

Our reality in Portugal is a little different. I was at a Cisco conference here in Lisbon and the guy said, "Oh, we have this solution," — it was for multi-factor authentication — "and we have different licenses. We have a license for 40,000 and for 20,000 users. And I was thinking, "This guy doesn't know Portuguese reality. There are no companies in Portugal with 40,000 employees."

Large companies who do use ASA use various security tools like IPS and Layer 7 control. From my experience, and from common sense, it's best to have solutions from different vendors joining together. The majority have defense products for the deterrent capacities they need to achieve security. Our clients also often have Cisco ISE, Identity Service Engine. It's a NAC solution that integrates perfectly with ASA and with AnyConnect as well.

As for future-proofing your security strategy, ASA is the perfect solution if you integrate other Cisco solutions. But the ASA alone will not do it because it does not handle some of the core issues, like full visibility of the network, the users, the machines, the procedures, and the applications, in my opinion.

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.