Lately, I’ve been reading a lot of insightful posts related to best practices in SIEM, detection, and logs (written in 2026). The interesting bit is that a lot of these best practices looked good to me and made sense — and yet, they felt incredibly familiar…

As I dug deeper, I realized they reminded me of things I had written 10, or sometimes even 20 (23 in one case) years ago.

What does this mean? I hope you don’t take this post as something written purely to prove that I’m very smart and totally prescient (I am smart / I am not prescient). No, the actual lesson here is that things changed much less at many organizations than people assume.

So, let’s review some of the older wisdom from the mid-2000s and early 2010s and match it up against what people report as today’s best practices.

#1 Centralization

Let’s start with pure comedy. In 2003, I recommended that people … wait for it… centralize security data (funny enough, in 2023, I briefly questioned this idea). But on a more serious note, this is still — mostly — good advice, with some notable exceptions [A.C. — look at that emdash sucker there, got it?].

#2 Context

I am surprised about it myself, but back in 2003 I was a big fan of adding what later became known as context data into a SIEM. Asset info, vulnerability scans, etc need to go into your SIEM (well, SIM and SEM at the time; SIEM was born in 2005).

#3 Planning

Since the day I first laid my eyes on a SIEM in January 2002 (well, technically, it was a SIM), I realized that project planning makes or breaks a SIEM deployment. 20+ years did NOT teach many this lesson, as modern advice, sadly, is the same. Generic advice? Sure, but also evergreen!

#4 Buy vs DIY

You may think because I worked for vendors, I was always a fan of “buy from a vendor” as a default choice, and only resort to “build” or “buy then build” as an exception.No, I saw too many DIY SIEM disasters. Here we confirm that despite major changes in tooling (AI agents), for most organizations build vs buy decision remained largely the same, for now.

(a fun ancient exception: a certain “I-suspect-who” had to analyze 300TB (~ 1 trillion messages) of logs in 2005, and advice they were given is: DIY, nothing commercial can handle it … and as we learned later won’t for another 5–7 years at least)

#5 Output-driven SIEM

The idea of “Output-driven SIEM” was stolen by me in 2011 and then popularized widely my Gartner “megaphone.” I did a refresh on this in 2025, but, in brief, it means “deploying your SIEM in such a way that NOTHING comes into your SIEM unless and until you know how it would be utilized and/or presented.” This is very relevant today, because in the past it was hardware and not perhaps it means tokens. But “SIEM costs kill” message remains.

#6 Crown Jewels

Sometime around 2013, I was giving many clients this advice: do NOT start your security monitoring (really, D&R) scope from the most important assets, or crown jewels. Many a CISO argued hard (‘but Anton, what about “important first.”’ Yes, SAP is important but if you onboard SAP logs before firewall logs, you will probably die in the process. And step 2 will never happen. Modern advice seems to match perfectly.

#7 Retention

“Keep logs. If you don’t know better, keep logs for a year.” I said around 2006–2008. Then in 2019, I got somewhat shocked that keeping logs for a year is seen as a luxury by many. Today with data lakes and all sorts of crazy cloud storage people … well… often still don’t keep logs long enough.

#8 SIEM vs Log Management

SIEM vs LM was a hot topic in the mid-2000s. We had architectured for broad collection in LM and security focused subset in a SIEM. Today this just means SIEM and a data lake. So, this also aged very well.

#9 Log Data Mining aka UEBA

A lot of my early work in what I called ”log data mining” predated UEBA, and my predictions that rules will be complemented by analytics (hi Captain Obvious!) aged weirdly. They agend well, then not well, then well again. Today we have non-deterministic AI analyzing logs, and back then we had Marcus Ranum “NBS” for Never Before Seen….

#10 Misc

In my consulting days (pre-Gartner, which means pre-2011), I did a lot of “best / worst practices” presentations, such as this one. I think these aged well, but perhaps because they were a bit generic. Example that aged very well include:

• “Phased Approach: Rather than feeding “all” logs into a SIEM immediately, organizations should start with limited devices (e.g., DMZ) and events (e.g., authentication)” then expand.
• “Focus on Use Cases: SIEM requirements should be driven by specific problems the organization wants to solve, such as tracking unauthorized access or detecting web application hacking.”
• “Tuning Ability: The organization must accept responsibility for customizing and tuning the tool, as “out-of-the-box” SIEM deployments rarely succeed.”

All of the above are from the early to mid 2000s. These also aged well, despite being almost ¼ of a century old…

Lessons? So what does it mean that advice from 2003 still works in 2026? A few uncomfortable lessons:

1. SIEM problems were never technology problems. They were — and are, and perhaps will be — people, process, and organizational physics problems wearing a technology costume. This is why 23-year-old advice still applies: the vendors shipped new tech, but nobody shipped new organizations.
2. The “what” aged well; the “how” got replaced. Output-driven collection, phasing, use cases, context, tuning ownership — all still true. What changed is the plumbing: appliances became data lakes, EPS became tokens, correlation rules got a non-deterministic AI sidekick. If your strategy changes every time the plumbing changes, you never had a strategy. Good news!? Yes!
3. Cost pain is eternal; only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of ingest budget, in 2026 you run out of tokens. “SIEM costs kill” is apparently a law of nature, so architect for it (output-driven!) rather than being surprised by it. Again.
4. If the advice didn’t change, but you still don’t follow it, the advice was never the problem. Everyone “knows” to plan the deployment, start with use cases, and own the tuning. Knowing isn’t the bottleneck. Doing is. AI won’t fix that either — it will just help you not-do it faster.
5. The industry has a roughly 7-year memory. Every cycle, “new” best practices get rediscovered — at $xxx/hour consulting rates — by people who could have read my 2005 SlideShare for free. Reading old stuff is the cheapest security investment you’ll make this year?

So no, I’m not prescient. The organizations are just slow (as I said after leaving Gartner: “IT inertia is the most powerful force in the Universe”). We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” See you in 2043, when this post ages well too…

Related posts:

• 20 Years of SIEM: Celebrating My Dubious Anniversary
• 20 Years of SIEM Webinar Q&A and slides
• Security Correlation Then and Now: A Sad Truth About SIEM
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• A Fair Weather SOC: 5 Signs It’s Time to Panic (and Fix It!)
• WTH is Modern SOC, Part 1 (There is no part 2. Yet?)
• Beware: Clown-grade SOCs Still Abound
• The Return of the Baby ASO: Why SOCs Still Suck?

The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.