Detection Engineering 101: Using AI to Write One Rule and Convert It Everywhere


Detection engineering is a beautiful, frustrating, and often tedious art. You write a killer detection for one SIEM, pat yourself on the back, and then—bam—your SOC lead tells you it also needs to work in Splunk. And Sentinel. And whatever other logging monstrosity they’re using this week.

Now, you have two choices:

  1. Spend your afternoon manually rewriting queries in different languages or spend your time building pipelines to try and convert one language to another.
  2. Let AI do the heavy lifting.

Welcome to the new age of detection engineering—where AI helps us write once and (mostly) run anywhere.


The Pain of Multi-SIEM Detection Engineering

Let’s be real: SIEMs are all basically the same… except for when they aren’t.

They all take logs, store them, and let us run queries to find bad things. But when it comes to writing detections? Oh no, they each had to invent their own special snowflake query language.

  • Elastic Security? Uses KQL or EQL.
  • Splunk? Bless its heart, it runs on SPL.
  • Microsoft Sentinel? Yep, it had to be different, too—KQL, but not the same KQL as Elastic.

So now you have to write the same logic in three different dialects, which is both time-consuming and soul-draining. But AI can help.


How AI Can Generate and Convert Detections

AI isn’t going to replace your job as a detection engineer (yet), but it can do the annoying grunt work—like translating a query into different SIEM formats.

Step 1: Write Once, Use Everywhere

Let’s say we want to detect some shady PowerShell execution—you know, the kind threat actors love because LOLBAS (Living Off The Land Binaries and Scripts) is their jam.

Our Elastic Query (KQL)

process where process.name : "powershell.exe" and process.args : ("-enc", "-w hidden", "-nop")

Great. It’s clean, simple, and would work beautifully in Elastic Security. But we also need it in Splunk and Sentinel.

Step 2: AI Does Its Magic

Instead of manually rewriting this for each platform, we toss it into an AI model trained on query conversion (or even use ChatGPT, GitHub Copilot, or a custom-built internal tool).

Here’s what AI gives us:

Splunk (SPL)

index=windows EventCode=4688 Image="*powershell.exe" CommandLine="*-enc* -w hidden -nop*"

Microsoft Sentinel (KQL)

SecurityEvent
| where EventID == 4688 and ProcessName == "powershell.exe"
| where CommandLine contains "-enc" and CommandLine contains "-w hidden" and CommandLine contains "-nop"

Boom. AI just saved us 15-30 minutes of query rewriting. That’s more time for coffee, doomscrolling, or pretending you’re updating documentation.


Why You Still Need to Know Query Languages

Now, before you go full automation-hype, let’s be clear: AI isn’t perfect.

  • Log sources aren’t identical. Splunk and Sentinel might log process executions differently, so blindly trusting AI-generated detections is how you miss alerts (or flood your SIEM with garbage).
  • Performance matters. Some AI-generated queries might run, but they could be horrendously inefficient. You don’t want to be that engineer who crashes Splunk with a 10-minute regex disaster.
  • Tuning is still on you. AI doesn’t know your environment—it’ll write a generic query, but you’ll still need to tweak filters, add thresholds, and remove noise.

Translation: AI is your assistant, not your replacement.


The Future of AI in Detection Engineering

We’re just scratching the surface of what AI can do here. In the next few years, we’ll likely see:

  • Self-tuning detections: AI learning from past false positives and tweaking thresholds automatically.
  • Threat-informed detection engineering: AI analyzing new threat reports and suggesting pre-written detections.
  • Instant SIEM conversions as a built-in feature: Eventually, Elastic, Splunk, and Microsoft will realize we don’t want to do manual conversions and automate it themselves. (Okay, that last one might take a while—vendor lock-in is a hell of a drug.)

Final Thoughts: Work Smarter, Not Harder

AI-assisted detection engineering isn’t about replacing your knowledge—it’s about removing the boring parts so you can focus on the interesting work: tuning, testing, and actually catching threats.

So, next time you find yourself manually rewriting a detection for the third SIEM of the day, ask yourself: Why suffer? Let AI do the heavy lifting. You’ve got better things to do—like finding that one threat actor who insists on naming their C2 servers after Pokémon.

Happy hunting.


Discover more from Annoyed Engineer

Subscribe to get the latest posts sent to your email.

, ,

Leave a Reply

Your email address will not be published. Required fields are marked *