Initially I wanted to call this post “SIEM has no brains”, but then questioned such harshness towards the technology I’ve been continuously loving for 13 years 🙂 In any case, my long-time readers may recall this post called “Pathetic Analytics Epiphany!” (from 5 years ago) [and this one from 8] where I whine incessantly about the lack of actual analytic capability in our log analysis tools such as SIEM and log management (“search and rules? that’s it?! WTH!”). Well, I didn’t just whine, I tried to do something about it.
Now in 2015, the situation has started to change … but sadly not much in SIEM tools themselves. The good news is that we now a decent number of vendors that offer, essentially, an add-on brain for your SIEM. Some can also add a brain to your DLP, since it turned out that DLP is pretty brainless as well…
These new vendors (whether they are classified by us as UBA or not) essentially focus on 2 problems:
- Reduce/refine/prioritize alerts coming from other tools (SIEM, DLP) by applying algorithms to the SIEM output i.e. alert flow (e.g. this is a rare type, this is not common for this source, this has never triggered at night, etc)
- Detect better and/or detect new, difficult threats by applying algorithms to the SIEM input and/or fusing the SIEM data with other data
On the detection side, they may be effective with things like:
- One example – many people’s favorite! – is finding compromised user accounts. You can read about it here – to compare “the SIEM way” and “the analytic way” (UBA way, in this case)
- Another is malicious domain detection (DGA-cooked domains detection, in particular) – sure, you can rely on threat intelligence feeds of “bad domains”, or you can ML the sucker like these folks do here (sure, “the known bad way” is easier, but guess how helpful it would be for finding freshly created bad domains?)
- Exfiltration detection via interesting channels (DNS for exfil, anybody?) has been on the target list for those “add-on brains”; after all, humans tend to burn out after looking for outbound firewall logs non-stop for a weak or two :–)
So, why isn’t this in all SIEM tools?! [A short answer is: beats me …]
Longer answer: There are political and economical reasons, but there are also performance engineering reasons. Remember the old days of SIEM when a SQL query hitting the database to run a report “Top User Logins by Count For Last 7 Days” took 3 hours? [“Stop complaining, its Oracle, man!” was the typical response.] Now try something more 2015-style, such as “match a set of 3000 threat indicators [such as IPs or domains] vs historical log data over the last 60 days” (we call it “TI retro-matching” and it is useful a long list of reasons) – BOOM! down goes your SIEM. And this was trivial matching – not analytics, really. A lot of SIEM deployments are spec’d out to run close to maximum performance (more useful discussion here); you can think of this as sort of SIEM coffin corner: go faster – airframe breaks, go slower – become a big drag on the budget and crash. If I want to use your SIEM for any unsupervised learning, as I did back in the day, you will need to dramatically increase hardware – or wait a looooooooooooooooooooong time for results.
Finally and to be fair, some SIEM vendors (very few!) are starting to think about it, but – seriously, guys – you could have totally owned this 5 years ago! BTW, I’ve been asking many of those emerging analytics-focused vendors (whether UBA or not) on “why don’t you think that SIEM vendors will crush you?” and received many exciting answers …
Blog posts on the security analytics topic:
- Those Pesky Users: How To Catch Bad Usage of Good Accounts
- Security Analytics Lessons Learned — and Ignored!
- Security Analytics: Projects vs Boxes (Build vs Buy)?
- Do You Want “Security Analytics” Or Do You Just Hate Your SIEM?
- Security Analytics – Finally Emerging For Real?
- Why No Security Analytics Market?
- SIEM Real-time and Historical Analytics Collide?
- SIEM Analytics Histories and Lessons
- Big Data for Security Realities – Case 4: Big But Narrowly Used Data
- Big Data Analytics Mindset – What Is It?
- Big Data Analytics for Security: Having a Goal + Exploring
- More On Big Data Security Analytics Readiness
- Broadening Big Data Definition Leads to Security Idiotics!
- 9 Reasons Why Building A Big Data Security Analytics Tool Is Like Building a Flying Car
- “Big Analytics” for Security: A Harbinger or An Outlier?
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.