And we have this week’s Friday SIEM post.
This week I wanted to talk about something that has been sitting in the back of my head for a while: where does attack emulation / simulation actually fit in the new SIEM architecture, whether we call it decoupled SIEM, Integrated SecOps, or whatever new acronym we invent next.
I think more people are finally realizing how important detection engineering is. Bad detections create a ton of pain downstream. But if we go even further left, the data pipeline matters just as much. Garbage in, garbage out still applies, even if the garbage is now being investigated by an AI agent with expensive frontier model .
If I had to put the SecOps lifecycle on a scale of importance, I’d probably put more weight on the left side. The funny part is that the left side is also the quiet one. Alerts, investigations and incidents usually make it obvious when something is wrong.
Pipelines and detections, on the other hand, can be broken for weeks without anyone noticing.
In most SIEMs, you won’t find out until an alert is supposed to fire, assuming it ever does.
By default, not many SIEMs give you particularly good pipeline monitoring(SIEM vendors don't jump now to convince me yours has the best one), so you need continuous testing to catch broken ingestion, parsing or detection logic before the attacker does.
And this is where I think attack emulation, detection validation, pipeline monitoring and the broader SecOps resilience bucket become really important.
Because if you don’t continuously test whether your detections actually catch what they were designed to catch, you basically have two options: trust that they work, or let the attacker QA them for you.
Neither is a great strategy.
Same for pipelines. If logs stop arriving, fields change, parsers break or some connector quietly dies, you might still have a beautiful SIEM dashboard. It just happens to be beautifully wrong.
Attack emulation has obviously been around for a long time, so none of this is particularly revolutionary. What I think is changing is that the category starts to expand. Automated red teaming, BAS, attack emulation, detection validation and probably parts of pipeline validation start converging into something closer to a continuous SecOps resilience layer.
And I think that becomes even more important as the SOC gets more automated. If agents are going to investigate, triage and eventually make more decisions for us, someone still needs to make sure the foundations underneath them are not held together with duct tape and three broken API integrations.
Does attack emulation remain its own category, or does it eventually become a native part of the SIEM / SecOps architecture?
Have a great weekend ahead!
Originally posted on LinkedIn on 11 September 2026
Read the original post and the comments