SIEM Features - Log Management

Incident and event management is a hot topic these days.  Well, to be honest, it was a hot topic long before I came into the security field.  The most recent SANS survey on information and event management claims that 37% of respondents are using a SIEM in some capacity while 22% are solely using SIEM.  You can find more information about this survey here.  With the every increasing complexity of systems deployed in production environments, I feel that it is getting harder to find a security professional to know all the systems well enough to be able to detect events of interest.  That is the secret sauce that SIEM sells.

My own research has lead me to believe that there are four main "feature" areas to look for in a SIEM.  They would be:

- Log Management
- Reporting
- Threat Correlation
- Incident Management

In this post, I want to talk more about the first one, log management.

When trying to sell the idea of SIEM to upper management, log management will be the single, strongest foothold you will have.  The problem is, most management will just stop right there.  Why you ask?  Well, most management prefer the illusion of security.  But that discussion is for a separate post.

Selling features for Log Management:

1)  It's EASY!
2)  Everyone needs log management (networks, unix, server admin, application guys, etc)
3)  Regulatory Compliance

The last one listed above is the Ace in the pocket sorta speak.  

There are a few things to look for in a log management solution that any SIEM vendor will sell you.  The first thing you really want to understand is EPS that the boxes can handle.  What you have to remember is that the industry calls an event "a log message with about 150bytes of data".  That is really important to note because some applications, etc, will actually be generating a lot more than EPS then you think.  With they way that hardware has gone these days, most SIEM vendors have devices that can scale up to the 10 000's of EPS.

The second thing you want to consider is the types of parsing that is done on the logs by the SIEM.  Ultimately, the SIEM needs to be able to perform two main functions.  For starters, they need to be able to store the raw event logs, unaltered.  Furthermore, they need to prove that the logs were not tampered with.  This is usually done with hashing and I'm sure there is a FIPS standard (140-2) that will cover that.  The second, the SIEM needs to be able to parse the events in order to be able to later run correlation rules against it.  You will want to get an idea of how many different parts of the log is "parsed".  This will give you an idea of how granular you can make your rules.

The third thing that you want to consider is the method in which the SIEM gathers it's logs.  Syslog is great, but not everything is transmitted well in that format.... *ahem* checkpoint *ahem*.  In any event, having a broad range of log collection methods is key.  Look for SIEMs that can do things like WMI, .net calls, SNMP traps, and any other proprietary ones you can think of.  It is probably best to make a list of the type of devices you have in your environment and ask some pretty pointed questions.

The fourth thing you want to look for is flow data.  From my months of experience in security, the host can lie, but the network never does.  Flow data is yet another dimension of data that can be used to correlate events and look for anomalies. 

Last, and probably most important, is log retention.  Any good log management software will provide you with endless combinations of settings to allow for just the right log retention period by device.  Don't settle for anything less.

Remember, a SIEM needs to be as functional as it is usable.  Really, in this day and age, a usable system that flows and has lots of white space etc is a bare minimum.  If the front-end is klugy, run and never look back.