Time to touch the main challenge: SIEM use case implementation / refinement process [also applicable to other monitoring technologies, like UBA / UEBA]. In our seminal paper on the topic, “Security Information and Event Management Architecture and Operational Processes”, (did I mention that it exudes pure awesomeness – from each of its 61 pages!), we have described the process similar to this:
Define a particular problem to be solved by a SIEM tool in clear, unambiguous terms.
Review the SIEM functionality (rules, algorithms, reports and dashboards) that is needed to solve the problem.
Look at the available and potentially available log data that is useful for solving the problem.
If a correlation rule is the chosen piece of content to be created, analyze what sequence of logged events needs to be tracked and how these events are represented in a SIEM tool; using normalized events and taxonomy categories is highly recommended because they make the rule easier to modify, maintain and apply to additional log sources.
If using a statistical detection method, review its logic to confirm that it will deliver the result needed.
Draft correlation rules on paper, and review the logic flow.
Implement the correlation rule using the SIEM rule interface; some products allow one to click on events and define a rule straight from the observed sequence of events.
If a product has functionality to test the rule or algorithm on historical data, execute this functionality to determine how often this rule would have fired in the past if it had been enabled.
Review any alerting process that this rule will trigger, and set up alerts to go to the people who know how to triage them.
Enable the rule to run on real-time data flow in the production environment.
Review alerts generated by this rule, review the cases where the rule matches partially (if the SIEM product has such functionality) and refine when the rule is needed.
What stages do you think need additional details? Examples? Specific guidance? Any changes?
Select recent blog posts related to SIEM:
- Fun Challenges with SIEM Use Cases
- SIEM Use Case Discovery
- Discovering New Monitoring Use Cases
- 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
- Do You Want “Security Analytics” Or Do You Just Hate Your SIEM?
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
I can add something –
Verify that the configuration changes to the environment needed to create the relevant log are feasible and if not, what needs to change in order to support the needed logs.
during many implementations (~60), I’ve found that every use case has a financial price. (storage, network, hardware, support), in some cases, the price is too high and the use case is forfeit at that stage or at least reconsidered.
In order to create a use case that checks for internal assets returning to external attackers, you have to allow logging of Firewall’s “access allowed”, in many cases, the Firewall breaks down from this change or at least becomes congested, checking with the Firewall people that they can handle it, or what’s needed in order to allow it, will assist you in assessing a part the “price” of the use case. same true for monitoring a database or a file server access.
Thanks a lot for the comment — we wholeheartedly agree. Also, you definitely get extra points for mind-reading – we discussed a very similar addition to the process flow just yesterday.
If changes are needed but impossible/infeasible, likley the use case won’t fly….