We live in a world where everything around us is controlled, influenced or represented by electronic data. Visit a hospital and everything from your lab results, to pharmacy information, to x-rays is stored in an electronic medical record. Need to pay some bills? Login to your financial institution’s website and you are a few clicks away from not having your electricity turned off. Speaking of electricity, more and more utility companies are using smart meters to electronically and remotely provide meter reads. Feel like staying home to watch a movie? Simply give your credit card information to Netflix and start streaming. Popcorn not included. I could provide many more examples, but it should be clear the world runs on data.
Keeping that data safe is a high wire balancing act between security and accessibility. Falling on one side of the wire means the data is not accessible to those who depend on it. Falling to the other side leaves data exposed to the wrong people.
There are many aspects to data security, of which network security is only one. There are also many aspects to network security, of which firewalls are only one. Let us discuss the role of the firewall in network security.
The Two-Headed Monster
Managing network security today is hard work, and this difficulty can be summed up into two broad categories.
Firewall and Security Policy Heterogeneity
Security controls should be implemented everywhere from data centers, private clouds, and public clouds, to branch offices, remote sites, and mobile worker locations. With each type of location, comes a set of performance requirements that are filled by various makes and models of firewall. With each type of location also comes a set of security policy requirements. An effective security design should try to minimize the number of combinations of firewall and security policy, but it is almost impossible to get to a single combination that works everywhere.
- Evolution is constant and occurs in a few areas that have direct impacts on network security.
As a business evolves, the services it offers also evolves. As such, the security policy needs to change to allow access to new services while removing access to retired services.
- Some businesses evolve through one or more acquisitions and mergers, which cause firewalls and security policies to be inherited.
- Businesses must adapt to product and operating system life-cycles as firewall vendors evolve with the changing times.
- Industry and legal compliance also evolve. Whether it’s Sarbanes-Oxley, PCI, HIPAA, NERC-CIP or some other mandatory compliance requirement at play, you can be sure that these will be amended in the future as required.
- Most importantly, bad actors are always evolving. They are always looking for the weakest point to enter your network, whether it be to install ransomware, increase the size of their botnet or exfiltrate data.
Invariably, the operations teams are left to manage several security policies across stateful firewalls, next-generation firewalls, unified threat management devices and firewalls in the cloud provider, each with their management consoles, user interfaces and policy structures. The result is a higher complexity that increases operational costs and weakens security. Operational costs increase because more highly trained staff is required. Inconsistent policies, introduced through errors, weakens security.
CDO to the Rescue
Cisco Defense Orchestrator is a cloud-based policy orchestrator that provides consistent policy and consistent visibility across all your environments. It currently supports the Adaptive Security Appliance (ASA), Firepower Threat Defense (FTD), virtual ASA, virtual FTD, Meraki as well as cloud firewalls in both AWS and Azure.
Benefits become apparent from the moment you start onboarding your devices. The system immediately ingests and processes configurations, categorizing devices by type and version for quick reference. Algorithms immediately start looking for ways to optimize and improve security policy by highlighting duplicate objects, unused objects and inconsistencies across the entire environment. Here are some of the key features in more detail.
Smart Configuration Management
This feature ensures that the most current configuration is always stored in the cloud. Not only does this include changes pushed by CDO, but it also includes out of band changes. Out of band changes are those made using legacy methods such as the CLI, ASDM for ASA, FMC for FTD or the Meraki dashboard. These out of band changes can be accepted as the new configuration, or you can roll back the changes to the last known, good configuration stored in CDO.
Proper documentation is essential to most change processes, so CDO tracks all configuration changes in a change log. The changes can be rolled back to the previous config with the simple click of a button. This rollback functionality is non-disruptive as only the difference is applied rather than replacing the entire configuration. The backout configuration is created automatically and available to the operations team to be pasted into the change request documentation. This feature saves time and gives confidence to all stakeholders.
The benefits of upgrades and patches are well known in the information technology industry. When it comes to upgrading and patching security systems, the benefits should be obvious. As previously stated, most systems are attacked at their weakest point, and unpatched security systems are exactly that.
CDO automatically provides views of your device inventory that are grouped and categorized by version. Upgrading a group is as simple as clicking the upgrade button. CDO does all the work to download your selected image from Cisco, upload it to each device in the group, and verify the checksum of the uploaded image. Disappointingly, I do not know many engineers who validate their images before they reload their devices to complete the upgrade.
The final option in your upgrade process is whether to stage the image or go ahead and reload the device immediately or at a scheduled time.
Speaking of upgrades, as a bonus, you can use CDO to convert your ASA devices to FTD.
Resolve Policy Issues
Inconsistency, in its many forms, is a common problem experienced by operations teams that manage multiple security devices. Unused objects, duplicate objects and inconsistent policies are all examples of inconsistencies that weaken security and generally extend troubleshooting time.
CDO analyzes the existing security policies across your entire environment and identifies where optimizations offer quick wins. Quick here is precisely that, as hitting the “easy button” finishes the process.
Unified Security Policy
Having multiple device types deployed throughout your environment and expecting some semblance of a standard security policy to apply across that same environment is a tall task for the operations team. However, this type of environment is common for many reasons and is prone to errors which weaken security.
Such an environment is child’s play for CDO as it’s the only place you can manage your fleet of ASA, FTD and Meraki devices. The look and feel are very similar to the Firepower Management Console (FMC), and once you have defined your policy, you can deploy it to any device. For those of you that are used to the lack of object group support in the Meraki dashboard, CDO has a special surprise for you. When object groups are leveraged in CDO, they are pushed to the Meraki dashboard using the standard IP, protocol and port information and then deployed to the chosen Meraki devices without any further intervention or conversion.
Not all ASA config items are templated in CDO. While this would typically mean you would have to access an ASA directly to modify these items, CDO provides a command line interface (CLI) tool that accesses the ASA instead. This function allows you to continue to access all your devices from one place while continuing to log the changes centrally.
Policy deployments come with guard rails for added safety. Rather than immediately deploying a policy modification across the entire environment, CDO highlights which devices are to receive the update. Now you can select a few devices to test the update and deploy to the remaining devices once the test is successful.
There is always a risk of losing access to a device after a policy deployment. When working with remote devices, it is common for engineers to issue the “reload in x” command to help recover from such a situation. CDO provides this option as well, and immediately cancels the reload if the device is still accessible after the deployment. If delayed policy deployment is a guard rail, the “reload in x” option is a parachute.
Monitoring the Environment
CDO is not limited to configuration management, device upgrades and policy manipulation. Information regarding intrusions, connections, malware and all other alerting is accessible through CDO. There are also hooks to Cisco Threat Response so you can zero in to get more information about specific events rather than having to search and filter through all events.
In most environments, there exist security devices that do not and should not have access to the internet. How do you get the cloud-hosted CDO to manage these devices? The Secure Device Connector is used to proxy management traffic between such devices and CDO. The SDC is a virtual appliance that is self-updating, so you never need to touch it again. For added security, the SDC stores the credentials locally for the devices for which it is responsible, rather than having this information stored in the cloud.
Earlier, we discussed the CLI function available on CDO. Using CLI has always been error-prone and is a common way to introduce inconsistencies into an environment. A nice touch to the CLI function is the ability to create and use macros with variables. As an example of the benefits, senior staff can create virtual private network (VPN) macros to ensure the use of appropriate encryption settings. When junior staff need to implement a VPN, they run the macro, filling in variables for IP address information, and a completed configuration with all the proper settings is deployed.
Proper configuration management is challenging to get right. CDO has done such a good job that it has included support for IOS devices. You can use CDO to archive your configurations, or you can use it to restore to known good configs if need be. The CLI function, complete with macros and variables, works with these devices as well. This function gives the added benefit of also updating the change log.
Cisco Defense Orchestrator offers some overdue respite to beleaguered security operations teams as well as comfort to CISOs, CIOs and CEOs trying to keep their organizations out of the news. If you are struggling with configuration management, device upgrades and overall security policy management, CDO may help end those struggles.