Views: 17
How To Build SIEM Use Cases
- Comprehend your needs, risks, and establish alerts for monitoring all necessary systems accordingly.
- Determine the priority and impact, then map the alert to the kill chain or MITRE framework.
- Establish the Time to Detection (TTD) and Time to Response (TTR) for the alert to assess the SIEM’s effectiveness and analysts’ performance.
- Create a Standard Operating Procedure (SOP) for managing alerts.
- Outline the process for refining alerts based on SIEM monitoring.
- Develop an Incident Response Plan (IRP) to address true positive incidents.
- Set Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) between teams for handling alerts and following the IRP.
- Implement and maintain an audit process for managing alerts and incident reporting by analysts.
- Create documentation to review the logging status of machines or systems, the basis for creating alerts, and their triggering frequency.
- Establish a knowledge base document for essential information and updates to case management tools.
Example SIEM Use cases
Use case 1: Microsoft Build Engine Started By An Office Application
A practical example using the Elastic stack as a SIEM solution to help understand how to map each of the use case points listed above.
MSBuild, part of the Microsoft Build Engine, is a software build system that assembles applications according to its XML input file. Typically, Microsoft Visual Studio generates the input file, but the .NET framework and other compilers can also compile applications without it. Attackers exploit MSBuild’s ability to include malicious source code within its configuration or project file. This risk is known as Living-off-the-land binaries (LoLBins) and falls under the high global risk category.
The term “living off the land” (LOL) was coined by malware researchers Christopher Campbell and Matt Greaber to explain the use of trusted, pre-installed system tools to spread malware. There are a few different types of LOL techniques, including LOLBins, which use Windows binaries to hide malicious activity; LOLLibs, which use libraries; and LOLScripts, which use scripts.
When monitoring process execution command-line arguments, it is crucial to investigate instances where a web browser or Microsoft Office executable initiates MSBuild. This suspicious behavior suggests a potential breach.
To monitor this risk, let’s create a detection use case in our SIEM solution that monitors instances of MSBuild initiated by Excel or Word, as this behavior could indicate a malicious script payload execution. Then next step is to define priority, impact, and map the alert to the kill chain or MITRE framework.
Link to MITRE ATT&CK Navigator
Github Link for the MITRE ATT&CK Navigator
Regarding MITRE mapping, this use case involves bypassing detection techniques via LoLBins usage, falling under the Defense Evasion (TA0005) tactic, the Trusted Developer Utilities Proxy Execution (T1127) technique, and the Trusted Developer Utilities Proxy Execution: MSBuild (T1127.001) sub-technique. Additionally, executing the MSBuild binary on the endpoint also falls under the Execution (TA0002) tactic.
https://attack.mitre.org/tactics/TA0005/
To define TTD and TTR, we need to focus on the rule’s execution interval and the data ingestion pipeline discussed earlier. For this example, we set the rule to run every five minutes, monitoring all incoming logs.
When creating an SOP and documenting alert handling, consider the following:
- process.name
- process.parent.name
- event.action
- machine where the alert was detected
- user associated with the machine
- user activity within +/- 2 days of the alert’s generation
- After gathering this information, defenders should engage with the user and examine the user’s machine to analyze system logs, antivirus logs, and proxy logs from the SIEM for full visibility.
The SOC team should document all the above points, along with the Incident Response Plan, so that Incident Handlers can reference them during analysis.
For rule fine-tuning, it is essential to understand the conditions that may trigger false positives. For example, while the Build Engine is common among Windows developers, its use by non-engineers is unusual. Excluding legitimate parent process names from the rule helps avoid false positives.