What advice do you have for others considering Cisco Defense Orchestrator?

Cisco Defense Orchestrator is a solution that does not have a lot of competition, it is unique. However, the next similar solution would be Palo Alto Demisto. I rate Cisco Defense Orchestrator a seven out of ten

I would recommend this product to anyone who is interested in using it. I would rate this solution an eight out of ten.

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.

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.

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.

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.

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.

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.

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.

Cisco Defense Orchestrator is a very great solution to centralizing device management and security. I would want to give it a nine out of ten. It is not a ten because everything can be improved — such as the integration of third-party options, as I mentioned. As far as advice for those considering this solution, it will save a lot of time. It actually saves our organization about 40% or 60% of the time we used to take to do things manually. That is about three days of labor a week. Now those resources can be used in different and better ways to benefit productivity and the organization. We have obviously also realized security improvements.

For me, it was a very straightforward setup. It worked as described on the box. There are a few little issues that we've had. For example, when you create an object, you can't set a description on the object. But there are feature requests that are coming down the line as the product evolves. So far, the biggest things we've learned from it is about the rules we've got in place that are duplicated or which shadow another rule within the firewalls. That's something which would've been very difficult to identify. In terms of it simplifying security policy management across an extended network, we're not using a single policy across the firewalls. Excluding our guest WiFi firewall, all of our other firewalls have different configurations because of the way they work. As far as its effect on firewall builds and daily management of existing firewalls go, at the moment, we're not using the templates, but we are going to move towards the templates. At that point, it will make our builds quicker because we will have a templated model where we just click and deploy from that template. It will make that faster and more consistent. We've been using it for about a year. We've got some projects lined up for next year where we will take some of those features and start to use them a lot. In the long term, we'd like to get to standardized policies, but because we've implemented it into existing solutions, there's obviously a lot of rework needed to get the policy standardized. On a scale from one to ten, I would rate CDO as an eight. The thing that comes to mind with that rating is the centralized view of everything in one place. I've got a centralized view and I can make all the changes, from one central console, to any of the firewalls I need to. To get it to a ten, for me, it would need those little bits there around descriptions on objects. Also, in the firewall, by default, there are some system rules. They don't work in CDO, so you have to create custom rules instead of using the system rules so that CDO knows as well. It needs some little improvements like that.

Try it with realistic situations in your environment. Make sure that you're able to perform the tasks that you were doing before. In other words, make sure you don't lose capabilities because you're going to do everything exclusively through the product. Make sure you understand what it covers and what it doesn't. Do your homework before you buy. We haven't learned any big lessons from using this solution, but we have learned that using a firewall management tool that is good enough will allow you to save time and staffing, but that applies to any product, not just this one. This product hasn't existed for a very long time, but the very general lesson is that we benefit from using a firewall management tool as opposed to not using one, and CDO happens to be the one that we chose. But the lesson of benefiting from using a tool isn't the result of CDO being what it is. It's the result of CDO being one of the products in that category. In terms of the solution's security features around storing our firewall configuration in the cloud, we assume that it's handled in a very secure way, considering that it is a security management product. The one thing that we are not happy about is that it is storing passwords and similar secret strings in clear text in the user interface. So when we copy and paste from the website, we have to manually remove those values and replace them with stars to hide the secret information. That's just about the only security issue we're not happy about or feel is not secure. As for users of CDO in our company, excluding the read-only users, we have three people who are using it to perform tasks that affect what the firewalls do. My role is not very well-defined - I do all kinds of things. The other two are information/computer security specialists. Their job involves all kinds of IT security stuff. We have different levels of experience, so what each of us does depends on the complexity of the deployment. Once it's installed, there's no maintenance or other deployment required. Only one person at a time can do deployments. Let's say that on the scale of one to ten, ten represents something where we can't think of anyone ever doing something better, anywhere in the world, and zero means we can't use it. I'm very harsh, in general, in my evaluations. I'm thinking of the ten most important aspects and how many of those it covers, and how many it comes up short on, and I end up rating CDO at eight out of ten. The solution is 75 percent of our ideal.

It's worth it to dive in. If you have an environment with several firewalls, more than five, I would recommend just doing it. The biggest lesson I've learned from using it is that you can configure multiple devices at once. In terms of its security features for storing firewall configurations in the cloud, I'm not bothered by it. I don't see that as a security issue because I believe that Cisco is protecting it. I'm generally not against the cloud. It's good that we can do more and more from a single pane of glass, like Cisco Meraki, Cisco Defense Orchestrator, DNA Center, and so on. They should keep going in that direction. I think it's good. I didn't try that many features but I can see that it has a VPN feature. I would like to try some of these things, but I only have one firewall. It's difficult to do everything with one firewall. I would like to test out the VPN functionality and how it can save time in troubleshooting. I would also like to test the ease of creating new VPNs between firewalls. I would rate CDO at ten out of ten. It's a nice product and that's taking into account my experience with other products.

As an engineer, I would say that if you can afford it, you will not be sorry that you invested in it. There's no question of whether it's going to deliver. The question is more from a value standpoint, the size of your business. If you're a national company with multiple locations across the US, CDO is the direction you need to be going in. If you're a small company, 50 people or less, you can probably get by using Threat Grid. Medium-size businesses will probably also be okay with using something like that. From an outside-of-Cisco vantage point, for small and medium-size business, Fortinet does a pretty decent job. But when you start getting into large-scale enterprise, there isn't anything right now that's doing the things that CDO is doing to enable you to integrate. Cisco still has Tetration. To me, they are giving me a taste of Tetration, which is very high-scale leveraging. Think CDO but well beyond that. It's a multi-million-dollar device, a 42U-rack equipment storage device which is going to manage any and all network transactions happening on any of my networks. Tetration is for Exxon or Apple or Google-type visibility into the infrastructure. CDO gives me a taste of that without spending millions of dollars. The biggest lesson I've learned from using it is that it sure is nice when people buy it. It just makes our job a lot easier. If you ask me to get a job done, with CDO you're giving me all of the components that I need to make everything you're asking me to do a success. When it comes to its security features around storing firewall configurations in the cloud, there are things about that I probably don't fully understand, from a security standpoint. We've been doing that kind of thing for a long time, so I'm confident in it. But I'm a security guy, so I don't really trust anything. But that's where everything's going. It's good to know that I've got backups. "Cloud" is such an overused word too. As long as you thought through the security of everything, it's just some other place. Your attack spectrum is everywhere nowadays. To me, the biggest security problem is the human element. When you start looking at it like that, the fact that it's stored in the cloud is not really that big a deal. It's just a different way of doing business. These are things that traditionally, ten years ago, even five years ago, people weren't comfortable doing. Cisco was kind of late to the party in a lot of these things, but over the last three years - the acquisitions, the overall way they've attacked everything - they're doing the best job of bringing everything in. There are all the products which they have through acquisition, such as the OpenDNS acquisition for Umbrella, and CloudLock is going to be integrated into that as well; the next-gen firewall of FirePOWER and that's the evolution going into the FTD. They made a lot of improvements with ISE, even though there were some complexities that caused a lot of my higher-end clients to frown. It seems like they've righted the ship on all those things. So, there's a lot of good things happening. There are more things that I'm not really talking about, such as the evolution of even their switches, going with the FTD architecture of using Lina - Linux ASA - to do a lot of those pieces. One thing that they still have to rethink is how they're going to integrate a lot of the stuff that's on the ASA alone with AnyConnect, into FTD and those types of devices. We've been very pleased with the overall experience. In terms of the solution’s support for ASA, FTD, and Meraki MX devices, we have tons of clients who use all these devices. Since 2007, we've done over 2,000 medical facilities in the southeast Texas market, just using Cisco ASA firewalls. But in many cases, these places aren't large enough to use Defense Orchestrator. Now, if we took over complete management, I see how we could integrate CDO from an industry standpoint because a lot of these places are very similar. They use the same EMR practice management. They operate the same way on their infrastructure, have the same type of buildings. In many cases they're in the same building, a medical center. But they don't operate that way. They have independent practice managers. They're typically somewhere between 25 to 60 users. It would be nice to be able to have something like that. Maybe somebody really forward-thinking in my organization could possibly sell that idea, although I'm sure our legal department would tell us it's a bad idea. When you start dealing with HIPAA, there's a whole lot more to it than just IT. In managing that side of things, we do a lot of compliance and testing. We give them a HIPAA compliance report from an IT standpoint. And a lot of that is difficult because it has to be answered by someone within the organization who is familiar with their processes; for example, how they're turning their screen in an encounter with a patient. To have something like Defense Orchestrator, where I could manage hundreds of clients - their ASA or their Meraki MX or FTD - that would be huge. As for increasing our usage of CDO, we don't have it in our internal infrastructure yet, due to cost and the fact that our needs aren't that great. If we start doing some private cloud hosting or the like, I could see us utilizing it. That's one of our goals. We've got four data center locations where we're planning on rolling out Cisco UCS with some redundancy and failover. We're looking at CDO as our main point of visibility. I would rate Defense Orchestrator a ten. The only caveat I have for anybody trying to decide on it would be in terms of the budget and does it make sense for you. Do you need a 10,000-pound hammer to drive it home? We have a wide variety of clients in terms of size. Most people are somewhere in the middle-to-upper echelon with us. Others, and this is going to sound ugly, can't afford to use our services, because they're just looking for break-fix IT. They're still doing things the old-school way. Half of their data is compromised. They've been through several ransomware and malware attacks to the point where it has crippled their businesses. I don't know how those people operate. It's difficult because the attack spectrum is in our backyard. As a security guy, with the things that are being done and that happen, I just don't know how people do it. That's especially true if they're using a static firewall or if they have in-house equipment and services opened up to the public. If they're using a static firewall and trying to do traditional things like port-forwarding, we see that. We walk in there and they're saying, "Everything's running really slowly." And they're completely compromised. We had somebody who couldn't place phone calls. Somehow, half their trunks had been compromised and were being used for a telemarketing service in Philippines. It's to the point where, if you're a fireman, you just let it burn. They need insurance at that point because they have massive problems.