Cisco Security Cloud Control Reviews

This is part of our network orchestration solution. It allows us to optimize our network. For example, if I want to communicate with a laptop, this solution gives us a way to route the communication.

We have a public cloud deployment using Microsoft Azure.

If our server is blocked, this solution shows us why it is blocked and allows us to update the network routing. It gives us recommendations of what to do, and it can be done automatically.

The most valuable feature of this solution is the visibility that it provides into our network. It shows a graphical topography of the network.

The dashboard needs to be more customizable to provide better reporting for our network.

This solution appears to be stable for the moment.

The scalability of this solution is good.

There are three people who use this solution. We have an administrator, and engineering architect, and a software engineer.

I would rate technical support a seven out of ten.

Prior to this solution, I was working on Skybox. It is primarily used for firewalls.

The initial setup of this solution is of medium difficulty. The deployment took one day, although for a larger infrastructure I think it will take more than one day.

One person is suitable for deployment. In terms of maintenance, two people including the administrator are sufficient.

We deployed this solution with assistance from Cisco.

My advice for anybody who is researching this solution is to consider the advantages that it provides in terms of infrastructure.

It is easy to configure administrators and other users who can generate reports and check the dashboard. For the moment, this solution meets our needs and I cannot think of any additional features that should be added.

I would rate this solution an eight out of ten.

I use it to manage my group of firewalls, and I make some configuration changes with it. If I have to update multiple devices at one time I will use it as well.

Its ability to make bulk changes makes it much easier, that's for sure, when I have to upgrade multiple clients. Although I don't update too often, maybe every six months, it saves me 20 minutes per device for the four devices we have.

It also helps that I'm able to look at synchronizing my configuration across all of the devices. When it comes to configuration of my access rules, it allows me to create a standard across all of them.

Our security team is just me, one guy. We're a pretty small organization. But in a way, it has made me more productive.

In addition, its support for ASA, FTD, and Meraki MX helps maintain consistent security.

• The bulk changes feature is definitely the most valuable. 
• Being able to look at the configuration before and after the change is made, is helpful.

They should make it more of a one-stop shop for everything. It should have more features to manage FirePOWER appliances.

I'm pretty impressed with the stability. It hasn't broken on me. I'm pretty satisfied.

Since I only have the four devices I really haven't done anything on a mass scale. I can see us possibly increasing usage in the future.

I haven't used tech support.

We didn't have a previous solution.

The initial setup was pretty straightforward. I had one of the guys from Cisco show me how to onboard one device, and I was able to get the others onboard within about five minutes. There wasn't really an implementation strategy. He just showed me how to do one device at a time.

It's just a good product to have.

In terms of CDO's security features around storing firewall configurations in the cloud, I haven't delved into that yet. I plan to get into it this month, but I haven't logged into it yet. I still use the ASDM a lot of times. I also have a FirePOWER which most of the firewalls are in and I will the FirePOWER Management Center for that because Orchestrator doesn't manage it quite as well. For firewall builds and daily management of existing firewalls, I normally use FirePOWER, as far as monitoring goes.

We have it set up to test to look at policy from an overarching perspective. Then, we are hoping to use it for policy push, such as making both changes across different firewalls, but we haven't gotten to that point yet.

We have the on-prem relay, and then that connects into the cloud for Cisco Defense Orchestrator (CDO),

We deployed the most recent version about a year ago.

We don't use it on a day-to-day basis. It's not something that we really spend a lot of time reviewing. I just haven't had time to sit down with it.

It hasn't really improved our organization. It has been more like a PoC which was spun up and played with for a little while, and we haven't gotten back to it.

I saw that it could simplify security policy management across our extended network and it does have the capability. We just never went to do anything with it.

We don't work with the auditing. That is another security team who hasn't been exposed to the team, as far as auditing the current firewall rules.

This has the potential to make our security teams more productive, but we have never used it for that.

The rule usage is a nice feature. 

The ability to see the uptimes on the different VPNs that we have configured for site-to-site.

The overarching policy as far as the rules go and the assessment that it can do with the rule base.

The GUI on it was decently put together.

When logging into the device, we sort of had problems with it staying in sync. If somebody made a change onsite, it wouldn't do an automatic sync. It would have to wait, as you would have to do a manual sync up.

It has been stable, as far as I can tell.

We never pushed the limits. We put about 15 or 20 firewalls on it, and it seemed to take that just fine.

There are about five or six people who can log into it, look at it, and explore the capabilities of it. To my knowledge, no one is currently using it. If they do, they'll log in there to look at the rule base or for general usage. It was good for getting reports out.

I used the technical support once. It was to get a username reset. The experience was okay.

We use the solution support for our ASA devices. We also have Firepower, and at the time, it only does FTEs. Therefore, everything we deploy is in an FMC manner. We never could get that in there.

The initial setup was straightforward. We spun up the VM onsite. We generated the key that it needed to talk to the Cloud Orchestrator. After that, as I started adding devices, it was relatively quick and easy.

Provided that you can get the VM spun up without politics involved, it takes a couple hours to a day to set up.

It was just myself who set it all up. 

Once we got the virtual machines spun up for the onsite piece of it, we got it connected to the cloud, added a few devices, and went on from there. It was straightforward. There wasn't anything that really required much human interaction.

The biggest thing that we were looking at it for was the ability to push out a mass firewall change, if we needed it to. We just never got to a point of testing that feature and setting that up.

It is covered under the CIsco Enterprise License Agreement (ELA). So, it is licensed and ours, but we didn't spin it up with the intent to permanently move over to it. It was just something our account team said, "You have this. Why don't you try it out?"

We are still using FireMon as our firewall manager right now. FireMon is definitely a little more feature-rich. It definitely could get further into the rule base of it. We didn't use FireMon to deploy anything, so it was more or less just to validate configuration, put a source and destination, and have it spit out what firewalls it would hit. We never really tried to sit down and do a comparison between the two. The UI within FireMon has probably a little more security-centric viewpoint.

I don't always spend a lot of time in either FireMon or CDO. These are for the security team who have ability to look and see policy, and if they want to make any changes or remove anything of that nature.

We are moving away from FireMon and starting to look more at a RedSeal approach right now. Some other members of my team have looked pretty closely into it. Our security team really liked it. I think they've actually issued a PO for it.

We will probably not be increasing usage of the product because we are moving over to Palo Alto firewalls. Eventually, a lot of ASAs that we have will be phased out.

It was just something for us to spin up and look through, then see if it was something that could benefit us from a policy perspective by pushing policy out. It might have been able to, but it was a little cumbersome to select firewalls. We just didn't go through and spend a lot of time with it.

With the security features around storing firewall configurations in the cloud, I sort of go back and forth on it. you are putting a configuration out there on the cloud for somebody to read. However, it is a private cloud that Cisco manages, so all we can really do is hold Cisco accountable if something happens. While I don't have strong feelings about this, my organization does. They don't like to have it out there.

We have not used it for spinning it up and having a look.

The primary use case for it is to verify that we have connectivity with the systems that we put into it. We also use it for configuration backup.

If we have a firewall go down, I can hop into CDO, pull the latest configuration off and apply it. That's really good. It helps save time. We've done that a couple of times and we've sped things up quite a bit. The first time we had a firewall go down, we panicked: "Hey, do we have the config?" We can pull it right off CDO. And sure enough, we pulled it off and there you go. We had somebody console in, remote to it, and pop that back in. Next thing I know, it's back up and working.

I don't have a number, but it has saved us a lot of time. For example, just last week one of our small Tier 4 sites, a little ASA 5506 went down. I don't keep the configs on my system and we don't have a central repository for them on our network. They want to keep that separate, which is what CDO is for. Went right into CDO, copied it down. We said, "Hey, we've got this firewall here, we're all set and ready to configure." Remoted in, console, applied the config, and they were back up and running. We could have had them back up and running even faster if they had had a spare ASA there but they didn't, so it took them a little bit of time to get it. But within 15 minutes of connecting, we had them back up and running.

Prior to CDO, the amount of time that would have taken depends on if someone even had a config. We hoped somebody did, but didn't necessarily know how old that config was. We would run into that problem before we had CDO. The situation would be, "Okay, we think this config is pretty current," and then they would say, "Well, this isn't working." Then we'd have to go back, look through tickets that were approved to find, "Oh yeah, this rule was on there but we didn't have it stored on the latest config for that site." There was a lot of trial and error and there were a lot of issues; all that fun stuff. CDO has negated all that.

I generally go into CDO once a week, at a minimum, and check all the rules to make sure the ones I put in it were caught - which they are. I also audit, in case anybody else has made changes that I'm not aware of. It catches that too. I can also to see what systems are online or any systems having issues or which rebooted. For example, we have quite a few Active Stone by pairs. If they fail over, we have a monitoring tool, Orion, which is not quite set up yet - they're just starting to get the firewalls in there. So it doesn't alert you if a firewall has failed over. And I can understand why it wouldn't, because the IP stays the same. As far as it's concerned, it's still pingable. But I'll see that there's a change on it and I'll have a look. The only change on it is that now this one is the standby, it took over the active role. I can go into that firewall and find out what happened. Why did that change? Why did it fail over, and troubleshoot based on that. That's pretty cool too.

The auditing's good. If they say to us, "Okay, we need a list of all your firewalls." We can say, "Here you go." We just export that out of CDO so that speeds things up, instead of us having to keep a separate spreadsheet. We do that anyway, but that's just for checks and balances. But if it's something we need quickly, we pull it out of CDO and we match CDO up to our manual spreadsheet.

Once it was up and running we saw value from it pretty immediately. We could see what changes were made, how well it tracked. There have been a couple of times where it showed me a change I didn't remember making. And then I have had to go back and start finding out, "Hey, who did this? Who got into this firewall and did this?" "Oh, that person did. Great." We ended up tying that back with data to see who logged into it at such and such time, whenever it said the change was made. That has been good, one of the biggest things.

I don't stay in CDO all the time, so it's good that it shows what changes, if any, have been made by anybody else. That's a good feature.

We use it for limited changes, although I still don't find it one of the easier ways to make changes. I wish it was a lot easier for that. I have told Cisco about it before. We got it for configuration storage backup and it works great for that. They had me go through a couple of WebEx's as me as far as changes go, and it seems easier to do them through ASDM. If they had like a GUI-type interface merged with CDO through which we could do changes, it would be definitely an awesome tool. But ASDM is easier for times when we're doing one or two rule additions. If it's going to go any bigger, CDO runs through a script. It's easier for me just to make a script and put it on the device in the first place, instead of going through CDO to do that.

For managing or making changes on the ASA in a way that is similar to ASDM, if they somehow might be able to look at incorporating that functionality, that would be good. Currently, when you want to add a change, you go through the process in CDO and all it's doing is creating a script. I can just use my past scripts - adjust accordingly, copy and paste into the firewall - quicker than I can running through the tool on CDO. Again, if it's just like a one-liner or a basic admin-type change on a firewall, ASDM is my go-to application to do it. It's just so much quicker and easier.

I know Cisco is trying to get away from ASDM, using Java-based GUI for firewalls. We're actually starting to go over to FirePOWER Chassis, and I don't know if they're going to be putting in the capability in CDO to monitor the chassis themselves or not. We can, of course, do the Virtual ASA through CDO, but that doesn't handle the chassis itself. It would be nice if CDO had that ability.

I'd like CDO to be the one-stop-shop where we could do all the configurations easily. It would be nice, for ASA upgrades, if we could do them from a central repository and not have to reach out to Cisco. That would be a definite plus. CDO is great for a quick view of something like how many systems I have running a certain set of code. Or maybe a vulnerability came out and we have to check if we are running that code. What are the cases? What are our vulnerable firewalls? It's helped to identify them. But what would be even easier is: "Here's all the identified ones. Want to upgrade them and schedule?" That's something we can do but, again, they have to go out to Cisco to pull the image down. I'd rather say, "I don't want you to go at Cisco. I want you to go over to this server," and SFTP over to our server right here. "Pull this image down," and then let it run through its upgrade process. That would be awesome.

The one recommendation that would be the most beneficial, in my opinion, would be the ability to upgrade from a local repository instead of off of Cisco. We tested it out in lab in terms of how it upgrades, and it was literally "click, click, click," and then sit back and wait until it was done; and it tells you it's done. That worked perfectly. The problem is we don't put DNS resolution servers on our firewall configs. So they have no way to resolve cisco.com or whatever URL it is sending to for pulling down those updates. If I could do it from a central repository, I'd use this thing a whole lot more.

I kind of see the benefit of going to cisco.com, but if it did a hash on the download and that hash was fine compared to what it brings off the repository, I wouldn't see a problem with it. But I'm not the application engineer. I don't even know if it could do it that way or if they might want to look into it. But that is the best recommendation and it would make me get into this thing a heck of a lot more.

We haven't had any issues with the Secure Device Connector losing connectivity. The application has always come up when we've needed it. It's been great and stable.

We haven't hit any limits. We haven't overtaxed it.

We have about 250 firewalls in it, and we're getting ready to add another 250. We'll see how it handles that. That's going to be in the next six months. As we put them in, we'll put them into CDO. Hopefully, we don't come into a point where it says, "Oh, I can't do any more of this," and then we have to reach out to Cisco. I don't even know if there's a limitation on it, as far as how many devices you can have into it. They just added the ability to put Meraki into it. We don't have Meraki but, obviously, you can put more than just firewalls into it.

The only thing that would make me use it more would be if there were an easier way to do changes or upgrades. Right now, there's no benefit to doing changes through CDO; it doesn't save me time.

Every time we've had a question, they've been johnny-on-the-spot. They answer really quickly, get emails back to us, and help as needed. We've had no issues with them whatsoever. It's like anything with Cisco. If you get ahold of Cisco and say, "We have a problem," they're right on it.

We actually got it before we decided to buy it. I heard about it at Cisco Live about three years ago and brought it back here. We decided to try it out. We thought, "Man, it looks pretty good. Let's buy it." And we bought it.

We didn't have a competitor's solution before CDO and that was another big reason to buy this. If nothing else it was, one of the things we were happy about, and that we feel justified the spend, was having the configurations kept in a central spot, where we can go really quickly and pull them down as need be. Without CDO, we had a problem with that a lot. A firewall would go offline and maybe our on-call didn't have the config, or the config was six months old, and changes had been made. With CDO, it is right up-to-date. It's so much easier.

We just kept tape backups all the time. With that many firewalls, it's hard for one person to do that and have an up-to-date configuration for all the firewalls. It was near impossible. This makes it possible.

I didn't actually deal with the server-build, but that seemed to go fine. We didn't hear any issues from the server team on that. The Secure Device Connector which is liaising with the web, we haven't had any issues with it. It was pretty straightforward. We did have a little bit of help when we first bought it. They had a couple of WebEx's to show us how to do some basic stuff. It seemed to progress, so we learned, researched, and have asked questions about it.

I don't remember how long the deployment took but it didn't stick in my mind as being overly cumbersome or painful, so it couldn't have been that bad. Otherwise, I'd probably remember it.

From my group, one person was involved in the deployment. She was handling it at the time. She worked with our server team to build the virtual server for the Secure Device Connector. There were probably one or two people on that team, at the most.

For maintenance, it's just me who gets into it and uses it. We don't really have anybody else on our team that does VPN/firewall. That's my luck of the draw.

Cisco assisted us. We were among the first group of customers to try it out.

The main return on investment is time. If a firewall goes down, the site goes down. We need to get the backup config for it and get it applied as soon as possible. If we don't have a decent enough backup config, we have to put a config on there that is supposed to be okay, but there can still be issues. Now, we get the site back up with the config they were running when it went offline. Some of these sites are our major mills. They do process control, handle large machines, they make paper and boxes, etc. Getting them back up the way there were saves time.

I'm sure somebody could put a monetary value on it. And the first time that happened, the savings probably exceeded what CDO costs. That would be a definite return on investment. I don't have a way to quantify, but I definitely believe it is worth the price we're paying for it, just in that respect alone.

The more Cisco keeps adding to CDO, the more capabilities, the better it's going to be.

I don't think our company looked into any other options.

The biggest lesson I've learned from using CDO is, of course: Have a backup. And this gives us the means to have a backup. I think management was under the impression for a long time along the lines of, "Hey, you've got backup on your hard drive for all this stuff don't you?" And the answer was "no." There was an expectation in other areas, things they assumed we were doing but that we couldn't do. Ultimately, it's like you tell anybody with any form of data storage: Back up, back up, back up.

We weren't doing backups, we didn't have a way to do backups, and this gave us that opportunity. That's why they're very happy to pay for it, because of what we're getting out of it.

In terms of advice, the first thing I would ask you is what are you looking at it for? But I would never shy anybody away from CDO because our reason for using it could be different from somebody else's reason for using it. It's a good product. Do I think improvements can be made? Sure. Just like any other product. Do I think that this is a waste of money? No, not at all.

There are a lot of things it can do as far as cleaning up your policies, object groups, etc. We just don't use that. And we haven't really used the templates portion because we have a varied range of ASAs out there and we already had templates built for that. We could import them into CDO, but generally, we don't have a way to put them on the network. It's mainly a manual process for us anyway.

We can't do the image upgrades because we don't do DNS settings on our firewalls. That's company policy. CDO requires a DNS lookup and external access to do image upgrades through CDO. If we had a repository in-house which had the images, and we could pull images from there and transfer them over to the device, that would be great. But I don't think that functionality is in CDO. Even if we upgraded from ASDM, I do it with the images that are stored on my machine and transfer the program package over to the firewalls that way. They don't go out to Cisco and pull them down directly.

We haven't really touched the policy features. We've got roughly 250 firewalls and our management is a little leery of doing any kind of policy changes or even removal. This policy may not be used, or that object group may not be used, and it recommends taking them out. But management really doesn't want to use the application for that. They're not that confident with it yet. That's not necessarily because of CDO itself, it's that they're just not that familiar with it and they tend to want to keep things the old way. So we just go ahead and remove them ourselves.

If I get time to play with the policies and to show justification to be able to say, "Stop being so afraid of it, it actually works well," they might start cutting over and letting us do that.

We're not using CDO for storing configurations in the cloud. We're storing them on a local server. We have a Connector, but I don't believe our configurations are stored on the cloud.

We don't use FTD. We're looking at doing that but we still have some TippingPoint IPSs, so they don't want to migrate over to a different type - however you want to look at IPS application or firewall - until we get rid of those. That won't be for about another year.

CDO hasn't really affected our firewall builds or daily management of existing firewalls. It's easier for me to script it out and put it in the firewall itself. We really don't have a standard firewall build for each site out of our 250 unique firewalls. So we don't use a standard group. For example, we have an application called PI and it's used for manufacturing. We don't have a standard object group named PI, because it's spread across many of our process-control firewalls. So that makes it kind of hard to use CDO for a large-scale push. And if it's a one-liner or creating an object group for specific systems, it's easier for me to go to ASDM, put that in and pop the rule on there and be done with it, instead of going through CDO.

That's not a hit against CDO by any means. It’ more of a product-improvement suggestion. Whether it’s CLI or CDO, each interface has its benefits and no one is better than the other ones. I can see certain things in CDO, or see them more easily in CDO, than with other applications. To me, it’s just another tool to manage my firewalls.

Back to the auditing issue, we generally don't like to give our auditors configs. They don't need them. If they ask specific questions, we'll take them on a case-by-case basis. But most of the time they say things like, "We want to see that you have Telnet turned off, that you don't have Telnet on your firewalls." We just tell them, "We don't, and if you want to audit then give us a couple of specifics," and we'll give them limited configuration output. But we don't really use CDO for that at all. Generally it's just, "How many firewalls do you have?" - a very broad, general question. Usually, if they want to get something more specific, then they'll pick out a handful of firewalls and they'll want to see certain things off of them. And then we'll provide that separately, instead of going through CDO.

I'd like to rate it a ten out of ten, but nothing is ever perfect. The reason I'm saying eight is that it would be really great to get a couple of things added to CDO to make it better; to make it that central one-stop-shop. I want to see my firewalls. I want to be able to make changes on my firewalls easily. I don't want it to be, "Click here, click here, click here, go over here, do this, do that, and add this over there." I can script it out and do it more easily. I can go into ASDM and it's easier. Also, if we could do upgrades from a central repository instead of having to reach out to Cisco, I would be all for it. That would be a much higher reason to say this is one of the better one-stop-shops which you need for your firewalls.

We use it to manage our firewalls.

There are two main aspects. One is that it makes it easier to make sure that things are consistent and that there aren't too many mistakes being made through a more manual process.

The second aspect is that it makes it easier for people to learn how to manage firewalls, or at least it makes it easier for them to be able to make some changes without having a deep knowledge of the technical aspects of firewall management. It allows us to have more people taking part in managing firewalls, without requiring a lot of training.

The solution has made our security team more productive because it allows us to have more people do the same kind of work, and they take less time doing it. It catches what could have been mistakes on our part.

It also makes it easier to make changes across firewalls. Daily management is probably the main benefit that we were looking for with this product and that works. There are a lot of problems which I noted elsewhere in this review but, generally speaking, daily management of our firewalls was the point of having it and that aspect is successful.

It has increased the visibility of security quite a bit. It allows us to give read-only access to some people who are not supposed to be making changes, but who are helped a lot by being able to see what the security policies are. However, those people aren't making use of that ability very much. The solution only makes it marginally easier for management to take a look and see if they find something wrong.

The ability to do operations on multiple firewalls at once is valuable because it saves time and mental effort. The solution's ability to make bulk changes makes it very convenient to manage things at once on multiple targets.

Although the solution supports ASA, FTD, and Meraki MX devices, we don't have any FTD or Meraki. But for ASA, which is the only thing we use it for, that's where it saves time and mental energy in figuring out what needs to be done, or how to implement something that has been requested.

In terms of bulk changes, specifically for accessing policies, there is one limitation which is especially annoying and at least one bug which hasn't been fixed. In terms of bulk changes for image upgrades, that's nice, but I have found that it's not really useful in most cases, because of limitations of the product.

I've found dozens of bugs over the year we've been using it. The more I use it for different things, the more problems I find. Some of them get resolved pretty quickly. For others, I have to argue for a long time about why they are problematic and should be fixed. For some, they decide they're not going to fix them because they don't care.

By far, most of the problems have to do with the user interface. A lot of thought and work has gone into the back-end component to make the product do what it's intended to do, but the way it is presented for use hasn't gotten nearly as much thought to make it smart and bug-free. I wouldn't say that it's not user-friendly, but there are a lot of bugs or features that are not very adequate. It's kind of user-friendly but there are a number of display issues or ways of doing things that are not as comprehensive; they're more limited compared to what you can do on your own with other products.

In terms of auditing, we're worse off. It took away some of the capabilities that we had without the product because of a decision Cisco made on how to handle the history of changes. That's one example of a specific issue where we asked them to do things more intelligently, but they haven't. They kind-of agreed, but they haven't done it yet, and it's not going to be possible to make up for the past year of not having that in place. So auditing is definitely.

There have been no interruptions or failures. It works all the time, as designed.

In terms of evolving, it's good that they've been continuously making changes as customers request features or, in my case, find bugs. They've stabilized it. They've been improving it continuously by fixing bugs or adding features which make it useful for more than one type of firewall.

As they make changes, it improves. The changes they're making are not breaking things, which is sometimes a problem with software. It happens with other companies, sometimes, that they release a new version that has a problem which wasn't a problem before. They end up breaking things and it's not a stable platform. 

In the case of CDO, that's not what's happening at all. They're always making changes that don't affect the reliability of the product at all. I consider that to be stable.

We're on the small end of the scale in terms of environment size. We have four production firewalls and one test firewall, and there are no plans to expand on that. We could use it to manage more firewalls, but those other firewalls are managed by a different team which doesn't want to use the same products that our team uses to manage firewalls. We have the potential, the switches and other networking products, for even bigger savings or integration, but our internal structure prevents it from happening.

With maybe one or two exceptions out of 20 or 30, so more than 90 percent of the time, technical support has been very responsive. For this product, they are very uncharacteristically interested in resolving whatever issue the customer reports. They're really attentive, and they address whatever we bring up as quickly as they can. That's been a very positive aspect of the product.

The flip side is that it's a fairly new product and they're still polishing it. So it's certainly logical that they would take into account whatever customers say because that allows them to improve the product. That makes the technical support an "intermediary" between the customers and the design team. They're still doing a lot of design, and technical support plays an important role in that.

As I've mentioned, I have found a lot of bugs. I have reported them to technical support and they have opened cases internally with the development team for the product. That team takes action as they have resources to do so. More than 90 percent of the time, they agree that what I have said should be done. It has been a very good experience with technical support.

Before, we were using a completely manual process which is obviously less efficient, but also more controllable. We chose how to do things, which is something we can't do anymore because of product limitations or shortcomings that they may or may not fix eventually.

The initial setup was very easy. We had to build one virtual machine on our infrastructure and then the process of adding firewalls to the system was very straightforward. It took almost no time to get going. The whole VM part took less than an hour and the adding of firewalls took about five minutes each.

We started seeing value as soon as we tested it, even before we purchased it and started using it for production work. The value was obvious from the beginning of getting to know the product.

We did it ourselves.

Before settling on Defense Orchestrator, we evaluated two other similar products. One was another product from Cisco which turned out to be way too complex and lack some of the features that we wanted. It turned out not to be usable in practice. The other was a lot more straightforward and a lot cheaper, but it was missing key features. CDO was a middle ground between the bigger Cisco product in the same category and a much smaller, cheaper product from another company.

The one from Cisco that was a pain to deal with was Security Manager, and the other one was from SolarWinds and is called Network Configuration Management.

Try it with realistic situations in your environment. Make sure that you're able to perform the tasks that you were doing before. In other words, make sure you don't lose capabilities because you're going to do everything exclusively through the product. Make sure you understand what it covers and what it doesn't. Do your homework before you buy.

We haven't learned any big lessons from using this solution, but we have learned that using a firewall management tool that is good enough will allow you to save time and staffing, but that applies to any product, not just this one. This product hasn't existed for a very long time, but the very general lesson is that we benefit from using a firewall management tool as opposed to not using one, and CDO happens to be the one that we chose. But the lesson of benefiting from using a tool isn't the result of CDO being what it is. It's the result of CDO being one of the products in that category.

In terms of the solution's security features around storing our firewall configuration in the cloud, we assume that it's handled in a very secure way, considering that it is a security management product. The one thing that we are not happy about is that it is storing passwords and similar secret strings in clear text in the user interface. So when we copy and paste from the website, we have to manually remove those values and replace them with stars to hide the secret information. That's just about the only security issue we're not happy about or feel is not secure.

As for users of CDO in our company, excluding the read-only users, we have three people who are using it to perform tasks that affect what the firewalls do. My role is not very well-defined - I do all kinds of things. The other two are information/computer security specialists. Their job involves all kinds of IT security stuff. We have different levels of experience, so what each of us does depends on the complexity of the deployment.

Once it's installed, there's no maintenance or other deployment required. Only one person at a time can do deployments.

Let's say that on the scale of one to ten, ten represents something where we can't think of anyone ever doing something better, anywhere in the world, and zero means we can't use it. I'm very harsh, in general, in my evaluations. I'm thinking of the ten most important aspects and how many of those it covers, and how many it comes up short on, and I end up rating CDO at eight out of ten. The solution is 75 percent of our ideal.

As an IT person for Egypt Foods Group company, we primarily rely on Cisco Defense Orchestrator as centralized management for our Cisco devices (e.g., firewalls and other security devices).

Implementing the solution improves our company's performance. It does this by providing timely reporting, saving money, advising our IT personnel and improving the defense of our servers and internal network. It helps us to make sure our customers' information and practices are secure when using our company.

The most valuable feature of this solution is the centralization of device control. This helps to ensure that transactions between us and other companies are all secure. After we installed the firewalls we get reports for a safety check on a daily basis. Executive reports, custom reports, and penetration testing reports are all very valuable.

While I think it's a good product right now and does everything we need it to, everything has some room for improvement. I'm sure Cisco would definitely be looking for ways that they can make its product better. My suggestion would be for Cisco to add third-party devices to the management family. Third-party integration would allow more flexibility and I think that would be a feature that would satisfy the business needs of other potential clients today. Some companies may want flexibility in the products they choose and others may already have legacy equipment that they are not ready to get rid of.

So far we find the solution to be quite stable. We do not experience interruptions and down-time.

Scalability is pretty good for a company. We do not have immediate plans to scale much, though we probably will in the future. We work with three firewalls currently. One external firewall and two for the circuits. We have about 800 employees using the system across our organization and scaling from here will be incremental. When we need to we are confident we can scale easily. For example, firewall configuration in the cloud seems like a good idea, so we may take advantage of that — though that may be flexibility rather than scalability.

The customer service is helping us out and giving us great support when we need it. The Cisco team is helpful and knowledgeable when we put in queries or tickets. They consistently respond very fast to our issues and that helps us maintain productivity.

This product was the first firewall security manager that we installed at our organization, and we didn't really consider anything else because we were already very dedicated to Cisco products.

The product was easy to implement. We are using the Cisco Defense Orchestrator on-prem solution. It only took about two weeks to have it on board. I'm not the one in charge of security as we have a team for security. The team is happy with the solution and doing well with it.

To implement the product originally we used a consultant from outside our company. It was 
SIGMA IT. They had a small team of two come to do the deployment. We keep a security team of three to monitor and maintain the system.

We do experience a return on investment in time savings, security and device management. It would be hard to quantify.

As I'm in higher management, I was involved in the product selection but not the pricing negotiations. Security and finance officers would know more about the pricing.

Because of our environment, Cisco was the only vendor that we looked into. The product did what we needed it to, so we went with it.

Cisco Defense Orchestrator is a very great solution to centralizing device management and security. I would want to give it a nine out of ten. It is not a ten because everything can be improved — such as the integration of third-party options, as I mentioned.

As far as advice for those considering this solution, it will save a lot of time. It actually saves our organization about 40% or 60% of the time we used to take to do things manually. That is about three days of labor a week. Now those resources can be used in different and better ways to benefit productivity and the organization.

We have obviously also realized security improvements.

My primary use case was just to see what the solution is about. I'm a system engineer and a Cisco partner. I was using the trial to see what it can do.

I rolled it out in my home lab. I have a Cisco ASA firewall so I used it to push configurations to my firewall. I used the Secure Device Connector as a virtual appliance, so I rolled it out like a production environment.

It could improve things when I need to create an object and to create a new policy. Instead of logging into several devices, one at a time, I could push the policy at one time and mitigate, let's say, vulnerability. Instead of taking three hours or two days, I could do it in 30 minutes. It would save time.

It could improve visibility. When I try to push a configuration tool to my firewall locally - instead of doing it through Defense Orchestrator - I can see through the Defense Orchestrator that configuration on the firewall doesn't match. In that way, it can provide better visibility for a security administrator. He can see that there have been changes on this firewall and determine if they are permitted changes.

In terms of the management of firewalls or firewall builds, it is possible to do upgrades from Defense Orchestrator. I could also push new certificates and that would help because I wouldn't have to go to each firewall or each device to deploy a new certificate or upgrade. I could do it all from a single pane of glass.

Its support for ASA, FTD, and Meraki MX devices could potentially free up staff to do other work, although I have not tried the FTD or the MX.

The most valuable feature is that you can push one policy or one rule out to several devices at a time. That's pretty neat.

If I make a change locally to the firewall, CDO gives an alarm or an error message and says there's a change in compliance: "The firewall has this configuration but the last time it was compiled it had that configuration." That view of new changes versus the old could be better. Which one is the new configuration? Which one is the old one? I had trouble seeing which configuration of the two which CDO showed me was the one that was actually running. I had to log in manually, locally on the firewall, to check which version, which configuration, was actually running. I couldn't see it in CDO.

The stability seems fine. I didn't experience any outages.

The tech support was great.

I'm using Cisco ISE, and I use Firewall Device Manager, and FireSIGHT Manager Center. I haven't worked with Defense Orchestrator in-depth as I have been with the FireSIGHT Manager Center (aka FirePOWER Manager Center) but what I can see and what I have experienced is that Defense Orchestrator is better built than FirePOWER Manager Center.

There are a lot of things you can't do with the FireSIGHT Manager Center. You have to have FirePOWER Management Center to get all the features. You install the FirePOWER device manager on the device to get rid of FirePOWER Management Center, but some of the features aren't available in the Firepower device manager if you don't have the FirePOWER Management Center. That's not good.

Now there is Adaptive Security Device Manager (ASDM). If we compare these two, Defense Orchestrator is much better because you can handle many devices at once.

I had a problem. I couldn't deploy the Secure Device Connector. I tried to deploy it in a VMware environment and I had some issues. I needed help from Cisco tech. I also had an issue deploying the on-prem virtual appliance. I had a Cisco guy helping me and he solved it for me.

If I didn't have those issues, it would have taken one hour, but because of the issue it took me three days. It took three days because I had to wait for a technician to become available. When the technician was available, we solved it in two to three hours. That was okay.

But I have tried many of Cisco's products and, normally, it's pretty straightforward to deploy their products or services.

Once it was up and running, I could see value from it straight away, in the first minute. I saw that I could push policies from the cloud. I could push certificates, I could push upgrades. I could push a command line. I could do anything. The value was not hard to see.

For one customer I have in mind, I think it could save up them eight to ten hours per week.

I tried to see what the pricing is. What I could see it is that it is about a $100 per year for the ASA 5506 firewall, and from there it keeps going up if you have a bigger box. For example, the 5516 is $200 to $300 per year. It can sound like a lot but I see the potential it has to free up many hours of technician time. So the pricing is okay.

It's worth it to dive in. If you have an environment with several firewalls, more than five, I would recommend just doing it.

The biggest lesson I've learned from using it is that you can configure multiple devices at once.

In terms of its security features for storing firewall configurations in the cloud, I'm not bothered by it. I don't see that as a security issue because I believe that Cisco is protecting it. I'm generally not against the cloud. It's good that we can do more and more from a single pane of glass, like Cisco Meraki, Cisco Defense Orchestrator, DNA Center, and so on. They should keep going in that direction. I think it's good.

I didn't try that many features but I can see that it has a VPN feature. I would like to try some of these things, but I only have one firewall. It's difficult to do everything with one firewall. I would like to test out the VPN functionality and how it can save time in troubleshooting. I would also like to test the ease of creating new VPNs between firewalls.

I would rate CDO at ten out of ten. It's a nice product and that's taking into account my experience with other products.