Detection Engineering: DIY or Die Trying

There’s a rising practice becoming the critical backbone of SecOps—and surprise, it’s not CNAPP. Sorry, unicorn Wiz.

Hey, I’m Alex Hurtado—and if we haven’t met, here’s the TL;DR on me: I got into cybersecurity because I couldn’t resist asking questions and figuring out how shit works. My former boss pulled me from another team doing something completely different into hers. I then pretty much cut my teeth on that team monitoring satellite comms that protected prime-time TV commercial space (a 5 million dollar per 30-second slot business model). I dabbled in QRadar after that before landing in the world of detection engineering (DE). Now, I host a podcast on it, but that’s not why we’re here.

We are here for the 2025 State of Detection Engineering Report, which I just went live with to capture the true pulse of this evolving role. We teamed up with SANS Institute and tapped 264 security professionals across industries, regions, and org sizes to get an authentic snapshot of where detection engineering stands today. And let me tell you—this data? Absolute gold. It’s the inspiration for the spicy takes you’re about to read.

First Up: This Detection Engineering (DE) Gig Didn’t Even Exist a Decade Ago

Crazy, right? Just ten years ago, detection engineering wasn’t even a thing—now, 70% of enterprise organizations have dedicated teams, and 80% are putting real money behind it. What changed? This pivotal moment I’m seeing and am witness of, flashes before me of the industry going from tactical alert monkey triage to a more strategic approach. Security teams seem to collectively agree that—off-the-shelf security content kinda sucks.

What I mean is that security is moving away from signature-based detections and static rules—especially as Living-Off-the-Land (LOL) techniques make them easier to bypass. This shift played a big role in the rise of detection engineering. It became clear that security couldn’t just be about maintaining EDR, firewalls, and SIEMs anymore—someone needs to connect the dots across these tools.

Enter the Detection Engineer.

What Detection Engineers Love vs. Hate

According to the survey, detection engineers love building detections (shocker) and threat hunting. So this THOR Collective Collab that’s all about community just couldn’t have come at a better time!

What do they hate?

• Putting together metrics/reporting on their work.

• Babysitting or tuning security tools (let’s be honest no one gets into security to babysit).

• Working with rigid, uncustomizable rules (ever tried fitting a square peg in a round hole? Or washing your shirt in the dishwasher, I have don’t try it!).

• Messing with siloed, incomplete data hygiene work.
  

And when it comes to detection types? Behavior-based detections dominate, which makes total sense—attackers change IOCs like outfits, but behaviors stay relatively consistent across threat groups and ransomware gangs.

The downside? Building behavior-based detections is a pain, and engineers reported their biggest struggles as:

• Mapping behaviors accurately (ATT&CK matrices are your friend, but also your enemy). I actually like AVV’s piece on how you really don’t need 100% coverage to win based on compound probability. If you’re not following AVV drop everything you’re doing and go do that! You won’t be disappointed.

• Tuning them to reduce noise without missing threats (good luck).

Scaling detections across multiple data sources (because SIEMs are hungry, expensive beasts).

And that brings me to my first hot take...

---

Your Environment, Your Detections—Why Let Someone Else Decide?

No one knows your environment better than you do. Buying generic detections and expecting them to work perfectly in your network is like letting an Airbnb guest tell you where your kitchen is. You know your house. You know the weird back door that sticks when it rains, the secret spot where you stash your good bourbon, and the exact path to the fridge in the dark.

Anyone outside your org? They don’t live there. They’re not in the thick of it, in good times and bad.

Out-of-the-box detections are fine as a starting point, but if you’re 100% reliant on them, you’re setting yourself up for some headaches. Here’s what the data says as to why:

• False positives galore. Prebuilt rules weren’t tuned for your logs, your users, or your infrastructure, so congrats, you’re now drowning in alerts that mean nothing.

• Attackers evolve, static rules don’t. The bad guys are tweaking their tactics daily—if your detections aren’t just as dynamic, guess who’s winning?

• Context is king. Your detection logic should reflect your environment’s nuances. Tough for a vendor to map that out for you and get that level of depth. In this particular case, YES IT IS that deep bro.

This is exactly why custom detections win every time. Detection engineers aren’t just alert monkeys—they’re true artists and sculptors, molding precise, high-fidelity detections that actually work. No matter what you’re using, sometimes you just have to bite the bullet and start from scratch. It’ll be far more effective, tailored to your environment, and a better investment than forcing something else to fit where it doesn’t belong.

But hey, don’t just take my word for it—the survey speaks for itself. Detection engineers overwhelmingly prefer custom, behavior-driven detections.

• 42% use custom detections

• Only 2% use only vendor detections

• 15% don’t use vendor detections at all
  
  I’ll leave you with some Alex Stemaly wisdom (my DE homie hacker over at LastPass)

---

What’s Next? Even Spicier Takes on Detection Engineering

This report uncovered a ton of insights, and I’m just getting started. Let us know what you’re interested in!

🔥 Types of Detections – Why some are MVPs and others are just noise.
🔥 THE UEBA Illusion– The good, the bad, and the “meh.”
🔥 The Unmonitored Device Problem – How rogue endpoints are ghosting your EDR like your GPS going down Lower Wacker (my Chicago peeps get it)
🔥 Detection-as-Code – reasons are obvious.