This post is perhaps a little basic for true SIEM literati, but it covers an interesting idea about SIEM’s role in today’s security. I suspect that this topic will become even more fascinating in light of the appearance of XDR — but more on this a bit later…
So let’s talk about what’s to the left and to the right of SIEM. Note that this has nothing to do with the “shift left” of software development. Well, it has nothing to do with it directly, but perhaps there are lessons to be learned in this area for our domain.
Your SIEM looks at certain inputs and produces some outputs (this is not all about GIGO, BTW). But, yes, if the inputs are dirty and/or the outputs drop on the floor, SIEM cannot succeed, no matter what the SIEM vendor says or does.
When I say that somebody succeeded with SIEM, it often implies that they got things to the left of SIEM and to the right of SIEM right or at least “right enough.” It is not enough – absolutely, not enough! — to just install your SIEM software correctly or sign up for a cloud SIEM service.
Ultimately, I believe that success with SIEM means succeeding with what’s left and what’s right. Because your goal is not to “succeed with SIEM” at all — but to succeed with detection and response, compliance monitoring or whatever you use the tool for.
By the way, why do I offer this type of structured thinking about what is to the left and to the right of your SIEM? In my opinion, this approach will help make your SIEM operation more effective and will help you avoid some still-not-dead misconceptions about this technology. It will also let you not step into the mud puddle of excessively optimistic promises by some vendors.
LEFT OF SIEM
What is to the left of SIEM? Mostly data collection. Data collection sounds conceptually simple, but operationally it is still very difficult for many organizations. It has been that for the entire quarter of a century of SIEM existence (the first SIM/SEM vendors launched in 1996, as a reminder).
To the left of SIEM lies a vast and unexplored — well, explored, but largely still unknown for many — land of data collection. Just as early SIM/SEM innovators struggled with collection [and then UEBAs did], innovators in 2022 struggle with it as well. When some vendors made some collection easy in a naïve way, it dramatically decreased the quality of their data (GIGO FTW!), reduced security insight and increased the amount of work needed to be done by their clients…
Today, we also collect a lot more context. Now, some prefer to have just logs collected and then left context collection to the clients, which is, in my opinion, a big mistake. To me, context is critical for detection and the more work we do to add context to logs early and automatically, the quicker path will be to a security outcome for a client. Better, richer context — better detection!
Practically, how do you get the left of the SIEM right? Frankly, for a broad enough set of log sources, you never get it completely right. What makes it easier is throwing away your SIEM that charges per gigabyte, and focusing on what you need to collect and retain, not what you can afford to (but, yes, there is a lot more to it than this). Still, focusing on collection (sources, messages, volumes, architectures, use cases, etc) is still be required to succeed.
And of course you will still have filtering — there’s always stuff that you need to not collect. Many years ago, I worked for a company that had a slogan of “collecting all logs” and while I can see the appeal of that simple message, it has become impractical in 2020s. There is just too much.
RIGHT OF SIEM
How do you get what’s right to the SIEM’s right? Well, let’s start with the elephant in the room: SIEM creates alerts and other signals and handling them (manually or automatically such as via SOAR [ha, tricked you :-)]) is the central part of what is to the right of SIEM.
Just as with collections, there’s no magic here, but response playbooks play a huge role. There is a lot already written on this (example), but seeing the SIEM as a “member” of a pipeline from sources to security outcomes is what allows one to get the right …well…right.
BTW, there may be more enrichment of alerts to the right of SIEM (such as via enrichment SOAR playbooks), not just logs to the left of it. Context for detection means additional context for alerts and even incidents (and hunting clues), not just logs.
Many things to the right of SIEM are about process. From alert triage to escalation and even tuning (that sort of connects right to left), the things to the right of SIEM that needs to be done right are practices and processes. This reminds us why success with SIEM means getting the processes right — and there is no other way.
Now a trick question that this discussion also touches: if what is on the left is truly broken, can you fix it from the right? This is debated, and I prefer to spend my time fixing both sides, if both are broken, rather than trying to fix the left from the right, but YMMV.
Practically, how do you get the right of the SIEM right? Know what you want your SIEM to produce, know your outcomes, and then work on the processes that alerts and signals flow into. BTW, this came as fuzzy advice, but hey … I am not paid to give advice anymore 🙂
Some people are asking whether it’s more important to fix what to the left or what to the right. Recall again this passionate social media discussion about whether it’s better to tune the inputs or to use another tool (SOAR again) to clean the outputs from your SIEM?
To summarize, what has to be done right for success with SIEM needs to be done to the left and to the right of it.
Key tasks that you must succeed that sit on the left from SIEM: telemetry collection, context collection, scalable collection architecture, etc.
Key tasks that you must succeed with to the right of SIEM: alert triage, automation of some responses, collection of additional context needed for alert, etc
BTW, this may mean that whoever owns more of that chain gets better outcomes? First party data collection to quality native response action may win the battle in the long run … is this what XDR is about?
As the discussion indicated, there are few chances to do that for real. To me, better log data would be a true “shift left” for SIEM. Better, more structured and more meaningful, and more security relevant log data will fix many problems, but I am not entirely hopeful here, especially after this experience back in the day….
- Security Correlation Then and Now: A Sad Truth About SIEM
- Anton and The Great XDR Debate, Part 1
- Modern SIEM Mysteries
- I mean, come on, I’ve been writing about SIEM for ~20 years, do you really need more links? 🙂
*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/left-of-siem-right-of-siem-get-it-right-4b07c54cf062?source=rss-11065c9e943e------2