Part of successfully setting up your security operations center (SOC) is defining your SIEM use cases.

Use cases help and support security analysts and threat monitoring goals. What is a use case? A use case can be a mix of multiple technical rules within the SIEM tool, or can be a mix of actions from multiple rules, depending on the need. It converts business threats into SIEM technical rules, which then detect possible threats and send alerts to the SOC. Building and defining the correct use cases helps tell false positives from real ones. It also recommends action based on current or historical activity that could be part of an ongoing or future attack. Learn how to set up SIEM use cases and how they could help your SOC.

Parts of SIEM Use Cases

First, it’s important to note that various use cases can be interlinked. By nature, they don’t work as well alone. Their combined input or chain of action will determine the complexity or type of incoming attacks.

All use cases have three major components:

• Rules, which detect and trigger alerts based on targeted events
• Logic, which defines how events or rules will be considered
• Action, which determines what action is required if logic or conditions are met.

How to Build SIEM Use Cases

Before you start selecting use cases, it’s important to decide on a framework for them.

1. Pick a tool where you can design and map the use case framework. Once you decide what framework to use, start prioritizing and focusing on business threats and risks that have financial, reputational and data impact for your group.

2.  Think about categories of attack. This means defining business threats that are likely to affect you, such as phishing, data extraction, etc. Link every type of attack that applies to you to one or more business threats. At the end of this step, you’ll have a map showing the relation between business risks and attacks.

3. Create another relationship to specify where and how these attacks should be addressed. Identify listed attack types and place them within the selected framework. For example, an external scan attack will fall under reconnaissance/target within the framework.

4. Connect both relationships: business threats to attacks and attacks to framework.

Now, you can organize them into SIEM use cases. Identified business threats will be high-level use cases. These can be further broken down into low-level use cases. Two to three may nest within each high-level use case. There will always be some overlap in terms of how a use case will fit in multiple business threats/high-level use cases. For example, suppose you have a high-level use case: data loss. The low-level use cases nested within the data loss use case would be server compromise, data export from the server and unauthorized administrator activity on the server.

Each low-level use case will have a logical connection to certain attack types, which will help when you are defining technical rules. Each low-level use case might fit in multiple rules, and one rule might relate to multiple low-level use cases. It’s important to define this structure to showcase that connection, as this will further define what log sources you need for the technical rules to function.

The Lifecycle of SIEM Use Cases

Diagram by IBM

During the lifecycle of SIEM use cases, there are multiple points where a use case gets input. This will depend on the source that is feeding data to the use case. During the day-to-day operations in a SOC, the use cases will get inputs from level 1 or level 2 SOC analysts. The majority of these inputs are due to the detection of false positives. If you have threat hunting and intelligence functions within your SOC, there will be inputs from them based on traffic that was not detected by current use cases or a new threat that they identify from the threat intelligence inputs.

Based on the false positives that level 1 and level 2 SOC analysts identify, you can modify use cases to reduce unwanted alerts generated in the SIEM platform. A SIEM administrator or use case engineer will also look into the efficiency of the use cases by identifying half-matched events, the number of duplicate alerts generated and other criteria.

Use Case Management

Use cases are like any other application or product that has to be managed from time to time and taken care of to ensure effectiveness. There are multiple stages a use case goes through to complete its cycle from plan to deployment:

Diagram by IBM

Define/Review Requirements: Start thinking about business threats and risks before setting up SIEM use cases. Refer to the earlier section on how to build use cases.

Identify Data Source: Once you know what you want, the next step is to think about where you can find it. Attacks are defined by the source from which they emerge.

On-/Off-board Data Source: Start integrating identified data/log source into the SIEM. This could require some configuration at the source depending on the SIEM in place. It may also require a few firewall changes to ensure the data source communicates with the SIEM.

Design/Review Logic: Once you have data/logs in place, it’s time to look at logs and identify what you need to detect an attack (the event fields). An important factor while building this logic/rule is to identify the correct event field to perform correlation or aggregation.

Define Baseline: Within the use case/rule, define thresholds/baselines to aggregate similar events.

Testing and Tuning: The defined logic and baseline in the use case needs testing. Based on the testing results, tuning will be required to ensure you reduce noise.

Optimize Based on Outcome: Based on the testing, optimize your baselines to detect an attack.

Monitoring Performance: Deploy a use case in production and start monitoring the performance and alerts generated to keep a check on false positives and overall health.

Use Case Framework

There are multiple frameworks available you can use to build SIEM use cases. For this example, let’s look at the most effective frameworks, MITRE ATT&CK and Lockheed Martin Cyber Kill Chain. Both frameworks have two sections: pre- and post-attack. Pre-attack includes all use cases/rules that relate to target selection and finding vulnerabilities. Meanwhile, post-attack involves use cases/rules that are related to delivery, execution, connection and extraction.

Diagram by IBM

SIEM use cases are an important part of making sure your SOC functions at its best. They can determine whether an attack within your network will be detected or missed, and at what stage you can detect incoming threats. SOC analyst proficiency will also vary based on defined use cases. The more tuned and refined the use cases are, the better detection and analysis will be.