What needs improvement with Cisco Firepower NGFW Firewall?

Cisco could improve its score by developing more features that integrate seamlessly with various applications and investing in hardware acceleration to enhance performance.

Cisco firewall needs experience with hardware. They should also enhance security antivirus, application detection, user detection, and ID detection.

The dashboard can be improved.

The product's user interface is an area with certain shortcomings where improvements are required. From an improvement perspective, the product's price needs to be lowered.

The solution's deployment is time-consuming, which should be minimized and made more user-friendly for us. The solution's graphical user interface could be made more user-friendly, and the configuration can be simple.

The solution's price can be lowered because, currently, it is pricier than the tool its competitors offer in the market. If the product's prices are lowered, it may help Cisco to expand its market base. If Cisco reduces the price of its product, then it can gain more advantage and become much more competitive in a market where there are solution providers like Fortinet FortiGate.

In terms of ways that the firewall could be improved, third-party integration is already reasonable. We were able to integrate with our vulnerability management software, for example. However, I would say that when we're looking at full-stack visibility, it can be difficult to get the right information out of Firepower. For example, you may need to get a subset of it into your single pane of glass system and then refer back to Firepower, which can add time for an analyst to look at a threat or resolve a security incident. It would be nice if that integration was a little bit tighter.

The policies module in FMC specifically isn't the most user-friendly. Coming from Cisco ASA, Cisco ASA is a little bit easier to use. When you get into particularly complex deployments where you have a lot of different interfaces and all that kind of stuff, it's a little bit tricky. Some usability improvements there would be nice. For scalability, they could support a little bit more diverse deployments around clustering and high availability. Currently, it's very active standby, and being able to do a three firewall cluster or four or five firewall cluster would suit some of my deployments a little bit better. It would also help to keep the cost down for the customer because you're buying smaller devices and clustering them versus larger devices.

I would like to see an IE version of the solution where it is ruggedized. Most of what we do is infrastructure based on highways. Now that the product has a hardened switch, the only thing left in our hubs that isn't hardened is probably the firewall. It would be nice to pull the air conditioners out of the hubs.

The cloud does not precisely mimic what is on-premises. There are some new challenges with the features in Azure. Due to Azure limitations, we cannot synchronize configurations between an active standby. This aspect makes it difficult to perform such tasks in the cloud, requiring manual intervention.

The integration with all the necessary products needs improvement. Managing various product integrations, such as Umbrella, is challenging.

It's a question of performance. When we talk about data centers, we are talking about 100 gig capacity or 400 gig capacity. When it comes to active-active solution clustering and resilience and performance, Cisco should look into these a little bit more.

The virtualization aspect has room for improvement. The scalability has room for improvement.

Firepower's implementation and reliability need room for improvement.

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.

In today's world, cyberattacks have become a common occurrence. However, so far, we have not faced any issues with our systems. I hope the situation remains the same in the future. If Cisco introduces even more advanced security measures, it would be beneficial. One of the major issues we face in the Middle East is the long delivery time for Cisco products. Currently, they are taking almost 10 months to deliver, which is much longer compared to before when we received the products within 70 to 80 days or even two to three months. For instance, we recently placed an order that has a delivery date in the middle of 2024. This delay is unacceptable as customers cannot wait that long, and they may opt for other alternatives, such as Huawei, Juniper, or HPE. Therefore, Cisco needs to improve its delivery time and ensure that they deliver products within a reasonable timeframe, as it did before.

I don't have any specific improvements to recommend. However, when you compare the throughput of a Cisco firewall to the competitors, especially Fortinet, what you find is that Cisco has lagged a little bit behind in terms of firewall throughput, especially for the price that you pay for that throughput.

The usability of Cisco Firepower Threat Defense is an issue. The product is still under development, and the user interface is very difficult to deal with. That's one area where it should be improved. Another area for improvement, which is also related to the firewall, is stability. We are having stability issues, and we had some cases where customers had a network down situation for about one or two days, which is not great.

The overall licensing structure could improve to make the solution better.

There should be more integration with Microsoft Identity.

There is room for improvement in the stability or software quality of the product. There were a few things in the past where we had a little bit of a problem with the product, so there is room for improvement. In the past, we had problems with new releases. Also, from the beginning, some functionalities or features have not worked properly. There are bugs. Every product has such problems, but sometimes, there are more problems than other products, so it's definitely something that can be improved, but Cisco seems to be working on it.

We have encountered problems when implementing new signatures and new versions on our firewall. Sometimes, there is a short outage of our services, and we have not been able to understand what's going on. This is an area for improvement, and it would be good to have a way to monitor and understand why there is an outage.

I would like to see more configurable feature parity with Cisco ASA, which is the legacy product that Cisco is moving away from. When configuring remote access VPN, not all of the options are there. You have to download another tool, which means that the configuration takes a little bit longer with Cisco Secure Firewall. Though it's getting there, there are still some features lagging behind.

If WSAP remains to be an active product, it might be an idea to integrate the configuration policy logic between Umbrella and WSAP. There should be one platform to manage both. The integration between the on-prem proxy world and the cloud proxy would benefit us. One single policy setting would make sense.

Cisco Secure Firewall could benefit from enhancements in its API, documentation, and automation tools. Additionally, we've noticed that the Terraform provider for FMC has only two stars, few contributors, and hasn't been updated in a year. It only has 15 to 20 resources, which limits our capabilities. We'd love to update it and add more resources. For example, we currently can't create sub-interfaces with the provider, so we have to add Python code to our Terraform provider and use local provisioners. Additionally, improvement in the API would be helpful so that we can create ACL on the GUI with a simple click, but at this time we cannot create requests via the API.

it is difficult to say what it needs in terms of what needs to be improved. I don't work with it on a daily basis. I haven't heard anything negative about it. While this applies to all vendors, pricing can be always lower. In my opinion, Cisco is the most expensive. The pricing can be reduced.

Maybe the dashboard could be a bit better. There are some reports where we don't get it. We need a deep dive into a particular URL, however, it provides the URL and the IP address, and there is no more information that can show more details. Basically, the report models can be improved. With their console, we have to build a separate VM. In some of the products, the management console comes along with the box itself. It'll be one solution to take the backup and keep it. Even if you want to build a DR, it'll be easy. However, the challenge we had is if that VM is down, my team may not able to access the Firepower remotely. Therefore, the management console itself should be built within the Firepower box itself, rather than expecting it to be built in a separate VM.

Licensing is complex, and I'd like it to be simplified. This is an area for improvement. If we could create a Firepower solution that became like an SD-WAN or a SASE solution in a box, then perhaps we could exploit that on remote sites. We've already kind of got that with Meraki, but if we could pull out some of the features from ASA Firepower and make those available in SD-WAN in SASE, then it would be pretty cool.

The application detection feature of this solution could be improved as well as its integration with other solutions.

A major area of improvement would be to have more functionality in public clouds, especially in terms of simplifying it. The high availability doesn't work right now because of the limitations in the cloud. Other vendors find ways to make it work differently than with on-prem solutions. This is very important because we have customers that build solutions in the cloud that are like what they had on-prem. They have done a lift-and-shift because it's easier for them. They lift their on-prem physical boxes and shift them to the cloud, convert them to virtual, and it continues to work that way. Many times it's not the most efficient or best way to do things, but it's the easiest. The easiest path is probably the way to go.

The ability to better integrate with other tools would be an improvement.

The ease of use, when it comes to managing Cisco Firepower NGFW Firewalls, is getting better because the UI is improving. It was a bit cumbersome in previous versions. Checkpoint, for example, has one of the most intuitive user interfaces, and now Cisco is really improving. The only drawback of the user interface is when it comes to policies. When you open it and click on the policies, you have to move manually left and right if you want to see the whole field within the cell. Checkpoint has a very detailed user interface. Cisco is getting better and becoming more and more user-friendly. Cisco needs a more intuitive user interface. When you know what to do, it's easy. Otherwise, you need training. You can install it and do the initial configuration, but if you don't have the proper training it's also possible to configure it the wrong way. If that happens, some things might pass through that you don't know about.

The maturity needs to be better. The product is not yet mature. A running product is hit with the software bugs most of the time, and whenever we then log a case with the tech team, they're sometimes helpless with that. They have to involve the software development team to fix that bug in the next release. It's not ideal. Being an enterprise product, it should be mature enough to handle these types of issues.

I'd like to see Cisco continue its approach to making it easier to navigate the UI and FMC and make it easier to get from point A to point B. Generally, the room for improvement is going to be all UI-related. The platform, overall, is solid. I'd also like them to continue to approach things from a policy-oriented perspective. They are moving more and more in that direction. Also, the change-deployment time can always be improved. Even at 50 seconds, it's longer than some of its competitors. I would challenge Cisco to continue to improve in that area. It's very reasonable at 50 seconds, it's not like it used to be in early versions of Firepower, where it was around seven minutes. Still, it could be quicker. The faster we can deploy changes, the faster we can roll back changes if we have messed something in the configuration. Low deploy times are really good to have. I would also like to see more features that will help us connect things to the cloud dynamically, and connect things to other sites dynamically. There should be more SD-WAN features in the boxes. If I can use one box to solve cloud connectivity problems, and not have to do stuff so statically, the way I have to do things today on them, that would be helpful.

It needs better patching and testing as well as less bugs. That would be nice. I would like it to have faster deployment times. A typical deployment could take two to three minutes. Sometimes, it depends on the situation. It is better than it was in the past, but it could always use improvement.

When you make any changes, irrespective of whether they are big or small, Firepower takes too much time. It is very time-consuming. Even for small changes, you have to wait for 60 seconds or maybe more, which is not good. Similarly, when you have many IPS rules and policies, it slows down, and there is an impact on its performance. In terms of tracking users, the Palo Alto Networks firewall is better than Cisco Firepower.

The Firepower FTD code is missing some old ASA firewalls codes. It's a small thing. But Firepower software isn't missing things that are essential, anymore.

We cannot have virtual domains, which we can create with FortiGate. This is something they should add in the future. Additionally, there is a connection limit and the FMC could improve.

This product has a lot of issues with it. We are using it in a limited capacity, where it protects our DR site only. It is not used in full production. The main problem we have is that things work okay until we upgrade the firmware, at which point, everything changes, and the net stops working. As a financial company, we have a lot of transactions and when the net suddenly stops working, it means that we lose transactions and it results in a huge loss. We cannot research or test changes in advance because we don't have a spare firewall. If we had a spare then we would install the new firmware and test to see if it works, or not. The bottom line is that we shouldn't have to lose the network. If we upgrade the firmware then it should work but if you do upgrade it, some of the networks stop working.

FlexConfig is there as a bridge for features that are not yet natively integrated into Firepower. It is a way of allowing you to be able to configure things that wouldn't otherwise be possible until the development team can add them into Firepower's native capability. There is still some work that needs to be done around FlexConfig. There are still quite a few complex things, like policy-based routing, that have to be done in FlexConfig, and it doesn't always work perfectly. Sometimes, there are some glitches. It is recommended that you configure FlexConfig policies with Cisco TAC. It would be good to see Cisco accelerate some of those configurations that you can only do in FlexConfig into the platform, so that they are there natively.

Try to understand if there is a need, e.g., if there is a need to log this information, get these logs out, and forward to some sort of a SIEM technology or perhaps a data store that you could keep it for later. There is limited data storage on the appliance itself. So, you need to ship it out elsewhere in order for you to store it. The only point of consideration is around that area, basically limited storage on the machine and appliance. Consider logging it elsewhere or pushing it out to a SIEM to get better controls and manipulation over the data to generate additional metrics and visibility. In some cases, I could see how SIEM is not an option for certain companies, perhaps they either cannot afford it, or they do not have the resources to dedicate a security analyst/engineer who could deploy, then manage the SIEM. In most cases, Firepower is a useful tool that a network engineer can help set up and manage, as opposed to a security engineer. To make the solution more effective and appealing, Cisco could continue to improve some of the reporting that is generated within the Firepower Management Console. Overall, that would give a suitable alternative to a full-fledged SIEM, at least on a network detection side, application identification side, and endpoint identification and attribution side. Potentially, a security analyst or network engineer could then simply access the Firepower Management Console, giving them the visibility and data needed to understand what is going on in their environment. If Cisco continues to improve anything, then I would suggest continuing to improve the dashboarding and relevant operational metrics present within the platform, as opposed to taking those logs and shipping them elsewhere.

The configuration in Firepower Management Center is very slow. Deployment takes two to three minutes. You spend a lot of time on modifications. Whereas, in FortiGate, you press a button, and it takes one second. Three years ago, the Firepower Management Center was very slow. The solution has improved a lot in the last couple of years. It is now faster. I hope that continues to improve.

On the VPN side, Firepower could be better. It needs more monitoring on VPNs. Right now, it's not that good. You can set up a VPN in Firepower, but you can't monitor it. Firepower Management Center is slow. It could be better. And the Firepower Device Manager doesn't have all the features that the ASA has, and that's despite the fact that it's almost the same product. Cisco could use many more features from ASA in Firepower Device Manager.

FirePOWER does a good job when it comes to providing us with visibility into threats, but I would like to see a more proactive stance to it. Maybe more of an IDS approach. I don't know a better way to say it, but more of a heavier proactive approach rather than a reactive one.

The initial setup can be a bit complex for those unfamiliar with the solution. There are better solutions in terms of border security. Palo Alto, for example, seems to be a bit more advanced. The cost of the solution is very high. Fortinet, as an example, has good pricing, whereas Cisco has very high costs in comparison.

Cisco makes horrible UIs, so the interface is something that should be improved. Usability is poor and it doesn't matter how good the feature set is. If the UI, whether the command-line interface or GUI, isn't good or isn't usable, then you're going to miss things. You may configure it wrong and you're going to have security issues. Security vendors have this weird approach where they like to make their UIs a test of manhood, and frankly, that's a waste of my time. The SNMP implementation is incredibly painful to use.

The initial setup could be simplified, as it can be complex for new users.

To configure the FirePower it is required an external console. It would be nice to have the console embedded in the Firewall so you don't require an extra device. I'd like to see some kind of SD-WAN included as a feature.

When using this product, our network is slower. The performance should be improved. The installation could be made easier.

The solution could offer better control that would allow the ability to restrictions certain features from a website. For example, If we want to allow YouTube but not allow uploads or we want to allow Facebook but not allow the chat or to playing of videos. This ability to customize restrictions would be great.

An area of improvement for this solution is the console visualization.

Cisco Firepower NGFW Firewall can be more secure. But no product is 100% secure, so it's a case of always wanting more security. The product is also really expensive. It would help if they provided free academic access to the enterprise edition for students for a whole month, two months, three months, or a year.

They need a VTI. I know it's going to be available in the next software version, which is the 6.7 version. However, the problem with that is that the 6.7 is going to deprecate all the older IKEv1 deployment tunnels. Therefore, the problem is that we have a lot of customers which are using older encryptions. If I do that, update it, it's not going to work for me.

The price and SD-WAN capabilities are the areas that need improvement. In the next release, I would like to see more of the FortiGate features added. FortiGate is compatible with Cisco ACI, but I can't see the firepower with the security fabric. For example, if I had Fortinet activated, could I integrate with it?

Report generation is an area that should be improved.

The security market is a fast-changing market. The solution needs to always check if the latest threats are covered under the solution. It would always be helpful if the pricing was improved upon a bit. In a future release, it would be ideal if they could offer an open interface to other security products so that we could easily connect to our own open industry standard.

This product is managed using the Firepower Management Center (FMC), but it would be better if it also supported the command-line interface (CLI). Cisco's FTD devices don't support the command-line interface and can only be configured using FMC.

Its interface is sometimes is a little bit slow, and it can be improved. When you need to put your appliance in failover mode, it is a little difficult to do it remotely because you need to turn off the appliance in Cisco mode. In terms of new features, it would be good to have AnyConnect VPN with Firepower. I am not sure if it is available at the moment.

There needs to be an improvement in the time it takes to deploy the configurations. It normally takes two to four minutes and they need to reduce this. The deployment for any configuration should be minimal. It's possibly improved on the very latest version. An additional feature I would like to have in Firepower would be for them to give us the data from the firewall - Cisco is probably working on that.

I believe that the current feature set of the device is very good and the only thing that Cisco should work on is improving the user experience with the device. Also, they need to ensure that all of the implemented features are working as they should, and able to integrate with more third-party software in an easier manner. As it stands currently, Cisco is doing this, but I am not confident enough to say that their QA team is doing as good a job as they should as there have been software releases that were immediately pulled back the same day as they were released.

The product line does not address the SMB market as it is supposed to do. Cisco already has an on-premises sandbox solution. They should include a cloud-based sandbox as part of the security subscription service. In my experience, apart from the expensive price, SMB customers are lured away by other vendor solutions because of these reasons.

One feature I would like to see, that Firepower doesn't have, is email security. Perhaps in the future, Cisco will integrate Cisco Umbrella with Firepower. I don't see why we should have to pay for two separate products when both could be integrated in one box.

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.

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.

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.

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 would like to see improvement in recovery. If there is an issue that forces us to do recovery, we have to restart or reboot. In addition, sometimes we have downtime during the maintenance windows. If Cisco could enhance this, so that upgrades would not necessarily require downtime, that would be helpful. We would also like to have a solution on the cloud, where we could manage the configuration. CDO is in the ASA mode. If Cisco could do it in full FTD — the configuration, the administration, and everything — it would be very good, and easy.

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.

Cisco firewalls provide us with some application visibility and control but that's one of those things that are involved in the continuous evolution of the next-generation firewalls. We have pretty good visibility into our applications. The issue that we run into is when it comes to some of the custom apps and unusual apps that we have. It doesn't give us quite the visibility that we're looking for, but we have other products then that fill that gap. There would also be a little bit room for improvement on Cisco's automated policy application and enforcement. The worst part of the entire solution, and this is kind of trivial at times, is that management of the solution is difficult. You manage FireSIGHT through an internet browser. I've had Cisco tell me to manage it through Firefox because that's how they develop it. The problem is, depending on the page you're on, they don't function in the same way. The pages can be very buggy, or you can't resize columns in this one, or you can't do certain things in that one. It causes a headache in managing it. That's part of the reason that we don't do some of the policies, because management of it can be a little bit funky at times. There are other products that are a little cleaner when it comes to that.

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.

The performance and the level of throughput need to be improved. This would make things easier for us. I would like to see the inclusion of more advanced antivirus features in the next release of this solution. Adding internet accounting features would also be a good improvement.

There are quite a few things that can be improved. Firepower is an acquisition from another company, Cisco's trying to put it together. Their previous ASA code with the source file code that they have acquired a few years ago still has some features that are not fully supported. Also, they have a Firepower source file that I can work on the ASA device and on Firepower devices. A problem here lies in the way that you manage these devices. Some devices do not support the FMC, and some devices have to be managed through ASDM, and others have to be managed through FMC. Most of the high-end devices do not support Onboard management. The Onboard management is only supported on the 2100 IP at the 1050 Firepower and on select ASA devices that bear the Firepower image. It would be very nice if the Onboard management integrated with all the devices. Log key loading for the evidence at the logs, because clearly you only have loading on the remote on the FMP, you cannot store the logs located on the device.

I was trying to learn how this product actually operates and one thing that I see from internal processing is that it does fire-walling and then sends it to the IPS model and any other model that needs to be performed. For example, content checking or filtering will be done in a field processing manner. That is something that causes delays in the network, from a security perspective. That is something that can be improved upon. Palo Alto already has implemented this as a pilot passed processing. They put the same stream of data across multiple modules at the same time and see if it is giving a positive result by using an XR function. Something similar can be done in Cisco Firepower. Instead of single processing or in a sequential manner, they can do something similar to pile processing. An internal function that is something that they can improve upon. They can also improve on cost because Cisco is normally expensive and that's the reason customers do not buy them. Also, if they could provide integration with Cisco Umbrella, that would actually improve the store next level. Integration is one thing that I would definitely want. From a technical perspective, maybe they could simplify the CLI. That is one thing that I would like to be implemented because Cisco ASA or Cisco, in general, is usually good at simple CLIs. That is one thing that I saw lacking in FTD. Maybe because they got it from another vendor. They're trying to integrate the product.

I would say when Cisco is selling something called a firewall, they put a lot of services together to make a single box solution. When a company develops a firewall, they need to develop certain features like intrusion control and offer it pre-loaded in the product. On the mix of projects that I am responsible for, I feel comfortable using the Cisco firewall for management. One feature lacking is superior anti-virus protection, which must be added. I have to say I am very proud of the Cisco Firepower 41400 as it can give you multiple layers of four-degree connectivity in operations. We do not use the Cisco 9000, but even the lower level firewalls are pretty expensive, considering the features and software included. In summary, we would like Cisco to provide more features inside regarding network trafficking forecasting. Ideally, the belief is that this would add an immediate resolution.