Configuration management is the practice that gets cut first. It produces no visible service, no customer-facing improvement and no story at the town hall. It is a database of things you already own, maintained by people who could otherwise be closing tickets, and it is always slightly out of date.
I have watched it get deprioritised in more organisations than I can count. I have also watched what happens afterwards, and the pattern is always the same: the CMDB is never the thing that fails. It is simply the thing that would have made the failure survivable.
ITIL 5 keeps both practices and moves them where they belong. Service configuration management is “the practice of ensuring that accurate and reliable information about the configuration of services, and the configuration items that support them, is available when and where needed.” IT asset management is “the practice of planning and managing the full lifecycle of all IT assets.” Both now sit in the Product and Service Management group, and in the qualification scheme they are grouped with change enablement, deployment and release in the Plan, Implement and Control module.
That grouping is the point. You cannot control change to something you have not recorded.
Three cases make the argument better than any maturity model.
Equifax: the scan that looked in the wrong place
On 7 March 2017, Apache disclosed CVE-2017-5638, a remote code execution flaw in Apache Struts with a CVSS score of 10.0. US-CERT alerted Equifax on 8 and 9 March. Equifax’s own internal alert stated the position clearly: “As exploits are available for this vulnerability … it requires patching within 48 hours.”
Two things then went wrong, and only the second one is really about patching.
The alert circulated to a distribution list that did not include the team responsible for the ACIS application. Nobody verified that patching had actually happened.
And the vulnerability scan missed it. Equifax’s scanning tools scanned the root directory of the web servers. The vulnerable Struts instance lived in a subdirectory. The scan came back clean.
That is an asset management failure wearing a security costume. The organisation did not fail to look; it failed to know where to look, because it had no accurate record of where the component was deployed.
ACIS — the Automated Consumer Interview System, an internet-facing consumer dispute portal whose lineage dated to the 1970s — remained vulnerable. On 13 May 2017, attackers exploited it.
Then the detection failed too, for a configuration reason
The SSL Visibility appliance inspecting ACIS traffic could not do its job, because its certificate had expired on 31 January 2016 and had not been renewed for nineteen months. Encrypted outbound traffic was not being inspected at all.
Equifax had over 300 expired certificates across its estate.
The attackers found unencrypted application credentials in plaintext configuration files and moved laterally. ACIS needed three databases to function; it could reach forty-eight unrelated databases. Roughly 9,000 queries were run, personally identifiable information was retrieved 265 times, and data was exfiltrated in small encrypted batches over seventy-six days without triggering an alert.
On 29 July 2017 the certificate was finally renewed. Suspicious traffic became visible immediately. ACIS was taken offline the next day.
Around 148 million individuals were affected — roughly 56 per cent of American adults. The July 2019 settlement with the FTC, CFPB and forty-eight states was at least $575 million, rising to $700 million. The House Oversight Committee’s conclusion was one sentence: “Such a breach was entirely preventable.”
The committee’s root causes read like a configuration and asset management audit: no comprehensive, accurate inventory of where the vulnerable software ran; certificate management failure across 300-plus certificates; no network segmentation; credentials in plaintext; PII unencrypted at rest; and an accountability gap between where policy was written and where it was executed.
Certificates, incidentally, are configuration items. Almost nobody treats them as such. An expired certificate on a monitoring appliance is a configuration item whose lifecycle nobody managed, and it cost Equifax seventy-six days of blindness.
Log4Shell: when even the organisations with SBOMs could not answer
In December 2021, CVE-2021-44228 in Apache Log4j 2 allowed unauthenticated remote code execution through a string in a log message. Because logging is everywhere and the attack string could arrive in any logged field — a user agent header, a username, a device name — the attack surface was, practically speaking, anywhere text was logged.
The US Cyber Safety Review Board’s first ever report examined it. Its central finding was not about the exploit. It was about the question every organisation on earth was asked that weekend and could not answer: where do we run this?
Four reasons, and each one is worth internalising.
Log4j was a transitive dependency. It was embedded inside other applications, frequently unknown to the operators of those systems. You did not have to have chosen Log4j to be running it.
There was no customer list. The Apache Software Foundation is a volunteer open-source foundation; it maintained no register of who used Log4j or which commercial products embedded it. The CSRB stated: “The fact that there is no comprehensive customer list for Log4j hindered defender progress.”
Scanning did not work. Log4j could be repackaged inside JARs, shaded, or renamed inside fat JARs, which defeats file-name and hash-based detection.
And software bills of materials did not save anyone. This is the finding I found most sobering. Organisations that already had SBOMs could not use them to locate vulnerable deployments. The CSRB found SBOM practice lacked standardisation, reliable version information and automation — making it ineffective for a fast-moving response.
Cloudflare observed roughly 400 exploitation attempts per second within five days of disclosure. CISA issued Emergency Directive 22-02 on 17 December requiring federal agencies to enumerate every internet-facing solution containing Log4j and mitigate it, on a deadline measured in days, and stood up a public GitHub repository of affected software — effectively crowdsourcing the customer list that did not exist.
One US federal cabinet department reported dedicating 33,000 hours to Log4j response. That is the most useful number in the entire case, because it converts an inventory gap into a payroll figure.
The CSRB concluded that Log4j is an “endemic vulnerability” that will remain present in systems “for a decade or longer.”
Maersk: the backup that was one backup, replicated 150 times
NotPetya reached Maersk through a single machine. A finance executive in the company’s Odessa office had asked for M.E.Doc, Ukrainian tax accounting software, to be installed on one computer. The attackers had compromised M.E.Doc’s update server.
One installation was enough. NotPetya spread laterally across a flat global network at machine speed, encrypting master boot records with no recoverable key.
Then it destroyed all 150 of Maersk’s domain controllers simultaneously.
The controllers were designed to replicate to each other as mutual backups. That is a perfectly reasonable design, and it is resilient against individual failure. It is completely defenceless against correlated destruction. As I have written elsewhere about hot standbys in air traffic control: 150 mutually-replicating domain controllers is not 150 backups. It is one backup, replicated 150 times.
Without domain controllers, Maersk could not rebuild Active Directory. Without Active Directory, it could not rebuild anything else.
The company was saved by a power cut. A domain controller in a Maersk office in Ghana had been offline when NotPetya struck and held the only surviving copy of the directory. The Ghana office lacked the bandwidth to transmit several hundred gigabytes to the recovery centre in Maidenhead, so Maersk flew an employee to Nigeria to hand a physical drive to a colleague, who flew it to Heathrow.
Maersk rebuilt approximately 4,000 servers, 45,000 PCs and 2,500 applications. Seventy-six port terminals were affected. Up to 400 Maersk staff and 200 consultants worked simultaneously at the recovery site. Booking ran on WhatsApp, Gmail and Excel. Partial operations took about ten days; complete software restoration took nearly two months.
The financial impact, in Maersk’s own Q3 2017 report: “Cyber-attack had a significant impact on the operations in Transport & Logistics, with a financial impact of USD 250-300m.”
The structural causes are all configuration and asset management. A flat global network with no meaningful segmentation. A backup design that protected against individual failure but not correlated failure. No offline or air-gapped copy of the directory. And software installed at local business request, on one machine, without any central assessment of its update channel.
That last one deserves emphasis. Somewhere in your organisation right now, a local team is installing something because a regulator or a customer requires it, and no one central knows. Maersk’s entry point was a legitimate business requirement met by a legitimate local decision.
What to actually do
Nine things, ordered by how quickly they pay back.
1. Define what a configuration item is, narrowly and honestly. The classic CMDB failure is trying to record everything. Start with the configuration items whose absence would have made these three cases survivable: internet-facing applications and their component libraries; certificates and their expiry dates; identity infrastructure; and the relationships between applications and the databases they can actually reach.
2. Reconcile discovery against the record, and report the delta as a metric. The number that matters is not how many CIs you have. It is how many things discovery found that the record did not know about. Track it monthly. It is the only honest measure of CMDB quality.
3. Scan the whole filesystem, not the root. Equifax in one line. Then verify the scanner’s coverage independently of the scanner’s own report.
4. Treat certificates as managed configuration items with owners and expiry alerts. Three hundred expired certificates is not a security failure, it is a lifecycle failure. And check specifically for expired certificates on the appliances that perform your monitoring, because those failures are silent by construction.
5. Map application-to-database reachability, then constrain it. ACIS needed three and could reach forty-eight. That number exists in your estate too; nobody has ever measured it.
6. Build a dependency inventory you can query in an hour. The Log4Shell test: when the next endemic vulnerability lands on a Friday evening, how long before you can produce a defensible list of where the component runs? If the answer is “we would ask the teams,” your answer is days, and days is the whole problem. SBOMs are necessary but the CSRB found them insufficient without standardisation, versioning and automation — so test yours against a real query before you rely on it.
7. Audit for correlated backups. For each critical dependency, ask whether the copies share a failure mode: same credentials, same network, same automation, same update channel, same time. At least one copy of your identity infrastructure should be offline. Maersk’s survival was luck, and luck is not a control.
8. Find the locally-installed software. Ask business units directly what they have been required to install by a regulator, a customer or a partner. You will not find this in a discovery scan if the machine is not managed, which is exactly the machine you are looking for.
9. Put the lifecycle end on the record. ITIL 5’s asset management practice is about “the full lifecycle of all IT assets,” and the framework’s new eight-stage lifecycle model — Discover through Support — conspicuously omits decommissioning. Add it yourself. Half of what you are struggling to inventory should not be running at all.
The argument for funding it
Configuration and asset management will never win a business case on their own merits, because their benefit is the absence of an event.
So make the argument with someone else’s numbers. Equifax: at least $575 million and a finding that the breach was “entirely preventable,” where the proximate technical failure was scanning a directory that did not contain the software. Log4Shell: 33,000 hours in one government department, and a formal finding that existing SBOMs were unusable. Maersk: $250 to $300 million, and a recovery that depended on a power cut in Ghana.
None of those organisations lacked money, tooling or talent. Each of them, at the critical moment, could not answer a simple question about its own estate.
The CMDB is not paperwork. It is the list you will be asked for on the worst day of your year, by someone who needs the answer in an hour.
A minimum viable CMDB
The most common reason configuration management fails is over-scoping. Somebody decides to model the estate, the tooling is bought, the discovery is run, and eighteen months later there is a large database that nobody trusts and everybody works around.
Start smaller. If I had one quarter and a small team, this is what I would record — chosen entirely on the basis of what would have mattered in the three cases above.
Internet-facing applications, with: the business service they support, the named owner, the technology stack including framework and library versions, the environment they run in, and the date of the last vulnerability scan plus the scan’s coverage path. Equifax’s scan was clean because it looked at the root directory. Record what was scanned, not only that scanning happened.
Certificates, with: what they secure, expiry date, owner, renewal method, and — flagged separately — whether the certificate sits on a device performing security monitoring. Those failures are silent. Equifax had over 300 expired certificates and the one that mattered had been expired for nineteen months on the appliance that would have seen the exfiltration.
Identity infrastructure, with: every instance, its replication relationships, and the location and recovery time of the most recent offline copy. If the answer to “where is the offline copy” is a shrug, you are relying on the same luck Maersk had.
Application-to-datastore reachability, expressed as: what this application needs, versus what it can actually reach. The gap between those two numbers is your lateral movement exposure, and almost nobody measures it.
Third-party and open-source components, at least for internet-facing and business-critical applications, with a version you could query in an hour. Not a perfect software bill of materials — the Cyber Safety Review Board found that existing SBOMs were unusable during Log4Shell for lack of standardisation, versioning and automation. A queryable list that is 80 per cent complete and known to be 80 per cent complete beats a formal artefact nobody has tested.
Supplier-managed components, with: who can change them, whether the change is visible to you, and whether you can defer it. Post-CrowdStrike, that last column is the one to fill in first.
Six tables. Every one of them is answerable, and every one of them was the missing answer in a case that cost somebody hundreds of millions.
Then the discipline that makes it real: reconcile discovery against the record monthly, and publish the delta. Not the size of the CMDB — the number of things discovery found that the record did not contain. That single number is the only honest measure of whether your configuration management is working, and it is the one I ask for first.
Sources
- US House Committee on Oversight and Government Reform, The Equifax Data Breach (majority staff report, December 2018)
- Federal Trade Commission, FTC v. Equifax Inc. — stipulated order and settlement announcement, 22 July 2019
- Cyber Safety Review Board, Review of the December 2021 Log4j Event (11 July 2022)
- CISA, Emergency Directive 22-02: Mitigate Apache Log4j Vulnerability (17 December 2021)
- A.P. Møller-Mærsk A/S, Interim Report Q3 2017 (financial impact of the June 2017 cyber attack)
- Andy Greenberg, The Untold Story of NotPetya, WIRED (August 2018), and Maersk executives’ public conference accounts of the recovery
- ITSM.tools, ITIL (Version 5) management practices (practice definitions and grouping) — itsm.tools
- ILX Group, Introducing ITIL (Version 5) (Plan, Implement and Control module contents) — ilxgroup.com