How To Build SIEM Use Cases
Building effective SIEM use cases requires a structured and methodical approach. Below is a step-by-step guide to developing SIEM use cases, along with practical examples using the Elastic Stack as a SIEM solution.
Step 1: Comprehend Needs, Risks, and Monitoring Requirements
Objective: Understand the organization's security risks and define what needs to be monitored.
Actions:
Identify critical assets (e.g., servers, endpoints, applications).
Determine potential threats and attack vectors.
Establish alerts for monitoring all necessary systems.
Example:
Risk: Attackers may exploit MSBuild (a legitimate Windows tool) to execute malicious code.
Monitoring Requirement: Detect when MSBuild is invoked by suspicious parent processes like Microsoft Office applications (e.g., Word or Excel).
Step 2: Determine Priority, Impact, and Map to MITRE ATT&CK
Objective: Assign severity levels and map the use case to the MITRE ATT&CK framework or the Cyber Kill Chain.
Actions:
Assess the risk level (High, Medium, Low) based on the potential impact.
Map the use case to specific tactics and techniques in the MITRE ATT&CK framework.
Example 1 (MSBuild Started by an Office Application):
Priority: HIGH (due to the significant risk of Living-off-the-Land Binaries (LoLBins)).
MITRE Mapping:
Tactic: Defense Evasion (TA0005)
Technique: Trusted Developer Utilities Proxy Execution (T1127)
Sub-technique: Trusted Developer Utilities Proxy Execution: MSBuild (T1127.001)
Tactic: Execution (TA0002)
Step 3: Define Time to Detection (TTD) and Time to Response (TTR)
Objective: Set expectations for how quickly alerts should be detected and responded to.
Actions:
Define the rule execution interval (e.g., every 5 minutes).
Monitor logs and ensure timely ingestion into the SIEM.
Example:
Rule Execution Interval: Every 5 minutes.
TTD: Detect suspicious MSBuild activity within 5 minutes of log ingestion.
TTR: Respond to alerts within 30 minutes of detection.
Step 4: Create a Standard Operating Procedure (SOP)
Objective: Document the steps analysts must follow when handling alerts.
Actions:
Define the investigation process.
Specify escalation procedures and teams to involve.
Example:
Alert Details:
process.name:msbuild.exeprocess.parent.name:WINWORD.EXEorEXCEL.EXEevent.action: Process creationMachine and user details where the alert was triggered.
Investigation Steps:
Analyze system logs, antivirus logs, and proxy logs for context.
Review user activity (+/- 2 days around the alert).
Engage with the user to verify legitimacy.
Escalation Matrix: Escalate to the Incident Response team if malicious activity is confirmed.
Step 5: Outline the Process for Refining Alerts
Objective: Continuously improve the accuracy and effectiveness of alerts.
Actions:
Identify and address false positives.
Update rules to exclude legitimate scenarios.
Example:
Exclude legitimate parent processes (e.g., Visual Studio) from triggering alerts.
Fine-tune rules based on feedback from SOC analysts.
Step 6: Develop an Incident Response Plan (IRP)
Objective: Define how true positive incidents will be handled.
Actions:
Include containment, eradication, and recovery steps.
Ensure alignment with SLAs and OLAs.
Example:
Containment: Block the source IP or isolate the affected machine.
Eradication: Remove malicious files and terminate suspicious processes.
Recovery: Restore affected systems and monitor for recurrence.
Step 7: Set SLAs and OLAs
Objective: Establish agreements between teams for handling alerts and incidents.
Actions:
Define response timeframes for different alert severities.
Ensure collaboration between SOC, IT, and other teams.
Example:
HIGH Severity: Respond within 30 minutes.
MEDIUM Severity: Respond within 2 hours.
LOW Severity: Respond within 24 hours.
Step 8: Implement and Maintain an Audit Process
Objective: Ensure accountability and continuous improvement.
Actions:
Regularly review logging status and alert triggers.
Document lessons learned from incidents.
Example:
Audit logs to confirm that all machines are logging process creation events.
Review alert frequency and adjust thresholds to reduce noise.
Step 9: Create Documentation
Objective: Maintain a knowledge base for reference and updates.
Actions:
Document the basis for creating alerts and their triggering frequency.
Include troubleshooting tips and fine-tuning recommendations.
Example:
Knowledge Base Entry:
Use Case: Detect MSBuild started by Office applications.
Trigger Condition:
process.parent.name=WINWORD.EXEorEXCEL.EXE,process.name=msbuild.exe.Frequency: Rare under normal circumstances.
Practical Examples
Example 1: MSBuild Started by an Office Application
Scenario: Detect when MSBuild is invoked by Microsoft Office applications, which could indicate malicious script execution.
Rule:
MITRE Mapping:
Tactic: Defense Evasion (TA0005), Execution (TA0002)
Technique: Trusted Developer Utilities Proxy Execution (T1127)
Sub-technique: Trusted Developer Utilities Proxy Execution: MSBuild (T1127.001)
Severity: HIGH
SOP:
Investigate process creation events.
Analyze logs for malicious activity.
Escalate to the Incident Response team if confirmed.
Example 2: MSBuild Making Network Connections
Scenario: Detect when MSBuild establishes outbound connections, which could indicate adversarial activity.
Rule:
MITRE Mapping:
Tactic: Execution (TA0002)
Technique: Command and Scripting Interpreter (T1059)
Severity: MEDIUM
SOP:
Investigate the destination IP address.
Check the reputation of the IP using threat intelligence feeds.
Exclude legitimate IPs (e.g., Microsoft update servers) to reduce false positives.
Conclusion
Building SIEM use cases involves a combination of understanding organizational risks, mapping to frameworks like MITRE ATT&CK, and defining clear processes for detection, response, and refinement. By following a structured lifecycle and leveraging tools like the Elastic Stack, organizations can create robust use cases that enhance their security posture.
Key takeaways:
Understand Risks: Focus on high-priority threats and critical assets.
Map to Frameworks: Use MITRE ATT&CK to align use cases with known adversary behaviors.
Define Metrics: Set TTD and TTR to measure effectiveness.
Document Processes: Create SOPs and IRPs to ensure consistency.
Refine Continuously: Address false positives and adapt to evolving threats.
Last updated
