I recently did this fun SANS webinar titled “Anton Chuvakin Discusses “20 Years of SIEM — What’s Next?”” (the seemingly self-centered…
I recently did this fun SANS webinar titled “Anton Chuvakin Discusses “20 Years of SIEM — What’s Next?”” (the seemingly self-centered title was suggested by CardinalOps who organized the webinar). As it is common for SANS webinars, we got a lot of great questions that I feel like re-answering here for posterity.
Q: When do you think the industry will understand what XDR entails?
A: A cynical part of me wants to say “never”, for the following reasons: what various vendors define as XDR morphs and shifts too fast and (this is a gut feel, not based on any solid fact base) it is not really converging to a common position.
The “better EDR” crowd keeps taking past “integrated SIEM-like thing” crowd who both talk past “EDR+NDR” crowd. So no convergence yet, and this means one can’t easily predict where it is going. Hence I am guessing “never.” As we used to say in Hype Cycles, I predict “dead before plateau” for XDR or at least many years before plateau.
Q: How do you define ‘XDR’ and what role does SIEM play here?
A: I tried very hard not to define XDR. You can review my ideas on the topic in this blog series “Anton and The Great XDR Debate, Part 1” “Anton and The Great XDR Debate, Part 2” “Anton and The Great XDR Debate, Part 3.” Specifically, post #1 has several definitions (all conflicting) that sort of make sense to me as choices for a future definition (that is, provided XDR has a future).
The exact connection between SIEM and XDR is under debate — just as the definition of XDR is. For those who are of the opinion that XDR is merely an improved EDR, SIEM seems like a nice complementary technology that needs to be integrated with their tool. For people who see XDR as the next great platform for your SOC, SIEM is the legacy technology they need to defeat before they are successful. Finally, some SIEM vendors have adopted XDR messaging and they think of themselves as both SIEM and XDR simultaneously, however much it may hurt their brains…
Q: In terms of a small security team in a mid-large size environment, should a SIEM or EDR solution be managed by a third party or can it be reasonably managed by 1 person? Does it depend on which vendor/solution is chosen?
A: In the scenario you describe, some form of managed detection and response (MDR, MSSP, co-managed SIEM/EDR) is very strongly recommended, in my opinion. It really does not depend upon which solution is chosen as most SIEM or EDR tools, even cloud-backended (cloud-native, SaaS, etc), are not really manageable by one person, if you want to do it well.
This is likely true even in the mid-size environment. Naturally, vendors are making rapid progress to make solutions more easily manageable and cloud-backended EDRs are the closest to this, in my view. However, in many regards, even a SaaS threat detection and response tool requires dedicated personnel such as for tuning and optimization as well as use case design and refinement. Hence managed service is very helpful in your scenario and, I dare say, essential.
Q: From a practical approach, does it pay to integrate known vulnerabilities into SIEM cases and rules? If it does, what frequency would you recommend to make it effective yet sustainable?
A: Historically speaking, I first encountered (well, helped build, really) an SIEM tool that can consume vulnerability data back in 2003. Naturally, at the time many of the tool designers assumed that including vulnerability data in SIEM (well, SIM and SEM at the time) is essential and can help triage alerts and produce better reports. However, in many cases, I’ve noticed that SIEM tool operators do not include vulnerability data or, if they include it, they only use it to “right-click” during investigation and not for any automated analytics or detection.
Do I still think it’s a good idea to include vulnerability data in your SIEM? Yes, I do. Today I want to use vulnerability data in my SIEM for risk scoring and alert prioritization (obviously) and as investigative context. But I probably wouldn’t push for it as a “hard must,” given what I’ve seen
If you are going to do vulnerability data uploads into your SIEM, I don’t see anything wrong with “after every scan” timing. Please don’t expect magic, however.
Q: What role do you see SIEM playing in Zero Trust?
A: Contrary to recent opinion, monitoring, detection and response play a critical role in zero trust deployments. In many cases, robust visibility controls over identities, access and endpoints are essential to make zero trust a success (as we say in papers describing our own experience here). For example, you will need a lot of VPN logging and log analysis before you move to ZT-style access controls.
Would I say that you absolutely have to deploy an SIEM to have a robust zero trust deployment? Perhaps I will not, but I will definitely insist on robust telemetry collection leading to detection and response activities. Zero trust approach will not work without observing what is actually happening in your environment (example). You cannot blindly trust anything …
Q: How are folks making decisions on what data to centralize into their SIEM?
A: The discussion about what data to centralize into their SIEM is indeed at least 20 years old, if not more. There are many approaches for log source prioritization that were considered over the years (for example, review this).
I have been a big fan of output-driven SIEM where I emphasize the fact that only telemetry and context data that is driving your use cases should be collected. When a SIEM is confused with central log management, more organizations just try to collect a broad scale of data and then suffer from their lack of clarity. SIEM is fine, broad log management is fine, but confusing them is not fine.
Q: What about running multiple different SIEMs, have you seen that work in practice? A: Please review this blog for a discussion of deploying multiple SIEM tools. As I say in that blog, I would almost never make this choice from first principles of security architecture, but there are situations where such a setup is a good idea. Chronicle often plays in these situations, specifically. Very often a solid SOAR tool is needed to harmonize your multi-SIEM experience.
Q: Where do you see UEBA fitting into the next generation SIEMS? Any specific use cases you think are key?
A: UEBA technology has been included in the SIEM. It has been going on for a few years (e.g see blog from 2016 where we first spotted it). My best advice on the analytics use cases can be found in this blog (a bit dated, but largely reflects current conditions, I think).
So, today UEBA is a feature of SIEM, and a core feature at that. There are no good UEBA vendors left who are also not SIEMs.
Q: What is your opinion on retention of data in your SIEM? How long should you retain and why?
A: Data retention question is another age-old SIEM question. Please review this blog where I highlight the value of retaining security data for at least a year. It is not just compliance regulations that recommend that, there are solid security reasons for keeping data for at least a year (such as investigating an incident that you just uncovered that happened 4 months ago). So, if you want a short answer then a year. PCI DSS (even the new v4) agrees “Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.“
Sometimes when you retain raw logs and do not retain the context — for example, who did this user ID belong to at the time of the alert — retaining logs alone will not help you for investigations. Thus, retain logs with relevant context, not just raw logs.
Q: Should you pay for threat intelligence feeds for the SIEM?
A: Including threat intelligence in SIEM is yet another classic discussion — see this blog. For example, today I would absolutely rely on the intelligence feeds provided by my vendor, whether SIEM or EDR. However, in many cases, I would also look for curated, high quality feeds that would allow me to run my threat detection without much additional intel cleaning. I would absolutely pay for those feeds (see this on modern TI use cases).
However, most organizations perhaps would not pay for context-quality (not alert-quality) feeds that help me understand alerts, but don’t drive any new detections, unless my maturity level is very high (then I will try to collect as much TI as possible because I actually do know what I have as item #2 in “1. Get more threat intel 2. ??? 3. Profit!”)
Q: Do you see anyone using the kill chain framework to develop use cases and rules with specialized focus on the phases of the kill chain.
A: Kill chain framework was a very popular approach for use case development until the ATT&CK framework came and expanded upon it. Essentially, this builds on the kill chain with more depth and more value for most use cases today. I would probably focus my analysis on the ATT&CK framework and not on the original kill chain model (while keeping my awareness of it, of course).
Q: How much energy should we invest into updating use cases? How do you align SIEM with change management so it becomes a sustainable process?
A: The question about use case processes and updating use cases is very dear to my heart. Back in my analyst days, we wrote an entire paper focused on that. Today, I definitely correlate success with SIEM with the use case process and its robustness.
Q: Have you seen Sigma uncoder.io used successfully to intake and translate rules to different SIEMs?
A: Not first hand so far. I do know of it, but I’ve not met many users of it yet. I am also aware that it will not magically convert a long complicated stateful rule from SIEM A to a very dissimilar SIEM S.
To be honest, many attempts to translate rules between different SIEM tools have failed. There are tools such as the one you highlight that would allow very simple, not stateful rules to be converted from one tool to another with modest degree of success. In most real life SIEM migrations, the rules are rewritten by humans by hand
Q: You mentioned this talk has a longer blog post. Could you provide a link to that?
A: Here is the “20 Years of SIEM: Celebrating My Dubious Anniversary” in all its glory; please also follow some links there for additional insights.
Related blog posts:
Originally published at Medium.
