What does a CMDB asset criticality and owner lookup tell you about whether an alert is malicious?

## The problem enrichment solves A detection arrives carrying almost nothing a human can reason about. A rule over a database audit trail fires because one session read four million rows from a cardholder table at 04:03. The record names a database account, an object, a client host and a timestamp. None of those are meaningful on their own: the account is a string, the host is a hostname, the object is a schema and table name. **Enrichment is the set of lookups an analyst - or an automation acting for them - runs against non-security systems of record to attach meaning to those bare identifiers before forming a verdict.** ## Two classes of enrichment, and only one of them moves the verdict **Consequence enrichment** answers *what is at stake*. It comes from the configuration management database (CMDB) and its neighbours: criticality or service tier, environment (production, staging, test), data classification, internet exposure, the business service the asset supports, and the owning team. **Evidence enrichment** answers *what explains this behaviour*. It comes from records about the event and the actor: a change record whose scope and window may cover it, the break-glass account checkout register that names the human behind a shared account, the directory's role and working-hours attributes, the account's sign-in history, the parent process, the destination of the data. A fact can only change the probability that something was hostile if a hostile world and a benign world would have produced different values of it. Asset criticality is identical in both worlds. It was true last week and will be true next week, and no adversary decision changed it. So it cannot be evidence *about the event*. The break-glass checkout register can: in the benign world it names the DBA who was paged, and in the hostile world it is empty or names someone who was asleep. ## What criticality and owner genuinely do change - **Queue order.** A moderate alert on a tier-1 payments database is worked before a loud one on a scratch VM. That is not a statement about likelihood; it is a statement about expected loss. - **Who you contact, and how quickly.** The owner is usually the fastest source of *evidence* enrichment - they can say in one sentence whether the export was theirs. - **What response is available.** Isolating a tier-1 database with cardholder data is a business decision needing an owner on the phone; isolating a disposable test host is not. - **Scope framing.** If the verdict does end up malicious, the data classification tells you what an intruder could have reached, which is what the rest of the investigation has to bound. ## The two symmetrical mistakes **Upgrade by criticality.** *It is a crown-jewel database, so this is probably an attack.* This inflates a verdict on consequence. It produces escalations that burn responder time and the owning team's goodwill, and it teaches the SOC that important assets are noisy. **Downgrade by label.** *The CMDB says non-production, close it.* Development and test estates routinely hold copies of production data, valid production credentials, and a network path onward. A host being unimportant to the business does not make it unimportant to an intruder, who is looking for a foothold rather than a crown jewel. ## Treat the CMDB as testimony, not telemetry A CMDB is populated by humans at build time and rarely revalidated. Owner fields survive reorganisations, team splits and leavers; criticality is whatever the person filling in the form selected. A field from it is a **lead you corroborate**, not a fact you assert. Corroborating signals are observable rather than declared: who deploys to the asset, whose on-call rota covers it, which team's service accounts authenticate to it, what the cloud resource tags say, who has approved changes to it in the last year. When two of those disagree with the CMDB, write in the case notes which one you used and why. ## The worked case The 04:03 export lands on payments-db-prod-01. The CMDB says tier 1, cardholder data, owner the payments platform team. That lookup moves the alert to the top of the queue and makes a 04:20 phone call worth its cost. It does not shift the verdict a millimetre. The verdict still hangs on the break-glass checkout register, on whether an emergency change record covers this schema in this window, and on where the rows went. Run the same export against a tier-4 reporting replica and the verdict would be exactly the same; only the urgency would differ. ## Answering it in an interview Say the split out loud, name one lookup from each class, and state precisely what each can and cannot conclude. Then add the one line that shows you have worked a queue: the CMDB is often wrong, so an owner field is where you start looking for a human, not proof that you have found one.