In my last blog, I discussed some of the challenges for a DIY asset inventory platform leveraging a CMDB. This time around, I’m discussing the “buy” side of the argument.
The first and foremost consideration for buying a cybersecurity asset management platform should be time to value. We often overlook this seemingly simple concept, but how frequently do we see projects that take 12 to 18 months to get off the ground post-purchase?
Time to value (TTV) is similar to return on investment (ROI), which measures the financial return of an investment. However, TTV is instead related to the effectiveness of an investment. For an asset inventory and management tool, effectiveness boils down to mean time to inventory (MTTI). From start to finish, how quickly can an organization obtain and rationalize an asset inventory to inform, improve and/or complete internal processes and workflows?
What Factors Impact MTTI?
Using our ubiquitous definition of an asset inventory (complete, contextual, credible, always up-to-date, and unique) we can start to carve up MTTI into smaller segments of time-based functions that make up MTTI in the aggregate.
Below are a few key areas to consider.
Preparation & Planning
How much time and effort will be spent in the design and architectural phase of the solution?
- Network-centric tools typically require the deployment of sensors spread throughout the network. Planning for correct placement, network performance and impact, architecture changes, and more can be a time-consuming task that requires input from various cross-functional teams.
Additionally, network devices can and do fail and therefore planning for backups, redundancy, minimization of impact of failure and replacement strategies are all additional areas to contemplate.
- Agent-based tools usually require performance and impact testing of the agent on the various standard images of the company.
Additionally, an exercise should be conducted to identify all the servers and workstations that will be in scope for the agent deployment. Particular attention must be paid to how to find and reach and when to deploy to remote mobile devices and virtual machines.
- Scanning tools may require deployments of endpoint agents and/or network scan engines. Therefore, typical network-centric and agent-based tool considerations as listed above must be carefully analyzed.
Different systems are likely to need different types of scans. So time and thought must be given to what those various conditions are and how to properly rollout, configure, and schedule the scans. No one wants to knock systems offline with the wrong type of scan at the wrong time!
Deployment
How long does it take to fully deploy the technology to obtain the complete inventory?
- Network-centric asset discovery tool rollout may take months — or even years, depending on the size and complexity of the network.
The introduction of network listening devices may be invasive. It often requires network configuration changes or upgrades (taps or span port configurations). It can impact network uptime, can cause performance degradation if done incorrectly, and should be completed during agreed maintenance windows.
Additional network changes are usually needed to accommodate remote sensor management including out-of-band reachability, backup and restore, device health monitoring, etc.
- Agent-based tools can take months to fully deploy, depending on the chosen solution. Finding every single system that requires an agent can lead to a whack-a-mole situation, requiring continuous monitoring for new systems missing the current agent and then scheduling the agent package delivery. Because the deployment may take some time, the deployment team must consider how to maintain agent version control throughout.
- Scanning-based tools can take significant time to reach near complete deployment. As mentioned earlier, scanning tools may be agent-based, network scan engine-based, or a combination of the two. This results in the same complexities found with other tooling methodologies.
Time to deploy does not end here, as teams will have to manage through the process of tuning scanning packages and tuning scan intervals, always with an eye out for performance and system availability challenges.
Configuration & Use
How long will it take to analyze and transform asset inventory data into practical, real-world use cases?
- Network device discovery tools can be leveraged to identify devices and characteristics of devices as they communicate on the network. Every communication says something about what the device is (and in some cases how it is configured).
Given the limited perspectives that can be obtained from simply analyzing how and what a device communicates, teams managing these solutions must look to other sources of data for complete context. Time is inevitably spent analyzing what data is needed for context, where to obtain the data, how to integrate the disparate sources of data, and how to finally use this data in terms of process and workflows.
- Agent-based tools are typically used to understand diverse characteristics about a single device. These tools do allow you to ask questions about characteristics across all devices, and can be used to provide numerous use cases like users of devices, missing patches, installed software, services, and processes running on the device.
All of this can be configured rather quickly. However, context is important and teams ultimately gravitate to more complex use cases. Managers of these platforms often find themselves looking for missing pieces of information only found in other data sources. Understanding the context of device vulnerabilities in relation to how security agents are deployed and configured, and where the device exists in the network, is not straightforward or easily understood. Determining if the device had a specific vulnerability or patch at some point in time in the past (perhaps in the time range of a network breach) and who the users were at that time is an elongated process, requiring access to a multitude of systems to find the right answer.
Also, time and effort will be spent using other data sources and manual efforts to identify misconfigured agents, corrupted agents and agents that have either been disabled or removed
- Scanning-based tools provide a wealth of data about users, open ports, installed software, version and vendor, as well as vulnerabilities, depending on the tool. These pieces of data can be used to formulate many use cases, like finding unsanctioned applications, identifying the riskiest servers and identifying some system configuration aspects.
However, these solutions are limited in terms of context and are almost never useful for answering real-time questions. Companies spend inordinate amounts of time trying to combine device scan data with other sources to answer useful questions. Scan data alone cannot identify unmanaged devices, device exploitability nor all ephemeral devices (virtual machines and containers). A significant investment of time and effort over months will occur before a scanning platform can realize many of the most commonly desired use cases.
Selecting an asset inventory tool should account for a wide range of time and effort-based variables for an organization to understand when their initial spend will result in the actual intended value of the solution.
Many of the traditional asset inventory traditional approaches in the market have a relatively high TTV, leading one to better understand a DIY mentality. If the current tools on the market are incomplete, require a great deal of time and effort, and involve significant integration complexity with other tools, why not leverage the in-house CMDB? This is a logical place to arrive when considering what the market has offered in the past.
Axonius represents a radical paradigm shift to the equation. Axonius’ approach is a fresh method and unique approach to delivering a complete, credible and out-of-the-box usable inventory. As a result, the TTV for an Axonius customer is literally measured in hours and days.
