We saw what typically happens when trying to use static rule-based log correlation to perform real-time incident management... combinatory explosion and lack of scalability. How do you automate non-deterministic attacks in a few discrete steps???
Today, we'll look at more scenarios for which static rule-based log correlation doesn't make sense.
Attack Scenario Example 2: Brute Force Attack
Let's look at another example scenario. Brute Force Attack.
- A user tries to log in to his account
- He fails many times in a row and then finally succeeds
- Then "probably" a successful Brute Force Attack just took place
Again, let's look at this apparently simple scenario in more details.
- Some organizations consider it more likely that Brute Force has taken place if the login failed are on the same account.
o But what if the attacker attacks different accounts?
§ The attack may not be detected.
- Do you want to be alerted only if the attack is coming from the same machine?
o But what if the attacker performs random IP Spoofing?
§ The attack may not be detected.
- Do you want to be alerted only if the attack is coming from different machines?
o But what if the attacker doesn't perform IP Spoofing, or spoofs coming from a single source IP?
§ The attack may not be detected.
- Do you want to wait for the Brute Force to be successful and the attacker finally succeeds?
o Wouldn't you rather be alerted when you have enough unsuccessful tries? And before he actually succeeds?
§ Then static rule-based log correlation is not required.
In this scenario also, regardless of how many static correlation rules you put in place, how many exceptions you overlay to the account (or not) for IP Spoofing and account (or not) for UserID rotation, you would still be left with plenty of false positives and false negatives.
To keep things simple yet get a good level of protection, instead of static rule-based correlation, put a simple Threshold-Based alert in place, congruent with your AD policy, get a certain number of failed logins in a specified period of time and ring an alarm. For example, five login failed in an hour and ring an alert.
Attack Scenario Example 3: Vulnerability Management and IDS
Often times, customers want to correlate logs from IDS and data from vulnerability management tools. The thought behind it is to put Windows attacks on a vulnerable Windows system on a higher priority level than Windows attacks on a hardened Linux system.
This is similar to putting a higher priority if somebody is trying to burn your wood house than if he's trying to burn your steel house - it will be more resilient and less likely to burn.
If somebody is trying to burn your steel, concrete or wood house, don't you want to be immediately alerted that a bad guy is after you?
Likewise, if somebody is banging on your Linux system with Windows exploits, don't you want to be alerted that a bad person is after you?
Again, no need for correlation here, if your IDS is complaining that an exploit is attempted, then you should be alerted immediately and launch a validation/forensics exercise.
Attack Scenario Example n: What else
How many attack scenarios will you need carefully mapped out in order to provide you with a good level of security?
Let me ask this differently. How many different ways and variations are there for a bad guy to attack you? The answer is "an infinite number".
This means that no matter how many scenarios you can think of, there will still be an infinite number of ways to get attacked.
Remember my analogy with the early days of signature-based IDS detection and why this model doesn't scale?
Static rule-based correlation is not optimum when you are dealing with an infinite number of variations of the same problem.
Attacks are not deterministic, they are heuristic. And automating non-deterministic attacks is not easy, and certainly not doable through log correlation.
Next installment, we'll see additional issues on static rule-based log correlation... performance impact. Ouch.
Subscribe to Web Security Journal Email News Alerts
Subscribe via RSS
