Asset life cycle, the CMDB, and an inventory you can trust

Why this matters

Almost every other control in this course silently assumes this one works. Vulnerability management scans a scope, and the scope comes from the inventory. Monitoring expects telemetry from a known set of sources, and "known" comes from the inventory. Segmentation places assets in zones. Risk assessment assigns impact to assets. Incident response asks what else that account could reach.

When the inventory is wrong, every one of those degrades in the same direction — they all become confident about a subset and blind to the remainder — and none of them reports a problem, because each is working correctly on the data it was given. This is the most important structural idea in domain 1, and it is why CompTIA place configuration management in the governance domain rather than in operations.

The examinable form is usually a scenario in which a breach involved a system "not included in the scanning scope" or "no longer in use but still connected". Recognising that the failure is inventory rather than the control that missed it is the point.

The lesson

The life cycle from acquisition to secure disposal, and the security decision at each stage

The asset life cycle is worth learning as a sequence of decisions rather than a diagram, because scenarios describe a stage and ask what should have happened.

• Planning and acquisition. Before anything is bought, the decisions are classification of the data it will hold, the security requirements that follow, and supplier due diligence. A control specified here costs negotiation; the same control retrofitted later costs a project.
• Deployment. The asset is built to a baseline, given an owner, given an identity, and recorded. Recording is a security act: an asset that enters service without a record has entered the estate without entering any scope.
• Operation and maintenance. Patching, configuration drift, access review, monitoring coverage. The examinable idea is that ownership must persist — assets whose owner has left the organisation are the ones that stop being maintained.
• Change and repurposing. A system that moves environment, changes function or changes data classification needs re-evaluation. Repurposing is a common source of silent misclassification: a decommissioned production host reused for testing, still holding production data.
• Decommissioning and disposal. Data destruction appropriate to classification and media, revocation of every identity and credential the asset held, removal of network and firewall entries, certificate revocation, licence reclamation, and closure of the record.

The security decision that recurs at every stage is the same one: what data does this asset hold or reach, and who is accountable for it. An asset whose answer to either is unknown is a finding regardless of how it is configured.

What a configuration management database holds beyond a list of hostnames

A CMDB is not an inventory of machines. It records configuration items — anything under configuration control — and, crucially, the relationships between them. That second half is what makes it useful and what most implementations neglect.

Per item, the fields that matter for security work:

• Identifier, stable across renames and re-addressing.
• Type and environment — production, test, development, and what kind of thing it is.
• Owner, a role rather than a person, plus the business service it supports.
• Data classification, inherited from the data it processes or stores.
• Lifecycle state — planned, live, retired — because "exists" and "in service" are different questions.
• Source of the record and when it was last confirmed.

The relationships are what turn that into something you can reason with: this service depends on that database, which runs on those hosts, which sit in that segment, which is reached through that gateway. With relationships, "what is the blast radius of this compromised host" is a query. Without them it is an investigation.

Scope is broader than hardware and is where most estates under-record. An identity, a role, a certificate, a DNS zone, a cloud subscription, a SaaS tenancy, a pipeline, a container image, an API and a data flow are all configuration items with owners and lifecycles. The cloud and identity items are the ones most often missing, and they are also the ones most often exploited, because nothing was watching a resource nobody had recorded.

Why an inventory that is 90% accurate is not 90% useful for vulnerability management

This is the idea to take away from the lesson, and it is arithmetic rather than opinion.

If an inventory covers 90% of an estate, a vulnerability management programme built on it cannot exceed 90% coverage — and an attacker is not choosing uniformly at random. Unrecorded assets are disproportionately the ones that are unowned, unpatched, unmonitored and forgotten, which is precisely the population an attacker is looking for. The missing 10% therefore carries far more than 10% of the risk.

Worse, the programme's own reporting is computed over the known set. Remediate every finding on the recorded 90% and the dashboard shows 100% compliant. The number is true and the conclusion it invites is false, and nothing in the pipeline can detect that, because a scanner cannot report on an address it was never given.

Two consequences are examinable. Inventory completeness is itself a security metric and belongs in reporting next to remediation rates — a remediation figure quoted without a coverage figure is not interpretable. And the fastest improvement to most vulnerability programmes is not faster patching but better discovery, which is counter-intuitive enough that scenarios are built on it.

Reconciling discovery output against the CMDB and treating the difference as a finding

The mechanism that keeps an inventory honest is continuous reconciliation between what is recorded and what is observed, from sources that do not share a blind spot.

Useful observation sources, deliberately overlapping:

• Active network discovery across owned ranges.
• Passive observation — DHCP leases, ARP tables, switch port data, NetFlow.
• Identity provider and endpoint management enrolment.
• Cloud provider APIs, per account and per region, which is where forgotten resources accumulate.
• Certificate transparency logs and external DNS, which reveal internet-facing assets nobody registered.

Reconciliation produces three classes, and each is a different problem:

1. Observed, not recorded. An unmanaged asset. Highest priority: it is in no scope at all. Includes shadow IT, forgotten projects, and anything arriving through an acquisition.
2. Recorded, not observed. Either decommissioned without closing the record, or present and not visible to your discovery — which is the more serious reading and the one to rule out first.
3. Recorded and observed, attributes disagree. Wrong owner, wrong environment, wrong classification. Quietly damaging, because downstream controls act on the wrong attribute confidently.

The governance part is that each difference is a finding with an owner and a due date, not a list to be regenerated weekly and ignored. A reconciliation report that nobody is accountable for closing produces the same number every week, and the stable number gets read as normal.

Decommissioning: the asset that no longer exists but still holds a certificate and a firewall rule

Decommissioning is where the life cycle most often fails, because the business driver disappears the moment the service stops being used. The machine is switched off, the project closes, and the artefacts the asset accumulated remain.

What typically survives a careless decommission, and each is a live exposure:

• Identities and credentials — service accounts, API keys, certificates — still valid and now unmonitored.
• DNS records pointing at an address that has been released, which is the precondition for subdomain takeover: someone else acquires the address or the service name and inherits your hostname's reputation.
• Firewall rules and security group entries authorising traffic to an address that has been reallocated, possibly to a different tenant.
• Backups and snapshots holding the data the destruction plan covered on the live volume only.
• Monitoring and log forwarding, whose silence is indistinguishable from a healthy quiet system.
• Licences and subscriptions, a cost rather than a risk, and the one most likely to get the process funded.

The controls that address this are unglamorous and effective: decommissioning as a change with a checklist covering each artefact class, the CMDB relationships used to enumerate what the asset was connected to, and a scheduled review of resources whose owner has left or whose parent service is retired. Data destruction is sized to classification — cryptographic erase where the preconditions hold, physical destruction where they do not, and both covered in domain 3.

The scenario to recognise: an organisation compromised through a hostname that resolved to infrastructure it no longer owned. Nothing was misconfigured. The record was never closed.