Cisco Secure Firewall Reviews

Our primary use case includes basic firewalls, VPNs, NAT, and our connections to customers.

It's used in our data centers to protect the network and customer circuits.

Cisco ASA Firewall has improved our organization by allowing connectivity to the outside world and into different places.

Cybersecurity resilience is very important to our organization. There are always threats from the outside, and the firewall is the first line of defense in protecting the network.

Cisco ASA Firewall is a well-known product. They're always updating it, and you know what they're doing and that it works.

It would be good if Cisco made sure that the solution supports all routing protocols. Sometimes it doesn't.

I've been using it for probably 10 to 15 years.

For the most part, it's stable.

It's a very scalable solution.

The technical support is very good, and I would give them a nine out of ten.

Positive

The pricing and licensing are getting more complicated, and I'd like that to be simpler.

We evaluated some Palo Alto and Juniper solutions, but Cisco ASA Firewall is better in terms of ease of use. You could get certified in it.

To leaders who want to build more resilience within their organization, I would say that the ASA, along with its features, is a good product to have as one of the lines of defense.

The solution does require maintenance. We have four network engineers who
are responsible for upgrading code and firewall rules, and for new implementations.

On a scale from one to ten, I would rate Cisco ASA Firewall a nine. Also, it's a very good product, and it compares well to others.

We are primarily using the solution for VLAN implementations and also for remote VPN capability - basically it's used for connecting to remote offices securely.

After implementing tools, including Cisco ASA, unauthorized access comes down a lot. We are not facing asset issues as of now. We are not facing an issue related to malicious traffic or any bad activity in our network.

The solution can allow and block traffic over the VLANs.Some of the unauthorized actions and malicious traffic can also be blocked effectively, as we are following PCI DSS compliance. We are a card industry. We are using cards as a payment method, and therefore we need to follow the compliance over the PCI DSS. That's why we chose one of the best products. ASA Firewall is very secure.

It's always easy to integrate Cisco with the same company products. If you are using other CIsco products, there's always easy integration.

Cisco is one of the most popular brands, and therefore the documentation is easily available over the internet.

They are best-in-class.

The remote VPN feature is one of the best features we've found. 

We like that there is two-factor authentication on offer.  We can integrate a Google authenticator with Cisco ASA so that whenever a person is logging on to any network device, they need to enter the password as well as the security code that is integrated by Google. It's a nice added security feature.

Cisco ASA provides us with very good application visibility and control. The Cisco CLI command line is one of the easiest we found on the market due to the fact that the GUI and the user interface are very familiar. If you're a beginner, you can easily access it. There's no complicated UI.

When compared to other products available, the cost is pretty similar. There's no big gap when you compare Cisco pricing to other products. 

There are multiple features in a single appliance, which is quite beneficial to us.

Support that is on offer 24/7. Whenever we face some technical issue, we can reach out to them easily.

We have not had any security breaches. 

They provide a helpful feature that allows us to configure email. 

We are getting a lot from the appliance in real-time.

There's an upgraded version of the 5500 that has come to the market. It offers the latest encryption that they have. If they want to add better features to the current Cisco ASA, they can start by increasing the encryption. That is the only thing they need to improve. The rest is good.

We've been using the solution for about five or more years at this point. It's been a while. 

The stability and availability are very good. there are no bugs or glitches. It doesn't crash or freeze. it's a reliable solution. 

We have it in our infrastructure for around 15 plus users, including Fortinet sites.

We have found that whenever the traffic spikes at peak times, the product automatically scales up to the requirement. We have also implemented the single sign-on it, and therefore, it automatically scales up. We haven't felt any limitations. Currently, we are using it for 1500 plus users. At any given time, there are around 700 plus users available in the office. It's a 24/7 infrastructure. We have tested it for up to 750 plus users, and it's perfectly fine.

Technical support is excellent. they are always available, no matter the time of day, or day of the week. We are quite satisfied with their level of support. They are quite helpful and very responsive. I'd rate them at a ten out of ten. They deserve perfect marks.

We did not previously use a different solution. When the office was launched we implemented Cisco as a fresh product.

We are using a Cisco ASA Firewall, as well as Sophos at the remote sites. We are using another product is for log collecting. There are three solutions that basically cover us for security purposes. Those, at least, are the physical devices we are using as of now. The rest are cloud solutions such as Nexus. 

That said, I personally, have used Sophos XG as a firewall in the past. Sophos is good in terms of traffic blocking and identifying interruptions to the traffic. The features are better on Cisco's side. For example, there is two-factor authentication and a remote VPN. The only benefit I found in Sophos was the way it dealt with the traffic. 

The initial setup was not overly complex or difficult. It was quite straightforward and very easy to implement. 

Deployment takes about 20 to 25 minutes. 

In terms of the implementation strategy, at first, we put up the appliances in the data center. After that, we connected it with the console. After connecting the console, we had an in-house engineer that assisted. Cisco provided us onboarding help and they configured our device for us. We have just provided them the IP address and which port we wanted up. Our initial configuration has been done by them.

While most of the setup was handled in-house, we did have Cisco help us with the initial configurations.

The ROI we are getting from Cisco ASA is higher availability, which we are getting all the time. On top of that, it's good at blocking traffic and protecting us from cyber-crime issues.

The pricing is pretty reasonable. it's standard and comparable to other solutions. The maximum difference between products might be $20 to $40. It's not much of a difference. 

We did not evaluate other solutions. We trust Cisco. It's a very good product and well known in the market.

We are a customer and an end-user.

We are using physical Cisco appliances.

We use a lot of Cisco products, Cisco router (the 3900-series routers), and Cisco switches.

In the next quarter, we will implement SD-WAN. Once the SD-WAN is implemented, then we will go with an automated policy and DNS kinds of tools. We are in the process of upgrading to Cisco ASA Firepower in the next quarter. We have not integrated Cisco ASA with Cisco's SecureX solution.

I'd recommend the solution, especially for medium-sized or larger companies and those who are looking for long-term solutions (for example those with a user base of around 2,000 plus users in and around 20 plus applications). It's reliable and offers users a lot of features. This helps companies avoid having to rely on other third-party solutions.

If you are new to Cisco, you should take advantage of the education they have on offer. Cisco provides access to training and it's worth taking advantage of this.

Overall, I'd are the solution at a nine 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.

It helps the firewall in our network and the VPN (Virtual Private Network). It creates a secure tunnel for our network.

The IPS (In-plane switching) is the most valuable feature. This enables visibility to our networks and to outside attacks. It is a solution to maintain the visibility.

At times the product is sluggish and slow.  Sometimes when deploying a new configuration or role, it is painstakingly slow. It should be a little faster than it is. 

It is a very stable solution. 

It is a scalable product. We have a lot of demand.  But, it supports any additional network that we add. It expands easily. 

Normally the Cisco tech support team are good. But, we have had some problems with tech support with this product. Some of the tech support team are really not familiar with how the IPS works. And, there is some disconnect between the tech support. Maybe they're not trained well. They're helpful, but not knowledgeable.

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.

We mainly use it in the data center. We are obliged to use a firewall. It's a necessity.

It has helped in securing our infrastructure from end to end so that we can detect and remediate threats. There is another office in my company that does threat detection, but it has been helpful.

It hasn't freed up any time. We still have to manage the firewall. It's something we have to do.

All the features except IPS are valuable. IPS is not a part of my job.

It's already pretty good. In terms of functionality, there isn't much to improve. There could be more bandwidth and better interface speed.

I've been using Cisco firewalls for 20 years.

Its stability is very good.

It's better to have a higher speed. I'd rate it an eight out of ten in terms of scalability.

We have multiple locations and multiple departments. We are a big company, and we have a lot of remote sites. We have about 6,000 of them.

They are very good. From time to time, Cisco employees come to us and provide information about the latest features and new products. I'd rate them a ten out of ten.

Positive

We have other firewalls, and it hasn't helped to consolidate other solutions. We have to use the Cisco firewall and other vendors because of internal law. We have to use two firewalls, one from vendor A and the other one from vendor B.

We went for Cisco because it's affordable. It's something you can trust. It's something you know. It's a valued product. 

I've been involved in configuring it and assessing and ensuring that the configuration is up to date and there are no bugs, etc.

Its initial setup is not at all complex. I've been working with Cisco firewalls for 20 years, so I know them very well. It's not complicated for me.

We have all deployment models. We have on-premises and cloud deployments. We have everything. I belong to a big organization.

We had a consultant for integrating the product. Our experience with the consultant was good.

The number of people required for deployment varies, but one person can deploy the solution. It's quite easy to implement. It doesn't require a lot of staff.

It requires normal maintenance.

It's affordable.

Try it. You will be happy. 

I'd rate Cisco Secure Firewall a ten out of ten.

With [my company], NIL, it's cross-domain. It's just not ASA, but in particular we work with customers where we talk about the physical boxes or even the virtual appliances that we're deploying. The use cases can be multiple, but mostly what we have seen is perimeter security, looking at blocking [and] allowing of traffic before accessing the internet.

The majority of the challenges that we see across customers and partners is looking at the data, the integrity, security, [and] looking at various areas where they need to put in boxes or solutions which could secure their environments. It's not just about the data, but even looking at the endpoints, be it physical or virtual. That, in itself, makes the use case for putting in a box like ASA. 

And, of course, with the integrations nowadays that we have from a firewall, looking at multiple identity solutions or logging solutions you could integrate with, that in itself becomes a use case of expanding the genres of integrated security.

The best features would obviously be the ones that are most used: the perimeter security, allowing/blocking of traffic, NAT-ing, and routing, or making it easy as compared to a router. If you were to do the similar features on a router, it would be way more extensive and difficult as compared to a firewall. These are the majority of the features that anyone would begin with.

But of course, they expanded to other features like IPS or cyber security or looking at vulnerabilities or scanning, port scans. Those are the advanced things.

[In terms of overall performance] in the last decade or so, especially in the last three or four years, the scale of where the architecture has been—all the numbers, the stats, everything—has gone up exponentially. It's all because of the innovations that are always happening, and not just at the hardware level, but particularly at the software level. Of course, we can always look at the data sheets and talk about the numbers, but all I can say, in my experience, is that the numbers have really gone up, and the speed at which the numbers have gone up in the last couple of years or so, is really progressive. That's really good to see.

We're reaching [the point] where we want it to be. If you go 10 years back, we did miss the bus on bringing in the virtual versus the physical appliance, but now that we have had it, the ASAv, for a few years, I think we are doing the right things at the right place. 

The only improvement that we could make is maybe [regarding] the roadmap, to have better visibility as to what we are targeting ahead in the next few quarters. That is where we, as partners, can also leverage our repos with our customers and making them aware that there might be some major changes that we may have to introduce in their networks in the near future.

I started back in the days with ASA when I was [with] Cisco. I was [with] Cisco for 12 years. I started as a TAC engineer, and one of the teams I was leading was the ASA team, firewall, and across VPN, AAA. it became like a cross-border team or cross-architecture, and it's been long enough. I've been working with ASAs for about 12 or more years now.

From the stability standpoint, it's way better. Is there a scope for improvement? Of course. There always is. But I can just speak from my experience. What it was and what it is today, it is way better.

We look at scalability for any product of Cisco. I cannot be confined to the ASAs. We have physical, virtual, and cloud deployments. Everything is possible, so scalability is no issue.

Support, when you look at any product from Cisco, has been top-notch. I was a TAC guy myself for 10 years and I can vouch for it like anyone would do from TAC.

Support has always been extensive. There is great detail in root cause analysis. Going back into my Cisco TAC experience, it's always the story that if you know the product well, you know the things that you need to collect for TAC or for any other junior SME to work with you collectively, to get down to the solutions sooner. Otherwise, they have to let you know what you need to collect. It's better to know the product, get the right knowledge transfer, work towards those goals, and then, collectively, we can work as a great team.

I have mostly been involved in the pre-sales stage, and then eventually the post-sales as well. But we do the groundwork of making sure that we have set the stage for the customer to get the initial onboarding. And at times, I do it with other engineers or other colleagues who take it over from there. In my experience, it has been pretty straightforward.

It's not just the implementation, but [it's] also managing or maintaining [the ASA]. It would depend on how complex a configuration is, a one-box versus cluster versus clusters at different sites. Depending on the amount of configuration complexity and the amount of nodes that you have, you would need to look at staff from there. It's hard to put a number [on it and] just say you need a couple of guys. It could be different for different use cases and environments.

[In terms of maintenance] it's about a journey: the journey from having the right knowledge transfer, knowing how to configure a product, knowing how to deploy it, and then how to manage it. Now, of course, from the manageability standpoint, there are some basic checks that you have to do, like firmware upgrades, or backup restores, or looking at the sizing—how much your customer needs: a single node versus multiple nodes, physical versus virtual, cloud versus on-prem. But once you are done with that, it also depends on how much the engineers or SMEs know about configuring the product, because if they know about configuring the product, that's when they would know if something has been configured incorrectly. That also comes in [regarding] maintenance [of] or troubleshooting the product. Knowledge transfer is the key, and making sure that you're up to date and you have your basic checks done. Then, [the] manageability is like any other product, it's going to be easy.

The return on investment is not going to be restricted to just the box, because nowadays, if you look at the integrated security that Cisco has been heavily investing into, it's not just about ASA doing the firewalling functions. Now, these genres have been expanded to cyber, to third-party integrations, having integrated logging, having integrated micro and macro segmentations. The scope has been widened, so the ROI, eventually, has multiplied.

Being a partner, we work with customers who already have different vendor solutions as well. At times, there are a mix of small SMB sites, which could be, let's say, a grocery. There are smaller stores and there are bigger stores, and at times, they do local DIAs or local internet breakouts. [That's where] you do see some cloud-based or very small firewalls as well, but when you look at the headquarters or bigger enterprises, that is where we would probably position Cisco.

[My advice] would depend [on] if they are comfortable with a particular product, if they've been working with a particular vendor. If it's a Cisco shop, or if they've been working on Cisco, or the customers are quite comfortable with Cisco, I would say this is the way to go. Unless they have a mixed environment. It will still depend on the SME's expertise, how comfortable they are, and then looking at the use cases and which products would nullify or solve them. That is where we should position it.

My lessons are endless with ASA, but my lessons are mostly toward product knowledge. When you look at the deployment side of things, or for me, personally, when I was TAC, to know how things work internally within ASA—like an A to Z story, and there are 100 gaps between and you need to know those gaps—and then, eventually, you will get to the problem and solve it in minutes rather than hours.