Blog post

2018 Popular SIEM Starter Use Cases

By Anton Chuvakin | July 20, 2018 | 15 Comments


One of the most popular posts (example) on my blog is “Popular SIEM Starter Use Cases.” However, this post is from 2014, and is, in fact, partially based on my earlier experiences doing SIEM consulting in 2009-2011. In other words, it is kinda old.

Perhaps surprising to some, our data seems to indicate that many of the mentioned popular starter use cases are very relevant today. Some of the use cases were reborn as popular UEBA use cases, BTW (and here is a list of our UEBA use cases, ABTW). Am I not a master of blog post cross-linking, Anna? 🙂

So, let’s take a look at these mid-level use cases (technically, I’d classify my use cases here as mid-level in abstraction, BTW) and perhaps add others we’ve been noticing lately:

Use Case Description Status in 2018
1 – old Authentication tracking and account compromise detection; admin and user tracking Very much alive, also became a popular UEBA use case
2 – old Compromised- and infected-system tracking; malware detection by using outbound firewall logs, proxy, etc Very much alive, more relevant than before, also an UEBA use case
3 – old Validating intrusion detection system/intrusion prevention system(IDS/IPS) alerts by using vulnerability data, etc Less relevant today, not common anymore – perhaps a candidate for removal from popular list?
4 – old Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs, etc Very much alive, also a popular UEBA use case (related to exfiltration detection)
5 – old Tracking system changes and other administrative actions across internal systems, etc Very much alive, AD log analysis became more popular, UEBA expands this to insider threats, etc
6 – old Tracking of Web application attacks and their consequences, etc I’d say alive today, but not that common, not sure why
7 – NEW Cloud activity monitoring, detecting cloud account compromise, cloud access and privilege abuse, other security issues, etc NEW! Also a use case for UEBA and (in case of SaaS, mostly) CASB, this covers many sub-use cases for AWS, Azure, Office 365, etc threat detection
8 – NEW Detecting threats by matching various logs to threat intelligence feeds NEW! A popular use case, pushed up by wide availability of low-priced TI feeds of … ahem… tolerable quality
9 – NEW SIEM as “poor man’s EDR” – review of sysmon and similar endpoint data NEW! As EDR and EPP converge, SIEM can occasionally help with deeper endpoint visibility by utilizing various source of endpoint telemetry; probably not a good STARTER use case though….

Note that I am NOT including foundational SIEM use cases like “use SIEM to search logs” or “use SIEM for PCI DSS compliance reporting.” Sure, they are alive and well, but …well…. not that sexy to mention here.

Any ideas? Anything to add? Anything to remove?

Posts related to SIEM research:

Comments are closed


  • Yi Zhou says:

    Why you think #3 should be removed? We still have some customers are confirming with us for #3. They want to use SIEM to evaluate IPDS detections.

  • Andrii B says:

    Ahem, Sigma for threat hunting and as input for correlation and hunting missions. A bit of of an overlap with 8 and 9, though I’d add Use Case 10: using SIEM as part of / as a whole threat hunting system. Surprisngily not a starter for some organizations yet and I wonder why: it is much easier to add in a precise generic query to find particular threat or TTP rather than learning the search syntax and correlation rule engine and writing thresholds/aggregation/baselining rules or ML models.

    • Hunting is Sec Ops 501 and not 101, and not a starter use case by any measure. Hunting is valuable, but way, way, way too elite to be a starter use case.

  • Haren says:

    Do you think we should expand these in terms of data sources required to trigger these cases >mapping them to Cyber Kill Chain > Simulating them > Identify grey areas and get them fixed. I have done such an activity for one of my customer and called as ” Threat Detection Framework” where the ratio was approx 60% depending on the detection controls available on IT Infra

  • Adam says:

    This makes sense to me. It seems like many fields have important breakthroughs early on that remain relevant for years, decades, or even centuries.

  • Kosh says:

    Root cause analysis be a category ? Ok malware on an endpoint was detected but how did it get there any bypass other controls ? User was compromised ok was it phishing, weak pwd..

    Cat 1,2,3,4 and 9 look pretty similar now with the end goal being detect either compromised user account (or attempts), detect compromised device ( whether its fw,ips,sysmon,edr logs correlated against threat feeds the goal is the same , the effectiveness vs cost is debatable) , unauthorised actual user activity ( BitTorrent, downloading movies, installing non approved sw)

    Guess what I’m getting at is have the category more aligned to what u want to do (goal) rather than how u do it.

    • Well, sure, but most detecting use cases aim at …well… detecting the attacker, right? But I think you are right – perhaps for 10 use cases we needed categories and NOT just a list…

  • Note to self – more candidates:

    – new account creation and changes
    – missing control monitoring, AV disabled (PCI DSS!)
    – more lateral movement detection
    – more netflow / traffic?

  • Note to self 2– more candidates:

    – more data access anomaly, data access violation

  • Note to self 3 – more candidates:
    – additionaL AD abuses, Kerberos attacks, etc

  • Naz says:

    How about monitoring power consumption and CPU utilisation spikes.
    Although sounds very “Ops” and not security, it can be used to spot the mining activity/infection.