During these past few weeks, we have looked at several reasons why a static rule based correlation is not the "SOC in a Box", end-all be all that many thought it was.

Indeed what to think about a "solution" that:

• Can only address a very limited set of attack scenarios
• Requires meticulous consideration on how to map out the few selected attack scenarios
• Doesn't guarantee you to catch attacks in progress even when one of the few selected scenario is taking place
• Obliges you to think of minute details to slightly reduce false positives
• Yields hundreds and thousands of basic correlation rules that need to be programmed, tuned, managed, kept up to date and constantly revisited
• Needs massive computing power and memory resources to run
• Cannot manage all of your logs or IT Data, otherwise the engine blows up in smoke

Don't ask your static rule-based correlation tool to be the universal solution to your security problems.

The Solution
The solution is to understand the problems of static rule-based correlation, understand when this technology is useful, and understand what to do to mitigate the issues. In the next installment we'll look at pragmatic steps to get the most out of it.

• Reduce the number of scenarios
• Don't go for too many correlation rules
• "Peter and the Wolf" - Validate the false positives
• Get yourself the best Forensics tool you can afford
• Ask Yourself if you really can afford an in-house Real-Time Incident Management

More details on each of these next time...

• Why Rule-Based Log Correlation Is Almost a Good Idea...
• Why Rule-Based Log Correlation Is Almost a Good Idea... Part 4
• Why Rule-Based Log Correlation Is Almost a Good Idea - Part 2