Performance Tolls - Why you cannot correlate 100% of your logs...?
Compounding the combinatory explosion in the number of static-based correlation rules, it is impossible to correlate 100% of all your logs, it is just too expensive and not practical. Read on...

A correlation engine works really hard, even when dealing with a limited set of scenarios:

• Each scenario requires lots of rules and exceptions, and most of these rules need to be interpreted further as dozen, if not hundred of simple checks and tests. For example, you may want to flag loops with a simple rule such as "IP Origin" = "IP Destination". If you have 1 000 logs this means that for each log you need to do 1 000 tests. Imagine having a million logs, a trillion logs, which is not uncommon on a medium sized infrastructure over a couple days.
• Each scenario requires state information to be kept and managed for hours, or even days. For example, you may want to be alerted if A happens then within 1 day B happens and then within 1 day C happens. This means that lots of state information needs to be kept over a 2-day span, the engine is constantly monitoring for A to happen, then as soon as A happens the engine starts the clock and monitors for B, and if B happens within that day then a new countdown starts to look for C, all the meanwhile also constantly monitoring for A so as to start a new A then B then C condition... If A happens a lot, and B also happens frequently after A then the engine will need to store lots of A then B state information while monitoring for all the required C.

This requires:

• Extremely powerful servers needed to run these rules and their corresponding "if then else" tests and checks when there are lots of logs.
• Vast amounts of temporary memory needed to keep state information in memory and speed up processing while avoiding swapping to disks.

So the correlation engine needs to be fed very carefully, don't give it more than what it can chew or it will essentially run out of resources and die.

Knowing which logs need to be part of scope is an important part of tuning a correlation engine.

No, you cannot ask your correlation solution to manage all of your logs. It's not designed for that. Managing only the most critical ones is already a daunting task for it.

Correlation load for one simple correlation rule over one hour
As an example, let's have a closer look at Attack Scenario 1 - Identity Theft that we elaborated on, and put a threshold of 1 hour for flagging Identity Theft.

Assumptions - at that time, we have:

o 5 logins/sec average from local logins

o 5 logins/sec average from VPN logins

o 1 000 events/sec average total infrastructure

o Logs kept for a total of 1 week - for reporting etc.

Total data space of 1000*3600*24*7 = 604 800 000 events

For each local login event - which is 5 times per second

o Look in the VPN login events - for the past 3600 seconds - and check if that same person logged in through VPN

Total data space of 3600*5 = 18 000 events VPN logins

Total of 18 000 * 5 = 90 000 checks per second

Size of that 1 hour data space in which to perform the 90 000 checks

o 1000 events/sec * 3600 = 3 600 000 events

So, for this one correlation rule:

• Among the 604 million records total for the past week
• Among the 3.6 million records for the past hour
• The Correlation Engine needs to perform:

Reads

90 000 database reads and checks per second

Writes

While at the same time doing 1000 record writes and inserts per second

• And at the same time, continue collecting, parsing and normalizing, reporting, alerting, "signing of logs", housekeeping and allowing users to log in and use the tool etc etc...

Correlation load for one complex global rule over one day
Imagine now a complex correlation rule that requires the engine to look 100 times per second, and to do this over the full 1-day sliding window.

The assumptions are then:

• Full data space

Same 1 week = 604 800 000 events

• One-day sliding window data space

1000 * 3600 * 24 = 86 400 000 events

• For each correlation rule, we are doing

Number of tests = 100 times per second, look into each record in the 1-day sliding window data space

100 * 86 400 000 = 8 640 000 000 tests per second

That's 8 billion reads per second!!!
Sure you can use tricks and shortcuts to avoid doing all the 8 billion checks, but that gives an idea of the searching power required... for this 1 scenario!!!

Imagine having to enrich this 1 correlation rule with geolocalization information, or somehow putting a dynamic dimension to it.

Imagine having 100's or 1000's of correlation rules, what would be the impact on number of database reads and load?

This is just not practical, and you cannot always solve this problem by throwing more hardware at it.

Did you know that APT attacks can last weeks and months? Stay tuned for what this means for static rule based correlation...

• 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