Cisco Secure Firewall Reviews

We primarily use the solution for the various firewalls.

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

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

The stability is very good.

Technical support services are excellent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The solution works well for medium-sized enterprises.

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

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

On-premises

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

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

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

I have been using this solution since they developed it.

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

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

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

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

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

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

The initial setup is quite straightforward.

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

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

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

On-premises

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

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

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

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

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

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

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

The integration between these products isn't perfect. 

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

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

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

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

Firepower has improved our enterprise defense ability by a lot. 

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

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

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

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

I have been using Firepower for 3 years. 

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

The scalability is reasonable and okay. 

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

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

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

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

The best firewall option is Palo Alto. 

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

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

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

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

We are the integrators and consultant team. 

18 months

Be careful

Yes

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

I would rate it an eight out of ten. 

Hybrid Cloud

Amazon Web Services (AWS)

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

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

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

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

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

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

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

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

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

Nearly a year.

So far, it has been stable.

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

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

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

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

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

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

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

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

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

We have seen ROI. Our productivity has increased.

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

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

There are additional implementation and validation costs.

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

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

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

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

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

On-premises

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.

On-premises

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.

We've been using next-gen firewalls for about four years.

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.

On-premises

Our primary use cases for FTD are IPS, intrusion detection, and to get visibility into the network and the traffic that is going on in some sites. We always have them in-line, meaning that they're between two networking connections, and we analyze the traffic for the purposes of internal detection.

In production, from the FTD line, we mostly have 2110s and 2130s because we have a lot of small sites, and we are starting to put in some 4110s. We only have FirePOWER here, but we don't use them most of the time as next-gen firewalls but more as an IPS.

Everything is on-premises. We don't use public clouds for security reasons.

When you put FTD between your internet and network units, you can get valuable insights about your encrypted traffic on the web, DNS traffic, and the like. It gives us statistics up to Layer 7.

Although I can't go into the details, the way the solution has helped our organization is more on the root-cause side when there is an incident, because we get very detailed information.

FTD's ability to provide visibility into threats is very good, if the traffic is clear. Like most companies, we have the issue that there is more and more encrypted traffic. That's why we use Stealthwatch instead, because we can get more information about encrypted traffic. But FTD is pretty good. It gives us a lot of details.

We put them in in-line and in blocking mode and they have stopped some weird things automatically. They help save time every day. We have 150,000 people all over the world, and there are times when computers get infected. It helps save time because those infections don't propagate over the network.

The fact that we can centrally manage clients for our IPS, and that we can reuse what we type for one IPS or one firewall, makes it easy to expand that to multiple sites and multiple devices. Overall, it has been a great improvement.

The IPS, as well as the malware features, are the two things that we use the most and they're very valuable.

Cisco Talos is also very good. I had the chance to meet them at Cisco Live and during the Talos Threat Research Summit. I don't know if they are the leader in the threat intelligence field but they are very competent. They are also very good at explaining complicated things easily. We use all of their blacklist, threat intelligence, and malware stuff on our FTDs. We also use the website from Talos where you can get web reputation and IP reputation.

For the new line of FTDs, the performance could be improved. We sometimes have issues with the 41 series, depending on what we activate. If we activate too many intrusion policies, it affects the CPU. We have great hopes for the next version. We have integrated Snort 3.0, the new Snort, because it includes multi-threading. I hope we will get better performance with that.

The stability depends on the version. The latest versions are pretty good. Most of the time, we wait for one or two minor version updates before using the new major version because the major versions go through a lot of changes and are still a bit unstable. For example, if you take 6.3, it started to be pretty stable with 6.3.03 or 6.3.04.

Scalability depends on the site. At some sites we have ten people while at others we have a data center with a full 10 Gig for all the group. We have had one issue. When there are a lot of small packets — for example, when our IPS is in front of a log server or the SNMP servers — sometimes we have issues, but only when we get a peak of small packets.

We've got a little history with tech support. We have very good knowledge within our team about the product now. We have a lab here in Montreal where we test and assess all the new versions and the devices. Sometimes we try to bypass level-one tech support because they are not of help. Now, we've have someone dedicated to work with us on complex issues. We use them a lot for RMAs to return defective products.

In our company, we have used another firewall which we developed based on FreeBSD.

I, personally, used to work with Juniper, Check Point, and Fortinet. I used Fortinet a lot in the past. If you use the device only for pure firewall, up to Layer 4, not as an application or next-gen firewall, Fortinet is a good and cheaper option. But when it comes to a UTM or next-gen, Cisco is better, in my opinion. FortiGate can do everything, but I'm not sure they do any one thing well. At least with Cisco, when you use the IPS feature, it's very good.

Setting up an FTD is a bit more complex with the new FTD line. They integrated the FXOS, but the OS is still not fully integrated. If you want to be able to fully manage the device, you still need to use two IP addresses: One for FXOS and one for the software. It's complicating things for the 4110 to have to, on the one hand manage the chassis and the hardware on one, and on the other hand to manage the logical device and the software from another one.

But overall, if you take them separately, it's pretty easy to set up and to manage.

The time it takes to deploy one really depends. I had to deploy one in Singapore and access the console remotely. But most of the time, once I get my hands on it, it can be very quick because we have central management with FMC. Setting up the basic configuration is quick. After that, you have to push the configuration that you use for your group IPS and that's it. My experience is a bit different because I lose time trying to get my hands on it since I'm on the other side of the world. But when I get access to it, it's pretty easy to deploy. We have about 62 of them in production, so we have a standard for how we implement them and how we manage them.

We have Professional Services and consultants who work with us on projects, but not for the deployment. We have our own data centers and our own engineers who are trained to do it. We give them the instructions so we don't need Cisco help for deployment. We have help from Cisco only for complex projects. In our case, it requires two people for deployment, one who will do the configuration of the device, and one who is physically in the data center to set up the cables into the device. But that type of setup is particular to our situation because we have data centers all around the world.

For maintenance, we have a team of a dozen people, which is based in India. They work in shifts, but they don't only work on the FTDs. They work on all the security devices. FTD is only a part of their responsibilities. Potentially we can be protecting 140,000 people, meaning all the employees who work on the internal network. But mostly, we work for international internal people, which would be roughly 12,000 people. But there are only three people on my team who are operators.

ROI is a difficult question. We have never done the calculations, but I would say we see ROI because of some security concerns we stopped.

Cisco changed its price model with the new FTD line, where the appliances are a bit cheaper but the licensing is a bit more expensive. But that's not only Cisco, a lot of suppliers are doing that. I don't remember a lot of the licensing for Fortinet and Check Point, but Cisco's pricing is high, at times, for what they provide.

FTD is pretty good. You can stop new threats very quickly because you can get the threat intelligence deployed to all your IPSs in less than two hours. Cisco works closely with Talos and anything that Talos finds is provided in the threat intelligence of the FTDs if you have the license. It's pretty good to have the Cisco and Talos teams working closely. I know Palo Alto has an similar arrangement, but not a lot of suppliers get that chance.

Our organization's security implementation is pretty mature because we try to avoid the false positives and we try to do remediation. We try to put threat intelligence over a link to our IPS next-gen firewalls.

Overall, we have too many tools for security in our organization — around a dozen. It's very complicated to integrate all of them. What we have done is to try to use the Elastic Assist Pack over all of them, as a main point of centralization of log information. The number of tools also affects training of teams. There are issues because one tool can't communicate with the another one. It can be very hard, in terms of technical issues and training time, to have everybody using all these processes.

We also use Cisco Stealthwatch, although not directly with the FTD, but we hope to make them work together. There is not enough integration between the two products.

Overall, FTD is one part of our security strategy. I wouldn't rely only on it because we've got more and more issues coming from the endpoints. It lets you decipher everything but sometimes it is very complicated. We try to use a mix and not rely only on the FTDs. But for sure it's great when you've got a large network, to give you some visibility into your traffic.

I rate it at eight out of ten because it's pretty good technology and pretty good at stopping threats, but it still needs some improvement in the management of the new FTD line and in performance.

On-premises

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.

We've been using them for about two years. We used to have Check Point and we moved to the ASAs. We didn't really do a whole lot with them, just got them running in the first year. So in the last year-and-a-half to two years we've just been getting our feet wet with them.

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.

I deployed the Cisco Secure Firewall at the Internet Edge for the most part.

We use the solution for deep packet inspection, Internet Edge functionality, IDS, and IDP.

The solution’s GUI could be better.

I have been using Cisco Secure Firewall for six years.

Cisco Secure Firewall is a scalable solution that allows you to add capacity.

The solution’s initial setup is straightforward.

The solution’s pricing is competitive.

I rate the solution's ease of management and configuration an eight out of ten. I would recommend Cisco Secure Firewall to other users based on what they want it for and a combination of price point and supportability.

Overall, I rate the solution an eight out of ten.

We deploy the firewall on the customer end and the customer can facilitate the VPN for their clients. We use Cisco Umbrella to secure their network and their endpoints.

We only work with Cisco products. We have been working with Cisco products for many years. In that way, we save time and we don't want to change to other vendors.

The security features are the most valuable. My customers find the security products very useful because nowadays there are many threats from the internet and other malicious users. The security products really help.

So far, Cisco Secure for securing infrastructure from end-to-end so that we can detect and remediate threats is good enough.

It should be easier for the IT management or the admin to configure products. For example, the firewall products are not very straightforward for many users. They should be easier to configure and should be more straightforward. 

Some competitors are very easy to configure, you don't need to spend a lot of time reading the documents and learning them.

I have been using Cisco products for ten years. 

The support is good. Sometimes it has a long waiting time. The waiting time depends on the products. For some products, for example, the Data Center solutions, you have to wait for an hour, even though they said that they escalated the case. 

Positive

The initial deployment should be more straightforward. It's not that straightforward at the moment.

The licensing is not good, it's confusing. I'm an engineer so I don't care about the actual price that much but the licensing part is confusing.

We've evaluated other solutions. We've been consulted to use competitors' products. There are things that are good with those competitors, but everything has two sides.

We choose Cisco because we are a Cisco partner, so we only recommend Cisco products. They believe in us, so we have a good relationship with them. 

I would rate Cisco Secure products an eight out of ten. 

My advice would be to use them.