🔧 Detection-as-Code: What It Really Means

Masterclass Series – Part 2

---

🧭 TL;DR: It’s Not Just “Put Your Rules in Git”

“Detection-as-Code” sounds like a trendy buzzword — and in some orgs, that’s all it is. But when done right, it’s a powerful transformation that:

• Turns detections into collaborative, auditable, testable logic
• Makes your SIEM stack faster to adapt, easier to trust, and safer to scale
• Pulls detection engineering out of the “power user” corner and into proper software development

And the best part? You don’t need a Kubernetes cluster or a team of DevOps engineers to start doing it.

---

🧱 What Is Detection-as-Code?

At its core, Detection-as-Code (DaC) is this:

🔄 Treat detection logic like software code — not static SIEM config.

This includes:

• Storing your rules, macros, thresholds, parsers in Git
• Structuring your detection content as modular, reusable files
• Using proper workflows — pull requests, reviews, CI pipelines
• Building, testing, and deploying changes safely and visibly

Think: the same way dev teams manage production code, you manage production logic.

It’s not a tool. It’s a mindset backed by a workflow.

---

🪚 Old World vs New World

Let’s compare what many orgs still do vs what a Detection-as-Code approach looks like.

🏚️ Old School SIEM	🚀 Detection-as-Code
Click “Save” in Splunk Web	Git commit + push
One-off rule tweaks nobody tracks	Version history + code review
Same logic copied across rules	Reusable macros or libraries
Rules break silently	CI pipeline catches errors
Alert noise is “just part of it”	Alerting logic is tested + refined

---

🧪 Real-World Example: Managing Correlation Rules in a Custom App (savedsearches.conf)

Let’s say we’re building a detection for RDP lateral movement, and we want to manage it properly — no UI edits, no ad hoc hacks. Just good, clean detection engineering.

🗂️ Step 1: Create or Edit a Custom App

Create a folder structure for your detection app, e.g.:

my_detection_app/
└── default/
    └── savedsearches.conf

Inside savedsearches.conf, we define the rule:

[ES - Lateral Movement via RDP - Multiple Targets]
action.notable = 1
action.notable.param.rule_description = This detection identifies users making RDP connections to multiple unique internal hosts in a short period, which may indicate lateral movement.
action.notable.param.severity = high
action.notable.param.urgency = high
action.notable.param.risk_score = 80
action.notable.param.confidence = 90
action.notable.param.priority = critical
action.notable.param.rule_title = RDP Lateral Movement - Multiple Hosts
action.notable.param.threat_object_field = user
action.notable.param.threat_object_type = user
action.notable.param.threat_group = endpoint
action.notable.param.ttl = 60
alert.track = 1
alert.suppress = 0
alert.suppress.fields = user
cron_schedule = */5 * * * *
dispatch.earliest_time = -5m@m
dispatch.latest_time = now
enableSched = 1
description = Correlation rule to detect potential lateral movement via RDP connections to multiple targets from a single user in a short window.
search = `get_windows_rdp_logs()` 
  | stats dc(dest) AS dest_count, values(dest) as dest_list, values(src) as sources by user 
  | where dest_count >= 5 
  | `notable` 

• 🔁 No SPL in the UI — it’s all here
• 🧠 Easy to tweak logic or thresholds
• 📦 Packaged like any other app

---

🔧 Step 2: Track It in Git

Add it to your Git repo and version it:

git add my_detection_app/default/savedsearches.conf
git commit -m "Add RDP Lateral Movement detection to app"

Make changes via pull requests — not directly in Splunk.

---

🚀 Step 3: Deploy It Like an App

You can deploy this app:

• Via scripted packaging (.tgz)
• Through GitLab pipelines
• Or even manually (copy to $SPLUNK_HOME/etc/apps/)

On restart (or reload), your detection is live.

---

🧪 Bonus: Local Testing Before Commit

You can manually test the search = ... SPL in Search, or:

• Use a dev/test instance
• Test macros (e.g. get_endpoint_data()) for expansion
• Validate logic before pushing

---

✅ What You Get

• 🧾 Version control with real audit trails
• 🛠️ Consistent detection packaging
• 🧪 Ability to test and review changes
• 📦 Easy rollback and portability

---

This is Detection-as-Code in its simplest form: treat correlation rules like software. No manual clicks. Just real config, owned in Git, shipped like any other product.

---

🧰 Tooling: What You Need (And What You Don’t)

Many think Detection-as-Code = complex infrastructure. Not true.

Here’s what the maturity curve looks like:

Level	Setup	Git Needed?	Bonus
🟢 Level 1: Git Lite	Store detection rules in Git repos manually	Yes	Manual reviews, simple folder structure
🟡 Level 2: Workflow	Introduce merge requests and peer review	Yes	Team collaboration + structured changes
🟠 Level 3: CI/CD	Add pipelines to validate, package and deploy content	Yes	Auto-checks, app inspect, validation gates
🔴 Level 4: Automation Nirvana	Fully automated testing, staging, deployment	Yes	Auto-rollback, tests on sample data, tagging, approvals

Even Level 1 gives you wins. You don’t need to jump to full automation to start.

---

👣 How to Start Detection-as-Code Right Now

No budget? No problem.

Start with this:

1. Create a Git repo (private is fine) for your detection content
2. Export all saved searches and macros into .conf files
3. Commit those files with useful commit messages
4. Start writing detection rules in modular form — use macros, tags, comments
5. Introduce merge requests for any change
6. If you’re using Splunk:
   • Use btool locally for testing
   • Use app inspect before deploying
   • Zip and upload via the UI or API

💡 Tip: Work in modular apps (e.g. detections_custom) so you can deploy safely without risking core ES apps.

---

🧠 Cultural Shift: Detection Engineers = Engineers

One of the biggest blockers to Detection-as-Code isn’t tech — it’s attitude.

Detection engineers are often seen as “power users” or “admins”. That’s wrong.

Detection Engineers design, build, debug, document, and maintain logic that directly affects the organisation’s risk posture.

That’s engineering.

And that means we should:

• Work from branches, not prod
• Review each other’s changes
• Refactor bad logic
• Write comments like devs do

---

🔄 But My SOC Isn’t Ready…

That’s okay.

You can still be the person who starts the shift. Even if it’s just you and GitHub at first.

Introduce version control. Start writing modular detections. Share the benefits.

Every mature Detection-as-Code setup started with one person saying:
“There has to be a better way.”

---

💬 Final Thoughts

Detection-as-Code is not about overengineering. It’s about building trust, quality, and agility into your detection content.

Even small steps have massive payoffs:

✅ Fewer mistakes
✅ Better visibility
✅ Faster fixes
✅ Happier SOCs
✅ Stronger detections

---

📌 Coming Next in the Masterclass Series…

🔜 Accelerated Data Models: When They Help — and When They Hurt