Defining Use Cases for a SIEM

A SIEM detection use case is a scenario or set of conditions defined within a SIEM system that outlines specific security threats or behaviours the system should monitor and detect. It provides a broader context by describing what the organisation aims to achieve, the potential threats to be addressed, and how these threats align with the overall security strategy, often mapped to frameworks like MITRE ATT&CK.

On the other hand, a SIEM rule is a specific, technical implementation within the SIEM that defines the logic and conditions to detect specific events or patterns of behaviour identified in the use case. SIEM rules are the actionable components that trigger alerts or responses when certain criteria are met, such as unusual login attempts or data exfiltration activities.

Essentially, detection use cases provide the strategic direction and context, while SIEM rules operationalise that direction into actionable, technical criteria for real-time monitoring and alerting.

Defining detection use cases is crucial because it ensures a strategic and tailored approach to security monitoring that aligns with an organisation’s specific threat landscape and business objectives. Unlike simply turning on pre-packaged SIEM rules or writing rules without planning, which can lead to a flood of irrelevant alerts and potential security gaps, well-defined use cases provide a focused and contextual framework.

They help prioritise the most significant threats, ensure coverage of critical assets, and align detection capabilities with the organisation’s risk management strategy. This planning phase allows for the customisation of SIEM rules to address real-world threats effectively, reducing false positives and ensuring that the security team can respond promptly and efficiently to genuine incidents.

To start defining detection use cases, begin by cataloguing the elements of your network that the SIEM will protect. This includes servers, network devices, applications, databases, and any other critical infrastructure.

Determine the priority for onboarding each asset based on its criticality to the business and potential impact on security.

For each asset being onboarded, talk with subject matter experts (SMEs) to gather both business and technical context.

Business context is the context around the role of the asset in the organisation, the type of data it handles, and its importance to business operations. Understanding the business context of an asset helps in identifying criticality and potential impact on the business.

Business Context Use Case Example: If an application handles sensitive financial data, it could be a target for a cyber threat actor (CTA). A use case might involve monitoring for unauthorised access attempts to this application.

Technical context is the context around the technical aspects, such as configurations, user roles, access controls, and how the asset integrates with other systems. Understanding technical context aids in identifying potential technical vulnerabilities and dependencies.

Technical Context Use Case Example: If a server configuration change could disable security controls, you might create a use case to detect changes made by privileged accounts.

Review existing risk assessments related to the asset being onboarded. Identify specific risks that have been documented, such as data breaches, unauthorised access, or system vulnerabilities. Reviewing the risks related to an asset that have already been identified helps in define what could go wrong related to the asset.

Risk Use Case Example: If there is a risk associated with end-of-life infrastructure, monitor for traffic attempting to exploit known vulnerabilities in that infrastructure.

Use threat intelligence to identify CTAs that target your industry and geographical location. These can range from hacktivists to organised crime groups through to state sponsored adversaries.

Utilise frameworks like MITRE ATT&CK to map the tactics, techniques, and procedures (TTPs) associated with these threat actors. Understanding how these adversaries operate helps in defining relevant detection scenarios.

If you do not know where to start with threat modelling, check out the Arachne Digital guide to threat modelling for your organisation.

Threat Modelling Use Case Example: If a threat actor is known for using spear-phishing followed by lateral movement, create use cases to detect these activities.

You now have detection use cases that cover business context, technical context, risk and threat modelling.

Translate the defined use cases into specific SIEM rules and alerts. Ensure that these rules can detect the outlined scenarios.

Conduct thorough testing of the SIEM rules to ensure they work as intended. Refine the rules based on testing outcomes to reduce false positives and improve detection accuracy. There are many tools out there to do this, such as Atomic Red Team that is produced by Red Canary.

Continuously review and update the SIEM use cases based on evolving threats, changes in the network environment, and new risk assessments. Use cases should be assessed to confirm if it is still valid every 12 months.

As well as ensuring the validity of the use case, the effectiveness of the underlying monitoring should also be assessed. Use metrics such as detection rates, false positive rates, and incident response times to gauge performance and tune as necessary.

Defining use cases for a SIEM is a detailed and systematic process that involves understanding the assets being protected, gathering business and technical context, assessing risks, and performing threat modelling. By following this methodology, organisations can develop effective SIEM use cases that enhance their ability to detect and respond to cyber threats. Regular review and updating of use cases ensure that the SIEM remains aligned with the evolving threat landscape and organisational changes, providing robust and adaptive security monitoring.