Cisco Defense Orchestrator Reviews

We manage all ASA devices, from versions 5506 to 5516, through CDO. 

When we are doing updates for security reasons, every six months we review certain companies. Before CDO, we had to spend hours and hours to update ten devices. Now, with one simple click, we select the devices and set it to update on a given day, and save different the configurations. It's pretty simple and a great feature for us. Whenever we have found any problems in the devices and we want to create a new policy that applies to ten or 20 companies, we select the devices and we send the same commands to all those devices at once.

In terms of auditing, CDO has the option to review all the logs and if something is modified we have control of that. We know what time it was modified. There is a history on it so we can go and check that. As for visibility, with CDO we can see any changes that were made. If there is a vulnerability from one device, we can go and fix it in different devices at once. It's not just one device. We can work and try to prevent that specific problem from hampering the rest of the devices.

The solution's support for ASA, FTD, and Meraki MX devices helps free up staff time for other work.

The most valuable feature is the restore history. For any changes that you have backed up, if something goes wrong, then the system will automatically prevent the system from crashing or from loss of the client's connection. When you start programming any ASA or device connected to CDO, if you make a mistake, you have the option to restore the previous configuration. You will not lose connection with the device and the client will continue working without problems.

We use a lot of image upgrades. We take some 20 devices and then we update everything at once, including the policies. We apply policies for groups. For certain groups, like anti-viruses, we send out policies and apply them to every single device. It's really easy and simple.

The solution’s security features for storing firewall configurations in the cloud are pretty secure. I don't see any problems with it. They have two-factor authentication. From what I see, it's working properly. I don't feel there is any gap there.

CDO doesn't have a report, an official report that I can check daily. It has another module called FTD, but it doesn't have that specifically for ASA. In the reporting, there are a lot of things that aren't there. There is also room for improvement in the daily monitoring.

I have been using it for two to three years.

It's really stable, I don't see any glitches at this point. Once one is connected, it's just a matter of doing maintenance.

If a person has knowledge of how switches and routers work, and that could be a Cisco technician, that would be enough to for scalability using this platform.

I don't see any limitations on the number of firewalls it can handle. We have, on average, about 100 running on it. We have five users.

In terms of features, we're not using the VPN section or the templates so there's room to grow and keep learning the platform.

On a scale of one to ten, tech support would be about a seven.

We definitely have to escalate the issues. The first tier is always complicated. We, ourselves, are basically second-tier here, so the guys don't often call support. We try to resolve problems here. I do recall that about eight months that ago we had a situation, a specific problem, but it was something out scope so the system was not supporting those devices. It took about a week to resolve it because we could never get the right person. We tried to explain what's going on and it was a little confusing. It had to do with CDO but not everybody at Cisco has knowledge of CDO.

We have something different, but at this point we are mostly using CDO. We use Cyberhub only to monitor vulnerabilities. That's all it does. With CDO we try to do SSH and all the language. But CDO doesn't have vulnerability monitors. That is something that they definitely need to improve on.

The initial setup was really straightforward. If the person setting this up has knowledge of firewalls and switches, it's pretty simple. It took about two hours for us to deploy. It depends on the company. It could be a company has only five ASAs, and that could take 20 minutes to one hour. All companies are different, so it depends on how many ASAs they have.

In terms of an implementation strategy, we used SSH first and then did the connections.

Deployment of the whole system can be done by one person. And similarly, it takes one person to maintain it.

Once we had CDO up and running, after first implementing it, it took about six months to see value from the solution.

The ROI comes from the fact that, before CDO we had different teams in charge of different companies. They were responsible for updates, checking for vulnerabilities, making sure the devices follow protocols and have all the policies necessary in those companies. For the most part, the companies share the same policies. We try to leave everything standard. We had teams in charge of that, but now we have one person who is in charge of it. That is saving a lot of money for our company and time for the clients. CDO has made our security team more productive. We're saving all that time. Again, it's just one person who can now take care of that.

We did a few tests but I don't remember the names of the other products. What made CDO stand out is that you can do different devices at once. The other companies offered only one system. There was no way we could do updates on all the devices. That's really the strong point of CDO.

My advice is to try to gain more knowledge of SSH. CDO needs to improve monitoring and reporting.

Every six months, we go in deep. We check the devices to make sure everything is working correctly. We have another system, not related to CDO, which is alerting us if something is not working correctly. It runs daily. For example, if we find any ASAs with vulnerabilities, we take the information from that third-party software and go to CDO and again do the update for all the devices that are affected.

We're not using CDO for firewall builds or daily management of existing files. It is not as strong in that.

Overall, I would rate the solution at seven out of ten. 

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.

What I take primarily take advantage of are ASA upgrades. I also use it, sometimes, to see other backups, because each time there's a configuration change, it creates a backup for it. I also check out conflicts or unused rules. But I mostly use it for ASA, for management. 

Ideally, I like CDO to be a central management tool for all my firewalls. It is not there completely, in my opinion, but I think it's going in that direction. I still do some stuff on my ASA, but I haven't done it globally. If I do any global changes, they are through my FMC. But adding or removal of single rules is done through CDO.

I like the upgrade feature. That is pretty valuable to me because I have dual ASAs and when I go through CDO it does it for me pretty well. It's all done in the back-end and I don't really have to be involved. I just initiate, pick the image, and I pick when I want it done and it just does it, whether I have a single ASA or have a dual ASA. If I have a dual ASA and the primary is not active, the secondary wants me to make the primary active. It tells me that, but it's not a big deal.

I like the solution’s ability to make bulk changes across image upgrades.

For configuration changes, every time there's a change in the firewall, it records it in the cloud. If not, I have to go there and manually make sure it is sent. But it does have a configuration in the cloud.

In terms of firewall builds and daily management of existing firewalls, I use it for a rule-change or to add a rule to a single firewall.

The main thing that would useful for us would the logging and monitoring. I have to check it out, to get the beta, because I don't have access to them.

I know they recently added Meraki to it and I tried to join it and it didn't work. I didn't create a support case for it to figure out why. It says there is an onboarding error on the Meraki devices.

Also, I wanted CDO to be a central place so where I could do everything but right now I don't think that's possible. I really don't want to go back and forth between this and FMC. Maybe the logging portion, when I look at it, will give me some similarities.

Finally, right now, it supports VPN but it's only site-to-site. It would help if had remote-access VPN.

It's been stable. There have been a lot of upgrades since the beginning and a lot of features added, which is good. I've been testing those out. I don't recall having major issues.

The scalability is pretty good, with all the features that keep getting added. They're constantly improving it.

We're a fairly small company. We have over six sites, and some of them have multiple ASAs. I probably have about 14 or 15 ASAs on it. There are three guys managing the ASAs. We have about 700 users globally. The biggest site is in San Jose, then Fort Wayne, then Bangalor. The other sites are small sites. And, of course, we have a couple of them in our data center as well.

Tech support is pretty good. Since day one I have received support. Anytime I have a question, I still reach out to my product manager and he and his teammates help me out.

I may have opened a TAC case once or twice and that was because of something that happened when adding a user. One thing I would like to see is more control when it comes to user setup. I don't have that. I cannot go ahead and set up a user. I have to open a case. It's time-consuming. Granted, it was fast, but I still had to send an email, wait, and go back and forth. That's something that I'd like to see changed. I don't know what the reason behind it is.

I didn't use anything prior to CDO. I went to CDO for better management, central management. CDO was suggested to me and they gave me a free trial for a couple of devices. We eventually signed the agreement for security, which is included.

The way we have it, we have a server here and that server talks to the cloud. I got help from the Cisco product manager and he set it up for me. It was easy. Since then, I really haven't done anything. I may have upgraded once, but then again they were involved because I really don't have access to it. It's just a server that gets the information and then talks to the cloud.

The initial setup took less than an hour. Then I added a couple of ASAs and the rest of them. The product manager walked me through what I could do with it. It was all WebEx-based and not much effort.

If there's a new application or a new device out, Cisco contacts me and helps me to set it up and then walks me through, to show me the features, etc.

The benefit that I really like, which has made my job easier, is the update portion. It saves time.

After our free trial was done we got a subscription for three years and it was under $3,000 or so. It's part of the EA we already paid for, so I don't know what it would be if it was a la carte. I'm guessing it's probably less expensive than other tools.

I didn't assess any other options at the time but I'm familiar with a couple of them. I tried Tufin, but that's just an auditing tool. 

Another one was FireMon, but I haven't tested it out. That may be pricey, although I'm not sure. It seemed like it was an overlay on the ASAs, on the firewalls, so you could manage everything. What you could do in ASA you could do there. And the monitoring was pretty good too. But that was a few years back. I haven't looked at it recently. That tool was much better than CDO, when I think back.

It's fairly straightforward and I didn't run into any hiccups where I would say, "Hey, be aware that or be aware of this." The only advice I'd give is that if the device is out of sync, be aware of which configuration you want to keep: the one on your outer-band, that you did on the ASA, or the one that you did here. That's something to be aware of. Other than that, I think it's pretty straightforward.

The support for ASA makes management somewhat easier, but I don't have a basic template for all our sites because each site is different. I would only use a template if I were to bring on a new site, but I haven't done that yet. Then the next thing I am going to do is buy FTDs, so I'll have to add them, but that is also supported. That was announced at Cisco Live. So I'll have to play with that. But it does help, especially if you have duplicate entries.

As for other bulk changes, such as policy management, I have FMC. So usually, if I want to block something, I'll just do it through FMC. I was told when I started using it - and I don't know if this is still the case - if I use FMC, leave everything there. Don't integrate, don't try to do the management through CDO. I don't know how it is right now, if I can get rid of the FMC. I doubt it. So for policy changes, I usually do them through FMC. I have a global rule that that applies to all my firewalls, so that's easier for me. I haven't done it through CDO. I've done it on a single ASA, but not for all of them.

CDO hasn't affected the visibility of security in my organization. I use FMC more. I do use CDO for upgrades and some cleanup stuff, but I haven't used it where it has affected visibility.

The monitoring will probably help me, the event logging, etc. I think there's a better version out now which has that. I'd like to use that. If the logging really takes off and it's more advanced than what I get currently, I would probably utilize CDO more, because currently, the monitoring is limited. Event-logging exists but I have to request a beta for it. Before that, there was not much there, so I wasn't going to utilize it. I will utilize it more often if the logging or monitoring is enabled.

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.

We have around 30 firewalls and we use it to centrally manage the firewalls. We use it to have one panel where we can log in and see all the firewall rules, all the objects, where they're deployed, where they duplicate across firewalls. We use it to maintain the configuration. We also use it to perform centrally managed updates. We can update ASDM and ASA images on the firewalls.

We have a connector on-premise and we have that linked to all of our ASAs internally. It runs within their cloud environment, which I believe is AWS. It talks back to a cloud connector on-premise which, in turn, talks to all of our firewalls to manage them centrally.

We use it daily for firewall administration and change management, and we use it as and when required to do all the software and firmware upgrades.

It is saving us at least a week's worth of work because we can log in and instantly see what version all the ASAs are at and which ones need to be upgraded. If we have a vulnerability and we need to patch that vulnerability, we can log in and see which ASAs are at which version, and then we can apply that patch. It's saving us a lot of time because we're not going around to all the ASAs and looking at the versions.

The other thing it's helped us identify is where we've got shadow rules and duplicated objects which aren't being used. Where before, we probably wouldn't have detected those objects and the shadow rules - where there's a rule that conflicts with another rule we wouldn't necessarily have picked that up. Now, CDO highlights that for us. It makes us have a more consistent rule set. It makes our configuration better because we haven't got rules in there that are not doing anything or are duplicated.

Regarding auditing or the visibility into security, it gives me a full change-log of all the changes that are going on across all of the ASAs, and I wouldn't have had that before, necessarily. It gives me that and, from a security point of view, obviously it gives me rules that are shadowed, as I mentioned, which improves security because we do not have duplicate rules everywhere.

Defense Orchestrator has made my network team more productive, since it's the network team which manages it. I can't talk about security team because that's a separate team which doesn't do any management of the solution.

Also, the support for ASA helps us to maintain a consistent approach.

The most valuable feature is being able to do centralized upgrades on the ASAs. We can literally go in and tick a bunch of ASAs - we have them grouped within their business uses. We can select all of those ASAs, and say, "Upgrade these ASAs at this scheduled time." It will copy down the ASA image, ASDM image, and then do the upgrade and failovers, and then put it all back into service as required at a scheduled time. It automates that process for us.

We use the command-line tool quite a lot to push out bulk commands and changes to ASAs. That saves us a considerable amount of time. We have firewalls that are used for guest WiFi access. We try and maintain them as a standard policy. We can do that centrally and push that out.

As for its security features around storing our firewall configurations in the cloud, I take it that it's secure, from conversations I had at the time. It's all encrypted on REST and in transit. That goes through our security team, who respond with that information. It doesn't concern me particularly because I know it's all encrypted. We also use two-factor authentication to be able to log in to the solution as well. Obviously, you need the user name and password, and you need the multifactor authentication key. That's built-in, we use the one that's provided by CDO, which is OneProtect. That works for rules.

Everybody has their own login and I've got a full, change-management log view, so I can see who's done what changes. The other advantage we get from that is, if somebody makes a change and there happens to be an out-of-hours issue, the users can log back in and they can look at the changes that were made on that firewall, and they can roll it back by clicking a button.

There could be some slight improvements to navigation. In some of the navigation you've got to go back to be able to get into where you need to be once you've made a change. If I make a change, I've then got to go back to submit and send the change.

The stability has been very good. We've had no issues with stability.

It has performed flawlessly in terms of scalability. It has dealt with everything that we've put out there. I have the feeling that it would expand beyond the 30 firewalls we currently have. It does what we need to do with no problems.

Tech support has been very good. They've always answered the questions very quickly and resolved the issues very quickly. The last issue they did for me was a new user account.

The CDO team has been really good with us. They've been really helpful and they're always open to new ideas and improvements to the application. It's very good because, with a company the size of Cisco, quite often you don't get to give that type of feedback. But I've had quite a lot of conversations with Derek around bits that could be improved or bits that are not quite there but need to be. They've taken them away and worked on them and then you start seeing all the new features coming through.

This is the first solution of its kind in our organization. Before that, I was managing everything as a point solution. We came to the realization that we needed something like CDO when we were doing firewall upgrades. It was taking us a couple of weeks to go through all of our firewalls and upgrade them and reboot them. It was clear that we needed a centralized solution that would do this for us.

I originally saw Defense Orchestrator at Cisco Live. It was Derek who did the demonstration, and it was clear that that was the right solution for us. Also, it was at the right price point.

The initial setup was very straightforward. To get the system up and running, including installing the connector, took us about half a day. Getting all the firewalls onboarded and into the system was done over a period of two or three weeks, but that was very quick. We were onboarding firewalls within five minutes.

We had a roll-out plan within the project to roll out so many firewalls per week. We had set up that staged rollout prior to deploying. To be honest, we could've onboarded them all in one day. The only reason we did it that way was to limit the amount of change.

Within a couple of months, we started to see improvements in change management and configuration management in the ASA.

It was all in-house, with support from team if needed. I did all the install and deployment myself. 

It's maintained by my team. But, on a daily basis, it needs very little maintenance. In fact, we don't even go into it every day. There are eight or nine users of the solution in our company. They are operational users, and they would be maintaining it as required.

I don't measure ROI, but for me, the return of investment would be the amount of time saved, versus doing it manually. The upgrades of the ASAs would be where the biggest time savings are for us.

It's around £500 per unit for a three-year license. We have 30 units but because we require availability, we only need one license per unit. With a high-availability pair, you only need one license for the pair. There were no other costs, other than resource time to install it.

We didn't evaluate any other options.

For me, it was a very straightforward setup. It worked as described on the box. There are a few little issues that we've had. For example, when you create an object, you can't set a description on the object. But there are feature requests that are coming down the line as the product evolves.

So far, the biggest things we've learned from it is about the rules we've got in place that are duplicated or which shadow another rule within the firewalls. That's something which would've been very difficult to identify.

In terms of it simplifying security policy management across an extended network, we're not using a single policy across the firewalls. Excluding our guest WiFi firewall, all of our other firewalls have different configurations because of the way they work.

As far as its effect on firewall builds and daily management of existing firewalls go, at the moment, we're not using the templates, but we are going to move towards the templates. At that point, it will make our builds quicker because we will have a templated model where we just click and deploy from that template. It will make that faster and more consistent. We've been using it for about a year. We've got some projects lined up for next year where we will take some of those features and start to use them a lot.

In the long term, we'd like to get to standardized policies, but because we've implemented it into existing solutions, there's obviously a lot of rework needed to get the policy standardized.

On a scale from one to ten, I would rate CDO as an eight. The thing that comes to mind with that rating is the centralized view of everything in one place. I've got a centralized view and I can make all the changes, from one central console, to any of the firewalls I need to.

To get it to a ten, for me, it would need those little bits there around descriptions on objects. Also, in the firewall, by default, there are some system rules. They don't work in CDO, so you have to create custom rules instead of using the system rules so that CDO knows as well. It needs some little improvements like that.

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.

Most of the time we use it for the simplicity, for streamlining security policy management. We have other layers of stuff that we use with Cisco, from an integrated standpoint. Defense Orchestrator brings everything together.

For one particular client, we had almost a 20 percent remediation on some of their equipment as a result of all kinds of attacks from the desktop department. We got them down to a zero percent remediation. In other words, in retrospect, their data center and their desktop division went to zero percent when we deployed everything along with Defense Orchestrator. It was a huge success for the client. Defense Orchestrator was instrumental in that. In terms of visibility and getting everybody involved, it was simple, scalable, and saved them tons of time, which in turn saved them money. Sadly enough, they didn't need as many people any longer in certain departments. They were able to move them over, get them training and move them out. They got more projects done and had to do less firefighting. The biggest thing was that it allowed them to dial in, quickly, on what the threat landscape was for their architecture.

When it comes to making bulk changes across common tasks, like policy management and image upgrades, one of the biggest complaints that I had from a lot of network engineers, was that everything was GUI, that Cisco had gone to GUI. But they can do bulk changes on the CLI. That was a big win for them, being able to do that across all the ASAs without having to log into every single ASA and make changes. They can do a lot of bulk changes on the fly. It's a huge time-saver. The biggest benefit is obviously from the security standpoint, but at the C-level what they see are the cost savings. It's less billable time and fewer resources.

One of the biggest problems we were able to solve was due to its ability to use third-party apps, using a RESTful API and being able to integrate Splunk - things the clients already had in place - without any issues. That part was very easy. 

There's a lot of built-in stuff. You pull logs on the fly and you can troubleshoot problems when they come up, as well. That's been really helpful. It has solved clients pain points. 

When there are issues when they roll out configs, CDO allows us to do rollbacks really easily on a bulk level. That works really well too. It keeps track of "good configs."

In terms of simplifying security policy management across an extended network, if a lot of people are working on the same stuff, then the architecture has been broken up to different areas. Now, from a management standpoint, it is no longer a nightmare when I go in there and try to determine what is going on in the network. I have one "throat to choke." When I login, I have visibility into what is going on over the entire infrastructure. In case somebody left the door open, I have that visibility now.

Its effect on firewall builds and daily management of firewalls is that it's super-simple on new deployments. We haven't done any really large ones, but I've read some deployments where people have done thousands of ASAs with one massive import and there wasn't any downtime with respect to changing out equipment which was no longer under Smart Net.

Also, when we're looking at policies, it identifies the shadow rules. It notifies us about anything that will supersede other rules.

The simplicity, efficiency, and effectiveness of it are valuable.

There are a lot of templates that are already built-in. They give you quick-to-create and quick-to-apply policies that are typically a little more complicated for people.

Some of the issues we've had aren't really a CDO problem. For example, we had some MX devices that were blocking Windows Update from happening. We found out it was a Meraki issue, but it would have been nice if it had been flagged for us: "Hey, these updates are failing because the MX is blocking it." It wasn't a huge problem, but there was a loss of our time as well as the fact that the updates didn't get pushed out. You could look at that as a security issue but, at the same time, when updates won't run for any reason on certain machines, you freak out a little bit.

We thought it was a licensing issue with Microsoft or it could have been Dell EMC. But we were wasting time making all these phone calls and having people remotely troubleshoot it. The troubleshooters were saying, "Man, this looks like a network issue." They tethered a phone and joined it to the wireless on the phone to see if it would update and, boom, it started working. The weird thing was that when we switched it back over to the network, the Meraki was letting it through at that point. It would have been nice if CDO had let us know that that was an issue.

There are probably some things that it could do as far as some of the analytics are concerned, things I know it would be capable of: "Hey, why are all these requests coming in? The reason is that a firmware update needs to happen on the Meraki. It's a known issue." That would be helpful.

We don't have a large window of time to look back on, we don't have years of experience, but so far the stability has been pretty darn good compared to anything we've ever had.

When it comes to scalability it's flexible, absolutely.

The largest network deployment that I've been involved with - we're not a very large company - had about 10 ASAs on the data center side and there were 29 other locations. There were less than 50, as far as the firewall devices go. At the largest deployment, the user count is somewhere a little over 1,000.

Scalability isn't an issue. We had some opportunities we didn't close, a university campus where the deployments were for about 15,000. We scoped it and scaled it out. The licensing gets a little different on some of the products when you go over 10,000 users. Sometimes the product line changes too in terms of design and scope.

When we had to use tech support on the first setup, it was more for asking questions because we got pretty good training prior.

There's a lot of different stuff, solutions which integrate into companies' ticketing systems. It depends on what your needs are. Even stand-alone, with FirePOWER, Umbrella, and AMP for Endpoints, there is Threat Grid - think CDO but on a very small scale. Prior to CDO, Cisco had, and they still have, Threat Grid. To me, Defense Orchestrator is a higher-scale evolution of Threat Grid. People wanted more, and that "more" was delivered with Defense Orchestrator. 

Threat Grid is like a small, short-line railroad; it handles a small area of traffic. In the metaphor it might take stuff off ships and put it on the back of 18-wheelers. CDO is more like a Class I railroad like Union Pacific or BNSF or Norfolk Southern. They're going to go all over the place, on a much larger scale. The strength and power that CDO has is huge. It's like comparing a lawnmower engine to a V12 from a Bentley or an Aston Martin.

There's a huge difference in cost between these solutions. With the smaller solutions there's lag, even if it's not huge. What you're getting for almost no cost is a huge, valuable piece. But it's not going to be the same type of visibility and logging speed that you're going to get with CDO.

On our end, the initial setup was pretty straightforward. We did receive some training along the way. I had done some test deployments, which I would tell anybody to do. There are certain things you can do inside of Cisco's dCloud to prepare you for deployments. But overall, it's efficient, simple, and there's the visibility on the security side. Deployment is fast. As a security person, I love the visibility and the ease of use when doing my upgrades.

In terms of implementation strategy, even before making the sell, we start from that standpoint. I don't want to say we're in the tank for Cisco, but it's what we have bought into. A lot of our engineers have training in it and they get ongoing training. Maybe it would be different if Fortinet gave us a ton of more training on their stuff.

There's a community that we're connected with, so when there are issues we typically hear about them in the communities beforehand. We know limitations going into projects and already have a good idea, a vision, of what direction we're going to go, so we can start planning properly. Cisco does a good job of training us in that process: When we model and design everything, how it's going to be set up; and once everything is deployed, how to analyze, how to remediate, how to get visibility into everything.

The time to deploy depends on the size of the deployment. In my experience, the longest part of the process is getting everything built and approved in CCW (Cisco Commerce Workspace). From a deployment standpoint, it's pretty easy at our end. We get the equipment in place, we stage the gear, we have all the existing stuff in place from the original infrastructure. The longest we've taken is about a month, once we have the gear in place and all the configs lined out. Typically, we've done a lot of front-load work in the process. In general, from first meeting the client to completing the end-to-end process, we're in and out in 120 days.

Everybody has a different part that they play, including the people who are doing racking and stacking. For the size of deployment that we've been discussing, we typically need ten to 12 people. There can be some travel involved so sometimes we need resources elsewhere, depending on the scale of the client and how far they are spread out.

Once it's deployed, an example of maintenance requirements is a location with a 24-hour operation, three eight-hour shifts, meaning three people are monitoring it and it works fine. You might need a fourth if you include like a "float guy" for when people go on vacation or get sick.

Once up and running, we see value from it right away. The impact is immediate. The biggest problem I have now is that something that gets forgotten is how bad things were before the implementation. C-level people tend to forget that.

The biggest part of ROI is the improvement to the operations. Our clients with CDO are having fewer issues. Things are just not going down. People are more productive. I don't know if any of the organizations that I've been with have done a study, but from an IT ticketing standpoint, tickets are down to one-tenth of what they were. People are able to bring in new projects and think about new things. From a staff being overtaxed due to remediation, because so-and-so clicked on an email or there was an issue with some type of a compromise, now it's eerily quiet.

If I had to say anything negative it's the price point. Clients who can't invest in the complete package, it's a disservice to them because they don't have everything. They don't have as many layers. They don't have Defense Orchestrator. It shortchanges the product. Going back to old school theory, you broke up your infrastructure so you weren't tied into one architecture, but that's not necessarily the case anymore. Even if you have other hardware, with APIs, a lot of Cisco stuff and gear integrates very well, even with other devices.

I'm more on the engineering side, I'm not in CCW (Cisco Commerce Workspace) as much as the sales team and the account managers are. But I can tell you that it's not inexpensive. But to be honest, there are not a whole lot of products that give you all those features. There isn't an apples and oranges comparison. You can't compare a McLaren or a Ferrari or a Lamborghini to a Smart Car. There are different purposes and different requirements. Typically, you're buying these devices because you want performance and you're willing to go the extra mile for whatever it is you're trying to protect, whatever your crown jewels are. Whereas with the other devices, in my opinion, people are just trying to save money and do a "best-effort" against some of these things.

If it were me and it was my company, and my main goal was to protect my infrastructure, then I'd be using Cisco devices.

There are all kinds of different costs and now there is the advent of Cisco DNA. Cisco DNA is where they have that service-as-a-service type of billing. There's a monthly cost that's tied in to give you some additional analytics and visibility into what's going on in your environment. It's like taking a little piece of Meraki, all the cloud analytics that are coming in from their cloud-control devices. It's that middle-of-the-road step from them with Catalyst switches. I haven't seen anything on the Fabric side, from a storage standpoint, but I think it's just a matter of time. You're going to be getting data on a different layer, analytics on everything.

As an engineer, I would say that if you can afford it, you will not be sorry that you invested in it. There's no question of whether it's going to deliver. The question is more from a value standpoint, the size of your business. If you're a national company with multiple locations across the US, CDO is the direction you need to be going in. If you're a small company, 50 people or less, you can probably get by using Threat Grid. Medium-size businesses will probably also be okay with using something like that. From an outside-of-Cisco vantage point, for small and medium-size business, Fortinet does a pretty decent job. But when you start getting into large-scale enterprise, there isn't anything right now that's doing the things that CDO is doing to enable you to integrate.

Cisco still has Tetration. To me, they are giving me a taste of Tetration, which is very high-scale leveraging. Think CDO but well beyond that. It's a multi-million-dollar device, a 42U-rack equipment storage device which is going to manage any and all network transactions happening on any of my networks. Tetration is for Exxon or Apple or Google-type visibility into the infrastructure. CDO gives me a taste of that without spending millions of dollars.

The biggest lesson I've learned from using it is that it sure is nice when people buy it. It just makes our job a lot easier. If you ask me to get a job done, with CDO you're giving me all of the components that I need to make everything you're asking me to do a success.

When it comes to its security features around storing firewall configurations in the cloud, there are things about that I probably don't fully understand, from a security standpoint. We've been doing that kind of thing for a long time, so I'm confident in it. But I'm a security guy, so I don't really trust anything. But that's where everything's going. It's good to know that I've got backups. "Cloud" is such an overused word too. As long as you thought through the security of everything, it's just some other place. Your attack spectrum is everywhere nowadays. To me, the biggest security problem is the human element. When you start looking at it like that, the fact that it's stored in the cloud is not really that big a deal.

It's just a different way of doing business. These are things that traditionally, ten years ago, even five years ago, people weren't comfortable doing. Cisco was kind of late to the party in a lot of these things, but over the last three years - the acquisitions, the overall way they've attacked everything - they're doing the best job of bringing everything in.

There are all the products which they have through acquisition, such as the OpenDNS acquisition for Umbrella, and CloudLock is going to be integrated into that as well; the next-gen firewall of FirePOWER and that's the evolution going into the FTD. They made a lot of improvements with ISE, even though there were some complexities that caused a lot of my higher-end clients to frown. It seems like they've righted the ship on all those things. So, there's a lot of good things happening. There are more things that I'm not really talking about, such as the evolution of even their switches, going with the FTD architecture of using Lina - Linux ASA - to do a lot of those pieces. One thing that they still have to rethink is how they're going to integrate a lot of the stuff that's on the ASA alone with AnyConnect, into FTD and those types of devices. We've been very pleased with the overall experience.

In terms of the solution’s support for ASA, FTD, and Meraki MX devices, we have tons of clients who use all these devices. Since 2007, we've done over 2,000 medical facilities in the southeast Texas market, just using Cisco ASA firewalls. But in many cases, these places aren't large enough to use Defense Orchestrator. Now, if we took over complete management, I see how we could integrate CDO from an industry standpoint because a lot of these places are very similar. They use the same EMR practice management. They operate the same way on their infrastructure, have the same type of buildings. In many cases they're in the same building, a medical center. But they don't operate that way. They have independent practice managers. They're typically somewhere between 25 to 60 users. It would be nice to be able to have something like that. Maybe somebody really forward-thinking in my organization could possibly sell that idea, although I'm sure our legal department would tell us it's a bad idea.

When you start dealing with HIPAA, there's a whole lot more to it than just IT. In managing that side of things, we do a lot of compliance and testing. We give them a HIPAA compliance report from an IT standpoint. And a lot of that is difficult because it has to be answered by someone within the organization who is familiar with their processes; for example, how they're turning their screen in an encounter with a patient. To have something like Defense Orchestrator, where I could manage hundreds of clients - their ASA or their Meraki MX or FTD - that would be huge.

As for increasing our usage of CDO, we don't have it in our internal infrastructure yet, due to cost and the fact that our needs aren't that great. If we start doing some private cloud hosting or the like, I could see us utilizing it. That's one of our goals. We've got four data center locations where we're planning on rolling out Cisco UCS with some redundancy and failover. We're looking at CDO as our main point of visibility.

I would rate Defense Orchestrator a ten. The only caveat I have for anybody trying to decide on it would be in terms of the budget and does it make sense for you. Do you need a 10,000-pound hammer to drive it home? We have a wide variety of clients in terms of size. Most people are somewhere in the middle-to-upper echelon with us. Others, and this is going to sound ugly, can't afford to use our services, because they're just looking for break-fix IT. They're still doing things the old-school way. Half of their data is compromised. They've been through several ransomware and malware attacks to the point where it has crippled their businesses. I don't know how those people operate.

It's difficult because the attack spectrum is in our backyard. As a security guy, with the things that are being done and that happen, I just don't know how people do it. That's especially true if they're using a static firewall or if they have in-house equipment and services opened up to the public. If they're using a static firewall and trying to do traditional things like port-forwarding, we see that. We walk in there and they're saying, "Everything's running really slowly." And they're completely compromised. We had somebody who couldn't place phone calls. Somehow, half their trunks had been compromised and were being used for a telemarketing service in Philippines. It's to the point where, if you're a fireman, you just let it burn. They need insurance at that point because they have massive problems.