We know something is compromised but don't know what it is. A case for “Just Enough Asset Management”??
Bob: One of our systems got compromised. We are seeing Command and Control traffic going out.
Laura: I have a few questions:
What do we know about the system?
What is the business criticality of this system and what application is it running?
What type of data is stored and who are the owners and business unit responsible for the system?
Bob: It is still early in our investigation, we are looking into it. We don’t have too many details about the asset at this time; we don't even have access, we know it is hosted in the Public Cloud Infrastructure. The team is working on getting the details.
Heard that conversation before? You are not the only one. Asset management has been one of those foundational capabilities that often comes up as THE capability to build and get right. Effective asset management is prerequisite for capacity planning, operational planning and support, operational security, cost management, and the list goes on. However, most organizations have difficulty building an effective and sustainable Asset Management capability. Often asset management deteriorates over time, leaving organizations scrambling to get information when they are in the middle of an incident or a planning exercise. This is a consistent story across many organizations.
The reason for failure is often that capability tries to deliver too much. Asset Management initiatives will have roadmap items that would build complex relationships between assets and entities, and create dependency trees between them, establish discovery methods for identifying assets that generate too much data, introduce new processes for registering and deleting assets, all this looks great on the project plan. However, this adds considerable overhead and these new processes are often easy to bypass for folks who just want to get their work done. Over time, all this becomes a burden on engineering and operations teams. The problem in some cases is made worse with the introduction of the on-demand provisioning infrastructure like public or private cloud. It is not uncommon for organizations to restart Asset management initiatives every few years to rebuild the Asset Management capability repeating the same mistakes from previous initiatives.
Asset management is not just a core Information Technology capability but pretty much all Cybersecurity initiatives and capabilities rely on Asset Management. Cybersecurity organization often asks the question: how can we build effective Cybersecurity capabilities if the underlying foundational capability is subpar? Of course, Asset Management is not the shiniest or sexiest of the Cybersecurity capabilities; however, this approach intends to change that. The concept below not only builds out an effective Asset Management capability but also makes asset management a force multiplier for the rest of the Cybersecurity capabilities.
Just Enough Asset Management(JEAM) has been in the works for a few years now. The core concept of JEAM is reducing asset information collection to the minimum required, a minimum set that could drive most of the Cybersecurity and IT processes. Selection of attributes is critical as these must be collected consistently and reliably through near real-time automated processes. JEAM does not introduce human-driven processes, regular discovery scans or add or modify workflows. Instead, JEAM at its core must use existing infrastructure logs to collect and index information that might already exist in the organization, so there is no need to run any discovery scans, you might already have the information needed. JEAM classifies attributes about assets as primary or secondary. Primary attributes remain unchanged across the life of an asset and act as the primary identifiers while secondary attributes might change and the frequency of change might vary depending on the nature and type of the secondary attribute. An important point to note here: one might start with a secondary attribute to get to a primary attribute for initial indexing. Example, you start with an IP address(a secondary attribute) and get to a primary attribute(hostname). The primary and secondary attributes collected and then linked together are used to build the core of the asset inventory database.
To provide a better idea here is a non-exhaustive table of Primary and Secondary attributes, your selection of primaries and secondary might vary based on your organizational needs but the table below should give you a good start:
The recommendation is not to expand this list too much, any additional attribute must meet the basic criteria that it can be collected consistently and accurately, collected data adds basic significant value to your over asset inventory. Data enrichment activities should be built on top of the indexed attributes. This loose coupling will ensure that your data never gets out of sync.
The following table includes data sources that might already exist in the organization and can be used to collect both primary and secondary attributes.
JEAM based system can potentially be built leveraging ELK or Splunk, however recently some startups have come up with a model to build out asset inventory. Google’s Beyond Corp model uses similar concepts for collecting Device Inventory. JEAM based system not only provides a consistent source of data to the Cybersecurity organization but also can be extremely useful for IT Operations.
The next blog post will provide an overview and a reference architecture of JEAM and how JEAM can be used for vulnerability management, Incident Detection and Response, Footprint assessment, Risk Management, and other capabilities. The post will also discuss how such a system can act as the core of an organization’s Cybersecurity capabilities.
