Lately, something made me think of using log management WITH security information and event management (SIEM) - I suspect it was either this or maybe this zombie here. I did spent some time in my career building SIEM tools and then spent some building log management. Nowadays, their “separate identities” are pretty much widely accepted; even “Big G” combines them in the same document, but calls them out by name separately (this, BTW, took about 2 years of fierce arguments back in 2005-2007 :-))
In any case, my recent bout of thinking revealed four scenarios, crudely depicted on the image to the right:
Those are:
- Log management as a foundation and SIEM as [one of the] applications: this is what I call “a common sense scenarios” since it is so …well… common sense. It can also be called “grow up to SIEM.” By some strictly unscientific estimates (=random guessing), it accounts for maybe up to 50% of SIEM deployments. This is the case where an organization gets a log management tool and slowly realizes the need for correlation, visualization, monitoring workflows, etc.
- SIEM and log management deployed together alongside and at the same time: this is what I call “emerging scenario” since more people now get both at the same time (from same or different “best” vendors). I have no idea about the percentage of adoption here, but likely vendors who offer SIEM and LM can attest to the growth of this scenario. Indeed, if you somehow realized the need for correlation, you better save all the logs and have an ability to perform efficient search and raw data analytics.
- SIEM=LM: this scenario means that either you are small (and use the same tool that can handle simple SIEM and log management functions) or, if you are large, you’ve been duped by the vendor who said “they are the same thing” [today they are still not and a smart vendor won’t tell you this – eventually maybe they will be…]. Admittedly, “one box with SIEM+LM functionality” can work in principle and for smaller environments, but typically there are too many things competing for CPU, RAM, network and disk (e.g. correlation and indexing are both resource hogs…). Still, this might well be the #1 by the number of deployments due to its applicability to smaller (and thus more numerous) environments.
- SIEM deployment with LM as an archive: this scenario arises when somebody buys a big fat SIEM – and then, over time, realizes that something is missing. As a result, a log management tool is deployed to "dump” all logs into and (sometimes) perform analysis of the raw logs that SIEM “rejects” (i.e. doesn’t know how to parse, normalize, categorize, etc). Specifically, incident response and PCI DSS come to mind here.
- “SIEM Shield” [UPDATED!]: the final 5th scenario is so obvious, I completely forgot about it :-). While it is similar to both #2 (simultaneous SIEM and log management deployment) and #4 (log management as an archive for a SIEM), it is also distinctly different – and VERY common.
In this case, an inherently more scalable log management tool is deployed in front of SIEM (typically after SIEM is first implemented, which is similar to scenario #4) to serve as a shield and filter to protect a less scalable SIEM tool from extreme log flows. It is not uncommon to only send every 10th event received by the “log shield” to a SIEM, hiding behind it. At the same time, all received events are archived, just like in case #4.
Obviously, it goes without saying there are lots of “log management only” (still growing) situations and some “SIEM only” (likely shrinking) deployment scenarios. But their are not the subject of today’s note here.
BTW, today is my birthday :-) … and I am writing about SIEM. How cool is that?
Possibly related posts:
- On SIEM Complexity
- All posts on SIEM.
