Security Event Correlation

This is an excellent post from TaoSecurity about SEM or SIEM.

Defining Security Event Correlation

This my final post discussing security event correlation (SEC) for now. (When I say SEC I do not mean the Simple Event Correlator [SEC] tool.)

Previously I looked at some history regarding SEC, showing that the ways people thought about SEC really lacked rigor. Before describing my definition of SEC, I'd like to state what I think SEC is not.

So, in my opinion -- you may disagree -- SEC is not:

1. Collection (of data sources): Simply putting all of your log sources in a central location is not correlation.
2. Normalization (of data sources): Converting your log sources into a common format, while perhaps necessary for correlation (according to some), is not correlation.
3. Prioritization (of events): Deciding what events you most care about is not correlation.
4. Suppression (via thresholding): Deciding not to see certain events is not correlation.
5. Accumulation (via simple incrementing counters: Some people consider a report that one has 100 messages of the same type to be correlation. If that is really correlation I think your standards are too low. Counting is not correlation.
6. Centralization (of policies): Applying a single policy to multiple messages, while useful, is not correlation itself.
7. Summarization (via reports): Generating a report -- again helpful -- by itself is not correlation. It's counting and sorting.
8. Administration (of software): Configuring systems is definitely not correlation.
9. Delegation (of tasks): Telling someone to take action based on the above data is not correlation.

So what is correlation? In my last post I cited Greg Shipley, who said if the engine sees A and also sees B or C, then it will go do X. That seems closer to what I consider security event correlation. SEC has a content component (what happened) and a temporal component (when did it happen). Using those two elements you can accomplish what Greg says.

I'd like to offer the following definition, while being open to other ideas:

Security event correlation is the process of applying criteria to data inputs, generally of a conditional ("if-then") nature, in order to generate actionable data outputs.

So what about the nine elements are listed? They all seem important. Sure, but they are not correlation. They are functions of a Security Information and Event Management (SIEM) program, with correlation as one component. So, add correlation as item 10, and I think those 10 elements encompass SIEM well. This point is crucial:

SIEM is an operation, not a tool.

You can buy a SIEM tool but you can't buy a SIEM operation. You have to build a SIEM operation, and you may (or may not) use a SIEM to assist you.

Wait, didn't Raffy say SIM is dead? I'll try to respond to that soon. For now let me say that the guiding principle for my own operation is the following:

Not just more data; the right data -- fast, flexible, and functional.