Introduction #

One cannot secure what one cannot see.

Asset management ¹ is the process of discovering, inventorying, and tracking all IT assets throughout their lifecycle, from hardware and software to cloud resources and data. A formal asset management practice provides the visibility and context required for an enterprise vulnerability management program to succeed.

Identifying, assessing, prioritizing, reporting and remediating vulnerabilities are the core responsibilities of vulnerability management teams in the industry, without having the visibility and context of all the assets in scope, one cannot secure them, let alone consistently detect and remediate their vulnerabilities. In fact, maintaining a comprehensive asset inventory is considered the backbone of most enterprise cybersecurity controls.

Underdeveloped asset management programs fundamentally undermine the efficacy and accuracy of vulnerability management capabilities. It is imperative that cybersecurity teams effectively convey to executive leadership and other stakeholders, that any limitations in the asset inventory will directly constrain the program’s scope.

The article seeks to elucidate the fundamental principles of asset management for cybersecurity professionals. By emphasizing the interdependence of accurate asset inventories and vulnerability management efficacy, readers will gain actionable insights on how asset management principles must be integrated into risk-based security initiatives.

Asset Management Fundamentals #

Enterprise asset management platforms strengthen each phase of the vulnerability management lifecycle by providing an accurate source of truth for asset visibility, context, and ownership data. By understanding the fundamentals of how asset data is structured, updated, and used, cybersecurity teams can influence and steer asset management decisions to ensure alignment with its requirements.

Companies often structure asset management programs within their IT department, while vulnerability management programs typically fall under the cybersecurity department. This organizational approach might be advantageous as it emphasizes the respective expertise of each department, where IT professionals maintain the CMDB, inventory devices, and handle lifecycle processes, whilst cybersecurity experts focus on building and maintaining security controls.

Cybersecurity teams responsible for vulnerability management programs are not required to achieve the same level of technical depth in asset management as their IT counterparts, however cultivating a collaborative relationship between these areas should be considered as a key initiative to ensure that both programs can mutually benefit from each other.

Asset Inventory #

A Configuration Management Database (CMDB) ² is often the core component of an asset management platform. It serves as the central record of all assets and their metadata (owner, location, configurations, relationships, etc.). A CMDB must be kept up-to-date, large organizations often have complex hybrid landscapes with hundreds of thousands of assets, such as on-premise servers, network devices, Kubernetes workloads and managed cloud services.

The heterogeneous nature of modern IT landscapes is driving the usage of asset discovery tools that are tailored to specific contexts, which can enable near real-time asset discovery. Given the speed at which environments change, automation becomes essential, this is particularly important when tracking ephemeral assets such as containers, virtual machines and serverless services.

A mature CMDB accurately tracks all assets through their entire lifecycle. The support status of an asset is often used to determine and trigger certain cybersecurity measures. Throughout the asset identification stage of an automated vulnerability management process, the asset lifecycle status can be leveraged to determine which measures to apply.

Asset Metadata #

Designing a functional CMDB requires a deep understanding of all assets in scope. Foundational metadata such as hostname, IP address, and hardware specifications are important, however combining it with business context data that enables the CMDB to become a dynamic resource for vulnerability management.

Asset management teams might fail to identify context that is relevant for cybersecurity controls when structuring the metadata, considering that a risk-based vulnerability assessment process is implemented, missing context will directly hinder the accuracy of the assessment, which is why asset management programs must always consider cybersecurity teams as critical stakeholders.

Asset criticality and business context are pivotal for risk-based vulnerability assessment processes. By cataloging each asset’s importance to organizational operations, cybersecurity teams can assign priority levels matching its real-world risk. This contextual information allows vulnerability assessments to move beyond severity scores, focusing remediation and resource allocation based on impact to the business, rather than dispersing them evenly across all assets.

Asset Ownership #

Assets must be associated with a specific team or department, in the context of a CMDB this is often called asset ownership, and it is an integral part of an asset metadata. Vulnerability management processes rely on the asset ownership data to report vulnerabilities only to relevant stakeholders, which enables timely remediation actions and clear escalation paths, whilst reducing alert fatigue.

Large enterprises operating microservices and other distributed architectures, depend on clear asset ownership assignments for each service or application layer in order to generate accurate vulnerability reports and remediation plans. By maintaining updated metadata that explicitly designates responsible teams, automated reporting can map each detected vulnerability to the relevant microservice and, consequently, to the engineers accountable for its maintenance.

The definition of owner can vary depending on the organization’s asset management model. In certain CMDB designs, the asset owner refers to the individual or department financially responsible for procuring and managing the asset lifecycle, rather than the team responsible for its technical maintenance and security upkeep. To address this distinction, some CMDB implementations include an additional asset maintainer field to explicitly designate the team accountable for the asset’s technical operations, including applying security patches, software updates, and configuration management. Identifying how these metadata fields should be integrated into vulnerability management reporting processes is relevant to guarantee that reports are delivered accurately.

Risk-Based Vulnerability Management #

Risk-Based Vulnerability Management ³ is a broad and intricate subject, spanning from traditional threat intelligence, compliance requirements to large language model (LLM) risk assessments. Although a comprehensive examination of this subject will be featured in a future article, the scope here will focus mainly on strategies used to integrate detailed asset metadata into refined prioritization workflows.

Vulnerability management programs often craft a risk scoring formula that computes a risk score per vulnerability instance that goes beyond baseline severity measurements (e.g. CVSS), by accessing CMDB data through its APIs, the vulnerability management platform can enrich vulnerability detections with the asset contextual information. Referencing a common asset identifier known by the vulnerability scanner and the CMDB, such as an IP address, hostname, or workload name, enables the business-relevant metadata for the asset to be retrieved, such as ownership, environment, criticality, compliance details, etc.

CMDB Integration Strategies for Complex Landscapes #

IT landscapes from large organizations are generally complex, and carry extensive contextual metadata, which is why integrating a CMDB directly to a vulnerability management platform will at a minimum limit how risk-based initiatives are implemented, possibly even being an unfeasible implementation approach when considering that both platforms are not customizable to capture all data enrichment requirements.

The asset types in scope might require multiple vulnerability scanning tools that are tailored to particular assets or platforms. Traditional network-based scanners, container-focused solutions and cloud native scanning services often coexist in the toolkit of vulnerability management teams.

Developing an in-house unified risk-based vulnerability assessment and reporting platform, enables the consolidation of vulnerability detections from the different tools in a common structured format, optimized to be enriched with asset context from the CMDB. The unified, contextualized and risk scored data can be leveraged by analysts to streamline processes, respond faster, and ensure that decision-making is consistently driven by accurate, up-to-date risk information, rather than consuming information from multiple tools.

Relevant Asset Metadata for Risk Scoring #

An effective vulnerability risk scoring formula can only be achieved if the CMDB can provide accurate asset context, and only with this solid foundation other enrichment sources can be integrated to further refine the prioritization. In addition, specific asset types often include unique metadata that is relevant for risk-based vulnerability scoring, therefore formulas are designed to integrate both the shared and specialized metadata, aiming at providing an accurate assessment of risk for each asset type.

Elementary Asset Metadata Examples #

The table below illustrates how asset criticality, asset exposure, compliance status, and ownership, often serve as fundamental descriptors shared across a variety of asset types, shaping how risk is assessed and prioritized.

Metadata	Purpose	Impact on Risk Scoring
Asset Criticality	Indicates the impact of the asset being compromised or offline.	Vulnerabilities on high criticality assets receive elevated risk scores, as their compromise has a significant business impact.
Asset Exposure	Indicates how easily reachable the asset is by attackers.	Establishing the exposure context of an asset enables the risk scoring formula to determine if the detected vulnerability poses an even greater risk due to its context, such as a being a Remote Code Execution.
Regulatory Classification	Indicates whether the asset handles sensitive or regulated data.	The risk scoring formula must interpret the regulatory context to ensure compliance, adapting the risk score based on the specific requirements of each legislation, for instance, the Payment Card Industry Data Security Standard requires organizations to maintain a minimum frequency of scanning and patching of vulnerabilities.
Asset Owner / Maintainer	Indicates the team or individual responsible for the asset’s technical and security maintenance.	Vulnerabilities on assets owned by executives, administrators, or privileged users may be scored higher due to the potential impact in case of compromise.

Asset-Specific Metadata Examples #

Enterprise landscapes hosts a diverse range of assets, from on-premise servers, laptops, to containers and cloud-native workloads, each with different threat profiles and criticality. Identifying and consuming relevant asset-specific metadata enables the risk scoring formula to assess each asset type through its unique lens.

• Virtual machine (VM) images serve as templates for rapid deployment, allowing organizations to create multiple identical instances with less configuration overhead. This provisioning approach means that when a vulnerability is detected in a single VM, it is likely present across all other instances derived from the same image. Contextual metadata tracking the number of VMs using a particular image can then be used to easily determine the potential exposure and attack surface, which combined with elementary asset context can more accurately represent the risk.

• Cloud assets introduce new dimensions to risk scoring as prioritization will often require alignment with the shared responsibility model from cloud providers. Distinguishing between managed services and customer managed infrastructure can be achieved when cloud assets are fully supported by the CMDB.

• The ephemeral nature and layered structure of containerized environments challenge vulnerability management programs to adapt the most in the pursuit of accurately capturing its contextual metadata for the risk scoring formula. Multiple asset types might exist in the CMDB to represent containerized services, such as images, workloads and deployments, therefore it is imperative to understand the container lifecycle to leverage the correct asset type in each phase.

• Kubernetes orchestration adds another contextual layer, where workloads are often deployed with the main application container and several secondary containers proving specific functionalities running images that are shared across the platform. Identifying these components and contextualizing them in the CMDB allows the risk scoring formula to assess the service criticality according to the Kubernetes workload specific architecture.

Surveying the organization’s existing asset types and their associated contextual metadata enables vulnerability management experts to determine which attributes are relevant and should be integrated into the risk scoring formula. Additionally, this process helps identify missing or incomplete contextual data that could improve the risk calculation accuracy if made available. Documenting these gaps and collaborating with asset management teams ensures the continues refinement of the risk scoring model over time.

Correlation of Risk Scoring and Alert Fatigue #

A finely tuned vulnerability risk scoring formula, informed by relevant asset and vulnerability context, helps alleviate the challenge of alert fatigue among maintenance teams. By focusing on meaningful data points, organizations can pragmatically allocate resources on genuinely high-impact vulnerabilities over those that pose inferior risk. Consequently, maintenance teams receive fewer, more pertinent alerts, enabling them to plan and remediate vulnerabilities that truly threaten the environment with minimal disruption to existing planned work and operations.

Conclusion #

A comprehensive asset inventory is the cornerstone upon which effective, risk-based vulnerability management practices are built. As discussed throughout this article, a continuously updated CMDB drives contextualized risk scoring, more accurate prioritization, and more efficient remediation. Without a clear scope of which assets exist and their business context, organizations risk allocating finite resources inefficiently or even neglecting high-impact vulnerabilities.

For vulnerability management programs that have yet to achieve a robust inventory process, understanding these requirements and advocating for the necessary tooling and integrations is imperative, knowing that a meaningful shift in security posture can be achieved by ensuring that vulnerabilities are tackled where they matter most and that risk is managed in alignment with actual business priorities.‌

 

‌