Cyber Security Pre-Sales Consultant at a tech services company with 51-200 employees
Consultant
2020-10-13T07:21:36Z
Oct 13, 2020
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.
Product Consultant at a tech services company with 501-1,000 employees
Real User
2020-08-26T07:13:27Z
Aug 26, 2020
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.
Network Security Engineer at a manufacturing company with 10,001+ employees
Real User
2019-08-13T06:46:00Z
Aug 13, 2019
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.
Learn what your peers think about Cisco Defense Orchestrator. Get advice and tips from experienced pros sharing their opinions. Updated: November 2024.
Network Engineer at a healthcare company with 10,001+ employees
Real User
2019-08-13T06:45:00Z
Aug 13, 2019
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.
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.
Network and Security Specialist at CONNECTED TECHNOLOGY
Real User
2019-08-07T06:15:00Z
Aug 7, 2019
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.
While I think it's a good product right now and does everything we need it to, everything has some room for improvement. I'm sure Cisco would definitely be looking for ways that they can make its product better. My suggestion would be for Cisco to add third-party devices to the management family. Third-party integration would allow more flexibility and I think that would be a feature that would satisfy the business needs of other potential clients today. Some companies may want flexibility in the products they choose and others may already have legacy equipment that they are not ready to get rid of.
Network and Data Centre Platform Manager at a manufacturing company with 1,001-5,000 employees
Real User
2019-07-24T20:05:00Z
Jul 24, 2019
There could be some slight improvements to navigation. In some of the navigation you've got to go back to be able to get into where you need to be once you've made a change. If I make a change, I've then got to go back to submit and send the change.
Systems Architect at a university with 1,001-5,000 employees
MSP
2019-07-24T20:01:00Z
Jul 24, 2019
In terms of bulk changes, specifically for accessing policies, there is one limitation which is especially annoying and at least one bug which hasn't been fixed. In terms of bulk changes for image upgrades, that's nice, but I have found that it's not really useful in most cases, because of limitations of the product. I've found dozens of bugs over the year we've been using it. The more I use it for different things, the more problems I find. Some of them get resolved pretty quickly. For others, I have to argue for a long time about why they are problematic and should be fixed. For some, they decide they're not going to fix them because they don't care. By far, most of the problems have to do with the user interface. A lot of thought and work has gone into the back-end component to make the product do what it's intended to do, but the way it is presented for use hasn't gotten nearly as much thought to make it smart and bug-free. I wouldn't say that it's not user-friendly, but there are a lot of bugs or features that are not very adequate. It's kind of user-friendly but there are a number of display issues or ways of doing things that are not as comprehensive; they're more limited compared to what you can do on your own with other products. In terms of auditing, we're worse off. It took away some of the capabilities that we had without the product because of a decision Cisco made on how to handle the history of changes. That's one example of a specific issue where we asked them to do things more intelligently, but they haven't. They kind-of agreed, but they haven't done it yet, and it's not going to be possible to make up for the past year of not having that in place. So auditing is definitely.
If I make a change locally to the firewall, CDO gives an alarm or an error message and says there's a change in compliance: "The firewall has this configuration but the last time it was compiled it had that configuration." That view of new changes versus the old could be better. Which one is the new configuration? Which one is the old one? I had trouble seeing which configuration of the two which CDO showed me was the one that was actually running. I had to log in manually, locally on the firewall, to check which version, which configuration, was actually running. I couldn't see it in CDO.
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.
Cisco Defense Orchestrator (CDO) is a cloud-based management solution designed to ensure streamlined and consistent security policies across the Cisco security portfolio. Specifically tailored to manage all Cisco Secure Firewall form factors (running either ASA or Firepower Threat Defense (FTD) software), CDO offers real-time visibility and troubleshooting capabilities, effectively enhancing overall network security. CDO addresses the challenges of migration, supporting transitions from...
Cisco Defense Orchestrator can improve by providing more support for third-party security components.
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.
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.
The dashboard needs to be more customizable to provide better reporting for our network.
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.
They should make it more of a one-stop shop for everything. It should have more features to manage FirePOWER appliances.
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.
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.
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.
While I think it's a good product right now and does everything we need it to, everything has some room for improvement. I'm sure Cisco would definitely be looking for ways that they can make its product better. My suggestion would be for Cisco to add third-party devices to the management family. Third-party integration would allow more flexibility and I think that would be a feature that would satisfy the business needs of other potential clients today. Some companies may want flexibility in the products they choose and others may already have legacy equipment that they are not ready to get rid of.
There could be some slight improvements to navigation. In some of the navigation you've got to go back to be able to get into where you need to be once you've made a change. If I make a change, I've then got to go back to submit and send the change.
In terms of bulk changes, specifically for accessing policies, there is one limitation which is especially annoying and at least one bug which hasn't been fixed. In terms of bulk changes for image upgrades, that's nice, but I have found that it's not really useful in most cases, because of limitations of the product. I've found dozens of bugs over the year we've been using it. The more I use it for different things, the more problems I find. Some of them get resolved pretty quickly. For others, I have to argue for a long time about why they are problematic and should be fixed. For some, they decide they're not going to fix them because they don't care. By far, most of the problems have to do with the user interface. A lot of thought and work has gone into the back-end component to make the product do what it's intended to do, but the way it is presented for use hasn't gotten nearly as much thought to make it smart and bug-free. I wouldn't say that it's not user-friendly, but there are a lot of bugs or features that are not very adequate. It's kind of user-friendly but there are a number of display issues or ways of doing things that are not as comprehensive; they're more limited compared to what you can do on your own with other products. In terms of auditing, we're worse off. It took away some of the capabilities that we had without the product because of a decision Cisco made on how to handle the history of changes. That's one example of a specific issue where we asked them to do things more intelligently, but they haven't. They kind-of agreed, but they haven't done it yet, and it's not going to be possible to make up for the past year of not having that in place. So auditing is definitely.
If I make a change locally to the firewall, CDO gives an alarm or an error message and says there's a change in compliance: "The firewall has this configuration but the last time it was compiled it had that configuration." That view of new changes versus the old could be better. Which one is the new configuration? Which one is the old one? I had trouble seeing which configuration of the two which CDO showed me was the one that was actually running. I had to log in manually, locally on the firewall, to check which version, which configuration, was actually running. I couldn't see it in CDO.
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.