Using a SIEM to identify the *really* important stuff

by Paul Stamp on 3/2/2009

Many people buy a SIEM system looking for a tool that will spot things they might not on their own, or things that a single data source might not. Here’s an example of correlation that will work - given the right input, an analytic engine and some expert knowledge.

So you’re an analyst, and you want to know when a critical, vulnerable server is being attacked. All of the information you need is available - but your time is valuable, so you don’t have time to cross reference it all.

For example, a CMDB can tell you a server is critical, and a vulnerability scanner can tell you it’s vulnerable, and an intrusion detection system (IDS) can tell you it’s being attacked. However each of these pieces of information is probably buried in separate systems along with all the information about non-critical systems, the vulnerabilities you’ve chosen to live with, and the gigabytes of attack noise every IDS produces.

A good SIEM system should be able to analyze all the event data and contextual information it has at its disposal to alert only on that really important event – when a critical vulnerable server is being attacked.

Doing this is harder than it would appear at first glance – newly discovered vulnerability and attack types are revealed every day. And that’s where the knowledge comes in. We at RSA spend a good deal of resources getting up-to-date information from vulnerability assessment vendors, IDS vendors and independent research bodies like the National Vulnerability Database. We then make regular updates available to clients so they have current information about how the attacks they’re seeing map to the vulnerabilities they have.

This means that we have a single rule that users can enable in order to receive alerts when a critical, vulnerable server is being attacked.