What does a CMDB asset criticality and owner lookup tell you about whether an alert is malicious?
answer
- stakes versus likelihood
- consequence enrichment, evidence enrichment
- true yesterday, true tomorrow
- owner field is a lead
- test label closes nothing
basics
~20 sNothing. Criticality and owner tell you what is at stake and who to ask, so they change urgency, routing and the response you may take. Only evidence about the behaviour itself moves a malicious-or-not verdict.
solid answer
~50 sSplit enrichment into two classes. **Consequence enrichment** - CMDB criticality tier, production versus test, data classification, owner - tells you what is at stake if the activity turns out to be hostile. **Evidence enrichment** - the change record covering the window, the break-glass checkout register, the account's role and normal hours, its sign-in history - supplies or removes an innocent explanation for the behaviour. Only the second class can flip the verdict, because criticality was equally true yesterday and so cannot be evidence about tonight's event. What criticality and owner do change is real: the order you work the queue, who you call first, and whether the containment you are considering is a business decision. Both directions of misuse are errors - inflating a verdict because the asset is a crown jewel, and closing one because the record says test.
go deeper
Be ready to list the lookups you run when an alert lands and to say, for each, whether it changes what is at stake or what you believe happened. Never answer that a critical asset makes an alert more likely to be an attack.
Explain why criticality cannot be evidence: its value is the same whether or not the activity was hostile. Then show the mechanics of a lookup that is evidence, such as joining a shared account in an audit record to the register that names the human.
Show judgment about source quality. Say how you corroborate a CMDB field against observed signals, what you write in the case when they disagree, and how you avoid both inflating a verdict on a crown jewel and closing one on a host labelled test.
Own the consequences of relying on data another team maintains. Be ready to say which enrichment sources you will treat as authoritative, what the SOC does when they are wrong, and how you price the triage cost of bad asset data to the people who can fix it.
## 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.
- Name an enrichment lookup that can move the malicious-or-not verdict, and say why it can.The break-glass account checkout register. The database audit trail names a shared account; the register names the human who took it and when. A checkout at 03:58 by the DBA who was paged supplies an innocent explanation for the 04:03 export; no checkout at all removes one. Unlike criticality, its value differs between the benign and the hostile world, which is what makes it evidence.
- The CMDB marks the host as non-production. Is that enough to downgrade and close?No. The label is self-reported and often years old, and non-production estates commonly hold production data copies, live credentials and a route into the production network. Verify the label against something observed - what the host authenticates to, what data the schema actually holds - and remember that an intruder values a foothold, not your service tier.
- The CMDB owner left the company two years ago. How do you get an owner without stalling triage?Fall back to observed ownership: the on-call rota covering the service, recent deployment or change actors, repository code owners, the directory manager chain above the last known owner. Keep triaging while you resolve it - the verdict work does not depend on the owner - and record the stale entry as a finding so the gap gets fixed rather than rediscovered at 04:00 next month.
Knowing a burgled building is a bank rather than a shed tells you how much to worry and who to phone. It tells you nothing about whether the open window was forced or left open by a cleaner.
saying these in an interview costs you the question
- Says a critical asset makes the alert more likely to be malicious
- Closes an alert because the CMDB calls the host a test system
- Treats the CMDB owner field as verified fact rather than a lead
- Cannot name a single lookup that would change the verdict
- Reports asset criticality as the outcome of triage