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