How to deploy your SIEM wrong

The market for good cybersecurity practices is oversaturated, which is why I’m exploring a niche of genuinely bad advice.

I’ve seen many SIEM deployments, architectures and migrations. I like to think that I understand what works. This article is not about that. Here are the 3 things that you can do, if you want to absolutely tank your security monitoring program.

SIEM migrations are an interesting topic. When you think about it, a out of all security tools, SIEM requires the most user input to get up and running. It sometimes makes me wonder whether a migration is really warranted. After all, how do you know it’s the tool that’s failing you and not you?

I like to say that as long as your SIEM is in the upper right corner of the Gartner’s quadrant (or roughly the same area of the Forrester’s thing), it likely has everything you need and more. But hey, that’s your money, not mine and if you choose to migrate then so be it.

Now, migration to a new threat detection system is this unique opportunity to reasses your security monitoring strategy. This is where I see the value of migrating to a new SIEM. The new shiny featuers were the lessons we’ve learned along the way. Or something like that.

Which brings me to my first bit of genuinely terrible advice.

Migrate 1:1

If you’re not familiar, that means copy - pasting the old setup to the new tool. That always fails. And is actually funny if you think about it, because recreating your old setup in the new SIEM means that… you liked the old setup. Why did you choose to migrate then?

Anyway, I promised step by step, so here it is:

You don’t need to do much else. Actually, you don’t want to. Your SIEM is technically operational, and yet it is an absolute pain to work with. Why?

First of all, you’ve brought over all the technical debt from the old SIEM into the new one. Every rule that didn’t work, every dashboard that showed nothing useful, all of that came with you.

Then, you’re probably over budget right off the gate. This is especially true if you’ve moved from an on-prem solution to the new SIEM. Migration is the perfect opportunity to trim unnecessary data, parse things better, maybe redirect some of it to a more cost effective option. You’ve done none of that.

Finally, and most importantly, you missed the opportunity to modernize. You’ll likely end up not taking advantage of the shiny featuers the new SIEM has to offer like UEBA, AI, ML, SOAR etc. because you’ll be busy untangling the mess that you’ve created. Believe it or not, technical debt has to be paid off.

I’ve seen organizations gravitate towards 1:1 migration approach because on paper it is a safe thing to do. If you’re not introducing any changes then you’re not blamed if anything breaks. Moving from SIEM A to SIEM B is already a challenging project, why add variables to it? The thing is - you have to if you want to migrate correctly.

HNDL (harvest now, decrypt later) is a strategy where threat actors collect data first and decrypt it once it becomes possible. Our SOCs are not so different, honestly. We also collect logs first, figure out how to get value from them later.

I call it CFDL (collect first, detect later) because I like how that acronym looks.

And look, you can’t common sense your way to a solid security monitoring strategy. This is because it makes sense to collect everything even remotely security relevant. Does it make sense to collect firewall logs? Sure. Endpoint logs? Yes, please. Cloud logs? Of course.

But in this article I won’t try to talk you out of it. In fact, I will encourage it. We’re peddling bad advice after all.

As far as what to expect, this is roughly the experience you’re in for:

If I had a dollar every time I heard that cloud SIEMs are expensive, I could afford a cloud SIEM (banger). And sure enough, I’ve met too many clients saying that cloud SIEMs with pricing built around ingestion volumes are simply too expensive.

But what more often is true is those clients tried a cloud SIEM without a clear approach, sent more data in that necessary and saw a cost they didn’t like.

For the purpose of this article I’m not explaining how to properly approach your data collection strategy. This is the bad advice section after all. If you’re interested in learning the right way of doing things, you might want to read this article:

You common sense just had a stroke. “Surely we need to focus on the most important systems we have!” - you, probably.

Yes, but consider this. By the time a threat actor reaches a crown jewel, it’s typically late in the attack chain. By focusing on monitoring of the most cirtical assets first, we decrease our ability to detect and subsequently stop the attack at the earlier stages.

Crown jewel monitoring is a fun topic, because companies rarely have a concept of crown jewels. What’s funnier is that many attempts to devise a list of crown jewels end with the security team deciding what the crown jewels are. Here’s roughly the workflow:

For security monitoring purposes, we want 3–5 crown jewels to work with. Any more than that dilutes the meaning of what a crown jewel is. And yet, businesses typically come up with long lists of crown jewels, mainly because their methodology is lacking.

My bad advice here is - allow it.

This almost guarantees problems further down the road. First of all, whatever time you have in mind to set up security monitoring for cjs - double it. Here are some of the issues you will realistically face:

In practicie, crown jewel monitoring is a never ending project. I’ve seen multiple SOCs stuck in this cycle of trying to establish good coverage of their cjs while failing to detect the most basic attacks. Happens more often than you’d think.

Early focus on crown jewels guarantees that things will be missed downstream. And as stated previously, even though you’ll have a narrow visibility of your most important systems, you’re missing the chance of picking up an attack prior to it hitting a crown jewel.

After all, in a properly designed architecture, crown jewels should not be easily accessible (I’m not open to discussing that thesis).

There you have it. Three antipatterns to avoid. Or patterns to follow if your goal is to absolutely tank your security monitoring program:

If this way of thinking about SecOps resonates with you, I'll be sending newsletters out weekly(ish). The best way to follow along is to subscribe to the SecOpsPOV newsletter below. No spam or vendor pitches. Just more of this.