Cisco Security Cloud Control Reviews

Our primary use case for Cisco Defense Orchestrator is the automation of playbooks. We primarily use it for this purpose to streamline processes.

The most valuable feature is the automation, as it reduces user intervention and allows us to focus on other tasks. Since the system is automated, response times for resolving security issues are fast, providing quick prevention of threats and making us more secure against zero-day attacks.

Cisco Defense Orchestrator should be made more user-friendly overall. Currently, to use it effectively, one must be specific with the rule set that needs to be set up. 

Additionally, I suggest improving its integration with other third-party products, such as Fortinet, to simplify the setup process.

I have used the solution for only one year.

Cisco's technical support is good in general.

Positive

We evaluated Microsoft, but we chose Cisco since its feature set had more use cases for our environment.

The setup is around eight out of ten in terms of ease.

We evaluated Microsoft as an alternative.

Those who want to use Cisco Defense Orchestrator should build their own use case and see if it fits their environment. The most significant benefit for us is the response time because it automates our playbooks. 

I would rate the overall solution as eight out of ten.

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. 

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.

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.

Cisco Defense Orchestrator has useful guides for the steps that need to follow by users.

Cisco Defense Orchestrator can improve by providing more support for third-party security components.

I have been using Cisco Defense Orchestrator for approximately eight months.

The Cisco Defense Orchestrator technical support is excellent.

I work with a lot of clients, and the price or value of the Cisco Defense Orchestrator can vary from one client to another. If you have a lot of Cisco solutions, the price of the Cisco Defense Orchestrator is justified. Whereas if you have some security components from other vendors, such as Check Point or Palo Alto. This solution would be a pretty expensive proposition considering that they don't integrate with them well.

I rate Cisco Defense Orchestrator a seven out of ten

We are using this solution for filtering and blocking some websites. It's a firewall.

This is the main tool for network segmentation and intrusion prevention. It blocks malware and malicious activity.

The most valuable feature is the Intrusion prevention.

It's a stable solution, but it could always be improved.

They need to work on the user interface. It needs to be improved to make it more user-friendly.

I have been working with Cisco Defense Orchestrator for five years.

It's a stable solution.

Cisco Defense Orchestrator is scalable.

We have 1,000 users but we don't plan to increase our usage.

Technical support is good.

Previously, we were not using another solution. We have been using Cisco Defense Orchestrator from the beginning.

The initial setup is straightforward.

It can take up to five hours to deploy.

We have a team of five who are mainly engineers to maintain this solution.

If you compare to what is available on the market, they are in the same range with respect to pricing.

I would recommend this product to anyone who is interested in using it.

I would rate this solution an eight out of ten.

We provide consultation for all Cisco solutions. We give consultations to customers for buying a preventive solution like Cisco Email Security, Cisco IronPort, Cisco Security, Cisco Web Security. 

With Cisco Defense Orchestrator, we can manage the complete Cisco Security solution. It provides a simple and centralized way to manage all products. 

They can centralize all products and provide a correlation about an incident and the response.

They can also provide an on-premises solution. Currently, Cisco Defense Orchestrator is just for cloud deployments, not for on-premises deployments. Customers have to manage it on the cloud. We are based in Vietnam, and most of the customers here prefer to have on-premises deployments. Customers, especially from banking and government sectors, do not prefer to do anything on the cloud. Some of the small enterprises use the cloud.

I have been working with this solution for around four years.

The stability depends upon the Cisco cloud. 

Because it's on the cloud, Cisco Defense Orchestrator can scale up very well.

They have good technical support. They're very good, and they can very well help a customer with implementation.

Cisco Defense Orchestrator is on the cloud. It's really fast to deploy.

I would recommend Cisco Defense Orchestrator. Cisco is a very good company and has a reputation. They can provide a comprehensive solution to customers. They have a lot of defense solutions for the network and endpoint security.

Cisco buys a lot of solutions and has a lot of acquisitions. When they combine them into one central management, the setup can be quite complex.

I would rate Cisco Defense Orchestrator an eight 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.