Cisco Secure Firewall Reviews

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.

Our business requirements are URL filtering and threat protection. We're using the Cisco 5525 and 5510 series. We have eight to 10 firewalls.

Our company is looking for vendors who can protect from the current, advanced technologies. We are looking for any technology that protects from the most threats, and that covers things like DDoS protection, spyware, and SSL.

We feel secure using Cisco firewalls. That's why we're using them. Cisco has never disappointed us, from a business point of view.

Cisco provides the most solutions.

We use some of our Cisco firewalls offsite. They provide DDoS  protection and multi-factor authentication. That is a good option as it enables work-from-home functionality. That is a feature that makes our customers happy.

Cisco needs to work more on the security and tech parts. Palo Alto gives a complete solution. Customers are very happy to go with Cisco because they have been around a long time. But that's why we are expecting from Cisco to give us a solution like Palo Alto, a complete solution. 

Cisco provides us with application visibility and control, although it's not a complete solution compared to other vendors. Cisco needs to work on the application behavior side of things, in particular when it comes to the behavior of SSL traffic. There is a focus on SSL traffic, encrypted traffic. Cisco firewalls are not powerful enough to check the behavior of SSL traffic. Encrypted traffic is a priority for our company.

In addition, while Cisco Talos is good, compared to the market, they need to work on it. If there is an attack, Talos updates the IP address, which is good. But with Palo Alto, and possibly other vendors, if there is an attack or there is unknown traffic, they are dealing with the signature within five minutes. Talos is the worst around what an attacker is doing in terms of updating bad IPs. It is slower than other vendors.

Also, Cisco's various offerings are separate. We want to see a one-product, one-box solution from Cisco.

I have been working on the security side for the last one and a half years. The company has been using Cisco ASA NGFW for three to four years.

The stability is good. It's the best, around the world.

The scalability is also good. But in terms of future-proofing our security strategy, it depends on the points I mentioned elsewhere that Cisco needs to work on.

We are getting the best support from Cisco and we are not getting the best support from Palo Alto.

In terms of costs, other solutions are more expensive than Cisco. Palo Alto is more expensive than Cisco.

Cisco is the most tested product and is more reliable than others. But Cisco needs to work on the security side, like website protection and application behavior. We have more than 40 locations around the world and all our customers are expecting Cisco. If Cisco provides the best solution, we can go with Cisco rather than with other vendors.

Palo Alto gives the best solution these days, but the problem is that documentation of the complete solution is not available on their site. Also, Palo Alto's support is not as good as Cisco's. We don't have a strong bond with Palo Alto. The longer the relationship with any vendor, the more trust you have and the more it is stable. We are more comfortable with Cisco, compared to Palo Alto.

If you're looking for a complete solution, such as URL filtering and threat protection, we recommend Palo Alto firewalls, but this Cisco product is also good.

We are using three to four security tools: one for web security, and another tool for application security, and another for email security. For email we have an Office 365 email domain so we are using other tools for that. For firewall security we are using Cisco ASA, Palo Alto, and Fortinet for protecting our business.

We have about 15 people on my team managing the solutions. They are network admins, and some are in security.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Currently, we have 16 remote sites. Some of them are sales offices and some of them are industrial plants. And we have a centralized IT department here in Brazil. The business asked me to support those remote sites. We started using the Firepower Threat Defense, which is one of the versions of next-gen firewalls from Cisco, at some of the sites. We have them operating at five sites, and we are deploying at a sixth site, in Mexico, with the same architecture. That architecture has the firewall running on the site's router, and we manage them all from here in Brazil.

Overall, I would summarize Firepower NGFW's effect on our company's security position by saying that, until now, we haven't had any major security incidents. The investment we made, and the investment we are still making in that platform, have worked because they are protecting us from any risks we are exposed to, having all these remote sites and using the internet as the way to connect those sites. They are doing what they promised and they are doing what we paid for.

For us, the main feature is due to the fact that we have internet connections for all these sites, and we use the internet to communicate with our data center using VPN. So the VPN support in these boxes is one of the most valuable features.

Also, with the firewall itself, the protection and security features, like URL filtering, the inspection, and the IPS feature, are also very valuable for us. We don't have IT staff at most of the sites so for us it's important to have a robust firewall at those sites, to support the business and give us peace of mind. If we do have an incident, since we don't have any IT personnel there for support, we need to do everything remotely.

It provides us with application visibility and control. We can see, on the dashboard, all the applications that are most used and which are under some sort of risk or vulnerability. From my perspective, which is more related to the network itself and the infrastructure, not the security aspect, it helps a lot when we need to check some situation or issue that could be related to any attack or any violation. We can see that there are one or two or three applications that are the top-consuming applications. We can use this information to analyze if there is a deviation or if it's something that we need to consider as normal behavior and increase the bandwidth on the site. It's very important to have this analytic view of what's happening. That's especially true for us, since we have information on all these remote sites but we don't have IT resources on-premises. Having this view of all the sites in the same pane of glass is very important.

It's not just the visibility of things, but the management of application behavior is very important. If I see that, for example, Facebook is consuming too much bandwidth, I can make a policy on the console here and deploy it to our remote offices. So the application visibility feature is one of the key parts of the solution.

NGFW's ability to provide visibility into threats is also one of the important features. Although we have several applications that are based on-premises — we have databases and file servers that only exist inside the company or inside those remote sites — we see more traffic going to and coming from the internet every day. It's not optional anymore to have visibility into all this traffic. More and more, we are moving things to Office 365 or other SaaS platforms which are hosted on the internet. We need to see this traffic crossing our network. It's a top priority for us.

When it comes to Talos, I recognized the importance of it before they were even calling it Cisco Talos. As a user of the URL filtering product, the IronPort appliances, for six or seven years, perhaps or more, I was introduced, at that time, to a community that was called SenderBase.org, which was like the father of the Cisco Talos. Knowing them from that time, and now, the work they do is very important. It provides knowledge of what is happening in the security space. The information they can collect from all the hardware and software they have deployed with their customers is great. But the intelligence they also have to analyze and provide fixes for things like Zero-day attacks, for example, is crucial. They are able to map and categorize risks. They're unbeatable, currently. Although we know that other vendors have tried to replicate this service or feature, the history they have and the way they do their work, make it unbeatable currently.

Some products supersede others within Cisco. I have three platforms and some of the features are the same in two products. It's not clear for us, as a  customer, if Cisco intends to have just one platform for security in the future or if they will offer one product for a particular segment, such as one product for the big companies, one product for the financial segment, another product for enterprise, and another product for small business.

Sometimes, Cisco itself has two products which are doing the same things in some areas. That is something they could make clearer for customers: the position of each product or the roadmap for having just one product. 

For example, I have a management console for the next-gen firewalls we are deploying. But the SD-WAN also has some security features and I would have to use another management console. I don't have integration between the products. Having this integration or a roadmap would help. I don't know if there will be one product only in the future, but at least having better integration between their own products is one area for improvement.

Also, the user interface for the Firepower management console is a little bit different from traditional Cisco management tools. If you look at products we already use, like Cisco Prime or other products that are cloud-based, they have a more modern user interface for managing the products. For Firepower, the user interface is not very user-friendly. It's a little bit confusing sometimes. This is another area where they could improve.

We have been using Cisco NGFWs for about for two years.

The stability is okay. It's robust enough to support the business we have. We haven't had any major issues with the product itself. Of course, we don't touch them frequently because it's a security deployment so it's not the type of thing where we make changes every day. Once we deploy them, and deploy the policies, we don't touch them frequently.

We have one issue at one of the sites, at times. There is a power outage at the site and the virtual machine itself crashes. We have to recover from the crash and reinstall the backup. It's something that is not related to the product itself. It's more that our infrastructure has a problem with power which led to a firewall problem, but the product itself is not the root cause.

It is scalable in our scenario. It is scalable the way we deploy it. It's the same template or architecture, and that was our intention, for all our remote sites. From this point of view, the scalability is okay. But if one of those remote sites increases in demand, in the number of users or in traffic, we don't have too much space to increase the firewall itself inside that deployment. We would probably need to replace or buy a new, more robust appliance. So the scalability for the architecture is fine. It's one of the major requirements for our distributed architecture. But scalability for the appliance itself, for the platform itself, could be a problem if we grow too much in a short period of time.

I don't know how to measure how extensively we use it, but it's very important because without it, we can't have VPN and we can't communicate with our headquarters. We have SAP as our ERP software and it's located in our data center here at our headquarters. If we can't communicate with the data center, we lose the ability to communicate with SAP. So if we don't have the firewall running on those remote sites, it is a major problem for us. We must have it running. Otherwise, our operations at these remote sites will be compromised. In terms of volume, 40 percent of our sites are deployed and we still have plans to deploy the other 60 percent, this year and next year.

Regarding future demands, if we create new business, like we are doing now in Mexico, our basic template has this next-gen firewall as part of it. So any other new, remote sites we deploy in the future, would use the same architecture and the same next-gen firewall.

For our remote sites we didn't use a specific security platform. We had the Cisco router itself and the protection that the Cisco router offers. But of course you can't compare that with a next-gen firewall. But here in our headquarters, we currently use Palo Alto for our main firewall solution. And before Palo Alto, we used Check Point.

The decision to use Cisco was because Cisco could offer us an integrated platform. We could have only one router at our remote sites which could support switch routing with acceleration, for IP telephony and for security. In the future we also intend to use SD-WAN in the same Cisco box. So the main advantage of using Cisco, aside from the fact that Cisco is, course, well-positioned between the most important players in this segment, is that Cisco could offer this solution in a single box. For us, not having IT resources at those remote sites, it was important to have a simple solution, meaning we don't have several boxes at the site. Once we can converge to a single box to support several features, including security, it's better for us.

The main aspect here is that if we had Fortinet or Check Point or Palo Alto, we would need another appliance just to manage security, and it wouldn't be integrated with what we have. Things like that would make the remote site more complex.

We don't currently have a big Cisco firewall to compare to our Palo Alto. But one thing that is totally different is the fact that Cisco can coexist with the router we have.

I participated in the first deployment. I know it's not hard to do, but it's also not easy. It requires some knowledge, the way we deploy it. We use next-gen firewalls inside the Cisco router. It's virtualized inside the Cisco router. So you need to set settings on the router itself to allow the traffic that comes to the router to go to the firewall and return to the router to. So it's not an easy setup but it's not very complex. It requires some knowledge, not only of security, but also of routing and related things. It's in the middle between complex and simple.

Once you have the templates for it, it's easier. It can take a day or two to deploy, or about 20 hours for the whole configuration.

The name of the local partner we use here in Brazil is InfraTI.

For the first deployment we had to understand how to do it because of the constraints. We have the router and we have the next-gen firewalls running inside the router. Until we decided how to deploy, it took a little while. But now we have the knowledge to do that more easily. They are able to deploy it satisfactorily. We are happy with them.

For deployment and maintenance of the solution, it requires two people and our partner. On our side there is an engineer to discuss the details, and then there is the person who does the deployment itself.

You must know exactly what features are important for you, and how you can manage all this infrastructure in the future. Sometimes you can have a product that is superior but it might demand an increase in manpower to manage all the software or platforms. Another point to consider is how good the integration is between products? You should check what features you need, what features you can have, and the integration with other products.

In terms of the maturity of our security implementation, we have had security appliances, software or hardware, for more than 15 years. So we have a long history of using security products. We started using Cisco competitors in the past and we still use them for our headquarters, where I am. Our main firewall is not currently Cisco, although we are in the process of evaluation and we will replace this firewall soon. Cisco is one of the brands being evaluated for that.

In the past, while it's not a next-gen firewall, we also used a Cisco product for URL filtering, up until this year.

We are moving to the cloud. We are starting to use Office 365, so we are moving email, for example, from on-premises to the cloud. But until June of this year, we mainly used security from Cisco. But we also have antivirus for endpoint protection. We also had Cisco IPS in the past, which was a dedicated appliance for that, but that was discontinued about two years ago. Those are the major products we use currently. In addition — although it's not specifically a security product — we use Cisco ISE here to support our guest network for authentication. We plan, in the near future, to increase the use of Cisco Identity Services Engine. When we start to use that to manage policies and the like, we will probably increase the integration. I know that both products can be integrated and that will be useful for us.

There's one other product which we use along with Cisco next-gen which is a SIEM from Splunk. Currently, that is the only integration we have with Cisco. We send logs from next-gen firewalls to the Splunk machine to be analyzed and correlated. 

Although I'm not involved on a daily basis in operations, I helped in the process of integrating it. It was very easy to integrate and it's a very valuable integration, because we can analyze and correlate all the events from the next-gens from Cisco, along with all the other logs we are collecting in our infrastructure. For example, we also collect logs from the Windows machine that we use to authenticate users. Having those logs correlated on the Splunk box is very valuable. The integration is very easy. I don't know who built what, but there's a kind of add-on on the Splunk that is made for connection to firewalls, or vice versa. The integration is very simple. You just point to the name of the server and a user name to integrate both.

We use them to block or allow traffic out to the internet and to control a handful of DMZs. Overall, they're for access control. We do IPS and IDS as well.

We have the FMC (FirePOWER Management Center) which manages the 4110s and we have 5516s and the ASA5545-Xs. It's an ASA running the Next Generation Firewall code. We're using all of the FMC with 6.4.04, so they're all running the Next Generation Firewall code. We deploy the software on-prem.

The information coming from Talos does a good job. It marks that information and bumps it up to us. We have rules where we are getting alerts and it does a good job as far as giving us alerts goes. Talos is pretty well-respected. I like the fact that Cisco is working with them and getting the information from them and updating the firewall. We get the vulnerability database stuff updated, and the location stuff gets sent out. I like all that.

In terms of how the ASAs have affected our security posture as an organization, it's done well. We're growing with ASA, with the FirePOWER. When we first started there were a lot of bugs and a lot of issues. But now they're coming forward and acting on requests, things that we want.

The majority of what I use is the policy ruleset. We have another company that deals with the IPS and the IDS. That's helpful, but I can't necessarily speak to that because that's not the majority of what I do. The majority of what I do is create rules and work with the customers to make sure that things are getting in and out of the environment.

I work with our e-commerce team to make sure that new servers that are spun up have the appropriate access to other DMZ servers. I also make sure that they have access to the internet. I make sure they have a NAT so that something can come into them if need be.

We use Umbrella, Cisco's DNS, which used to be OpenDNS. We use that to help with security so that we're not going to sites that are known to be bad. They work well together. They're two different things. One is monitoring DS and doing web URLs, while the firewall I'm doing is traffic in and out, based on source destination and ports protocols.

One of the things I like is that the upgrades are relatively seamless, as far as packet loss is concerned. If you have a firewall pair, upgrading is relatively painless, which is really nice. That's one of the key features. We do them off-hours, but we could almost do them during the day. We only lose a few packets when we do an upgrade. That's a bonus and if they keep that up that would be great. Check Point does a reasonably good job at it as well, but some of the other ones I've dealt with don't. I've heard from people with other firewalls and they don't have as good an experience as we do. I've heard other people complain about doing upgrades.

One of the things that we got out of the Check Point, which we're finally getting out of the ASA, is being able to analyze the hit count, to see whether a rule is actually used or not. That is going to be incredibly beneficial. That still has ways to go, as far as being able to look into things, security-wise, and see whether or not rules or objects are being hit. It could help in clean-up, and that, in itself, would help with security. The FTD or the FirePOWER has a little way to go on that, but they're doing well implementing things that not only we at Orvis, but other people, are requesting and saying should be done and are needed.

In addition, if pushing policy could take a little less time — it takes about five minutes — that would be good. That's something they're working on. 

Finally, our latest experience with a code upgrade included a number of bugs and issues that we ran into. So more testing with their code, before it hits us, would help.

The code has been reasonably good. It's getting better. The stability depends on the code and this last version of code we went through did give us a number of issues. It all depends on what the stability is in the code.

The devices we have can scale pretty well. We have 600 to 700 people and we have an e-commerce site. It's deployed across the entire organization, although we have multiple firewalls.

We have plans to increase usage. We're going to do more DMZ to protect ourselves. So we'll be having more interfaces off the firewalls and we'll be protecting more VLANs. That's probably as big as we are going to get. I don't see us doing too much more than that.

Tech support is good. We have an exceptional sales rep or project manager. Jenny Phelps is the person we work with and if we have any questions or anything that needs to be escalated, we send it to her and it's usually done very quickly. That relationship is a huge value. Jenny is worth her weight in gold.

I wasn't around for the initial setup, I was just starting. We were moving from Check Point to the ASA. It took about six months for them to engineer it and put it in place.

The implementation strategy was to try to determine all the rules in the Check Point and duplicate all those rules in the FirePOWER. We had to roll back twice before it finally took. That wasn't anything to do with the FirePOWER or the ASA. It had more had to do with the person who had to put the rules in and understanding what was actually needed and how they should be put in.

We did it through a consultant, Presidio. They had two people on it. Other than that, they were pretty good.

Just in terms of cost, the Check Point number was ten times as expensive as the Cisco number, so there was "instant" ROI in that sense. But we needed to replace our firewalls. Check Point had been in for five or six years. They did a bake-off to see which one was the best one to go to.

We used Check Point and the two are comparable. Cost was really what put us onto the ASAs. They both do what it is we need them to do. At Orvis, what we need to do is very basic. But the price tag for Check Point was exorbitantly more than what it is for the ASA solution.

We pay Cisco for maintenance on a yearly basis. There are no additional fees that I'm aware of.

My understanding is that Check Point and Fortinet that were evaluated, at the end.

I wasn't around when we did the actual bake-off. I came in when a solution was picked. I was told why the solution was picked and I was there when they did the final install. It was managed for a little while by Presidio and then it was given to us.

The biggest lesson I've learned from using the ASAs is the fact that they can do a lot. It's just figuring out how to do it. We don't do a lot, although once in a while we will do something a little interesting. These things can do more than what we're using them for. It's just a matter of our trying to figure it out or getting with our Cisco rep to figure it out.

My advice would be to have a good handle on your rules and, if you can, take the upgrades easily.

We have desktop security, application security, and then we have Umbrella. We use five or six different tools for security, at least. It would be nicer to have fewer but as far as I know there isn't one tool that does it all.

We do application firewall rules where it does deep packet inspection and looks at certain things. We don't use it as much as we should, but we do application inspection and have rules that are based on just an application.

We usually have two people on a call when we do maintenance, and we usually have Cisco involved. It's usually me and a colleague who is also a network/security engineer.

I would rate the ASA overall at eight out of ten. The thing that comes to mind with that rating is the code. As I said, we just upgraded to 6.4.04 and we ran into a handful of bugs. We've done upgrades before and we've run into a bug as well. Just last week, we finished upgrading, and I still have one final service request, a TAC case, open. I had four open at one point. That's at the forefront of my thoughts right now.

It's hard to judge how much time it saves our organization because it's doing things you don't realize. For example, when it's blocking web advertisements, when it's blocking phishing, when it's blocking geolocation, the time it saves is because of the things you might have had to deal with that, now, you don't. Any time we have some kind of internet-related event, it's definitely going to take us hours worth of time. We have to do an investigation, we have to report on it, we have to write something up. By protecting our environment it probably saves our security analysts a fair number of hours during the week.

It's the brick wall that keeps us from the bad guys. It does a lot of things. In the beginning when you just have a firewall, of course, it's your NAT and it's your Access Control List. It's the thing that allows traffic in and out. There is some routing involved in that too. But once you add Firepower onto to it and you start enabling some of its features, you get some IDS/IPS involved with it and you can even do web filtering.

We used to do some web filtering on the Firepower but we moved into Umbrella once we started. We do use Firepower for one piece of web filtering because Umbrella has yet to provide it: advertisement blocking. We don't allow our end-users to go into advertisements. If they're going to go to a site, they have to know what the site is, not just try to hit some kind of Google ad to get to it because those can be dangerous.

In Firepower, there is an ability to search and dig into a search, which is nice. However, I'm not a super fan of the way it scrolls. If you want to look at something live, it's a lot different. You're almost waiting. With the ASDM, where it just flows, you can really see it. The second someone clicks something or does something, you'll see it. The refresh rate on the events in Firepower is not as smooth. It's definitely usable, though. You can get a lot of good information out of it.

It's hard to stay on the bleeding edge on firewalls because you have to be careful with how they integrate with Firepower. If you update one you have to update the other. They definitely have some documentation that says if you're at this version you can go to this version of Firepower, but you need to be careful with that.

We've been using Firepower for two to three years.

It's pretty stable. There are times where I'll get an email saying a process has stopped. But a few seconds later, they'll say it restarted it on its own. It's hardy enough that if it is having problems, it's bringing things back up. For the most part, it's been very reliable.

It's been really good. And even so, if I've had to reboot the actual appliance, I'll bring it back up and it's good to go.

We haven't hit that issue of scalability. We have increased the amount of traffic through it and it's handled it, but I think that's also a product of the ASA as well. If the ASA is going to choke, Firepower is going to choke as well.

We're going to be bringing in two new firewalls, as early as the fourth quarter or first quarter of 2020, and those are going to be pure FTD appliances. We'll probably be using those a little bit more extensively. I don't think we're going to be using the SSL portion, but we'll probably have the IDS/IPS, and we'll probably have the AMP turned on. That's because with the endpoints, we're not sure if we're going to be able to install an antivirus, so we can at least watch that. We'll probably use most of the suite on it.

I've always liked Cisco support. We're a pretty big Cisco shop, so you're not going to hear a lot of complaints from me about support. And not only that, but if I do have a problem with Cisco support, we get ahold of somebody - our customer-success people and the salespeople from Cisco who are focused on our organization - and we get help. It's very good.

Sometimes, I'll have to contact the first tier of tech support. I'll still open up a case. But in case that, for whatever reason, is not going to our satisfaction, at least we have a chain of command we can go through and talk to some different people. We might get it escalated if we're just not getting something fixed on time. But Cisco has very top-notch support.

We've been with Cisco and haven't had anything else yet. We haven't had a desire to move in a different direction. We've stayed with it because of how good it is.

We were initially introduced to Firepower by a consultant. At that time, it was for the web filtering because the web filtering we had was awful. We were using Sophos. Without getting too derogatory, it was just awful. There was no alerting and it was very hard to manage, whereas this is really easy to manage. With Cisco, it was very easy to set up content groups, to allow some users to get to some stuff and other users to not get to it. That's where it really started. There weren't any pros to Sophos that weren't in Firepower. We got rid of Sophos.

Our organization is a big believer in training, So I attended a five-day class on this. From that, I was able to set it up pretty easily.

We have a virtual appliance. Once it actually installs and we set IPs and got some of the base set up, it was done within about a day. But the time it takes will depend. We're not an organization that has 10,000 users. We're probably a medium enterprise, of about 400+ users, rather than a large enterprise, so our ruleset is comparatively small. As a result, it didn't take me as long as it might for some, a total of two or three days, and that's even with fine-tuning. But because we're still using the ASA and the ASDM, we still have those rules in the firewall. We're not really at the FTD point where all the rules are in there. If we were, to migrate it would probably take some time.

For me, it was relatively simple because of the valuable training I had. There are some good resources online, don't get me wrong. It was just nice to be able to do something hands-on at a place, in training, and then come back and be able to do it.

The neat thing is that the gentleman who taught us, instead of just teaching us the material from a book or even, "This is how you can pass the Firepower test," taught us how he would go into a Fortune 100 and set up an organization. I had almost a step-by-step lesson on how to keep going through the configurations to get to a finished product.

With a firewall, you're always coming back to it to tweak it a little bit. You might find, "Oh, I'm not getting the logging a lot," or, "Oh boy, this rule is doing this, but maybe I want to tighten it down a little bit more." But to get the base configuration, to get the objects in, it takes about a couple of days. At that point, you can at least have traffic going through it. You may not be blocking anything, but you can be monitoring things.

It was just me.

The return on investment would be the fact that I'm just not spending a lot of time either searching for things or trying to stop what's coming in and out of our network. The return on investment is the time I would have to spend during the day looking at things versus it proactively doing its job.

We're going to get to a point, not this year and not the coming year, probably going into 2021, where we're going to want to replace the ASA appliances with either virtuals or actual physicals. But the Firepower series of appliances is not cheap.

I just got a quote recently for six firewalls that was in the range of over half-a-million dollars. That's what could push us to look to other vendors, if the price tag is just so up there. I'm using these words "fictitiously," but if it's going to be outlandish, as a customer, we would have to do our due diligence and look at other solutions at that point.

In addition to that cost, there are licensing fees for some of the individual things like AMP, the IPS/IDS piece. It depends on what you want to use, such as the SSL piece and the VPN piece, which we don't use.

We haven't evaluated any other options. The only thing that may ever force us in that direction would be cost. Only if the cost of the solution got so large would we have to look at something comparable.

The neat part about this is how Cisco continues to evolve its product line and help us stay secure, while still doing our day-to-day business.

My advice would depend on how you want to use it. What are you looking for Firepower to do?

Firepower added features that, until we introduced into our environment, we could not have done. We probably could have added a third-party product but we would hate to keep doing all that. It's nice to be able to have our products from the same organization because then, if something's really wrong, we can talk to the same organization as we're trying to troubleshoot something through our environment. We use Cisco switches, Cisco routers, we use ISE, and Umbrella. We have a lot of products through Cisco.

We use the ACLs. We use the intrusion side, just to watch traffic. We have used the malware and have actually caught stuff in there. We do have a DNS policy so that at least we can check to make sure someone's not going to a bogus site; things can get blocked for that, but Umbrella is really good at what it does. We also have it connected to our Active Directory so I can see which users are going where, and that is valuable. But I can also see that in Umbrella, so there's some overlap.

For managing the solution it's me and at least one other person. I'm the primary resource on it.

We used to use AMP for endpoints through the Firepower but we decided to discontinue that. We have AMP on all our endpoints but with all the other things we have, such as Umbrella, we were satisfied enough with the security we have. We didn't want two different things possibly stopping files instead of having one console area to be able to see those kinds of things.

Overall, I would rate Firepower at eight out of ten. Every product can improve. But for what we're looking to do, it does a very good job.

The primary use case is to protect our departments. We have sub-departments or sites categorized by the number of users and types of applications. We categorize the latter in terms of small, medium, or large. Based on that, we select a firewall in terms of throughput and the number of concurrent sessions it can handle. We then deploy the firewall with a predefined set of rules which we require for inbound and outbound traffic.

We are in operations delivery and we need to support multiple clients. We have different departments where our primary responsibility is to protect our organization's assets and data and to store them in a centralized data center. Apart from that, we have responsibility to support our clients in terms of infrastructure.

All the devices are on-premise. Nothing is on the cloud or is virtualized.

One of the most valuable features in the current version is the dashboard where we have a complete analytical view of the traffic behavior. We can immediately find anomalies. 

The most important point is the detection engine which is now part of the next-generation firewalls and which is supported by Cisco Talos.

Most users do not have awareness of this product's functionality and features. Cisco should do something to make them aware of them. That would be quite excellent and useful to organizations that are still using legacy data-center-security products.

The product's stability is perfect. From my observation, the mean time to failure is once in seven years or eight years. All the hardware in the device is quite stable. I haven't seen any crashing of the operating system.

Scaling is quite easy. 

On a scale of one to ten, I would evaluate Cisco support as a ten. I get support in a fraction of time. There is no problem in getting support.

Since I have worked in this organization, Cisco has been the primary product that has been deployed.

The initial setup is quite straightforward. It's quite simple, without any complexities. Whenever we find any issue during the primary phase, we reach out to the Cisco technical support team for assistance and within a short period of time we get support from them.

The most recent deployment we did took about three weeks.

In terms of deployment plan, we go with a pre-production consultation. We create a virtual model, taking into account all the rules, all the cabling, and how it should work in the environment. Once everything on the checklist and the prerequisites are in place, then we migrate the existing devices into production.

As consultants, most of the time we deploy ASA by ourselves. If there is any complexity or issue, we get in touch with a system integrator or we open a ticket with the technical support team.

There would definitely be return on investment by going with Cisco products. They are stable.

For any organization looking for a secure solution that can be deployed in their domain or infrastructure, my advice is to go with Cisco Next-Generation Firewalls because they have a complete bundle of security features. There is a single pane of glass with complete management capabilities and analytic features to understand and gather information about the traffic.

The lessons that most of our clients have learned is that in deployment it is easy to configure and it is easy to manage. It's quite stable and they do not get into difficulties in terms of day-to-day operations. 

We haven't faced any problems with this product.

Compared to other OEMs, such as Juniper and Fortinet, Cisco's product is excellent. There are no bugs and I don't see any lack in terms of backend and technical support. In my opinion, at the moment, there is no room for product enhancement.

Most of the users are system administrators working on their own domains. The minimum number of users among our clients is a team of 15 to 20 we have clients with up to 700 users at the largest site.

The product is quite extensively used in each department, to protect assets and data centers. We are using the attack prevention engine and URL filtering is also used at most of our sites. We are also using it for data center connectivity and for offloading transactions.

I would rate Cisco at ten out of ten for the functionality and the features they provide.