We'll see below some examples of security attack scenario that many people
will put forth as a perfect example of how powerful, valuable and simple
As you can see, the overall approach of using static rule-based correlation
on these is simply flawed.
Attack Scenario Example 1: Identity Theft
There are numerous ways to perform an Identity Theft attack, but let's focus
on just one of them, recognizing that somebody cannot be in two places at the
same time and hence that a user cannot log in your infrastructure from VPN
and locally from the office "at the same time." Furthermore, if he connects
through VPN, then disconnects and then "shortly thereafter" he reconnects
locally, then it is probably Identity Theft.
A scenario might be:
If one of my users is logging in my infrastructure from the Internet through
my VPN, then logs out. And then some time late... (more)
Rule-based log correlation is based on modeling attack scenarios
Back to the visibility aspect.
"By managing all your logs you get universal visibility in everything that is
happening in your IT infrastructure." Yes, this is a true statement.
But to tell that you can easily flag security attacks using rule-based
correlation is a major overstatement.
Rule-based correlation essentially automates the "If this is happening here"
and "That is happening there" then "We have a problem." More precisely, "If
this precise event is taking place at this particular time in this specific
(In the context of Logs of course!!)
So the honeymoon is over.
The Cloud Provider that you so carefully selected is not performing like you
expected and you are eying the competition. You might even be considering
re-insourcing back some of your IT services.
So what happens to all the logs? As a customer, can you Trust that your
Provider(s) will not let you down and mess with your logs?
Well, first off, whose logs are they? Are they the Provider's logs because
they are logs generated by their physical equipment, or are these your logs
because they trace your... (more)
Rule-based log correlation is almost a good idea.
It sounds like a good idea, it appears to be a good idea and many people will
tell you it's a good idea, but in fact it is not.
Rule-based log correlation is very complex, limited in use and applicability,
and boasts a terrible ROI.
It will give you a false sense of security, which is a bad thing.
We'll look at the reasons why this is not a good idea, and some ways to
augment the use of logs to improve your security through pragmatic Risk
History of Logs
What is rule-based log correlation and how did it come about?
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
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