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.

GCIH Certified!

Yesterday I finally took my GCIH exam after taking the Sec 504 course a few months ago.

It was a fairly comprehensive exam, but I think the 504 course is a little on the basic side.  I like the SANS stuff because you get exposed to some tools / techniques that might take you some time to figure out organically on your own.

In any event, 1.5 hours after I started the exam I walked out with a 92%.  Not too bad!

ie_execcommand_uaf xp only?

With the release of the latest Internet Explorer 0day exploit, I was eager to get an environment up to test it out.

I decided to test out two environments.

1)  Windows 7 fully patched with the latest Java version and IE9

2)  Windows XP SP3 fully patched without Java and IE8

My testing proved unsuccessful against the configuration (1) above.  I was very successful in crashing IE 9, but was not able to exploit it at all.  I would have to do some more analysis with this, but a quick google search reveals that I am not alone in this finding.  I think that scope of this 0day might have been exaggerated a bit.  I did not spend a ton of time on this, but I did try of couple of different configurations.

Configuration (2) above, however, did not fair so well.  IE8 still seems to be in use at about 20% of all browsers (and probably 90% of all corporate browsers).  I think given those facts, this is still a pretty important 0day.