Now that I’ve taken a fair number of “security analytics” client inquiries (with wildly different meanings of the phase), I can share one emerging pattern: a lot of this newly-found “analytics love” is really old “SIEM hatred” in disguise.
A 101% fictional and slightly over-dramatized conversation goes like this:
- Analyst: you said you wanted security analytics, what specifically do you want?
- Enterprise: I want to collect logs and some other data, correlate, analyze, report.
- Analyst: wait a second … that is called “SIEM”, SIEM does that!
- Enterprise, passive-aggressively: Well, ours doesn’t!!!
- Analyst: have you tried to .. you know… actually use it?
- Enterprise: as a matter of fact, we did – for 5 years! Got anything else to ask?!
Upon some analysis, what emerges is a real problem that consists of the following:
- Lack of resources to write good correlation rules, tune them, refine them and adapt them to changing needs
- A degree of disappointment with out-of-the-box rules (whether traditional or baseline-based) and other SIEM content
- Lack of ability to integrate some of the more useful types of context data (such as IdM/IAM roles and user entitlements, as well as deeper asset data)
- Lack of trust that even well-written rules will let them detect attacker lateral moves, use of stolen/decrypted credentials, prep for data exfil, creating backdoors, etc
- Occasionally, a lack of desire to understand a multitude of their own monitoring use cases, but instead to buy a box for each problem.
So, a few years of such SIEM unhappiness have born a result … UBA. Some vendors’ UBAs are “SIEM add-ons” (since their rely on SIEM for collection, normalization and storage), others are more like a “narrower but smarter SIEM” (since their collect a subset of SIEM logs and maybe other data).
A few can work with DLP and not just a SIEM (as we all know, tuning DLP is often – imagine that! – a bigger pain than tuning a SIEM) in order to create additional insight from SIEM and DLP outputs. As I hypothesize, UBA is where a broader-scope security analytics tooling may eventually emerge.
Now, do you need/want analytics or do you just hate your SIEM?
Blog posts on the security analytics topic:
- 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?
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
4 Comments
I find conversations with prospects with customers clarifying quickly as you are oft to say by defining first what you are trying to do and then moving on to how to do that. Go figure! I find success guiding them down the seemingly simple path of needing to detect better, investigate more effectively, and respond more quickly, which fortunately leads away from the circular SIEM logic, logs, correlation, rules and the raw emotions often attached to them. It leads to a better thinking place of what is/are the best way(s) to improve security visibility, the best way(s) to gain insight off of that improved visibility, and the best ways to speed up an effective response……which really leads more often that not now…to the best way to build and mature a CIRC/CIRT from a people, process, and yes technology point of view…..Traditional SIEMs have a role to play in just 1/3 of this equation, so my advice is get off of them as the intellectual starting point!
@Matthey Thanks a lot for the comments.
>detect better, investigate more effectively, and respond more quickly,
>which fortunately leads away from the circular SIEM logic
Hmmm….OK. But are those “pre-SIEM” (never used a SIEM) or post-SIEM clients?
Great blog Anton!
I’m getting a serious case of deja-vu. Your examples bring me back to my Business Intelligence days, where organizations that carefully planned for and resourced their BI deployments were successful, and others, not so much. Like the “useful practice” slides in your “actually use it” slideshare.
In my experience, IT Security teams seem chronically under-resourced. I can think of many examples where small teams can’t deal with the volume of alerts that are surfaced by their SIEM tools, and don’t have the bandwidth to build up the required rules.
Advanced analytics are a different, complementary approach. By mathematically discovering what’s normal, rules (a major resource drain) are less critical, and alerts (another major resource drain) can be prioritized. This different approach, as your first sentence suggests, is just not widely understood yet.
@Mario Thanks for the comment. Indeed, if one can automate [parts of] alert overflow, it would be a big win for the short-staffed teams.
BI parallels and current business analytics parallels are indeed all over the place, except for those make money and infosec [kind of] spends them 🙁