Managing consistent network security policy across multiple devices becomes increasingly complex as more devices are added. Cisco has a solution...
Complexity and Consistency
It’s relatively easy to keep a simple environment consistent. There’s usually a single edge security device and a single control point, which means there’s a single source of truth. Consistency is easy in simple environments.
When we extend the network into branch offices with their own internet connections, data centers, and clouds, we start dealing with multiple, and usually independent, edge security implementations. Each device is managed with no single source of control. Even two or three different devices are enough to produce complexity as configurations are manually copied between them and sometimes translated from platform to platform. Consistency is the first sacrifice on the altar when this occurs, and that can lead to accidental security vulnerabilities.
Complexity and consistency are the two primary concerns that CDO was built to address.
Cisco’s guiding principles with the CDO are simplicity, efficiency, and effectiveness. Simplicity is achieved by taking the various policy implementations across devices and streamlining them into a single policy. Efficiency follows by reducing the time spent on managing security across the same devices. Once the first two have been accomplished, effectiveness follows. Policy falls under a single point of control that’s easy to manage.
Enforcing security policy across a greenfield deployment with most orchestration engines is relatively easy. Doing it in environments where there are existing deployments is much more difficult.
Policy Analysis, Normalization, and Unification
When a device is attached to CDO, a number of things can be simplified almost immediately as the device is analyzed.
An object analysis can be performed, showing unused/duplicate objects and allowing them to be consolidated.
ACLs can be compared across devices for consistency. In the event that aberrations are found, the platform includes an “easy button” to consolidate them assuming that any address that was included in a device’s ACL belongs.
Policies build on these objects and ACLs can then be audited for accuracy and deployed to one or two devices as a test before large-scale installation.
Configuration changes can be built and deployed by CDO to any or all devices in its database. This includes a preview mode so that the operator can see everything that’s going to be done on the device and make an informed decision about proceeding.
CDO monitors all devices connected to it for changes in the configuration every few minutes. If there is a configuration change at the device level, the controller provides the option of either incorporating the change into the central database or overwriting it with the configuration on file.
All changes are registered in the changelog facility, which shows all changes at both the device level and the CDO database. The operator can then look and see if there was a change corresponding to when problems occur. Should problems be traced to the change, the system even provides another “easy button” to revert to a previous configuration.
Yes, there’s even a built-in “reload in 5” command, just in case there’s a catastrophic failure in the application of the change.
Software Image Management
Keeping software consistent isn’t difficult, but it’s a bit of a pain to manage. CDO keeps a full software repository for ASA and NGFW platforms and allows for the security devices to retrieve software directly from the repository either manually or on a schedule with no TFTP server required.
Arguably, this is one of the simpler features, but it’s a huge timesaver.
Event Management and Correlation
One of the most impressive features of CDO is the integration of its Event Management screen with Cisco Threat Response and Umbrella. Instead of manually looking up addresses and event details, inquiries can be made of the data presented in Event Management against these databases for quick evaluation of a threat.
CDO fully supports the NGFW platform in physical and virtual installations, but support for the cloud NGFW is still forthcoming. The FTD software needs to be at 6.4 at a minimum and 6.5 in the case of the 4100 and 9300 units.
There is also support for the Cisco ASA appliances running at least version 8.4 of the ASA Software. Physical, virtual, and cloud installations are covered.
The Meraki MX Appliances also supported by the CDO platform.
Cisco’s flagship products for edge security are the Next Generation Firewalls (NGFWs) and it stands to reason that these are CDO’s best supported platforms. When dealing with other supported devices (Adaptive Security Appliances and Meraki MX Appliances) some features go missing, due to further development required in CDO or limitations of the edge devices themselves.
On the ASAs in particular, VPN capabilities are read-only and are not configurable via the CDO. Even then, viewing of IPSec VPNs is limited to policy-based tunnels. IPSec Virtual Tunnel Interface (VTI) VPNs do not appear at all. It’s expected that full VPN configuration support will be forthcoming.
The Zone-Based Policy Firewall (ZBPF) on the Cisco router platforms is entirely unsupported and does not appear to be planned for the future.
There’s no workflow or approvals process for changes built into the product, but there is a very good audit trail to see who did what and when.
CDO has a feature to address some of these limitations, the CLI Builder. Similar to Prime Infrastructure’s configuration templates, this allows for custom macros and variables to be used to apply custom configurations to devices, even going so far as to support configuration management on non-security platforms like Cisco routers and switches.
Because of the custom nature of configurations applied using the CLI builder, normal rollback capabilities aren’t usually going to be available and will require a device reload. When rolling back, CDO will be good enough to warn us if the process will produce an outage.
The Whisper in the Wires
Cisco has done a really good job of bringing multiple dissimilar security devices under a single operating model. It’s equally effective with larger organizations slowly migrating to NGFWs from their ASAs as it is with the Managed Service Providers (MSPs) who have to manage everything from simple configurations, to larger and more complex ones. Though I didn’t mention it earlier, the CDO platform has full multi-tenancy support, making it really appealing for businesses.
The platform still has a significant way to go, to be sure, but it’s a great beginning and I’m looking forward to seeing where it goes with future iterations.
Originally published on the Gestalt IT site.