One note: I will often use the word ‘products’ when talking about the SIEM. By this, I am referring to any alerts, dashboards, reports and feeds generated by the SIEM.
I broke my goals up into categories, Documentation, Self-Monitoring, Tuning and Misc.
Documentation: While both Anton and John talk about the need to document your SIEM, I feel there are some specific items that I want to capture:
- Document all log and event sources. In addition to monitoring all input, know where those inputs are coming from and how those inputs get to your SIEM. This really helps during troubleshooting/compliance. I have some inputs that take two to three steps from the original source to the SIEM DB. Having a place where that is written down helps prevent from having to trace each step when something breaks.
- Document all tweaks, exceptions, 'rube goldbergs', and other customizations. As you know, some inputs work out of the box and others, well, others take some manipulation of the parser, the feed or permissions to get the input to work consistently and correctly. Annotating what you did to get the input working and why you did it, will help when that input breaks.
- Document any feeds being sent from your SIEM to other devices or groups. In some cases, your SIEM is exporting a data feed to another party or into another device. Document who or what is getting the feed, what type of data is in that feed, how that feed was created, and why that feed was created. Also, note the POC and contact information for who or what is receiving the feed.
- List all users and groups that have access. This should include what data each group or users should and should not have access.
- Document alerts and reports so that someone new can quickly understand what each alert is for, why it was made and what to do when it goes off.
Self-Monitoring: While self-monitoring is also mentioned in most of the research I did, I had a few other events for which I needed to watch:
- Monitor your users to see when and how often they log in and what they use/view. By doing this you may find new requirements, determine badly written use cases and/or find products that need to be adjusted.
- The SIEM should track it's own metrics. While the IBM SIEM security maturity model has some good examples of SIEM and SOC metrics to track, I feel you should also track items like license usage and the load on the SIEM. This is often built in, but not always in a location that is easy to view.
Tuning: As you know, you need to tune your alerts, dashboards and reports. But while I was doing refining my products, I realized two specific tasks I needed to make happen:
- While I mentioned earlier to document exceptions, I think I need to emphasis that you need to document the exceptions/customizations (see above) you make while tuning. This helps viewers of your products understand what they are looking at and why some data may not be included.
- As part of tuning, you should have a method for feedback, so that you can refine your products to better suit your customers based on what they tell you.
Miscellaneous: Some additional items that I thought a mature SIEM should have:
- A good written "Introduction to Our SIEM" type of document. This document can be given to new users and new groups that are starting to use the SIEM. It would contain basic instructions for how to search, how to use dashboards, and how to read alerts and reports. It also would contain a description of the products available and, if possible, a link to each one. The hope is that by using this document, it will accelerate a new users ability to use the SIEM without asking for help all the time.
- Custom use cases and custom content that have been created in the SIEM. Custom use cases are use cases created for the specific enterprise that the SIEM resides in. These use cases may also include custom content; that is content generated by scripts or DB queries or monitoring tools specifically for your enterprise.
- Context added to products and search events. By using Threat Intelligence as well as additional queries and/or inputs (such as nslookup or reference tables), all products and search results from the SIEM can provide additional information about the who, what, where, and when of an event. By providing more information the first time an analyst sees an alert or report, you speed up their ability to make a decision.
- Automation of simple use cases in any place that the SIEM is able to take action. This may include such actions as opening a ticket or modifying an access control list. In some cases the SIEM can take this action independently; in other cases, the SIEM works with another tool like an orchestrator to accomplish this task.
After adding these items to my maturing plan, I have a better picture of where I need to go with my SIEM and I am able to refocus my efforts to improve and increase the value it brings to my customers.
Did I miss anything? Over think something? Or is there an area I’m completely off?
Say it in the comments!
Anton Chuvakin of Gartner
IBM Brief from Portland, OR ISSA