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.

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.

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.