Blog post

SIEM or Log Management?

By Anton Chuvakin | July 26, 2017 | 8 Comments


Welcome to 2002! Let’s discuss a timely topic … and, no, its not Y2K – that one is fortunately over.

The topic is: SIEM vs log management.

Yes, really! In 2017. This. Is. Still. A thing.

Naturally, those of you avid blog readers from 2010 will immediately remember that I touched this topic many, many times. So why dig out this dead horse?

Frankly, I got too many questions like this and finally got mad.

Short version: if you really need log management, and you bought a SIEM and you only use it as a log aggregator, you are probably not having a good time. And you overpaid. This may lead you to think along the lines of “is ELK the best SIEM for me?” without any regard to the fact that ELK is not a SIEM. You, sir, never needed a SIEM! You needed log aggregation and log search, and ELK works well for that [probably not for petabyte scale though – note that the linked post was written in 2007…].

Like so:

Furthermore, yes, even now in 2017, there is confusion about “what is a SIEM?” vs “what is a log manager?” It is entirely possible that your IT and security requirements call for log aggregation and rapid log search – and for nothing else (so you only need log management). It is just as possible that they call for a robust real-time monitoring based on correlation and analytics, lots of security dashboards, etc (so you need both SIEM and log management, as we say here, and also perhaps a UEBA).

Finally, if you are really smart, you can use ELK as a foundational set of components to build your own SIEM, like these fine folks have done. But it will involve a lot of work.

To conclude, in a Capt Obvious fashion: it is all about the requirements. As it always is 🙂

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


  • Jack says:

    As of the date of USAA’s Elastic presentation, which I attended, they had not built a SIEM on ELK. They were using ELK for log management in front of their legacy SIEM, and using SIEM for the more complex SIEM rules and for incident management (the “M” in SIEM).

    • Well, the promised the conversion of “old SIEM” rules into ELK, and this sounds like building a SIEM to me, at least the direction is there…. if not the outcome

  • Norbert Bruneau says:

    Like many others I agree with this point of view.

    ELK is not a SIEM and I don’t think they pretend to be. But SPLUNK is not a SIEM either as they pretend to be (with Gartner MQ complicity ;o) ).

    We once tried to build a “SIEM” out of Splunk for a client. It took us months for a very poor result compare to a real “out of the box” SIEM.

    • Well, if you read it carefully, you’d see that Gartner agrees with you — splunk [base] is not a SIEM. But splunk + their Enterprise Security app most definitely is – today. Splunk with ES has defeated every major SIEM at the core SIEM use cases more times that I care to count….

      • Norbert Bruneau says:

        What is “core SIEM uses cases” and where can we find that ?

        Splunk has been a “Gartner SIEM” since 2011 and at the time you, like others, found that strange.

        I am just trying to point out that everybody (and specially log management tools) wants to be a SIEM (Splunk, ELK, Logpoint, etc) or replace the SIEM (Splunk, Darktrace, Prelert, etc.) even though nobody agrees anymore on what it means.

        Is it just a tool, is it features, is it “use case” (if yes, where are they ?) do those use cases include the level of expertise (and the HR price) needed to operate the tool or the length and the complexity of the search command you have to type to find anything. What about real time correlation … is it still a subject ? And alert format, is it important ?

        At the end of the day .. is ELK less a SIEM than Gartner said Splunk was in 2011 and who is deciding what is a SIEM and what is not a SIEM ?

        PS : One thing we will agree though is “It’s all about the requirements” !

        • Well, I spend all this time thinking about your comments…seriously. Thanks for your insightful comment!

          We are doing a bit of “define SIEM in 2017” work for our upcoming papers, and some things you refer to in your comments are definitely the stumbling blocks.

          Most likely, we’d still define SIEM by capabilities like correlation and use cases supported out of the box.

          > is ELK less a SIEM than Gartner said Splunk was in 2011 <- this particular bit does befuddle me, and I don't have a good answer at all 🙁

  • Norbert Bruneau says:

    From my point of view the first role of a SIEM is to centralise (normalize, correlate, agregate, etc.) all the security data of your system (and your security tools). So the question would be “is SIEM the best tool to centralize, normalise, correlate, agregate, etc.) and the answer is … YES !

    Then the SIEM can centralise/normalise/correlate/etc only the data you put in it. If you gather all logs or just a few (maybe to save money) , if you add NIDS or HIDS, if you have anti-virus and firewall, etc … if you add Splunk (or ELK) as a source of data in your SIEM ;o), etc … then is you have all this datas in the SIEM you can start asking yourself if it does good threat detection.

    I am sure you know all that. Just trying to explain that SIEM alone is not much … and often people think they can do/see everything out of logs as their security would be much better by adding few NIDS for example.

    PS : Sorry (but happy) to have befuddled you with my ELK question. ;o)

  • Thanks a lot for the comment. HOwever, it appears that at many orgs SIEM cannot centralize all data, not even all log, but only data some deem relevant for some task (which is OK, as long as there is an LM tool centralize all log data and/or some other tools to centralize other data beyond logs…)