A SOC analyst reviewing SIEM output sees three low-confidence alerts for the same workstation: an unusual login location, a PowerShell command with encoded arguments, and DNS queries to a newly registered domain. No single alert is high severity. What should the analyst do first to determine malicious activity?
Select an answer to reveal the explanation.
Short Explanation
Think of SIEM like a detective: one odd clue isn't proof, but a login, script, and beacon from the same host in the same window is a pattern. Don't chase the loudest single alert—correlate by user, host, and time to raise confidence. That's how you turn low-confidence telemetry into a credible incident.
Full Explanation
SIEM correlation works by evaluating several low-fidelity indicators against a common entity, such as the same user, host, and narrow time window. Any one weak indicator may be noisy, but when artifacts from authentication, endpoint execution, and network resolution appear together, the rule raises confidence and supports triage as a possible attack sequence. The analyst should therefore correlate the alerts before deciding whether escalation, containment, or tuning is needed. Escalating only the highest-severity alert while suppressing the others discards the supporting evidence that turns isolated noise into a pattern. Treating each low-confidence alert as benign until the endpoint is quarantined reverses the analyst's burden of proof and delays detection of activity that may not yet justify automatic containment. Blocking a destination after one DNS beacon alert is a containment action taken without sufficient confidence and can disrupt legitimate traffic while masking the underlying activity. Exam caveat: CS0-004 often asks for the next analytic action, not the first containment step, when multiple weak signals point to the same asset. Operational check: pivot in the SIEM on the affected host, user, and time range, then review EDR process lineage, DNS logs, and authentication events for a coherent sequence.