During my original SIEM architecture and operational practices research (see the paper here and a presentation here), I looked at the topic of SIEM operation maturity. Organizations that purchase and deploy SIEM technologies are at different stages of their IT and information security maturity (such as when measured by Gartner ITScore for Security). Certain security monitoring goals are extremely hard to achieve at lower maturity stages (such as “hunting” when you can barely collect data); they are also frequently unachievable unless the organization climbs all the steps in the maturity ladder to get to that step [so, no jumping stages].
The key purpose of this maturity scale is to evolve an SIEM deployment toward getting more value out of it at higher stages of the scale. Also, SIEM team members can use it to make sure that specific operational processes are in place as SIEM deployment evolves from stage to stage. For example, enabling alerts without having an alert triage process and incident response process is usually counterproductive and ends in frustration. Still, all the processes from lower stages must remain in place as SIEM deployment maturity grows.
Here is the current version of the table:
Table 7. SIEM Maturity Scale
|Stage No.||Maturity Stage||Key Processes That Must Be in Place
(inclusive of previous stages)
|1||SIEM deployed and collecting some log data||SIEM infrastructure monitoring process
Log collection monitoring process
|2||Periodic SIEM usage, dashboard/report review||Incident response process
Report review process
|3||SIEM alerts and correlation rules enabled||Alert triage process|
|4||SIEM tuned with customized filters, rules, alerts and reports||Real-time alert triage process
Content tuning process
|5||Advanced monitoring use cases, custom SIEM content, niche use cases (such as fraud or threat discovery)||Threat intelligence process
Content research and development
Source: Gartner (January 2013)
SIEM team members may also choose to add a Stage 0 (“tool deployed, no process”) and possibly higher stages, which are sometimes seen at security-mature, “Type A” organizations (with such exciting activities as data modeling process, visual data exploration process, use-case discovery process and so on).
At this point, I’d like to ask for your feedback and improvement suggestions?
Should I add dimensions to the maturity table, such as essential personnel skills, typical tool components deployed and utilized, use cases common at each stage?
In any case, feel free to suggest it below in comments, via email or via whatever social media venue you happen to frequent.
Previous version of the maturity table:
Select recent SIEM blog posts:
- My Evaluation Criteria for Security Information and Event Management Publishes
- On SIEM Tool and Operation Metrics
- SIEM Analytics Histories and Lessons
- Back to SIEM Research!
- SIEM Webinar Questions – Answered
- How to Use Threat Intelligence with Your SIEM?
- Detailed SIEM Use Case Example
- On “Output-driven” SIEM
- On SIEM Maturity Scale and Maybe On CMM Too
- On SIEM Deployment Evolution
- On People Running SIEM
- On SIEM Processes/Practices
- On Large-scale SIEM Architecture
- All posts tagged SIEM
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.