Cisco Secure Firewall Reviews

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. 

Our primary use case for this solution is to use it as a firewall. This product secures the internet from internal and public users.

Cisco Secure Firewall helped add to my organization's value. It is a selling product for us here. They have great support and documentation, which makes the solution easy to sell to customers. The Cisco name has a lot of value and high brand awareness.

We are selected partners now but are looking to grow to become a primary partner for Egypt. 

Cisco Secure Firewall definitely saved us time. However, security is never 100% with any product, even Cisco. So, you will have to spend some time securing your IT regardless of which solution you use.

I would say that it helped my company cut time by 50%.

The solution cautions us against threats via email notifications and internally in the web interface of the product itself on the dashboard.

What I found the most valuable about Cisco Secure Firewall is that if a client is educated about the solution, it can help him or her avoid many problems and mistakes. 

I think Cisco would benefit from comparing its solutions to other products. There is a lot to learn from solutions like Palo Alto or FortiGate. These are top security products. For example, Palo Alto has better inspection visibility than Cisco. When we ask customers about Palo Alto, they say "I like Palo Alto. It helps me see problems on time. I can audit everything through it." Cisco could improve in this regard. Cisco's inspection visibility could be better. 

I have been using this solution for a long time; since the PIX version in 2003. This adds up to almost 20 years now. I have had a plethora of experiences with this solution as both just an employee using it and also as the owner of a company. We also have a range of customers using the solution. 

We did not use any other solutions. Our strategy from the beginning has been to grow with Cisco. However, our customers have the final say in which solutions they choose and sometimes that's not Cisco. That has much to do with their previous beliefs and brand loyalty and trust. The customer's opinion matters and if the customer is loyal to Palo Alto, we are going to have a hard time getting them to make the switch. 

I am not involved in the deployment of the product. I have a sub that deploys Cisco Secure Firewall. I'm involved in guiding the deployment on the management side and making sure it's done in line with the customer's wishes. 

I did evaluate other options but ultimately went with Cisco because of the support they offer. You can reach their tech support engineers at any time. That's important. Their documentation is great as well. Their site is wonderful. 

I rate the solution a seven out of ten.

Cisco Secure Firewall should be consolidated with routers, switches, or VOIP.

We use this solution to provide firewall solutions for clients. We have been transitioning from ASA to FTD, since FTD has come out with new versions or upgrades.

This solution is very flexible and offers different functionality including firewalls and VPN connectivity. It checks a lot of boxes. It is an easy solution to learn how to use and the positive impact on our organization was apparent as soon as we implemented it. 

The CLI is the most valuable feature. We are moving towards FTD, which is more GUI based. The value of this solution lies in the fact that it is a standard platform that's been around for years and is always improving. This is important to us due to the necessity of ensuring cyber security. 

We are replacing ASA with FTD which offers many new features. 

We have been using this solution since 2009. 

This is a stable solution. 

This is a very scalable solution as long as you get the right hardware. 

Over the last two years, getting a response from the support engineers has been challenging. This could be due to the impact of COVID. 

We sell a lot of different firewall varieties including SonicWall, Cisco ASA, and FTD. 

When setting up the solution for our clients, we ensure they have the bandwidth they need and consider what their throughput needs are. The solution does require maintenance in terms of patching. This requires approximately six team members depending on how many moving parts there are for clients. 

We have seen a return on investment using this solution based on the fact that we are spending less money overall. 

The pricing for this solution is pretty fair. 

If it is possible, I would advise others to try out a demo with Cisco to test their firewalls. The biggest lesson I learned from using this solution is that there are many ways to achieve the same outcome. 

I would rate this solution a nine out of ten. 

I am using Cisco ASA 5525 for netting, routing, and site-to-site VPN. We have two sites. I am using Cisco ASA Firewall on one site and Check Point Next-Generation Firewall on another site.

We have integrated it with Cisco Anyconnect. This feature has been very good for us during the lockdown.

Netting is one of the best features. We can modify it in different ways. Site-to-site VPN is also an awesome feature of Cisco ASA.

The biggest advantage of Cisco products is technical support. They provide the best technical support.

Cisco should work on ASDM. One of the biggest drawbacks of Cisco ASA is ASDM GUI. Cisco should improve the ASDM GUI. The configuration through ASDM is really difficult as compared to CLI. Sometimes when you are doing the configuration in ASDM, it suddenly crashes. It also crashes while pushing a policy. Cisco should really work on this.

We have been using this solution for one and a half years.

It is stable and reliable. If you are looking for security from Layer 1 to Layer 4, Cisco ASA is good, but if you are looking for Layer 7 security, deep security, and malware detection, this is not the right product. You have to use some other product.

We have more than 400 employees. We are currently not thinking of increasing its usage because we need more security, and Cisco ASA is not good for Layer 5 to Layer 7 security.

The biggest advantage of a Cisco product is technical support. They provide 24/7 support on 365 days. Their technical support is one of the best. I would rate them a ten out of ten.

Cisco ASA is very not complex. It is a very simple firewall. If you are configuring it through CLI, it is easy. If you configuring it through ASDM, it will be more difficult for a beginner engineer.

It takes around two to three days to cover all the parameters. It is very easy to deploy in an existing network, which is one of the main advantages of Cisco ASA.

We are happy with its price. Licensing is on a yearly basis for technical support. There is one license for technical support. There is another license for IP Version 2 VPN and IPS.

I considered pfSense, but when I checked the reviews, pfSense's reviews were really bad, so we purchased Cisco ASA.

I am very happy with this product in terms of netting, routing, and VPN functionalities. If you are a small organization with around 100 people and you are not thinking of Layer 7 security, deep security, and malware detection, Cisco ASA would be very useful and cost-effective for you.

I would rate Cisco ASA Firewall an eight out of ten.

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.

Our primary use case is as a firewall and using it for web filtering. We use IPsec VPN services on it, as well as the router.

I have been using the product for only a few months, but the company has been using it for a couple of years.

The use of it has really bogged down our response time for certain problems, given we have to go through AT&T for everything. I don't think really highly of it, though.

The IPsec VPN and web filtering.

I would like the ability to pick and choose different features of it to run in a packaged infrastructure or modules, therefore I would like to have more customizability over it. 

It seems very clunky and slow. I would like to be able to tune it to be a more efficient product.

It has generally been okay in terms of stability. We haven't had it go down, but we do have some interruptions. I don't know if it is the ISP or the firewall. We have more frequent network disruptions, and other branches call in telling us that they are unable to use their services to do their job. Unfortunately, we can't really do anything about it. It just clears up in about five or six minutes. In terms of stability, I would give it a seven and a half out of 10.

I don't see it being very scalable. I don't have access to the actual interface on it. However, it is an older product, so it probably doesn't have high availability features. So, it's scalability is probably limited. I know that we kind of put it through the ringer with our fewer than a hundred connections into it.

AT&T handles our technical support, since it's leased through them.

I was not involved with the initial setup.

We pay a lot of money for it.

For big organizations who are used to throwing around a lot of money for absolutely surety, this would probably be a good fit for them. For the average SME, this particular firewall system, as well as Cisco in general, this product would not be a good fit for them.

We are currently looking at WatchGuard, pfSense, and Fortinet FortiGate. Netgate would provide the hardware.

We have still got nine months left on our contract with AT&T before we can actually do anything. We are just trying to do as much research and ask as many questions as we can before we get to that point.

We just don't have a lot of the control or customizability that we would like to have over the system. A lot of this has to do with how AT&T is handling the access to it. Also, the hardware is outdated. We would like to go with a product in which everything is very transparent, clear, organized, all in the same place, and we can monitor clearly. The reason that we are looking to change is price: We pay a lot for it. If we had more control over it, we would be better able to control the quality and performance of the network and services, as well as the budget.

The most important criteria when selecting a vendor:

• IPsec VPN
• Good stable connection
• Failover support: We need to have dual-WAN, so we can get two WAN connections in there and have failover. 
• Load balancing would be good, especially for those rough patches. 
• Internal web filtering and blocking: We need to be able to control what our end users are looking at.
• Monitoring: As much monitoring as we can get.
  

The ease of use and ease of deployment were the most important features. As a signature based appliance, SourceFire hits it on the head at detection and capturing traffic, but quite a few of the other IDS/IPS appliances are way too complicated and too time consuming to properly deploy. This will lead to improper deployments and often missing important spots in your network.

Being able to detect intrusions is very valuable, and this can be anything from reconnaissance attacks to malware beaconing from inside our network.

Being able to incorporate third party rules as the SourceFire rules often lag behind current threats. When the latest zero day or other threats hit the market and are high value threats, most departments want to have these signatures available and able to deploy automatically. SourceFire makes this a manual process with third party rules.

I've used it for two years.

No, it was quite easy.

No issues with stability.

The only issue I have is with the price, as SourceFire is VERY expensive.

Customer service is very helpful and there are some extremely knowledgeable people on board.

Very technical! The men and women know what they are doing and are very helpful.

No previous solution was used.

It's straightforward with easy to follow instructions. You just plug-in and go.

I implemented it myself.

Lousy! $250K/year just for maintenance and licensing costs for a defense center and five sensors? This is insane! There is a better way.

The original setup cost was very high, not sure of the exact numbers because this product was purchased prior to me joining, but it was expensive Tack on the recurring charge and this really racks up, but luckily the day to day operational costs aren't bad at all, unless you break out the recurring charge daily!

Other IDS/IPS products were looked at.

The same level of protection can be had at a much lower cost! Look at rolling your own with commodity hardware, Suricata (Or SNORT if you choose, but look at the differences please!), Aanval for the central management and the emerging threats rules.

It is for our VPNs and filters out websites. 

It helped us a lot with our VPNs for the home office during COVID. There has been more security and flexibility for VPNs and other applications.

Its security is easy to use.

I would like more features in conjunction with other solutions, like Fortinet.

I have been using it for five years.

It has very good stability.

It has really good scalability.

The customer service and technical support are good. I would rate them as nine out of 10.

Positive

We were previously using Fortinet. We switched to ASA and Firepower when our contract with Fortinet ended. Now, we are only using ASA.

The deployment was simple.

The ROI is good. Using ASA, we have saved 10% to 20% on our costs.

The pricing is fine. It is not too bad.

We had it integrated with the Umbrella solution a few years ago.

I would rate this solution as nine out of 10.