Alright, let's just put it out there: I'm starting to get a bit disillusioned with the "AI SOC" hype when it comes to the actual, gritty work of detection engineering. We have all these amazing demos of AI writing incident summaries, correlating alerts, and even suggesting actions. But the foundational layer—creating a precise, reliable, and portable detection rule—still feels overwhelmingly manual.
Specifically, I keep waiting for an AI agent that can ingest a piece of threat intelligence—like a blog post detailing a novel persistence technique or a new malware command-and-control pattern—and produce a robust Sigma rule that I'd actually consider deploying. Not just a skeleton with placeholder logic, but a rule with:
* Properly normalized field mappings for my most common log sources (think Microsoft 365, AzureAD, CrowdStrike, etc.)
* Correct conditionals that account for edge cases and potential false positives (like excluding known admin processes or common benign scripts)
* A meaningful description and references section pulled from the source material.
* An understanding of the difference between a high-fidelity alert and a broad hunting rule.
Right now, if I try to use a general-purpose LLM for this, I spend more time correcting its misunderstandings of CIM (Common Information Model) fields and Sigma syntax than if I'd just written it myself. The promise of the "AI SOC" is supposed to be scaling human expertise, not creating a new chore of AI supervision.
So my question to this community is twofold:
1. **Are any of you actually using an AI tool or agent that successfully assists in writing *production-ready* detection rules?** I'm talking beyond simple pseudo-code generation.
2. **What would your ideal "Sigma Rule Agent" workflow look like?**
For me, the dream pipeline would be:
* **Input:** A URL to a threat report, or a pasted technical description of an attack pattern.
* **Agent Tasks:**
* Summarizes the key TTPs and IOCs.
* Identifies the most relevant log sources (Sysmon, CloudTrail, etc.).
* Drafts a Sigma rule, flagging areas of uncertainty (e.g., "Is the registry key path case-sensitive?" or "Should this be filtered by user privilege?").
* Optionally, suggests potential related rules for a broader detection coverage.
* **Output:** A Sigma rule in a PR/MR, ready for a human to review, test, and approve.
Is this just a pipe dream with current tech? Or are we on the cusp of seeing this become a reality? I'd love to hear about your experiences, frustrations, and any tools or internal projects that are pushing the envelope here.
~Jane
Stay connected
You're not wrong. The demos always skip the part where you have to feed it your specific log schema. It's like asking for a budget forecast but the AI doesn't know the difference between an On-Demand Instance and a Reserved Instance up front.
I've seen attempts, but they usually spit out a rule with generic `process_name` fields when you need `aws.cloudtrail.userIdentity.sessionContext.sessionIssuer.userName`. Until an agent can ingest *your* data catalog and understand those mappings, it's just a fancy templating engine.
Maybe the real AI agent we need is one that first audits your broken log pipelines. That's where the real savings in alert fatigue would come from.
- elle