The following blog post is a guest contribution from Axonius partner, Sayers. Sayers creates personalized IT solutions designed to meet the needs of your business and the dedication to go above and beyond to provide you with unwavering support.
There aren't a lot of hard and fast rules in the world of disaster recovery planning, but it’s at least well known and understood that if you don’t know what’s in your environment, you won't recover it.
Creating a comprehensive disaster recovery program, therefore, requires that you get a handle on all the assets in your environment. You need to build a Configuration Management Database (CMDB) that tells you what assets you have and gives some idea of how they are configured, so they can be restored when needed.
Building a system of record
There are a number of tools out there that have been traditionally used to help with the creation of a CMDB. Most popular helpdesk and asset management tools have utilities to help with building and maintaining asset management data, and traditionally disaster recovery teams have used that data to develop recovery plans. However, most of these tools fall short of enumerating everything in the environment, because they tend to depend on agents being installed on systems and those agents working in the background to keep asset information current.
Using traditional asset management tools to build an accurate CMDB is often an exercise in futility. Some devices may be incompatible with whatever tool you are using, simply because an agent hasn’t been created that works on that device (like mobile devices, proprietary storage devices, or network appliances). Keeping agents up-to-date is a chore all on its own, and if someone adds devices to your network that you don’t know about, they generally don’t get picked up because they don’t have agents installed.
I've run into this phenomenon throughout my career. In one role, specifically, a group of engineers had re-tasked an old desktop computer to host a proprietary manufacturing quality database several years before I started working there. By the time I got there and we started creating business continuity plans, that database represented several million dollars worth of irreplaceable data. But their IT department's CMDB application didn't know it existed because there wasn't a client installed on it. They were one power surge or failed hard drive away from losing millions, and the IT department had no idea the risk even existed.
The challenge with CMDBs
In addition to not being able to find everything important in an environment, CMDB tools often create multiple records for a single device because of the various ways they might collect the data. If your CMDB tool gets one list of servers in your data center from polling its clients, another from your system management platform, and a third from manually uploaded asset management data, then it's a given that nearly everything in your server environment is going to have multiple systems of record making reference to it. That's going to create duplicate records for systems — it's inevitable. Many companies will skip the time-consuming manual step of justifying those multiple references and turning it into a single list, but even those that do the work and remove duplicates fight a losing battle. Every time a system gets renamed, gets issued a new IP address, gets shifted to a different virtual host, or gets some piece of software updated, there's a risk it will create new copies of records in the CMDB. The more of those steps that are done manually, the more of a chance for a human error as well, compounding the problem. It's not uncommon for a company to have one number of active devices from their asset management team, another from their system administration teams, and another from their helpdesk software.
Having so many conflicting sources of data makes it all the more difficult to determine ownership of devices, but also the ownership of the problem of fixing it. In previous roles, I’ve experienced infighting about who controlled the true system of record, and that was amplified by the fact that nobody's data was completely credible. All that gets in the way of resolving the real issue. When it comes to dealing with an actual disaster recovery incident, that CMDB data you need to be able to rely on just isn't reliable. You don't want to waste time creating disaster recovery plans for systems that don't exist, and worse yet, you don't want to leave systems out of your disaster recovery plans because you don't know they're there.
Traditional CMDBs, while necessary, just can't do everything you need.
Enter CAASM
Let's look at this from a different angle, though. Cyber asset attack surface management (CAASM) tools like Axonius have similar goals and collect similar data to what you'd want in a CMDB. They also go out and enumerate all the devices in the environment, often taking a look at configuration information as well. The distinct advantages that CAASM tools have, however, are that they generally aren’t dependent upon installed agents on devices, and they flawlessly rid themselves of erroneous or duplicate records in the data. Axonius uses adapters, or API integrations, to seek out and poll information about systems automatically, and deduplicates records as a part of the process. You get everything you want from a CMDB to keep your disaster recovery plans up-to-date, and get it with a lot less effort.
