CSA (312-39) SOC Simulation Lab
In this simulation, you will step into the early stages of the Incident Response Analysis phase. You'll learn how to approach high-severity SIEM alerts, distinguish actual threats from benign administrative noise, and prioritize SOC resources effectively before escalating an incident.
Scenario Context
You are a Tier 2 SOC Analyst at a mid-sized healthcare provider. It's 2:00 AM local time.
Your SIEM (Splunk) just fired a high-severity alert triggered by your newly deployed EDR solution.
The alert indicates possible ransomware behavior (Shadow Copy Deletion) on a critical database server (SRV-DB-04).
The SOC has been dealing with severe "alert fatigue" lately because the EDR policies are still in tuning mode, and IT administrators frequently run unannounced maintenance scripts overnight.
Security Environment Telemetry
Rule_Name: Suspicious Volume Shadow Copy Deletion
Host: SRV-DB-04
User: DOMAIN\svc_backup_admin
Process_Command_Line: vssadmin.exe delete shadows /all /quiet
Parent_Process: C:\Scripts\Nightly_DB_Prep.ps1
Investigative Action
The Security Operations Center (SOC) team is investigating a suspected malware incident during the Analysis Phase of their incident response process. Their primary goal is to validate the initial detection, ensure the threat is real, and gather critical intelligence to understand the scope of the attack. Which of the following actions should the SOC team take to confirm their initial findings and eliminate false alarms?
Nightly_DB_Prep.ps1 run by svc_backup_admin. Before we wake up the Incident Commander and declare a ransomware outbreak, what is the absolute first conceptual step we must do with this alert?
Senior SOC Analyst Debrief
Classification: TLP:CLEAR // Phase: Triage & Analysis
1. The Situation
We caught a high-fidelity indicator of ransomware behavior: deleting shadow copies (`vssadmin`). However, looking at the logs, it was executed by a service account (`svc_backup_admin`) via a scheduled script (`Nightly_DB_Prep.ps1`). In a real SOC, 90% of your time is spent distinguishing malicious activity from poor IT hygiene. If you declare an incident without validating, you burn out your IR team.
2. Why 'B' is Correct
Verify false positives is the mandatory first step of the Analysis phase in the CSA/NIST incident handling lifecycle. Before you calculate scope, declare severity, or start containment, you must confirm the alert represents an actual security incident. In our scenario, validating with the DB admins whether that script is authorized verifies if this is a true positive or a false alarm.
3. Why Other Options Fail the Workflow
- A (Scan & update scope): Scoping is critical, but it happens after you confirm it's a real incident. You don't scan the whole enterprise for a false alarm.
- C (Verify generated logs): This is a method used during analysis, but the overarching procedural goal/action required here to "eliminate false alarms" is explicitly verifying the false positive.
- D (Root-cause analysis): RCA is conducted during the Eradication/Recovery phases or Post-Incident phase. We are way too early for RCA; we don't even know if we have an incident yet.
Mandatory SOC Lesson: The Triage Pipeline
When an alert hits the SIEM, junior analysts often rush to contain. Senior analysts follow a strict pipeline:
- Alert Generation (EDR -> SIEM)
- Validation (Is it real? Is it authorized? -> Verify False Positives)
- Triage & Prioritization (Assign severity)
- Incident Declaration (Kick off formal IR processes)
Pro-tip: Once you verify this alert is a false positive (authorized script), immediately write a tuning exception in your SIEM to whitelist `vssadmin.exe` ONLY when executed by `Nightly_DB_Prep.ps1` via `svc_backup_admin`. This permanently reduces alert fatigue.