Log Management vs SIEM
What’s the difference between Log management and a SIEM? If we’re just breaking down the words Security Information Event Manager, it’s sounds like we can achieve that with just logging right? If all of my logs are in one space and I can managed them (search), don’t I have a SIEM solution? Well… not so much.
Log Management
This space has products like Elasticsearch, Splunk, and Graylog. Log management is really just about bringing your logs into a centralized location where they become searchable. These solutions are going to accept data indiscriminately. Whatever you throw at it, it’s going to retain until you delete it or it runs out of space.
I generally refer to log management as an inclusive model. Everything that’s useful gets collected and everything is available for use in analysis. Not all data is used for security though. Sometimes we’re storing system metrics about performance, twitter data for marketing, or maybe call logs from the voip system.
Security Information Event Managers
This space is home to products like LogRhythm, IBM Q1, and FortiSIEM. The first thing you notice when you look at SIEM vs a log management product is that you see graphs, alerts, etc… This is because SIEMs come configured out of the box to start processing data when it comes in and making use of it.
The focus of a SIEM and what sets it apart from log management is that it’s taking actions right away on the data that it knows how to work with. For instance, if it sees SSH logs coming in and it detects 3 authentication failures from the same username, it would alert you to a brute force. Log management systems by default have no way of knowing that you even cared about a brute force taking place.
A key part about SIEM solutions is that they are an exclusionary model when it comes to data. If the data doesn’t get used in security correlations, it’s effectively thrown away (gzipped and archived). This is good for performance but generally bad for analysis. Whenever we are called out to a site for an incident, if a SIEM is being used, we’ll often be missing key logs that were useful to us during the incident but not useful to the SIEM for its’ correlations.
Why is Splunk in both?
If you look at the Gartner magic quadrant, you’ll see Splunk in the SIEM space at the lead of the pack, so why did I call it log management? That’s because Splunk has an add-on called Splunk Enterprise Security that essentially turns your Splunk system into a SIEM.
Though I really like Splunk Enterprise Security tool, I don’t often recommend it to customers without existing Splunk installs. The reason why is that it uses the native search in Splunk to do the correlations rather than use something like redis to keep track of correlation hits (what you’ll find in other SIEMs). Where other systems may be running 60-100 correlations, on Splunk these are searches so a fair amount for a small install might be in the 20-30 area.
Can a log management solution become a SIEM?
Yes, and this is probably the best way to do it. When you purchase a SIEM solution, you are installing a system that has a lot of the defaults done already. The problem is that your organization probably isn’t a default organization. You have certain applications that are more critical than others, certain data that has a different classification. The vast majority of security detections that will trigger are meaningless because you may not even have the application it was targeted for.
I would actually suggest something of a hybrid. Use the log management system to bring in any data you consider to be of value and build your own security correlations. SIEMs certainly come with good correlations but it’s nothing that you couldn’t create on your own. In the end you will have more data that you can easily search, correlations that are valuable to you, and most likely you will have done it for a fraction of the cost.
