Yes, and this pre-dates the ML craze by a decade and a half...
Originally published at Medium.
Friday, January 21, 2022
"we believed (wrongly) that by centralizing data we could (maybe by magic) analyze it faster" <…
"we believed (wrongly) that by centralizing data we could (maybe by magic) analyze it faster" <- indeed. We did believe that centralization is a BIG step to this, and it was a step. A small one :-)
Originally published at Medium.
Symantec SIM (well, acquired) was a sad piece of tech with a few cool features, frankly.
Symantec SIM (well, acquired) was a sad piece of tech with a few cool features, frankly.
Originally published at Medium.
Thursday, January 20, 2022
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…
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! :-)
Originally published at Medium.
Monday, January 10, 2022
New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of…
Sorry, it took us a year (long story), but paper #3 in Deloitte/Google collaboration on SOC is finally out. Enjoy “Future Of The SOC…
Sorry, it took us a year (long story), but paper #3 in Deloitte/Google collaboration on SOC is finally out. Enjoy “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” [PDF].
If you missed them, the previous papers are:
- “Future of the SOC: Forces shaping modern security operations” [PDF] (Paper 1 of 4)
- “Future of the SOC: SOC People — Skills, Not Tiers” [PDF] (Paper 2 of 4)
My favorite quotes are below:
- “This paper highlights ways to create a consistent set of core processes, yet still allow room for creativity within the process set for your SOC.” [A.C. — capturing this magic was our focus for the paper!]
- “Strong thought out processes are sometimes (unfairly) seen as the most boring of the people, processes, and technology triad. But they are what differentiate mature organizations with capabilities from those with a collection of the latest shiny toys. ”
- “The security community has become increasingly vocal in its belief that out-of-the-box use cases from nearly any vendor do not cut it anymore. This is not to disparage vendor’s products; it is simply an admission that anything intended to be globally applicable to thousands of customers in a constantly evolving threat landscape is bound to come up short for the most pressing threats. A marriage of out of the box use cases with robust and continuous engineering of detections and process automations is needed for the modern SOC to keep pace. ”
- “True innovation can be scary for most security organizations because it is, to a certain extent, a commitment to organic and messy growth rather than measurable procedures. The challenge for a modern SOC leader is thus balancing the desire for consistency — backed by repeatable, predictable, and effective processes on one side — and the desire to harness human creativity, initiative, and perhaps even irrationality on the other side. ”
- “A highly functioning modern SOC, one that is able to anticipate and detect threats on their way in rather than on their way out, has likely attained that balance between consistency and creativity. But how is this balance achieved? The trick is to create an unconventional, but somehow harmonious mixture of consistent, repeatable processes and human, anarchic, and spontaneous creativity.“
- “In some maturity models, the highest maturity level is called “Optimizing.” Perhaps this best captures the vision of how a good SOC should look. Ultimately, security professionals are not striving for consistent operations alone; they are aiming for this elusive maturity tier whereby the previous foundational levels are so well entrenched that the SOC can spend its time truly optimizing, in a living, ever-adapting model.”
- “The better road is to build consistency and grow through lower maturity levels, and then let creativity loose within the processes that are already built. ” [A.C. — for more details on how, see the paper!]
Enjoy! We are writing the final paper 4 as we speak :-)
Related blog posts:
Originally published at Medium.
Subscribe to:
Posts (Atom)
Dr Anton Chuvakin
