20 Years of SIEM: Celebrating My Dubious Anniversary
On Jan 20, 2002, exactly 20 years ago, I joined a “SIM” vendor that shall remain nameless, but is easy to figure out. That windy winter day in northern New Jersey definitely set my security career on a new course.
With this post, I wanted to briefly reflect on this ominous anniversary. Where do we begin?
Let’s start with a sad fact that some of the problems that plagued the SIM/SEM of late 1990s and early 2000s are still with us today in 2022. One of the most notorious and painful problems that has amazing staying power is of course that of data collection.
I remember how our engineers struggled in 2002 with some API-based collection from a known firewall vendor. API-based log collection seemed new and weird back in the day (“why can’t they do UDP 514 syslog like normal people?”). Today, the current generation of engineers still struggles with some cloud-based collection mechanisms for telemetry data … and that is even before observability for security truly arrives.
Another problem — as we know now — possesses amazing staying power. “We collect data and then you get the insights” promise was made by SIEM vendors as early as 1999.
Do the SIEM operators today feel they got what was promised? Generally, no. In some areas, we are worse off, as users need to work more, not less, on getting the value from their collected data. Personally, I still hear SIEM users complaining loudly about “it just collects data” and “it is hard to get the outcomes we want.” This happens after a quarter of a century of promising that! Note to the excited security data lakers here: sorry, guys, but you are making this one worse, not better …
Next, another reminder is useful: the birth of security information management and security event management definitely predates the rise of compliance. In recent years, it always annoyed me when people equated SIEM with compliance, because I lived through the era before compliance mandates became “cool” in security. Thinking back to 2002, SOX just came out, HIPAA was new and cool, while PCI DSS … was not born yet.
If you are curious, what did people care about those days? Here are some juicy quotes from SIM / SEM / NSM / ITSM / LEM marketing of that era. BTW, lots of names for this technology space were in use back then, ultimately SIM/SEM won and then was forever fused together by Gartner.
(date: 2002, source)
(date: 2002, source)
(date: 2002, source)
(date: 2002, source)
(date: 2002, source)
(data: 2003, source)
[BTW, this last historical artifact makes me a bit angry, because at least one of the “cool” “search-based ‘SIEM’” vendors cannot do this today, in 2022, while the cheapest and simplest of the 1st generation SIM/SEMs could do it in 2003. This is literally 20 years of regress in front of your eyes!]
My writing at the time shows that I was quite obsessed with correlation, especially correlation of normalized / categorized data that allowed detection content (rule) creation without knowing the event IDs and other details from each log source [because single event matching was not considered cool in 2003, and so why is it acceptable in 2022?]
I have not kept copies of my oldest presentations (very few like this gem from 2003 survived), but my old speaker page reminds me that I focused on “Log Analysis for Security” (2004), “What Every Organization Should Monitor and Log” (2005) and “Log Mining for Security” (2006).
The point I’m making with these fond memories is that a lot of the problems we struggled with in our security operations are the same problems we struggle with today. Definitely, the technology context has changed, but the security challenges remain the same to a very large extent.
As an example, alert overload was what gave birth to SIM (usually network IDS alert overload back then). Guess what problem we are discussing now 20 years later? Alert overload of course!
One of the things that, in my estimation, the early SIEM did better than the later, text search-based products was focus on the quality of data. There were a lot of naïve decisions made in the early days (some for good reasons, some for bad, some because of technology limitations) such as to focus on data that is deemed security-relevant and discarding the rest. I recall agonizing over some Cisco event IDs when I was working with our log source integration lab.
Now, the more cynical among you may remind me that early SIEMs were plagued by parsing errors (yes, they were!) and that data quality was — in that sense — inferior to that of a tool that collects raw logs. Sadly, this is correct (this made it hard to trust those SIEMs), so perhaps this is a debate for another time. One approach I tried to use to solve it was to advocate the case for log standards.
XDR fans today may find it distasteful, but early SIEM pioneers really wanted to deliver effective and usable detection rules out of the box. Back in the day, we almost always called them correlation rules, because we that to be a good product in the space you have to have stateful correlation and not just simple matching.
As another theme, early on I was right in stating that workflow matters a lot for a good SIEM product. This happened perhaps 10 years before the first SOAR product was born. I recall designing a workflow system for our SIEM assuming people in the SOC will live in that UI most of the time…
In the early days, I also spent a fair bit of time looking at how threat actors behaved and then writing detection content (I even ran a honeypot and then used the observation to create correlation rules). Naturally, that predated the age of APT so most of our detection content was focused on commodity actors — script kiddies as they were known back then. But hey — it wasn’t the auditors!
After a few years (2006-ish), I spotted that a complete collection of logs would become a thing and left my original SIEM employer. Note that I did not expect that collecting raw logs would kill the original normalized, enriched and categorized SIEM… I wanted to have both full/raw and clean/enriched data (kinda what we have now…)
After that, I stepped away from SIEM and had a chance to experience a very well built SaaS security tool — although not in the SIEM area. This made me excited about the chance of creating a cloud-native or SaaS SIEM. Of course, now everybody knows this. Back in 2009, SaaS SIEM didn’t really exist…but that is the story for another day.
Now, I am not sure I can be called an official SIEM historian (I may not be the oldest SIEM developer alive, but it is possible I am the one who tolerated SIEM in my life for the longest time…), but here is what I have.
Feel free to share your SIEM / SIM /SEM or log analysis stories, let’s have a party! 🙂
20 Years of SIEM: Celebrating My Dubious Anniversary was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** 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/20-years-of-siem-celebrating-my-dubious-anniversary-f1cda2b453d3?source=rss-11065c9e943e------2
