A wastewater plant tabletop uses the Diamond Model of adversary, capability, infrastructure, and victim. How should the analyst apply those vertices in Enterprise Security?
Select an answer to reveal the explanation.
Short Explanation
Diamond is a thinking square, not a Splunk index. Adversary, capability, infrastructure, and victim tell you what to pivot on — IPs, domains, plant assets — inside the ES you already have. Do not go hunting for a Diamond sourcetype.
Full Explanation
A wastewater plant tabletop that uses the Diamond Model should apply adversary, capability, infrastructure, and victim as pivots inside the Enterprise Security environment the utility already runs. Analysts use those vertices to choose next hunts—for example infrastructure such as IPs and domains and victim assets such as historians or HMIs—rather than treating Diamond as a new Splunk object. Civic OT incident response benefits when Diamond stays an analytic square layered on existing ES evidence.
Searching a Diamond index because Splunk supposedly stores each vertex as a sourcetype fails by concept: Diamond is not an ingested log format or dedicated index. Replacing the CIM Authentication data model with Diamond fields fails by concept: CIM normalization is not displaced by an analytic model. Renaming a correlation search to Diamond Model so notables inherit the framework fails by concept: a cosmetic rename does not implement Diamond pivots.
Exam caveat: Diamond = four-vertex investigation framing (adversary, capability, infrastructure, victim), not an index, CIM model, or search rename trick.
Operational check: Update the plant IR playbook with Diamond prompts that force documentation of actor, tools, infra, and victim assets from ES events, and train Analysts to pivot on those fields without creating fictional Diamond sourcetypes.