Let’s Define “SIEM”!

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:

Select popular blog posts about SIEM: