Lazy SIEM Series #1 - Let’s talk about that pile of alerts...

Don’t let it get this bad

…or do, it’s your SOC not mine.

Welcome to the lazy SIEM series. I know you’re not lazy, so you’re ready to dive right in.

I’m starting the series with one of the most dangerous habits a lazy SIEM has, and it’s all about alerts.

Treating all alerts the same

This might be surprising, but alerts are not people (this is the wisdom you follow me for, you’re welcome).

The lazy SIEM doesn’t know this, so it treats all alerts as the same.

The lazy SIEM is so lazy, it tricks its boss into thinking it’s doing work. All it needs to do is keep closing the same alert, 100 times a day. All the while critical alerts are piling up on its desk.

The lazy SIEM might have different severity alerts, but that’s as far as it goes.

Here’s what it’s missing.

Context → Severity → Context.. and again

The lazy SIEM handles alerts statically. An alert comes in as high severity? It stays that way up until the very end.

What about everything that built up to that alert?

Think about these two examples:

• Franklin Brek Sin is a hacker. He performs a password spray against all your accounts from a single IP (he’s not the smartest hacker..) Franklin correctly guesses Mike’s password and logs onto his email with a never before seen laptop. Then.. Franklin starts to forward himself SSNs from Mike’s email (sorry Mike)

• Emily grabs a cup of coffee and logs into her laptop for another day of work. She realizes her tax deadline is coming up in two weeks, so she emails herself her forms.. which contain SSN.

Very different scenarios.. right?

Not to the lazy SIEM. Although the lazy SIEM was smart enough to set a DLP alert for SSN, both Franklin’s and Emily’s activities have the same severity.

This is the importance of context.

Because the lazy SIEM doesn’t see the context of the alert, it can’t make smart decisions about which ones to focus on. This ruins prioritization.

Here’s the cure to the first part of a lazy SIEM.

1. The goal is risk scoring

The Lazy SIEM hates risk scoring.. if only it knew how easy risk scoring could make life.

Risk scoring is backbone of effective alert prioritization.

A good risk scoring system considers the following things to come to a conclusion:

• Vulnerability of systems

• Impact of the threat

• # of related alerts

• User risk

• Anything related to the alert

To see a great example of risk scoring in Sentinel, check out the Sentinel Automation Triage Assistant.

Don’t limit your scoring to a single alert. Here’s how.

2. Correlate to reveal the trails

The lazy SIEM hates following breadcrumbs. Attackers don’t leave behind breadcrumbs, they leave a trail of entities instead (admittedly not as delicious to follow.)

They pivot from the firewall to devices, then accounts and files..

The attacker is walking through what they see as a clear trail in your environment, here’s how to make that path clearer for you:

• Know your environment’s attack paths

• Baseline your user’s behavior

• Merge similar alerts

• Do fuzzy matching

These give you the basics of chaining together activities, here’s how you can take that to the next level…

3. Leveling up

The last thing a lazy SIEM would do is level up, it’s struggling to stay at level 0…

But you’re different (you better be…) so you want to learn how to level up (ok no pressure.. be lazy.. I wouldn’t be offended).

The short answer is (ok I would be offended.. deeply) data.

Here’s the medium length answer:

You can use more advanced techniques like machine learning to put your data to use. Your analysts are classifying all those incidents..

so you might as well use that data to make your SIEM better.

This category is so big, it deserves its own edition (or a few)

I promise I didn’t forget about enrichment, but writing about lazy SIEMS is making me feel …lazy.

If you want, I might dedicate a full edition to enrichment. Stay tuned to make sure you see it.

Enjoyed the article (even a little bit)? Follow me on LinkedIn on to hear more of my rants: https://www.linkedin.com/in/nouraie/