Shockingly, I am going to do another “is this 2005?” kind of post, now that I riled everybody up with my previous one.
Let’s … DEFINE SIEM! But let’s define modern, today’s, circa 2017 SIEM since there is still confusion out there, it “siems”, especially in the area of “what is a SIEM”?” vs “what is a SIEM alternative?”
First, let’s start from our “official” definition – Gartner IT Glossary has this for SIEM: a “technology supports threat detection and security incident response through the real-time collection and historical analysis of security events from a wide variety of event and contextual data sources. It also supports compliance reporting and incident investigation through analysis of historical data from these sources” which makes sense, but still leaves some to imagination 🙂
In my head, I actually have a fairly clear definition of a SIEM. Unlike, say, security analytics, a modern SIEM can be defined fairly precisely. Let’s use our inputs/methods/use cases model that we invented for this paper.
The entry for SIEM will look like this:
| Inputs | Primarily event records / logs from many different sources, but also flows, a lot of context data, etc as context. Focus on: logs from many sources. |
| Methods | Primarily expert-written rules and static reports, but lately also other analytics (from stats to ML); methods run primarily in real-time and/or short time frame. Focus on: cross-device stateful correlation rules and reports. |
| Use cases | A very broad range of security use cases focused on threat detection, investigation and alert management, but also compliance reporting use cases. Focus on: no focus – whatever you make of it, broad scope but within security. |
So, this defines “SIEM DNA” as essentially…
- LOGS (from many sources, not merely one vendor) +
- CORRELATION / RULES in REAL-TIME | ACTIVITY REPORTS on stored data +
- BROAD SECURITY USE CASES =
- SIEM
The above I believe is what makes something a SIEM! Naturally, today’s best products analyze more than logs and use more than rules. In fact, in the past SIM was defined by reporting (compliance and security), while SEM was defined by real-time stateful correlation rules – this is the dark ages of 1997-2002. As a result, combined SIEM (since 2003) has been defined by both. Stateful rule-based correlation (and not simple matching alerts) and compliance reporting (and not just raw search) both require normalization, so it is implied in this definition. Today’s SIEM has grown to include other analytical methods (colliding with UEBA) and other sources of data (EDR-style agents, traffic and flows, etc).
Care to debate this one? I am aiming for simple/clear here, so it is entirely possible that I missed something.
So our Summer of SIEM continues…
Recent blog posts about SIEM:
- Is SIEM The Best Threat Detection Technology, Ever?
- SIEM or Log Management?
- Action Item: SaaS SIEM Users Sought!
- Flashback 2014: SIEM Deployment Blueprint Visual
- Summer of SIEM 2017 Coming…
- SIEM Future: A UEBA Path or An MDR Way?
Select popular blog posts about 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
13 Comments
SIEM must be able to interface with Intel. If a SIEM can’t differentiate threat data, what priorities do alarms get? Alarms must be able to have 2-way interface with orchestration tools…(i.e. ServiceNow, FireEye)
For sure! We keep saying “TI is a MUST for any SIEM deployment today”, thanks for this comment
Hi
I would humbly propose using events and not specifically security events as various events are collected and correlated.
” response through the real-time collection and historical analysis of security events from a wide variety of event and contextual data sources. It also…”
For sure, Dori. My mistake, all logs/events useful for sec usage and NOT “security logs”….
From the “operator” point of view the job of a SIEM is to raise an alert when there is a security problem. (like NMS raise alarms when there is a performance problem).
So if there is SIEM there is alert, and if there is alert there is “alert format”. A SIEM should be able to raise alert in such a format that it would give enough context to the operator to quickly react. I think this is a field (even in Gartner review) which is not enough studied between different SIEMs… each SIEM has its own alert format and they are far from being equivalent although the “content” of an alert is what is most used by the level 1 operator (or simple SIEM user) to quickly qualify an alert.
Alert format is also a big difference between “real” SIEM and log management tools (which use “log” format).
Thanks for the comments. Indeed, SIEM’s threat detection mission does lead to alerts. And, we never particularly looked at “alert as a SIEM product” , a thing that SIEM tools produce. We do however continue to beat SIEM vendors on some lacking context that makes triage difficult…. so this is a juicy part: do your alerts have all the info to triage them without digging for days?
As you mention it, SIEMs have been around for a long time. Isn’t time to talk about “standards” for alerts format so you don’t have to expect “the alerts has all the info without digging for days” but just check that it is “standard”.
Coming back to NMS no one works without SNMP any more, in messaging its SMTP, in web HTTP, etc … SIEM is still with the “NIH” (Not Invented Here) syndrom and each vendor with it’s own format. So no interoperability, no mutualisation when you change SIEM, no global vocabulary to define alerts, etc. and just hoping this one puts enough info in it’s alarm.
I know standard (by definition) are not perfect but not using them is just going no where specially in a time where “collaboration” should be the “master” word in cyber-defense (it is already in cyber-attacks ! ;o) )
In all honesty, while I am long-time fan of log standard, I am not sure about the value of alert standards due to too many use cases for alerts. Critical/wake-me-auto-at-3AM alert vs check this out alert, etc
I am not sure I understand. There are many domain full of many use cases which are all using standards. SNMP is one for performance monitoring. From my point of view, big editors have all chosen to go propitiatory and it’s now very difficult to change that, like it was at the time for SMTP for example. But it will come. ;o)
OK, perhaps I was too vague. When I think of alerts delivered BY a SIEM, I see little need of a standard (little BTW does not mean none) Why? And, also, what alerts are those? I am thinking of alerts delivered to humans and other upstream (from SIEM) systems. Humans – OK, here the need for a standard alert is lower, as long as it is clear and actionable, I will take it. Alerts to machines – for sure this is way more important. But – it is not that common that SIEM alert is delivered to a machine (albeit growing) and typically STRUCTURED is all you need (vs standard, i.e. with some schema vs the same schema globally). Hence my lack of motivation here…
I have been trying to answer you three times I have been trying to answer you three times but my post is maybe too long … 🙁 so I will try to make it short.
Here are few use case where one needs standards :
– SIEM to SIEM and probes to SIEM (more details) communication*
– better context in alert for rapid decision or mitigation*
– compartmentalize : people in front of SIEM not having access to the tool to get more information*
– real time : some information available just in real time (and not after)*
– modularity : ability to correlate ArcSight event in QRadar corelator
– centralisation : at country level for example (incident + alert for important companies)*
– etc.
First messaging system were build with proprietory format for people who would never communicate with the rest of the world. SIEM are a little bit like that today. The larger your system is, the more you need a standard, structured schema for alerts.
PS : I am working with IDMEF and all the case with the “*” are inspired by real use case. I see IDMEF like the “SMTP” of SIEMs.
Ability to rapidly search and hunt through events collected in the SIEM?
For sure, rapid search of structured and unstructured data is key!