A city analyst is drafting an Enterprise Security correlation search for after-hours admin logons on court case-management servers. Which dataset should that search use?
Select an answer to reveal the explanation.
Short Explanation
Correlation searches should drink from a labeled tap—an accelerated Authentication model or a tight threat or risk index. index=* every few minutes is how a SOC melts its own search heads. Constrain first, then detect.
Full Explanation
An Enterprise Security correlation search for after-hours admin logons on court case-management servers should target the CIM Authentication data model or another constrained, normalized store such as the risk or threat index. Normalized, accelerated datasets keep scheduled detections fast, vendor-portable, and scoped to the fields those detections need. Constraining the search dataset is a SIEM best-practice skill: the court SOC gets reliable notables without melting search heads on unbounded scans. Aim the detection at the labeled tap, not the whole lake.
Using index=* with no sourcetype or time bound across the whole city deployment fails by concept: it is an unbounded scan that destroys performance and consistency. Using only the _internal index because correlation searches must audit search heads confuses platform introspection with Authentication CIM evidence for admin logons. Choosing a randomly chosen raw index each night so attackers cannot predict the search invents security-through-obscurity and abandons CIM field reliability.
Exam caveat: ES correlation-search items expect constrained CIM or risk/threat datasets—not index=*, _internal-only, or randomized raw indexes.
Operational check: point the after-hours admin logon correlation at Authentication (or a tight risk/threat store), verify court case-management hosts and admin identity fields resolve, schedule the search, and confirm it completes within acceptable time without city-wide index=*.