In a recent blog post, I discussed how different functional roles within a company have varied responses to the question, “What is an asset?”
Ultimately, every company arrives at an asset scope for the device inventory they want to track. From an asset management perspective, once the asset scope is defined and the inventory established, users want to use the asset data for various use cases.
The ability to granularly define and execute use cases is driven by asset dimensionality. Dimensionality refers to an aspect, element, property or characteristic. When it comes to IT assets, this refers to compute characteristics. The more characteristics one knows about an asset, the more use cases can be formulated around the individual asset, asset groupings, or holistically across the entire inventory.
What Are Examples of Asset Dimensionality?
Asset compute characteristics span a wide array of properties. This ranges from physical to operating systems, from the security and management agent health statuses to the agent policy configurations, from the vulnerabilities to the open ports, from the admins and last used users to the installed software. There are thousands of granular components that can be collected, consolidated, queried, and tracked.
Where Do the Compute Characteristics Reside?
A plethora of compute characteristics already exist in singular, monolithic, and non-integrated data sources — and in some cases, in partially integrated databases and systems. Examples include Active Directory, vulnerability scanners, cloud platforms, endpoint management tools, security agents consoles, and various infrastructure components like virtualization platforms, routers, and switches.
How to Obtain a Complete Inventory of Compute Characteristics
Simply put, the best inventory comes from the aggregation of a wide range of data sources.
More sources of data = more data elements = greater dimensionality.
Data source diversity is critical to this effort because many device compute characteristics can only be found in a singular data source. One example would be vulnerability data. In many organizations, vulnerability data for assets only resides in one source: the vulnerability scanner. Another example is the last used user of the device. This information may only be found in a single source like SCCM or BigFix.
Connecting a multitude of data sources ensures a multifaceted view of an asset.
How Does Asset Dimensionality Impact Use Case Variability?
Deep characteristic dimensionality enables nuance, or context, to be expressed in increasing levels of complexity. Having a reservoir of data sources feeding into the asset inventory allows for granular operational conditions to be surfaced by aligning asset dimensions into logical data structures.
Let’s focus on an example in which we use various device characteristics to surface a series of context wrinkles in the virtual machine (VM) environment of a company.
Base Condition: Group all VMs Across the Estate
The condition is dependent on gathering up all the data sources in which VMs might be found running.
In this example, our environment has VMs running in two IaaS cloud platforms – AWS and Azure — and also two traditional data center VM platforms – VMware and Hyper-V.
This requires aggregation of four data sources into the platform.
Wrinkle 1: Isolate Only Those That Are Live and Running
This requires aggregation of the power state field from each data source into a single data plane in order to make a simple query:
Wrinkle 2: Isolate Only Those That Are Public Facing
This requires aggregation of the IP addresses assigned to the devices from each data source to a normalized field and then a selective isolation of only those that are in the IPv4 public subnet ranges:
Wrinkle 3: Tracking a Specific Vulnerability or Machines That May Have a Specific Vulnerability (CVE-2020-0646 impacting Microsoft .NET Framework 4.5.2)
In this case you will need both installed software information as well as vulnerability data from across the estate. Why?
If your team is tracking a specific vulnerability, you’ll need to isolate machines where the vulnerability scanner has found the particular CVE ID. But not all devices may have been scanned by the vulnerability scanner. This happens when not all devices are known to the vulnerability scan team at the time of the scan, devices are unreachable or unavailable at the time of the scan, or when new devices have appeared in the environment in between vulnerability scan cycles.
In the event you don’t have the vulnerability data for a device, you may find the specific piece of software version running on a machine:
So far we would have needed six different data sources and six different data field characteristics.
Wrinkle 4: Finding EDR/EPP (CrowdStrike in this case) Coverage Gaps for the Exploitable Server Devices
This particular wrinkle is a non-trivial condition. Why? Because it’s actually multiple different use cases when broken down into smaller parts.
Part 1: There are certain Windows Server versions the CrowdStrike agent doesn’t support – Windows 2000, Windows 2003 and Windows 2008 not R2, Service Pack 1. You must first account for these exceptions:
Part 2: You must find the machines missing the CrowdStrike agent for those Windows Server versions that are supported by the CrowdStrike agent:
Part 3: Among those Windows Server versions where the agent is deployed, you must find those running an agent version earlier than version 5.34.11501.0 (for example), which would not recognize exploit attempts for this particular CVE. Or, those running version 5.34.11501.0 and above (that do recognize and stop exploit attempts) but with either no policy applied or a policy that is not the prevention policy.
The various wrinkles above resulted in a multitude of slightly different use cases. This grouping of varied use cases required a minimum of seven data sources and ten different data characteristics.
A cybersecurity asset management platform like Axonius allows companies to develop and set a wide array of use cases into motion via continuous monitoring dashboards and enforcement actions tied to workflows and IT systems across the organization.
Want to learn more? See Axonius in action.