As far as data center hardware is concerned, Cisco is nearly ubiquitous. You’d be hard-pressed to find a data center that doesn’t use at least one piece of Cisco equipment and a corresponding Cisco application. This is why it’s a good idea to pay attention when Cisco announces a vulnerability in its software – because attackers will almost certainly get the same idea.
On January 2nd, 2020, Cisco announced six vulnerabilities for its Data Center Network Manager application. The most critical bug was in fact a compendium of three unrelated exploits that enabled attackers to assume administrator privileges without having to steal credentials. If exploited in the wild, this could be very serious – two of the exploits would let users perform arbitrary actions under the guise of an administrator, and one would let an attacker steal critical information directly.
Here’s the thing: we all know that patching is hard. It’s hard enough that 60 percent of companies that have been hacked admit that their data breach was caused by an unpatched vulnerability. Let’s take a closer look at this particular vulnerability and its associated patch and learn how Device42 can help you make sure that this patch gets applied.
Why is Patching So Hard?
Let’s begin by taking a look at what it takes to upgrade and patch the Cisco Data Center Network Manager (DCNM). Based on the instructional YouTube video that they provided with a previous release, this is a roughly eight-minute task. First, you need to download a specific update tool that matches your current version of the network manager, transfer the files to a chosen server using sFTP, and then log in to your DCNM server as root. After running the tool using the command line, you need to log into your DCNM virtual server and then power it off. Finally, you can deploy and configure the new release.
To be fair to Cisco, their set of instructions is both clear and comprehensive – but it also tends to highlight a lot of the reasons why patching has become so difficult. For example:
- This is an eight-minute process to update a single copy of DCNM. If you have multiple copies of DCNM, you’re going to spend a long time patching. Is there a batch process?
- How can you determine what needs to be upgraded? How can you determine which devices are affected based on their current OS/software version?
- What happens when you power down the DCNM VM? Does that take the associated switches offline? Does this, in turn, bring down your data center network?
- What happens if the installation and configuration instructions given above are incompatible with my current data center environment?
These are questions that data center managers have to deal with not just for the Cisco patch, but for every patch that gets released – and there are a lot of them. In 2019, for example, over 5,500 software vulnerabilities were reported in just a single quarter. For each of them, a data center manager needs to know that they have a potentially affected copy of the application, know where their application is and what version it is, and understand whether fixing the vulnerability will solve more problems than it creates. This means that a lot of unpatched vulnerabilities get left behind.
Device42 Helps Enterprises Solve Patching Problems
With its instant audit capabilities, Device42 provides a way for enterprises to streamline and solve many of the issues that get between them and a fully patched environment.
First, Device42 begins logging every device and application – including cloud storage, VMs, and containers – as soon as it’s attached to your network. That means instead of hunting down your license information for DCNM or manually tabbing through active virtual machines, you can immediately find how many copies of DCNM you’re running, as well as their associated version information.
How easy is it to do this? Here’s a query we made to find the software in your infrastructure. With Device42, you can write your own custom queries and store them as Saved DOQL Queries in the Tools section in Device42. This query will return a report with any servers with DCNM installed on them. You can also run our default Software Inventory advanced report and filter the results.
select d.name "Device Name", (SELECT array_to_string(array( select ip.ip_address from view_ipaddress_v1 ip where ip.device_fk = d.device_pk), ' | ')) "Device IP Addresses", s.software_pk "Software ID", s.name "Software Name", siu.component_name "Software Component Name", ac.name "Related App Comp", siu.alias_name "Software Alias", siu.version "Software Version", siu.file_version "File Version", siu.install_date "Installation Date", siu.install_path "Installation Path" from view_softwareinuse_v1 siu left join view_software_v1 s on s.software_pk = siu.software_fk left join view_appcomp_v1 ac on siu.appcomp_fk = ac.appcomp_pk left join view_device_v1 d on siu.device_fk = d.device_pk left join view_ipaddress_v1 ip on ip.device_fk = d.device_pk where s.name = 'DCNM' order by d.name ASC
In addition, Device42 maps application dependencies. So, if you need to power down a VM in order to deploy a new version of DCNM, you can understand exactly what this will affect. If turning off DCNM will affect too many systems – or if you can’t figure out a way to failover onto a secondary application while updating DCNM – then you can at least schedule your update so that it coincides with a period of diminished user activity.
With Device42, we provide the tools that let you understand and efficiently manage a data center environment that has grown ever more complex. If you’d like to understand for yourself how patching and managing a hybrid IT environment becomes easier with Device42, download a free demo today!