Cisco Defense Orchestrator Reviews

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.

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.

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 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.

We use it to manage our firewalls.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.