CSA (312-39) SOC Simulation Lab

In this lab, you'll explore the SIEM Use Case Development Lifecycle. We will look at what a SOC engineer must do immediately after pinpointing the target logs, ensuring the infrastructure actually supports the detection logic.

Scenario Context

You are a Senior SIEM Engineer. The Threat Intel team requires a new use case: Detecting malicious PowerShell execution via Process Command Line arguments (T1059.001).

You have already successfully mapped out the MITRE ATT&CK requirement and identified the required event source: Windows Security Event ID 4688 (A new process has been created). You are preparing to write the final Splunk SPL detection rule, but first, you need to execute the next logical phase in the lifecycle.

Security Environment

You run a preliminary test query in Splunk against your target servers to examine the identified event source (Event ID 4688):

SPL> index=windows sourcetype=WinEventLog:Security EventCode=4688 | fieldsummary
field count distinct_count values
-------------------------------------------------------------------------
Account_Name 15042 12 SYSTEM, Admin...
Process_Name 15042 45 powershell.exe, cmd.exe...
Process_Command_Line 0 0 NULL
Creator_Process_ID 15042 104 0x4c, 0x1f4...

*Review the terminal output. Notice the field Process_Command_Line has a count of 0, meaning the data is entirely missing from the collected logs.*

Question

Which of the following stage is executed after identifying the required event sources?

SOC Hint: Look at the terminal output above. We identified the correct log source (4688), but the critical piece of data (Command Line) is missing. If you define the rule now, it will never trigger. What must you do before defining the rule?

Expert Insight

What is happening?

The SOC is executing the SIEM Use Case Development Lifecycle. While they correctly identified that Windows Event ID 4688 records process creation, the environment's Group Policy Object (GPO) does not have "Include command line in process creation events" enabled. If an analyst jumps straight into writing the detection rule, the rule will deploy successfully but silently fail to detect any threats, leading to a false sense of security.

Why Option D is Correct:

After identifying the log sources, you must validate the event source against the monitoring requirement. You have to prove that the logs being ingested actually contain the specific fields (like `Process_Command_Line`, `Source_IP`, or `Target_User`) necessary to satisfy the use case. If validation fails, you must reconfigure logging before proceeding.

Why the others are wrong:

  • A (Identifying the monitoring Requirements): This is the very first step in the lifecycle. You cannot identify event sources until you know what you are monitoring for.
  • B (Defining Rule for the Use Case): This step happens after validation. You shouldn't write a Splunk SPL or Azure KQL query until you guarantee the telemetry exists.
  • C (Implementing and Testing the Use Case): This is the final stage, which involves deploying the rule to production, triggering a mock attack (like Red Canary Atomic Red Team), and ensuring the SIEM fires an alert.

🛡️ SOC Mini-Lesson: "Garbage In, Garbage Out" in SIEM Engineering

In modern SOC operations, log validation is frequently automated using data models like Splunk CIM (Common Information Model) or Sentinel ASIM (Advanced Security Information Model).

When an L3 analyst reviews a new use case request, they run a field summary check (like the Splunk query shown above). If the required field is missing, the workflow is paused, and a ticket is routed to IT/Infrastructure to update the logging policy (e.g., modifying Windows Audit Policies or AWS CloudTrail data event configurations). Only after the log schema is validated does the SOC engineer write the correlation logic.

Ready to sharpen your defensive skills further?

Explore more CSA simulations