Help desk tells the SOC the city was breached because an IDS signature fired toward the elections file server. Which CIM field should the analyst check first before escalating?
Select an answer to reveal the explanation.
Short Explanation
An IDS fire can be a smoke alarm that already went off in a locked vault. Check action first: allowed versus blocked. Do not call a breach until you know the control actually let the session through.
Full Explanation
When help desk escalates an IDS signature aimed at the elections file server as a city breach, the first CIM question is whether the control already stopped the session. On Network_Traffic and Intrusion_Detection, the action field records allowed versus blocked (or equivalent control outcomes). Checking action before paging executives separates a blocked signature fire from traffic that actually reached the elections host. That single field keeps civic incident commanders from treating every IDS hit as confirmed compromise.
Placing http_user_agent on the Authentication data model fails by concept: user-agent belongs on Web-model browsing or proxy telemetry, not on logon identity, and it does not answer allow-versus-block. Using src_user on the Web model because IDS events are mail hops confuses intrusion detection with mail identity and puts the wrong CIM field on the wrong model. Looking for file_hash on DHCP leases invents a hash field on address-assignment logs that neither store malware fingerprints nor describe IDS disposition.
Exam caveat: SPLK-5001 items often bait candidates to chase exotic fields or declare breach from signature name alone; remember action on Network_Traffic or Intrusion_Detection is the first control-outcome check.
Operational check: open the IDS or firewall events for the elections file server in the appropriate CIM model, filter or inspect action for blocked versus allowed, and escalate as breach only when evidence shows the control permitted the session—or when endpoint confirmation independently proves impact.