Our journey to SIEM use cases begins at SIEM USE CASE DISCOVERY, a commonly overlooked [even by me :-)] step. Coincidentally, why didn’t I take it seriously sometimes? Because if you acquired a million-dollar SIEM tool, an intelligent position would be to assume that you know what problems it will help you solve! As you can imagine, in our reality things are quite different. Plenty of organizations have acquired expensive SIEM tools for all sorts of magically idiotic reasons (such as “for compliance”) and only then started thinking about the problems the tools can help them solve and the operational practices need to actually solve them.
Use case discovery helps us accomplish the following:
- Find the organizational problems that are best solved via a SIEM tool; use your risk assessment and threat assessment as guidance as well as business unit requirements (if any)
- Identify externally-mandated (such as by compliance, audit, various mandates, etc) problems that are most relevant to the organization
- Convert vaguely-defined business and security problems into SIEM content
- Analyze the pre-requisites for actually implementing the use cases and getting value from them.
One of the important items related to this is that gathering the problems to be solved is easier than prioritizing them and identifying the most relevant ones. Sure, popular starter use cases and compliance lists work – you can mine ISO 27001, PCI DSS, SANS CIS Top 20 and NIST Cybersecurity Framework for ideas. Login monitoring, data access monitoring, attack detection, change detection, privileged abuse and many other items spill all over the IT-relevant mandates the world over, and SIEM is suitable for them.
Given all those juicy security problems to solve with a SIEM, which ones should YOU do first? For example, once I got into a fight with somebody who claimed that SIEM use cases always must be selected by order of importance. Big mistake! As we say in our paper, “organizations should never undertake application log analysis projects in the first phase of their SIEM deployments before obtaining the necessary product-tuning and operating experience.” (counter-intuitive thought it may be, but “don’t do SAP log monitoring before you can spell “syslog”). A much better order is a balance of importance with “doability” (or ease of implementation). Notable, your SIEM vendor “canned content” or out-of-the-box content needs to be reviewed for ideas as well, but please don’t just “do what they shipped you” since this likely has no real alignment with your organization security priorities.
Conceptually, we are thinking of a process similar to the following:
- Gather the problems, mine the compliance documents (control-centric use cases), threat assessment results and threats lists (threat-centric use cases) and asset lists (asset-centric use cases) – generate a big list of candidate use cases
- Figure the relevance of the above threats, controls and assets to your business, mission, etc – determine relevance
- Prioritize the use cases to start with focused on (and this is key!) importance AND “doability” – prioritize and select top use cases by value.
And, yes, of course we will have details in the new paper.
Finally, our call to action: vendors (SIEM and others), consultants, others – care to share your methodologies for finding, planning and executing the use cases?
Select recent blog posts related to SIEM:
- SIEM Use Cases – And Other Security Monitoring Use Cases Too!
- Co-Managed SIEM Rising
- Research on Security Monitoring Use Cases Coming Up
- My “Evaluation Criteria for Security Information and Event Management” 2015 Update Publishes
- Once More on Cloud SIEM or SaaS SIEM
- Requirements For SIEM as a Service
- SIEM/ DLP Add-on Brain?
- Do You Want “Security Analytics” Or Do You Just Hate Your SIEM?
