We used the Cisco partner for implementation, but overall it seemed pretty straightforward. The deployment has been an ongoing thing. I'd say that we're never done with deploying our firewalls because of that constant state of change of the network. But the original deployment took four to five weeks.

For the ongoing deployment, the amount of time somethings takes depends on what we're doing. We had some 5555 firewalls and all of a sudden they were no longer capable of handling the traffic that we send through. We had to operate those with 4110s. It all depends on what's going through them and what the scope of the project is. But most deployments take less than a week.

There is also the fact that when you upgrade FireSIGHT to the next version and there are new features, you have to go through all the firewalls and make sure that they're utilizing all those features. That's one of the reasons it's always ongoing. It depends on what's released, what's new, what's old, and keeping up on that.

Our deployment model is both public cloud and private cloud. The physical devices are on-premises at a data center or virtual in an on-premises data center, and the network virtual appliances are in distributed public cloud platforms including AWS, Azure, Google, and private cloud.

We have between 20 and 50 people who are responsible for the maintenance of the solution through a various mix of ticketing systems and troubleshooting. Their responsibilities are operating the platform, that is, making sure that the connectivity works, analyzing the security, the posture that those firewalls are protecting, and implementing change.

I've deployed them countless times, and I find it very easy. I did a high availability pair of internet edge firewalls for a 2,000 users organization migrating from Palo Alto, and I moved them over with AnyConnect, Umbrella, and Duo from Palo Alto in a week and a half with no downtime. I do a lot on-prem just because of my verticals. I work a lot in law enforcement. I work a lot in government, and those end up being very on-prem heavy. 

The standard setup is straightforward and takes around four hours. You can also do more customization and adjustments to deploy it in a particular environment.
I design a custom implementation strategy for each customer. It depends on whether I'm migrating an existing environment or doing a fresh deployment. I try to understand the customer's security footprint and all the issues I need to address before installation. 

We found that the initial setup using Firepower products was actually very simple. The initial configuration for the Management Console was very straightforward. Adding devices usually takes a few minutes. And then once you've got them physically set up in your Management Console, it's streamlined. It's actually very simple.

One of the great features of having the Cisco Firepower Management Console is having the ability to group. So we have each one of our hospitals as a group, so we can actually do any device configuration within a group. They're HA so that when we do an upgrade, it is seamless because when it fires off the upgrade, it will actually force the HA over automatically as part of the upgrade. And the other part of that is policy management. We have several policies, but specifically, one for the general use at our hospitals has been phenomenal because you build out one policy and you can push that out to all of your end nodes with one push.

We require two staff members to actually implement and devise the initial configuration.

At my company, you have to be at least a senior or an architect in order to manage any type of firewalling, whether that's the IPS, the actual firewall itself, or AnyConnect. So we have senior network engineers that are assigned for that task.

We typically have one person that will actually rotate through the group for the maintenance. There's a senior network engineer that will maintain that on a daily basis. Typically, it doesn't take maintenance every day. The biggest maintenance for us comes to updating policy, verifying the geolocation information is correct, and any upgrades in the future. So typically that takes about one to two people.

For deployment, we have different locations on the east coast, on-prem, and in the data centers. We introduced a couple of firewalls, AWS, and Azure and we're implementing those in the cloud.  

On-prem is pretty easy to implement. I could lab up an FTD on my own time. It's super easy to download and install. You get 90 days to mess around in a lab environment. I'm new to the cloud stuff. I've built firewalls there, but there were other limitations. I didn't quite understand that I have to get some practice and learn about the load balancers.  

Deploying ASA Firewall was complex because I needed to install an ESXi machine to implement the Firepower module. That was relatively complicated, and it took two or three days to complete the installation and verification.

I deploy and manage them afterward. I'm not only in the designing and implementing; I'm also in the operational business. Its deployment is not more complicated than other solutions. It's fine. When it comes to documentation, in general, Cisco is very good.

We have engineers that do the deployments. They're very skilled and have done many Firepower deployments. The methodology that Cisco has, the documentation they have out there on how to install it and how to configure it, are top-notch. That really helps us install it for a customer and get the customer up to speed on how well it works. A firewall is never a super simple thing to install and configure, but Cisco does a really good job with some of their automation tools and the documentation.

Usually, we assign a single engineer to a firewall deployment project and he's able to complete that. The amount of time it takes to deploy will vary. A small branch, may be several hours' worth of work to deploy a firewall. A large corporate site, obviously, that's going to be much more time-consuming, with lots of policies to configure and talk through with the customers and things like that. It varies depending on the size and application.

The initial setup was a bit complex. It wasn't a major challenge, but due to our requirements and network, it was not very straightforward but still easy enough.

We did a proper implementation plan according to the complexity of our network and our requirements. Then we used the best method for implementing it while mitigating our risks and meeting our requirements. We found a good way to implement it.

The setup took us two calendar months, but in terms of the actual time required to configure it, it was not so long. The setup took approximately as long as for other firewalls we have used.

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.

I am not involved in all Cisco firewall deployments. We also have an architectural team. We deploy based on a top-down level architecture and implementation structure.

The initial setup was pretty straightforward. It was very simple to deploy and replace. We did a lot of replacing, which was just copying the rules over from the old one, then deploying it in kind of the same manner.

I was involved in its design. Some parts of the initial setup were quite easy and some parts were quite complex. We were quite early adopters of some parts of the Cisco brand, so we had some challenges, but overall, it was quite straightforward.

It was not a straightforward implementation. The main challenge was that we were running two projects together, so we ended up doing the same activity twice. We had two requirements: refresh the data center devices and secure them because there was no security zone. We went for the ACI implementation, which was new for us and required a lot of discussions, and when we tried to introduce the firewall, we again had a lot of discussions with Cisco about whether to go with clustering or active standby.

We discovered that our ACI was not compatible with the firewall that we are introducing. So, we ended up upgrading our ACI. That was a big activity because we had to interrupt our data center. It should have been a seamless upgrade, but because some of our services didn't have dual links, we had to do some maintenance for that. After that, we also ended up upgrading our switches because they were not supporting 40 gigs, which is what the firewall interface supported. That was another challenge that we had. After that, going to active-standby or clustering was another challenge because the switch fabric didn't work well with our design. So, we ended up going with active-standby.

It was a journey, but in the end, we managed to overcome those challenges and implemented our solution.

The initial setup was complex. Firstly, we were migrating from a completely different platform and vendor to Cisco. Therefore, the ruleset migration was not only complex but also tedious because there was no suitable migration tool available for transitioning from Check Point to Cisco Firepower. The second part involved a complete change in our design, as we opted for a more zone-based approach where our checkpoints are more streamlined. This complexity was a result of our own decision-making.

These firewalls are deployed on-premises. We offer all the latest versions. We always advise customers to be updated with the latest technology. That's the aim of our business, but I have not been a part of the deployment.

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.

The firewall platform itself was not at all difficult to deploy in our environment. I would say that we do have a very complex set of requirements. So migrating the policy from our existing firewall estate to the new estate was quite difficult. The third parties helped us to achieve that. 

We migrated from Cisco ASA to Cisco Firepower, and it was straightforward because there were some migration tools to export the old ASA rule set and import it into Cisco Secure Firewall. With these tools and the documentation that you find on Cisco's site, it was pretty straightforward, and we had nearly no problems with the migration to Cisco Secure Firewall.

In terms of the deployment model, we have one high-availability cluster, and, of course, FMC to manage this cluster. These are physical clusters, and we have them on-prem in our data center.

I am not involved firsthand in its deployment. We have an oversight role within our company, so we ask our external supplier to do the implementation, and when needed, to have it validated via Cisco, but I've no real hands-on experience.

When I joined this organization, the solution had just been deployed. I was tasked with administrating and managing it. Managing it has been quite a learning curve. Prior to that, I had not interacted with ASAs at all. It was a deep-dive for me. But it has been easy to understand and learn. It has a help feature, a floating window where you can type in whatever you're looking for and it takes you right there.

We had a subsidiary that reverted back to our organization. That occurred just after I started using the 5516 and I needed to configure the integration with the subsidiary. That was what I would consider to be experience in terms of deployment because we had to integrate with Meraki, which is what the subsidiary was using.

The process wasn't bad. It was relatively easy to integrate, deploy, and extend the configurations to the other side, add "new" VLANs, et cetera. It wasn't really difficult. The ASDM is a great feature. It was easy to navigate, manage, and deploy. As long as you take your backups, it's good.

It was quite a big project. We had multiple solutions, including Citrix ADC and ESA email security among others. The entire project from delivery of equipment to commissioning of the equipment took from July to November. That includes the physical setup and racking.

Two personnel are handling the day-to-day maintenance.

I was involved with the upgrades. Our main firewall was a Cisco module, so we integrated from that because of ASA limitations. This gave us a better benefit.

The deployment was a little complex at first because we were so used to the one-to-one. Being able to consolidate into a single piece of hardware was a little difficult at first, but once we got past the first part, we were good.

The initial setup is straightforward. Since we were transitioning from ASA to Firepower, a significant portion of our work involved transferring the access control lists to the power values in the GUI. After that, we began adding additional features, such as IPS.

I've been part of the deployment. Specifically, how NATTING and the firewalls work, that part is not difficult at all, but there are some challenges when you take any product and manipulate the order of operations, but that's not a Cisco challenge. You're pairing different information. There are some tools that usually try to help with those conversions, but most of the time, I find it just easier to develop what you need and just build it from scratch.

The initial setup was relatively simple for us. During migration, we used the Cisco Firewall migration tool. From our point of view, the migration tool was okay.

Secure Firewall is more complex to deploy than previous Cisco Firewall products. However, it's not so complex that it's not achievable. There are some products out there that require a lot of reading to be able to deploy them. Cisco Secure Firewall has not reached that level yet, but it is a complex product.

Our clients' Secure Firewall deployment models are edge firewalls, internal firewalls, and, most often, perimeter firewalls. Sometimes, our clients ask us to help them with deployment because we have the experience.

We've used the Cisco Firewall migration tool quite a few times to migrate to Cisco Secure Firewall. It has come on a long way, and it's a lot better than it used to be. When it initially came in, there wasn't as much trust that the tool would give you everything you needed, but where it is now is great. If you've got a firewall that you want to migrate, you'll feel confident using the Cisco Firewall migration tool.

I wasn't involved in its deployment. That was before I started working in this space.

The initial deployment is easy, and I have not had any issues.

The solution is deployed on-premises. We have an on-premises FMC that connects everything.

It wasn't simple. Its implementation doesn't take much time, but we had to get a consultant in. Implementing a Cisco solution from scratch is harder than implementing FortiGate. With FortiGate, I can do my implementation and put all the criteria easily, but with Cisco, I need to do a lot more research, and I need to get someone to help me, but after implementation, it just works.

The initial setup and implementation of Cisco Firepower is very easy. I am working with a lot more vendors of firewalls, and Cisco Firepower is one of the best today. It is one of the easiest to set up.

The minimum deployment time depends on really what you want to do. If you just want to initiate a quick setup with some IPS and have already deployed FMC, then it takes less than one hour. It is very easy. 

What takes more time is deploying the OVA of Cisco Firepower Management Center and doing all the cabling stuff. All the rest, it is very easy. 

If you are working without a Firepower Management Center and using Firepower Device Manager with Cisco on the cloud, then it is even easier. It is like the Meraki setup, where you just plug and play everything and everything will be connected to the cloud. It is very easy.

If you configure Cisco Firepower, it has to be based on Cisco's recommendations. You can view all the traffic and have full visibility in terms of applications, support, URL categorization, and inspect malware or whatever file is being exchanged. We also love to interconnect Cisco Firepower with some Cisco ISE appliances so we can do some kind of threat containment. If something is seen as a virus coming in from a user, we can directly tell Cisco ISE to block that user right away.

The initial setup is not easy or straightforward. It's a bit complex and a little difficult.

We have three engineers on staff. They are capable of handling any maintenance.  

Cisco Secure Firewall's initial setup was pretty straightforward. They have a wizard, which helped in some instances, but there's also a lot of documentation online that helps a lot.

I was not involved in the initial deployment of the solution. 

Our customers use Cisco firewalls mainly in data centers, branch offices, and campus environments. They don't only use basic firewalls. They also use next-generation firewalls, which have email control, web filtering, and IPS. So, we have Cisco firewalling at all levels for providing the strongest protection policy.

The deployment of Cisco firewalls is very easy so far. We have the security expertise and all the knowledge that we need to deploy them and secure our customers' facilities. Networking and architecture are not really complicated, but you need a well-defined plan before doing implementation and going live.

Installation wasn't that difficult, but there were some challenges on the integration. Sometimes, we face issues from the integration between another Cisco product's API and Firepower NGFW. We just integrated with our existing networks.

The firewall takes no more than two weeks to install. The integration with the API takes about six months.

The initial setup is straightforward for me at this point. That is just because of the experience that I have in dealing with it. for a new person, it would be a little bit more complex. They have gotten better with some of the wizards. However, if you are not familiar with it, then that makes it a little more challenging.

I find the initial setup fairly straightforward. I wouldn't say it is simple, but it is not a simple piece of technology. You have different policies for different areas of the system, e.g., you have a policy for access control, NAT, FlexConfig, remote access, VPN, etc. There are a lot of policies that you either have to create or configure. However, it is fairly intuitive. Once you have done it once, you know where everything is.

If we assume the most basic variables, one FMC and one FTD on the same LAN, then the FMC can be provisioned with the policies in a day. The appliance can be imaged and added to the FMC with the policies pushed out on another day. If you add remote access VPN into the mix, especially if you have an Active Directory integration, I would probably add another day. You could probably have a working setup in three to four days, depending on if you have any issues with the licensing portal. 

It is very easy to deploy site-to-site VPN tunnels between Firepowers. I appreciate that Cisco deprecated all legacy cypher standards. This means you need to use the modern, robust cipher standards that cannot be broken right now. This is a good thing. However, if you are using two Firepower devices, then it is easy to set up a site-to-site VPN tunnel and use the strongest cipher standard, which is also good.

Cisco gives you lots of options, which means that it can be complicated to set up. You have to know what you're doing and it's good to have somebody double-check your work. But, on the other hand, it does everything from deep packet inspection and URL filtering to whatever you want it to do, with world-class integration. It integrates with Umbrella, AnyConnect, ISE, StealthWatch, and other products.

It is important to remember that a firewall is only as good as it's configured. Sometimes, people will forget to configure a policy, or they will create the rules but forget to apply them. It comes back to the fact that it's a professional product and it's only as good as the person who's using it.

I do some security consulting and I've seen many misconfigurations. People will write a Rule Set but forget to apply it to a policy, for example. There is no foolproof product and I think it is a challenge to say, "Wow, this firewall is better than that firewall." These things are complex, but Cisco has always, in my mind, set many kinds of standards. I don't know any serious security person that would argue that.

Especially AnyConnect with an Umbrella module attached, I think most people would argue it's state-of-the-art. I know that I would because it allows me to do a couple of things at once. It's not just the firewall; it's AnyConnect, and it's what you can do with AnyConnect given its functionality with Umbrella. It gets kind of complicated and it depends on the use case, and some people don't need that.

Again, what makes it difficult to say something about a firewall is, the configuration possibilities are so varied and endless. How people license them is different. Some people think, "I prefer the IPS License," or whatever. But again, I think to get the strength of a Cisco firewall is just that.

I found our setup straightforward, but you don't go into it blind. You have to be clear on your requirements and you need to take the setup step-by-step. Whenever I deploy a firewall, I have a couple of people to double-check my work. These are people who only work on Cisco firewalls and they act as my proofreaders whenever I am doing a new deployment.

Cisco's documentation is very good and it's always very thorough. However, it's not for a novice, so you wouldn't want a novice setting up the firewall for an enterprise. Personally, I've never had any issues with policies not deploying properly or any other such problems.

Talking about how long it takes to deploy, it's a good weekend if it's a new deployment. It's not just clicking and you're done. I haven't installed a Fortinet product, but I can't imagine any of them are easy to install. Essentially, I found it straightforward, but it is involved. You've got to take your time with it.

You need to make sure anything you do with your networking, that you have it planned out well in advance. But once you do that, you go through the steps, which are well-documented by Cisco.

The setup with the Cisco Firepower NGFW is very easy. I have used other networking and firewall equipment previously, including Juniper. I've implemented other solutions and those were really tricky compared to Cisco.

The Cisco firewall system has eliminated all our network setup problems. Earlier when we used other products for firewalls, it was very complex to set up. Cisco firewalls from the beginning have eliminated all of the difficult parts of the initial deployment. 

All you have to do is pull your management together and communicate to your team to follow the documentation provided by Cisco. Altogether, it is easy for our team to install the Cisco firewall products.

The deployment was complex because that was my first time doing a Firepower. I did ASAs prior, no problem. I had to get used to the GUI and the different order of deploying things. I had to reset it to factory defaults several times because I messed something up. And then I had to get with Cisco TAC, for them to help me, and they said, "Okay, you need to default it and start over again".

But now, going forward, I know I need to deploy the FMC first, and then you deploy the Firepowers, and tell them where the FMC is, and then they connect, and then you can go in and configure it. I had it backward and it was a big thing. I had to keep resetting it. It was a good learning experience, though, and thankfully, I had a patient customer.

[In terms of maintenance] I've not heard anything back from my customer, so I'm assuming once it's in, it's in. It's not going to break. It's an HA pair. My customer doesn't really know too much about it. I don't know that they would know if one of them went down, because it fails over to the other one. I demonstrated to them, "Look, this is how it fails over. If I turn one off, it fails over." VPN doesn't disconnect, everything's good. Users don't know that the firewall failed over unless they're actually sitting there looking at AnyConnect. I don't think they know. So, I'll wait for them to call me and see if they know if something's broken or not.

I have never found it hard to deploy. We didn't have a BCP solution set up as our secondary when COVID hit, which was something that we had to scramble to put together. However, it was something like a couple of days' work. It wasn't really a big deal or really complicated. It was a fairly straightforward system to separate and manage.

We have two data centers at two geographical locations. We have two firewalls - one in one data center, at the perimeter, and another at a different location.

The initial setup was okay. We had more of an in-between partner doing the installation part since the product was also new to us. The product was part of my overall product solution. We procured a firewall and another ACL fabric portion for the data center. Overall, the solution installation took over seven to eight months.

We had two people assist with the deployment process. 

The solution’s initial setup is complex and requires Cisco-certified people.

The product's initial setup phase was taken care of by another team in my company before I joined my current company.

On our company's core payroll, we have a very small support team, but we do have a support team in my company for the product. The support team in my company consists of around 20 to 25 engineers who work around the clock.

The solution is deployed on an on-premises model.

It's not a very big hassle to set up. It's a bit complex when you go into different topics that aren't the basic capabilities, such as when you go above VPN and basic ACL configuration, but all in all, it does the job.

The initial setup was somewhat easy because we had previous experience with implementation. We copied that strategy or tried to align it to that implementation, but there were some challenges.

We have a hybrid cloud deployment. We have our own data centers and a lot of branches. In the data centers, most Cisco technologies start with ACI. With firewalls for big branches, we find that it's easier to break out to the internet globally rather than to use data centers.

The implementation isn't complex. It's straightforward. However, it also depends on the specifications of the customer. Normally we check that out first and then we can make a judgment of how to best implement the solution.

Typically, the deployment takes about two days to complete.

In terms of maintenance, we have about five people, who are engineers, who can handle the job.

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.

The implementation timeline for our firewall is contingent on the readiness of the policy. If the policy is prepared, the deployment can occur within a day. However, if the policy is not finalized, a brief meeting is convened to gather the necessary data for rule establishment. Once the information is ready, the implementation on VMware proceeds. Notably, there is a requisite waiting period, such as fine-tuning for optimal rule configuration, as each customer has unique requirements. It's crucial to tailor the rules to fit the specific needs of each customer, as there is no one-size-fits-all best practice in this context.

It was fairly straightforward. We stood it up side by side with our nesting firewalls. We did some testing during an outage window, then migrated it over.

The initial configuration was done within a few hours, but getting all the policies in place took about a month. That was not related to the firewall, it was related to all the requirements from management and from other people as well. But the configuration to get it set up initially was straightforward, nothing special.

Initial setup is complex for a new user, straightforward for a seasoned user. Tons of documentation is available, but you can easily get lost for days if you've never touched one. Cisco offers ASDM, a GUI wizard that can help set up the firewalls. This is nice for newer folks.

The initial setup of the Cisco Secure Firewall is very straightforward. The average time it took to deploy the solution was very short. Deploying the VM and automating our configurations took a couple of minutes.

The deployment is pretty straightforward. It's the same as deploying any other Cisco equipment. If you know what you're doing, it's not a huge deal.

The deployment model is totally customer dependent. The way we work, we look at the customer environment and develop a proper deployment model for them. Some of them are using enterprise agreements. It's becoming more and more common, so they can use several solutions at once or with some kind of added use price and other benefits.

I'm not always involved in the deployment. I work as an architect. I do not implement all the solutions I design, but I implement some of them. For me, it's important because, for one, I like it, and second thing is that I need to have some kind of hands-on experience to understand the solution so that I can make better designs.

If you do the initial setup for the first time, it's somewhat complex., but over time, you get the experience, and then it's more or less straightforward. 

Our clients rarely used the firewall migration tool. It gives you a starting point for the configuration, but usually, there are so many things you need to rework afterward. We use it sometimes, but it only does a part of the job.

It does require maintenance. The clients have maintenance contracts for that.

The initial setup is straightforward because it is supported by good documentation. We did not experience many issues and deployment took a couple of months.

We first deployed the solution in monitoring mode before moving into protection mode. We required four or five engineers for this. It takes a lot of time to do any maintenance or upgrades. This is one of my key pain points for this product.

Maintenance requires two people; one to focus on the upgrade and one to monitor the traffic.

When I did the installation three or four years ago it was challenging. 

In my current place, I did not help set it up, but I did set it up previously as a dedicated intrusion detection and prevention tool with another security engineer. Honestly, the setup was pretty straightforward. This was a couple of versions behind. It definitely has well-understood requirements from a virtual machine and resources required perspective. No questions that came up.

For the dedicated intrusion appliance, we needed to identify where the most benefit would come from, so we identified the network space. The sort of choke point where we could apply the Firepower appliance in order to inspect the most traffic. In terms of efficiencies, the primary goal was to identify how to maximize the visibility using Firepower. We deployed it in a choke point and ensured that most of the traffic for the company goes through this intrusion appliance and the initial deployment occurred in a visibility mode only - No blocking, intrusion detection only. Then, with time, as we got comfortable with all the traffic that was being seen with a signature application across the traffic and understood the chances for false positives were low to none. At that point, we put it into prevention.

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. 

The product's initial setup phase is a little difficult.

The product's deployment phase is a good and easy process.

The solution is deployed on the cloud.

The initial one, for me, was a little bit complex because I hadn't done it before. It was inline and an active/standby pair, so it involved a little bit more than just deploying one firewall. 

We had some documentation written and we tested it in the lab and then the deployment took about four hours.

We deployed it alongside different solutions and then we cut over to it when it wouldn't impact the customers.

The maintenance involves doing code upgrades periodically to keep up with the security environment requirements. One person handles that.

The initial setup is straightforward.

We are in the middle of a migration plan to Cisco right now in our company. I am not directly involved. We are working with a Cisco partner but I have been communicating our needs to them. However, I believe the migration process will be smooth for our company. It is crucial to have a solid migration plan in place because we are a core data center, so we have to be careful. 

The initial deployment was straightforward. We have worldwide data centers. For one data center, it took three days from design to implementation. 

In terms of deployment, a lot of organizations are moving to the cloud. People are looking at the ASAv image for deploying into the public cloud on Azure or AWS. But there are still a lot of organizations that use ASAs as their internet edge.

The on-prem and the cloud-based deployments are very similar. When you're designing a solution, you need to look at the customer's business requirements and what business outcomes they actually want from a solution. From there, you develop architecture. Then it's a matter of selecting the right kinds of kits to go into the architecture to deliver those business outcomes. We talk to customers to understand what they want and what they're trying to achieve, and we'll then develop a solution to hopefully exceed their requirements. 

Once we've gotten that far, we're down to creating a low-level design and fitting the components that we're going to deploy into that design, including the ASA firewalls and the switches, et cetera. We then deploy it for the customer.

The initial setup is can be complicated if you are not familiar with the command line. There is documentation available by Cisco and once you are trained it is not difficult at all.

The initial setup of this solution is straightforward.

The deployment does not take much time. It is just a matter of installing the firewall and configuring the basic system to get it up and running. That's it.

There are, of course, different models of deployment, like deploying customers, that have to be considered. However, for the most part, deployment time is not an issue at all.

We announced the tender and bought this product with the installation plus setup included in the price. I was not involved in the installation or in the setup. 

The company just asked a consultant to do it. The whole process, after we announced the tender, took about one to two weeks. The consultant company installed the software. They also helped us to optimize other parts of the network such as the routers and switches.

The setup of the Cisco ASA NGFW was complex, not only for us as a firewall. We have now submitted another tender for a device router with two-node switchless support. We updated almost everything on the Cisco ASA NGFW with the core and distribution level software upgrades.

It's easy to deploy and maintain.

We have an implementation partner.

It's a hands-on job with a colleague of mine.

I don't know if it is particularly easy or not.

There was also some learning involved, such as knowing the traffic. This took some time. It took six months to deploy.

With the implementation partner, everything was written out. It was the best-case scenario for us.

We did not use the Cisco Firewall Migration tool.

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 initial setup is straightforward. 

The initial setup had a little bit of a learning curve, especially because I came from ASA. I needed some help from Cisco. However, I knew what I was doing once it was set up, especially with FMC and Firepower.

The complexity of the installation depends. It's not so easy to install. Each topic needs one management interface. So you end up with 20 to 40 different management platforms. All of them use a tremendous amount of resources. If you're willing to install it, you need a huge pile of hardware. It is not clear what everything does. Some consolidation there would be helpful. Other vendors face the same problem.

It's now easier than before. You can have virtual appliances.

We mostly have it on-prem, but some customers want on-prem virtual.

This solution requires regular maintenance and I have 10 engineers that manage it.

The one we deployed in the data center was pretty straightforward. I also deployed the Cisco ASA for AnyConnect purposes and VPN. I didn't have to call TAC or any professional services. I did it myself.

My view may be a little bit biased because I do a lot of Cisco deployments, and I have a lab where I play all the time. But overall the deployment is not too complicated.

The deployment time depends on what type of deployment you have. If it's a physical deployment, it may be a little bit faster because you don't have to set up virtual machines. But I recently had a project in AWS, and I used Terraform Templates and it was easy. I still had to configure some additional things like interfaces, IP addresses, and routing. 

Because I know where everything is in the UI, the deployment is okay. One thing I miss a little bit is being able to configure things, like routing, via the command line, which is how it used to be done with the ASA Firewalls. But I understand why they've taken that ability away.

With ASA Firewalls, even when you were upgrading them, the experience was much better because it didn't have those advanced Snort features and you could usually do an upgrade in the middle of day and no one would notice. You didn't have any drops. With Firepower, that's not always the case.

I didn't do the implementation. We have, however, upgraded to a higher version. From the Cisco side, we get the updates or patches using which we upgrade a device and do the configuration. We register the product model and serial number, and after that, we can download a patch. We also can get help from Cisco. It is easy to migrate or upgrade for us.

The initial setup was not complex.

Its setup is easy. We are familiar with Cisco ASA and other Cisco products, and they are easy to configure. A lot of resources are available on the internet, so it is easy to set up for anyone with basic training. It is easy in different types of environments, such as universities and colleges.

It generally doesn't take more than a day, but it also depends on the size of the organization. If an organization is very big and if you need a line-by-line configuration for access role and VPN, it can take a bit more time.

Cisco is constantly upgrading and providing features based on current requests. We usually plan deployments at the end of the year and at the beginning of the year. Everyone plans for new products, new configurations, and new expansions based on that.

I've been handling the implementation. So far, it's been good, even with no prior knowledge of the solution itself. It's my first time working with it.

On my team, lots of people are working on different aspects, and most of the setup is being done by those that have more knowledge about the firewall than we have. We don't have anything to do with the setup, we just make sure that we implement whatever connections the clients already have. It's already broken down that way, just to avoid as many mistakes as possible.

We already have a process for implementation based on the number of connections. The maximum we normally work on each connection is maybe 20 to 30 minutes. However, the process could be as little as one minute. It depends on how many connections we want to add at a time.

The initial setup was straightforward. 

It's easy to install and it doesn't take a lot of time for the initial configuration.

It took an hour to install.

The third-party did all of the setup. I told him what I wanted and he set everything up and got the tunnels for us as well.

The deployment of the firewall is more difficult if you want to use all of the features. However, if you're using it only as a VPN, then it's a little bit easier to deploy.

The initial setup is straightforward for smaller organizations, but it can be complex when companies are larger.

Migrating certain components of a client's previous firewall configurations to Cisco Secure Firewall with the migration tool is simple, easy, and quick. However, it would be really nice if we could migrate complete ASA configurations to FTD with the migration tool and not just the policies and objects.

Maintenance-wise, we troubleshoot and make changes if required.

Setting up the machines was straightforward, but exporting was complex. That is, it wasn't a complex deployment as far as the hardware goes. It was more of a complex deployment as far as transferring all the rules go because of our routing architecture.

Firepower is our main interface out to the outside world. We have about eight DMZs that are interface-based. You can do a logical DMZ or you can have an interface and a logical DMZ. We have about eight that are on interfaces. Then, we have our cloud providers and the firewall. We have rules so that our cloud providers can't ingress into our network.

I've found that Firepower does need a lot of maintenance. It needs a lot more software updates than other solutions. We have three people to maintain the solution.

As an architecture team, we had a pretty good idea of what we wanted to do and how we wanted to do it, so it was pretty straightforward and easy. We have each one across many different avenues and many different boundaries, so each one took about a day to deploy.

We needed two to three people to deploy them and another one to go over some things to make sure everything was good to go.

There is routine maintenance, keeping it up to date and making sure the licensing versions are all good to go. We have a four-man team for maintenance and they work a regular shift of eight hours.

All our deployments have been different. Some have been really easy and others have been really complex. It could go either way: some are complex and some are easy. The complex solutions could take days or a couple of weeks to deploy. Easy solutions take a day.

If it was a big project, there would be a pre-project identifying what we were going to do and making a plan for it, then we would realize that plan. If it was a smaller thing, we would just jump into it.

Once you deploy a few of these devices, the initial setup is really straightforward and easy to do unless the position of the firewall on the network needs you to do some connectivity magic in order for it to work.

The solution’s initial setup is straightforward.

We encountered some issues with the deployment because we run on Azure now. 

I was involved in its deployment, but that was a few years ago. It was not an in-depth technical installation; it was more of a physical installation. It was easy. We are a big company, so we need to plan the downtime and get approval from the business to take down systems and upgrade them. 

I was involved in the initial deployment. It was quite simple, not complex at all. 

The initial setup is not that simple. I don't do the installation myself, but from what I hear it's more complicated than some of the other firewall products.

We usually do our installation in two or three hours. Our customers usually have between 10 and 50 users and they are generally IT admins.

We have three people who work in the field and manage deployments, and another five to 10 to manage the solution.

The initial setup was straightforward. 

It is straightforward. For me, it is very simple. The menu is quite impressive. Everything that you want to do can be done from the web user interface. You don't need to access the CLI if you don't like it. It is very easy to make rules with its web user interface.

Its deployment took two days. In terms of the implementation strategy, the first cluster was in the data center, and its main job was to filter user traffic going to the data center. The second cluster was on the edge. Its main job was to mitigate attacks on the inside network and to capture the traffic that could have viruses, malicious activities, etc.

Due to the fact that we're experienced with it and we've scripted the command line, it's extremely simple for us. That said, I think it's complex for somebody that doesn't know the IOS platform.

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

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

The initial setup was very complex. Migration from Juniper (with wide usage of VR) to Cisco is complex and you should make sure to master all the flows on the node. Also, Juniper is more permissive on asymmetric traffic, which Cisco will deny by default. 

I have had difficulties with the implementation of this solution. When I first encountered this solution, I had difficulties bringing it up and configuring it, but this was maybe due to the fact that back then it was a new technology. It is possible that I would have an easier time with it right now. 

The initial setup is great. It's very easy and quite straightforward. If you understand the process, it is very easy. I'd rate it a 4.5 out of five in terms of ease of implementation. 

I'm a designer, so I don't do racking and stacking, but I'm hands-on when it comes to configuration. I have used this product for years, so for me, it's not like adding a brand new product. It is just a matter of adding features, a hardware refresh. I wouldn't call it a challenge.

For maintenance, we have two to three network engineers involved.

The initial setup is straightforward, with the caveat that I've been doing this for a long time, so for me it is simple and makes sense. But it is pretty straightforward. You have overall policies that wrap up into your access policy, which is the base policy. You have DNS policies that will roll right up into it. Likewise, platform policies get attached to devices. Generally speaking, it's a lot of working through the logic of the rules: How do you want to block stuff, and how do you want to permit stuff? A lot of that is normal firewalling. When I say the setup is simple, it's because it involves normal firewalling issues. You have to deal with routing, NAT rules, ACLs, and VPNs. It's a matter of just kind of working through those same things that every firewall has to solve.

The deployment time depends on the customer and how many rules. If we're building out all their rule sets, it could range from 40 hours to hundreds of hours. It also depends on what we're coming from. We're not generally walking into environments that are green, meaning there's no box there today. It's almost always that there's something else there that we're replacing. We have to take what we're coming from, convert it, and then put it on Firepower. Small businesses might have a couple of rules, enterprises might have hundreds of rules.

Our implementation strategy is to go in, document the current state of the environment, and then work on a future state. We then work through all the in-between stuff. When we have the old firewall configuration, we determine what it will look like on the new firewall configuration. Does the firewall configuration need to be cleaned up? Are there things that we can optimize and improve or modify? A lot of it involves copying configuration from the old platform to the new one. We're usually not trying to change a ton in a firewall project because it increases the risk of problems arising. Usually, customers' networks are operating when we get into them. We prefer to do a cleanup project after implementation, but sometimes they coincide.

In our company, one person can usually do a firewall cutover. And maintenance of Firepower 7.0 usually requires one person. Maintenance will usually involve a firmware upgrade.

It is not straightforward. You should know what to do, and it needs to be done from the command line. So, you should know what to do and how to do it.

From what I remember, its deployment took a week or 10 days. When I was doing the deployment, that company was migrating from an old data center to a new one. We were doing configurations for the new data center. The main goal was that users shouldn't know, and they shouldn't lose connectivity to their old data center and the new one. So, it was a very complex case. That's why it took more time.

There was no issue with the initial setup. It's straightforward because Cisco gives us lots of documentation. It's not a big deal, for me. In four or five years I have deployed 35 to 40 Firepowers for financial organizations and corporate offices.

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

Deployment takes about 20 to 25 minutes. 

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

The initial setup of this solution was a bit complex because it was a new technology for us. We did find documentation on the vendor's website, and it also helped that we found some videos on how to do the configuration.

Our initial deployment took approximately three months because we were learning from scratch. We still had some service requests open because we could not fine-tune the solution, and ultimately it took a full year to fully deploy.

This solution is managed by the qualified people in our network engineering team. 

The initial setup of this solution was straightforward. We had the proper documentation to reference.

I will say Cisco ASA has a complex setup just based on the security policy we have to enforce (asked by the chief, the CIO). For me, it's not complex. 

Cisco ASA is not difficult because I am in it for a year so it's easy for me to understand. I have no problem on the technical side. I always manage to do what I'm asked to do on security-side enforcement. I have no problem with that. It's normal for me. 

It was 2 years ago that we were trying to deploy our facility equipment. We took advantage to deploy the Cisco ASA firewall (model 5515X). 

For now, it's the only one. Since then, we're using it in an upcoming project. I will have to deploy some Fortigate and Cisco ISL as well.

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

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

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

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

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

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

I was involved in the design, deployment, and operations. Our team is very special in the fact that we don't delegate to other folks. We're responsible for what we eat and what we design. We actually do the hands-on work and then we maintain it. We tend not to hire out because they come, they wash their hands clean of it, leave, and then there's all this stuff that needs fixing. If we get paged at 3:00 AM it might be our fault, and the lessons are learned.

Our network engineering team consists of about 12 people.

The setup is of medium difficulty. It is not very complex. Generally, when working in the security field, things are a little bit complex because you are integrating with many vendors and you are defending against a lot of different kinds of attacks.

The amount of time it takes to deploy the ASA depends on the complexity of the site where it is being set up. On average, it can take about a week. It could be that there are many policies that need to be migrated, and it depends on the integration. For the initial setup, it takes one day but the amount of time it takes beyond that depends on the security environment.

Once I got used to this product, it was easy to use other products, but it was not easy for me the first time.

The Cisco firewall is straightforward. It isn't a complex implementation. Obviously, you have to bind your IP on the port and then you must go on to configure for security and something like that. It's easy for me to configure a firewall at such a level.

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

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

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

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

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

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

The most recent deployment we did took about three weeks.

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

The SA520W was a simple setup. There is no CLI option; it is all done within a straightforward GUI.

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

The initial setup was not easy and we were struggling with it.

In 2017, we bought the Firepower 2100 Series firewalls, but for a year, there was nothing that we could do with them. In 2018, we were able to deploy something and we had a lot of difficulties with it.

Finally, we converted to Cisco ASA. When we loaded ASA, there was a great difference and we put it into production. At the time, we left Firepower in the testing phase. In December 2018, we were able to deploy Firepower Threat Defense in production, and it was used only in our DR site.

My system engineer did the initial setup and he's the person who manages it, day in and day out.

We did a lot of site-to-site VPNs. We also did a third-party, which is Palo Alto or something. Though, some of them were SonicWall. It is like, "Okay, I don't know how the site is configured, then I spend hours trying to troubleshoot a VPN." The more you use it, the easier it gets. It used to take days to do it. Whereas, the last one that I built took about 30 minutes. The more we use it, the better the outcome is and the faster we can do it. Now, I am not spending days building a VPN, which should only take 10 to 15 minutes.

The setup is not too complex. We implemented it on all our ports.

It was easy to configure. The site-to-site VPN configuration didn't take too much time. It was complete in three to four hours.

The initial configurations were straightforward, not complex at all. It took us just two days to finalize things.

Its initial setup was very straightforward. Its documentation is very easily available on the web, which is very useful.

The initial setup is easy. The deployment took two months because we didn't have Firepower previously, and it took us some time to plan and implement.

The initial setup was complex because we had to migrate old ASA firewalls. The ACLs, or rather the policies, are very different now, and way more elaborate, so that that took some tweaking, and some consulting and some time. 

Deployment took two months. We had to make sure that our old ACL base settings from the ASAs were correctly translated and implemented into the new FTD setups.

I wouldn't call it extremely straightforward, but I wouldn't call it complex either. Its deployment took about a day.

In terms of the deployment strategy, we create our deployment plans for ourselves and our customers. The deployment plan depends on the environment.

The initial deployment of Firepower is a straightforward process. For me, it's pretty easy. If you have never worked with it, I can imagine it might be complex. 

Cisco makes it easier all the time. You can now deploy a remote branch by managing the device on an external interface. In the beginning, with previous software versions, that was hard. You needed to configure the file as a remote branch, but for that you needed the central Firepower Management Center to configure it and you didn't have a connection yet. It was a big issue to set up an initial firewall remotely when there was no connection to the Management Center. But that's been fixed.

In general, you just put down some management IP addresses and configure things so that the devices see each other and it starts to work. It's far from complex.

Generally, the initial setup takes four hours. The implementation strategy depends on the customer. I always have a conversation with the customer upfront. I explain how the connectivity works for Cisco Firepower, and then I say that I want to be in a specific subnet field. Then I start configuring the basics, and that is the part that takes about four hours, for Firepower Management Center and two firewalls in HA. Then, I start to configure the firewalls themselves, the policies, et cetera.

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.  

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

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

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

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

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.

I was not involved with the initial setup.

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

The deployment was simple.

The initial setup is not too complex, but as with Fortinet, they have some detailed steps required which adds to the flexibility also. With flexibility comes a bit of complexity, but it's not too bad. Deployment time takes a few minutes. I am responsible for implementation and maintenance for our clients. We were previously deploying only for medium or large enterprise companies but Cisco has come up with the 1000 and 1100 series firewalls for smaller companies which is pretty good. They're a cost-effective solution and competitive in the market. 

The complexity of the initial setup depends on the environment. Sometimes, it's brand new whereas other times, I install a replacement for an existing Cisco device or some other product.

At the beginning, it was complex, but we were able to develop a step-by-step implementation. Now, we can deploy one in about two hours, including integration testing, physical testing, configuration, and applying the rules.

The initial setup was not complex, it's just difficult to find out how to do it. The FAQ is not clear. In terms of deployment, it depends on the client, but deployment takes about an average of six hours.

The initial setup was straightforward, though I find as we proceed we need an extra feature or two to enable all the functionalities and protection of the tool. It's an ongoing process. We have to be quick and agile to provide client support.

The integration and configuration were pretty straightforward.

The initial setup is straightforward because most network engineers have worked with Cisco. Cisco invested in universities, and as a result, 40% of the network experience of students is with Cisco.

Our clients are mostly financial institutions and have strict policies that do not allow personal data on external clouds outside the country. As a result, they mostly use an on-premises or hybrid cloud deployment model.

We are currently having our customers switch from the 2000 to the 3000 series.

It was straightforward. Cisco is still leading in the network area. So, there are lots of resources where you can find information. There are community forums and Cisco forums, where you can find answers to any questions. You don't even have to ask. You can just Google, and you will find the solution. Apart from that, Cisco provides a lot of certification that helps our main engineers in learning how to use it. So, the availability of their resources was great, and we just followed their best-case scenarios. We could easily configure it.

The deployment took around two or three weeks because we had different firewalls. We had a couple of them, and we migrated all to Cisco. We also had around 30,000 rules. So, the data input part took a lot of time, but the initial installation and the initial configuration were done in a matter of days.

It took us one week to set up the management plane. It had different ports for management and for the data. After finishing with the management part, we slowly moved segments to Cisco. We consolidated the rules from other firewalls for one zone. After Cisco verified that it was okay, we then moved on to the next segment.

The deployment was with all new networks, so the architecture was with a peer. We first sat down and discussed or laid out our network and what it would look like through IP schemes and everything else in that sense. We then figured out how many users we would have and decide what size of hardware we would need. We decided on what type of VPN connection and what certificates we would need. After that, once we were able to secure those tunnels and get communication going between our two locations, we then started tightening down our two networks as we have multiple networks within each location.

We had to decide what all needed to communicate with one another. Not every network needed to touch the outside world.

I have been working with this equipment for years, so for me, the initial setup is pretty easy. For customers who use the Cisco solutions for the first time, maybe it's complicated. They probably feel it would be easier to configure if there was a simpler graphical view or something like that. Often a complaint is that it's difficult to configure. However, I don't have that issue.

To deploy one solution, how long it takes depends on the customer or the size of the enterprise. For a large enterprise or large public entity, we need more time or more resources to deploy the solution. That said, it's not too difficult for us as we work a lot of time with ASA. We can go fairly quickly.

The initial setup is quite straightforward.

I was not with the organization when they originally rolled it out, so I can't speak to how straightforward or complex the initial setup was. There are about six people who manage the solution. We have security engineers and network engineers. If someone is trying to get an idea of how many people are required, it varies because a lot of organizations will have multiple firewalls in different locations. Six for one organization may be way more than somebody needs or way fewer than somebody needs.

I think it is not the simplest solution to set up because it is sophisticated equipment. For engineers to work with vendors and incorporate totally different solutions, it could be difficult. It is also different from the other Cisco devices like Cisco Router IOS. It differs in a strange way, I would say, because the syntax or CRI differs. If you are used to other OSs, it is not easy to switch to ASA because you have to learn the syntax differences. 

It's common for there to be differences in syntax between vendors. But, I would say that this is more complex. The learning curve for start-up and configuration of ASA is at mid-level when it comes to the difficulty of implementation.

The initial setup of the Cisco ASA NGFW is not easy, but at the same time also it is not complex. It's somewhere in the middle. It took about 4 weeks, then it was activated.

The initial setup was completely straightforward. 

However, we have to rely on Cisco ASDM to access the firewall interface. This needs improvement. Because we have a web-based interface, and it is a lot more user-friendly.

Deployment takes two or three days. We are continuously deploying the solution to our plants over time.

The initial setup is a little difficult compared to other firewalls but once you get it right, especially the assistant control list, it's fine. It's a little difficult compared to other firewalls. 

The deployment took us about three days because we did some testing and we also did certain attacks and checked some hackers which is why it took some time. We wanted to make sure that it was at least 99.99% protected.

When Cisco was installed, it did not go as expected.

For me, it was very easy because I solved all problems, but I had to install it two times. 

The initial setup is 50/50, between straightforward and complex. Migrating from Cisco to another Cisco product is okay, but migrating to Cisco from other network devices, like an IBM switch, is a bit tricky. You can't test the configuration to see if it's the same as what you're going to. But we managed with support from Cisco.

It took a month to complete the deployment.

Our implementation strategy was based on not upgrading everything at the same time. It was phased. We deployed a specific device and then we monitored everything to make sure everything looked okay, and then we moved on to the next one.

It requires a minimum of two people for deployment and maintenance, from our network and security teams.

The initial setup is quite straightforward. I think someone who knows the iOS platform and knows about firewalls can setup the device. If you don't have experience, it will be somewhat complicated. If you know the platform, implementation is very quick. We've installed over 1,000 firewalls for different customers.

Initially, the preliminary set up took us some time. However, we did have some local expertise in Pakistan. Once, when we were stuck on something, we could manage to get help from Cisco online. It wasn't that tricky or complex. In the end, it was straightforward.

The initial setup is very complex. You need to set a load of settings, whether from the CLI or the GUI. It's not an easy process and it should be. That is one of the reasons why many retailers don't go for Cisco. They know Cisco is very good. They know Cisco does ensure security, that it is one of the top-three security vendors, but because of the work involved in the implementation, they decide to go with other solutions.

There are two possibilities in terms of deployment. If we go to a client who is the ASA purchaser and they give us all their policies, all their permissions, and everything is organized, we can deploy, with testing, in one full day. But many times they don't know the policies or what they would like to allow and block. In that scenario, it will take ages. That's not from the Cisco side but because of the customer.

One person, who knows the solutions well, is enough for an ASA deployment. I have done it alone many times. After it's deployed, the number of people needed to maintain the solution depends on their expertise. One expert could do everything involved with the maintenance.

The initial setup of this solution is pretty straightforward.

The initial setup was straightforward.

The initial setup was straightforward and it took me about two days to do the installation. The fine tuning took about a week. I am the IT Infrastructure Manager of our company, but I don't believe that individuals without IT knowledge would struggle to do the installation themselves.

The initial setup was a little complex. We required three staff members for deployment and maintenance.

We went with this solution via the AWS Marketplace because it’s been made so easy to use an ASAv on AWS with simple drop downs to set it up. Our demo machines were also in AWS so we wanted a one-stop shop where we could spin them up or down as needed and configure the ASAv before it was launched.

The integration and configuration are transparent and easy.

Setting it up is not as intuitive as other more modern NGFWs.

You can start very easy and set up the network cards, but it also has many traps to find out the right setting for your environment.

For example, you need fixed network settings on your switch to connect with full duplex 100Mb/s. There is no autonegotiation nor other settings. This is the same problem with the WAN connection. You need to know exactly what to configure to match the WAN, or it will not work.

For me, setup was half-and-half. In one update run I missed the step that discusses how the ASA and ASDM need to be on a specific patch prior to upgrading the SFR. FPMC attempted to push the new update to the devices regardless of this mismatch that caused FPMC to loose communication. I had to downgrade the SFR all the way back to v5.4.1 before I could install the latest version. You also have to step through several updates before you are done, so that can be tedious as well.

The initial deployment is easy for this solution.

The initial deployment was straightforward. The last implementation of an ASA took us about one to two weeks.

Our implementation strategy was to have good architecture and to have all the requirements for the project beforehand. Everything went really smoothly because of that.

We needed four or five people for deployment, including field techs and network engineers.

I recently deployed a similar solution at a customer's premises, and that setup was straightforward.

The steps are fairly documented and the documentation and guides on Cisco are straightforward. You know what you're expected to configure, and it's easy to get up, running, and started. It takes some more time to check everything and get everything as you want to have it, but getting started and getting connectivity and starting to create policies was easy to do and didn't take a very long time.

It took two to four hours, including some upgrades.

We deployed in several cities, but not the same day. 

The initial setup is easy.

The initial setup of this solution is straightforward.

The setup was straightforward, even without initially having all the information we needed. It was very intuitive. When I went in to get help, help was there.

For me, ASA is easy. The deployment of ASAv is done in 20 minutes.

The initial setup for Cisco ASAv was fairly simple. It wasn't very complicated, it would be okay for an intermediate professional. It can be made easier. I believe almost anybody could set up an ASA in a few hours. It took about two to three weeks for the platform to work properly.

The initial setup is very complex but once it's done, it's fantastic. 

I was involved in the initial setup. It was complex. 

Setup was pretty simple, because we implemented the single server model.

The initial setup is very simple to deploy in the Egyptian network. It takes two to three days to deploy but if you are implementing AMP then it will take an extra one or two days.

The initial setup was straightforward. To set up the VPN we are able to set up the feature key networks that are going to talk to each other. We can set up what access is going to be used. The connection was set up in one or two days. 

We set it up twice. The first time it took four hours and the second time took ten hours spread out over two days. 

The initial setup was straightforward. Within in an hour you're done, including with your basic training. For implementation, you need one to two people. You should have one senior network administrator. Two people can maintain it if they have the skill.

The initial setup was not so complex. Most of it was straightforward. We just needed to discuss different scenarios that we had to consider regarding the deployment scenario, what could go wrong and what could happen in the future. 

Straightforward -- console or via the interface.

I would say it's only complex if you're not familiar with either the CLI or ASDM.

So for me, it was easy, for those without Cisco CLI (or ASDM) experience, deployment can be a little daunting.

That being said, there are plenty of configuration documents available on the Cisco website that will "hold your hand" through any deployment.

Initial setup is straightforward. You can get as granular and complex as you want, but out of the box, ASAs provide a secure FW solution.

The setup was easy with lots of documentation and configuration examples provided.

It is easy to initialize. For advanced configurations, it is sometimes complicated.

We have multiple ASA firewalls for different clients now we migrated to Cisco Context.

I did not directly implement the solution. I don't have the right type of expertise. You need to know a bit about what you are doing, otherwise, the initial setup is a bit complex.

You may need, for example, a separate management device for this kind of solution. It's quite difficult to handle if you don't have in-depth knowledge.

The initial setup was somewhat complex at first.

Initial setup was relatively simple, it took around six months and I deployed myself. 

The initial setup is complex. I would say that it took a maximum of a week to deploy.

I wasn't part of the company at the time of the initial setup, and I am just performing additional tasks. We have a staff of a maximum of three or four persons so once the deployment is live it doesn't need much effort.

I'm not sure if the company has plans to increase usage and grow our responsibilities. It's not not for me to decide. I think the company is growing and traffic is increasing. But my superior is the person responsible for determining when it is time to scale.

We found the initial setup much more difficult to do even simple things, like setting up VPN tunnels.

Complex in configuration and understanding. It would be very challenging for a non-Cisco trained engineer.

It was not that complex because I was using Cisco routers and switches five years prior.

I have nothing bad to say about the deployment. It went pretty well, and we can configure everything as we need to.

First you have to configure the Firepower Device Manager, or Firepower Management Center. When you bootstrap it or do the initial config, you type in the IP address, host name, and DNS. When you have the IP configuration in place, you can log in to the Firepower Management Center and start building policies that suit your needs. When you have all the policies, you can add or join Firepower devices to the Firepower Management Center. After adding the devices to the Firepower Management Center, you can then apply the policies that you built in the first place, through the devices, and that will affect the behavior on the devices.

Not that simple, but anyone who have the knowledge can configure it.

The initial setup was straightforward. It took around two to three days to implement. 

The initial setup is easy. If we have an issue we contact their support. 

The initial setup was of normal complexity. It's not straightforward, and because we started so early, the migration tools were not so good at the beginning.

It was a bit complex to setup this solution. When we used the command line, it was not easy to implement. We needed Cisco technical knowledge to be able to manage the implementation.

The initial setup should not be left to the customer. The best way to do this is to make a basic setup and integration along with cabling and power-up, then verifying requirements and adjusting the configuration.

The initial setup was straightforward and there was a lot of documentation that can help out with specific cases.

The setup was straightforward. A new Cisco FTD can be set up and running in a couple of hours. If you're used to firewalls you can quickly get along with it. There is nothing complicated.

The time deploy is short. But the time to tune and create the policies involves a learning phase. Traffic changes over time, so the tuning for firewall rules has to be as granular as possible takes a bit of time. But to deploy you can go live is fast.

The strategy is to start with high-level security policies and then monitor the traffic and the applications affected. Then on the detection logs, create more granular rules.

The initial setup at many clients' sites was straightforward. Very complicated networks take a lot of planning.

Initial set up is straight forward, but there is not much documentation available if you have no experience with the offering. I'd recommend training for all network admins that administer SourceFire systems, especially if you want to leverage some of the advanced features.

The initial setup was slow. It took a day or two.

The initial setup is easy. Firewalls are like programming. If you know programming, you know every language. Firewalls are the same. If you know the security and blocking the perimeter, it's the same for all the firewalls. The difference with the different firewalls are the functionalities. Learn the functionalities in every brand.

My assumption is that it's a typical HA, basic setup.

The initial setup has been pretty straightforward. We have set up a lot of them. The solution works.

The deployment takes about half an hour. It takes a little longer than if we were using their virtual firewalls, which we could implement in a minute.

The initial setup is a bit difficult. Other vendors are doing the app integration solution. The initial setup was medium in complexity.

You need to install the Firepower CLI. You need to log into that and then you'll need to sit down to connect to the ASA and configure the ASA level services. You also need a Firepower management station for it to work appropriately. The setup is serious and a bit complex.

Setup of a firewall, on a medium / large deployment is always a complex work.

Cisco ASA (more than other vendors' solutions) require a lot of know-how and real world expertise to be configured properly.

Complex, because of non-ready Firepower service software setup.

The initial setup is straightforward, as there is a lot of documentation available on the Cisco site, and other sites, which makes planning and deployment pass without any problems. However, the ASA is a complex device, with a lot of features and further tuning is complex and you must have the right knowledge to do it. Configuration can be done through a Java based application called ASDM or through the CLI interface. Using ASDM is much more simple and easy, but ASDM is not compatible with the newer Java version, so before implementation you must read the compatibility notes. Also, keep in mind that when upgrading ASA software, you must also upgrade the ASDM package.

The installation can be easy, although it is slightly more difficult to install than Fortinet FortiGate. One day is enough for deployment but it takes a long time to configure.

The solution is normally easy to install but if the user has more requirements, as in a more complicated setup, it could take more time.

It's easy to install Cisco Firepower NGFW Firewall. You can install it on the platform with all the images in one set form. It took me about 20 to 30 minutes to install. 

I have not been present for most of the deployments, but from my experience, the deployment is not complex for organizations like ours because we have less equipment and infrastructure. 

In Ethiopia, most of the deployments, especially in government organizations, are on-premises because of government policy.

Our policies are limited and not complex.

Overall, I would say that it's pretty straightforward. While I was not a part of the deployment and had to guess, I would say it may have taken a week to deploy.

We require a team of four or five to maintain this solution.

When you configure the ASA, there is already a basic setup there. Based on your environment, you need to customize it. If you understand security and firewalls very well, you can create your own setup.

For me, the initial setup is easy, but is it good? Because from a security perspective, you always need to customize the initial setup and come up with the setup that fits with your environment. So it's always easy to do the initial setup, but the initial setup is for kids in IT.

The time it takes to set up the ASA depends on your environment. For a smaller deployment, you just have the one interface to configure and to put some policies in place and that's all. If you are deploying the ASA for something like a bank, there are a lot of policies and there is a lot of testing to do, so that can take you all night. So the setup time really depends on your environment and on the size of the company as well.

The initial setup was straightforward. 

The initial setup was a little complex for me because I had been using a different solution. But how complex something is will depend on the mind of that person. For me, it was a little complex for me. However, it really only took one day to set it up.

Step by step, when I work with the product for a longer period of time and gain experience, it will be very easy for me.

The initial setup was of a medium complexity. This was especially true when it came to integration of the data servers.

Initial setup was very straightforward because the training and certification provided by the vendor helped us to solve rapidly any configuration issues.

Quite straightforward for the most part, since I had TAC on call while setting it up.

Yes, straightforward and simple.

It's pretty straightforward. I came at these products already having considerable firewall experience.

The setup is easy to do if you are familiar with these type of installs, if not then it could be difficult.

The installation is not hard and not easy either, it falls in between.

The initial setup was straightforward and it took the company about a day to deploy the firewalls.

I was involved in the initial set up and it was complex.

Pretty straightforward.

The initial setup is straightforward and the deployment only takes a few hours. Our deployment strategy was to keep it simple. A large deployment of this solution can require up to 10 resources. 

The solution does require maintenance and we use an external service provider for this maintenance. 

My team tells me that other solutions such as Fortinet and Palo Alto are easier to implement.

The initial setup of this solution is pretty straightforward. We did have some rules that somebody had put on it that didn't match up, but we got it all worked out.

It was very straightforward. It was not complex at all.

The initial setup was a bit complex.

The setup was smooth and simple.

The setup was reasonably straightforward.

Depends on the product and the knowledge. Cisco firewalls can be difficult at first but once learned it's fine.

In our case straightforward, because we do not have many rules on our firewall, but I’ve seen cases where the migration from one firewall to another can be very tedious.

We have a team of 50 or 60 Network Engineers to maintain this solution.

For a new user, the initial setup may be a bit difficult. For me, since I am comfortable with Cisco, it's pretty straightforward. A new connection has its own complexities. It may be a different thing on Java SDK. There may be some programs that may not be able to access it.

I actually have lots of experience working on multiple firewalls and technical solutions, so for me I don't have any problem doing things by the command line. But for others, for a person who has two years of experience or one year of experience in general, they will definitely face issues working in the command line. You have to remember all of the commands, to search for the commands. If you're in a graphical user interface, you can go search somewhere and find some options. So I would say in that way it is complex.

It is a little difficult in newer IOS versions where the use of the NAT command is different. Otherwise its straightforward to configure.

The initial setup is fairly easy and there are wizards for almost all the basic needs, including the initial setup and all types of VPN technologies that the ASA supports.

It is straightforward.

It was a straightforward setup.

The implementation is not so straightforward. It's rather complex and we have a lot of trouble with it.

The implementation took us about one month.

We plan to implement an updated version next month as well.

We need three to eight people to handle the setup.

The initial setup was very easy. Cisco documentation is online, so it was no problem at all.

It took approximately 30 minutes to install.

Initial setup is pretty straightforward.

The initial setup was straightforward.

I was pretty junior when the solution was initially implemented in the organization. For that reason, I did not take an active role in implementing the solution. I wouldn't be able to really discuss the setup specifics or the level of difficulty.

I'm not exactly sure who handles maintenance, if any, within our organization.

The complexity of the setup depends on the needs and requirements of the client.

When a client does not know exactly what is needed, the complexity increases because the configuration is not clear. You really have to have a good understanding of what the client needs before configuring it.

If the model does not have SMC then it is complex to configure.

The length of time for deployment also depends on the requirements, but it will usually take between three days and one week.

The setup is always different. If you have a small company, the setup is quite easy, but if you have a bigger company the setups are quite complex. Cisco is pretty good in routing. So in bigger situations, configuring the ASAv file is pretty straightforward.

The deployment also depends on the customer's site. So, the time changes because most of the time we have to do a migration. For example, some customers have an old firewall, and you have to migrate things to a new one. And sometimes, it's just copy/paste, but in some situations, we cannot migrate all firewall configurations to a new one.

In terms of how many people you need for deployment and maintenance, again, it's dependent on the company strategy around the help desk. You should have a maintenance engineer who should be part of a team. The deployment will be done in a team. You can have one person to do the deployment but usually, you always have a backup, so it would be two. And then, for the maintenance, it can be one person or two. The maintenance can be done on the site desk, operating after office hours, so it depends.

It's not straightforward. You need to know what you're doing, you need to be trained. I don't know for other vendors whether it's the same issue, but for Cisco you have to be trained on the system.

The setup was straightforward with two layers of firewall.

The most complex part was figuring out the failover and what NAT mode to implement.

It requires training, but after that it is straight forward.

For a non-Cisco guy like me, there is quite a substantial amount of learning that needs to be done to actually understand how the products are. Some brands like FortiGate, require only an hour and 15 minutes to enable the product, to facilitate the basic requirements of connecting up the traffic and adding on the firewall router. For Cisco, there are levels of challenges because it's a hardened solution that sees a lot of restrictions right out of the box.

Without really understanding how it works, then there'll be a lot of confusion regarding the traffic, etc. You'll find yourself wondering if there are any security concerns if you alter it out-of-the-box. The management console is quite outdated; usually, a lot of configuration is through Commander. We really need to understand how to articulate the Cisco Commander to perform even the most basic feature.

The initial setup is straightforward. 

The initial setup was quite complex.

There were no issues with setup.

If you're a Cisco Administrator or Cisco certified, the initial setup isn't a problem. But if you don't know Cisco devices and how they work, it can get a little complicated.

It has moderate complexity. I didn't have any prior experience in configuring these firewalls. That's why I found its initial setup to be of moderate complexity, but now, I have got used to using and maintaining these devices.

The initial setup was very straightforward.

It was a bit complex to set up. However, after some practice, it was not too difficult.

For some things it is very easy, but configuring other things is a little complex. It depends on the use case.

If you know how to use Cisco IOS, it's easy. Otherwise, you will find no way
of configuring it with ease.

It can be complex, since a lot of CLI commands are different with respect to the CLI of IOS routers.

It was an easy initial set-up.

The initial setup is easy, with the installation and configuration taking about two hours.

The setup was straightforward. I was happy with the configuration and deployment of the solution, as it was quick.

It was straightforward, even though we migrated from a third-party to Cisco.

The initial setup configurations differ from customer to customer, from very simple to highly complex solutions. Depends on the customer’s needs.

Once you have the knowledge it is not complex to install an ASA, but it does depend on the network of the customer.

The initial setup is straightforward and it took two weeks to deploy. Currently, 5000 employees use this solution in our company.

The initial setup was not too complicated. It was good. 

The initial setup was straightforward. Implementation took two days. We needed two people for the deployment. 

It is complex. We have to set up ASA, SFR module, and FMC separately, which sometimes requires extensive troubleshooting, even for smaller issues.

As I enjoy working on CLI, I would say that the initial setup was not complex.

A bit complex compared to Watchguard Firewall.

Yes, but you need to read and understand how the device functions before deployment.

I can't really remember the setup. It was too long ago.

It was a little complex, but not so much that we couldn't figure it out.

Well, it is straight forward as long as you understand the components available.

ASA can be configured using the CLI or ASDM.

For the Firepower you will need to use a FireSIGHT as a management solution.

Since you will be using two GUIs, I wouldn't call it straight forward.

It was straightforward.

I believe it is straightforward, but again it depends on what you are trying to accomplish.

If you have no experience with the device it may be complex but being trained on the device helps drastically.

Straightforward.

Setup was complex because we had not taken a course previously.

Cisco implementations are always very straightforward.

It's easy for me to configure one because I have firewall configuration certifications. I don't know what someone with nothing in terms of experience would be able to do. 

It normally takes me a week to implement and deploy. I normally need a week and three people to do maintenance.

The initial setup is not simple and straightforward, because it is Cisco and you need to configure it by CLI.

It is easy to set up and implement.

Initial setup was fairly complex. Just having to know the command prompt rather than having a better user interface.

New version comes with initial setup tutorial, with very nice security policies baseline, set up by default.

Straightforward, two-tire setup.

It was straightforward.

It was straightforward.

The initial setup was straightforward. It was easy for us because we have experience.

It was already deployed when I arrived.

We have two or three guys for deployment and maintenance.

The initial setup was easy and simple. 

The setup is a little more complex than other solutions.

It was complex because I had to put the ASA directly into the production environment.

The initial setup was straightforward. With other vendors, it is easier, but it was straightforward.

The initial setup was complex because of its outdoor position. We had to solve this problem with outdoor protection.

It was straightforward as Cisco Asia integrated it into OSPF, another router on the stack, and for NAT IPSec.

Straightforward.

The initial setup is straightforward. The length of time for deployment depends on whether it is the entire setup or just the basic installation.

Actually it was simple, making port based policies more simple than PA.

It's not too complex, but it depends on the customers' network architecture.