Listen to this Post
Introduction:
The escalating volume and sophistication of modern cyber threats have pushed traditional, manual detection engineering to its breaking point. In response, the cybersecurity industry is pivoting towards a paradigm known as Detection-as-Code (DaC), which applies software development best practices like version control, automated testing, and continuous integration to security detection logic. This article explores the practical implementation of DaC through frameworks like OpenTIDE, providing security engineers with the commands and code to build an automated defense pipeline.
Learning Objectives:
- Understand the core principles and benefits of Detection-as-Code.
- Learn to implement a basic Detection-as-Code workflow using Git, Python, and Sigma rules.
- Acquire hands-on knowledge for validating, testing, and deploying detections in a cloud environment.
You Should Know:
1. Version Controlling Your Detections with Git
The foundation of DaC is treating detection logic as source code. Git provides the version control necessary for collaboration, audit trails, and rollback capabilities.
Commands & Code:
Initialize a new Git repository for your detection rules git init my-detection-repo cd my-detection-repo Create a directory structure for organization mkdir sigma-rules mkdir tests mkdir pipelines Add your first Sigma rule and commit it git add sigma-rules/process_hollowing.yml git commit -m "feat: add initial Sigma rule for process hollowing detection"
Step-by-step guide:
This setup creates a structured repository for your detection content. Using Git allows you to track changes to each rule, see who made them, and revert to a previous working version if a new rule causes false positives. The directory structure keeps rules, their corresponding tests, and deployment pipeline code organized and separate.
2. Writing Portable Detections with Sigma Rules
Sigma is a generic, open-source signature format for log events that can be converted into queries for specific SIEMs like Splunk, Elasticsearch, or Microsoft Sentinel. This eliminates vendor lock-in for your detection logic.
Code Snippet (Sigma Rule YAML):
title: Suspicious Process Hollowing Detection id: 9a8b7c6d-1234-5678-9abc-def012345678 status: experimental description: Detects a parent process spawning a child process and then terminating the child, a potential indicator of process hollowing. author: Your Name references: - https://attack.mitre.org/techniques/T1055/ logsource: category: process_creation product: windows detection: selection: ParentImage|endswith: '\msbuild.exe' Image|endswith: '\rundll32.exe' condition: selection falsepositives: - Legitimate software administration level: high tags: - attack.defense_evasion - attack.t1055
Step-by-step guide:
This YAML file defines a detection rule. The `logsource` specifies it’s for Windows process creation logs. The `detection` block defines the pattern to look for—in this case, `msbuild.exe` spawning rundll32.exe, which is a common abuse pattern. The `references` and `tags` link the rule directly to the MITRE ATT&CK framework, providing crucial context for analysts.
3. Converting and Validating Sigma Rules
Sigma rules are not directly executed by a SIEM. They must be converted into a query language like Splunk Processing Language (SPL) or Kusto Query Language (KQL). This is done using the Sigma CLI tool.
Commands & Code:
Install the Sigma CLI and Splunk backend pip install sigmatools Convert a Sigma rule to a Splunk query sigmac -t splunk -c tools/config/splunk-windows.yml sigma-rules/process_hollowing.yml Validate the rule's YAML syntax without converting sigmac -t splunk --validate sigma-rules/process_hollowing.yml
Step-by-step guide:
The `sigmac` tool is the workhorse for converting your portable Sigma rule into a vendor-specific query. The `-t` flag specifies the target (e.g., splunk, elasticsearch, azure-loganalytics). The `–validate` flag is crucial for your CI/CD pipeline; it checks the rule’s syntax for errors before the rule is even committed to the main branch, ensuring code quality.
4. Testing Detections with Synthetic Data
Before deploying a detection, you must verify that it triggers on known-bad activity and does not trigger on benign activity. This involves generating synthetic attack logs.
Code Snippet (Python Test Script):
import yaml
import subprocess
Load the Sigma rule
with open('sigma-rules/process_hollowing.yml', 'r') as file:
rule = yaml.safe_load(file)
Simulate a log entry that should trigger the rule
true_positive_log = {
"ParentImage": "C:\Windows\System32\msbuild.exe",
"Image": "C:\Windows\System32\rundll32.exe"
}
Simulate a benign log entry
false_positive_log = {
"ParentImage": "C:\Windows\explorer.exe",
"Image": "C:\Program Files\Vendor\app.exe"
}
Function to test a log entry (pseudo-code)
def test_detection(log_entry, rule):
This function would convert the rule to a query and run it against the log entry.
if all(log_entry.get(key) == value for key, value in rule['detection']['selection'].items()):
print("ALERT: Detection triggered!")
else:
print("No alert generated.")
test_detection(true_positive_log, rule) Should alert
test_detection(false_positive_log, rule) Should not alert
Step-by-step guide:
This Python script demonstrates the principle of unit testing for detections. By creating logs that clearly should and should not trigger the rule, you can validate the rule’s logic. In a mature DaC pipeline, this would be automated, running these tests against a containerized SIEM instance for every proposed change to a rule.
5. Automating Deployment with CI/CD Pipelines
A CI/CD pipeline automates the process of testing, converting, and deploying detection rules. GitHub Actions is a common tool for this purpose.
Code Snippet (GitHub Actions Workflow .yml):
name: Deploy Detection Rules on: push: branches: [ main ] jobs: test-and-deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 <ul> <li>name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.10'</p></li> <li><p>name: Install Sigma run: pip install sigmatools</p></li> <li><p>name: Validate Sigma Rules run: | for file in sigma-rules/.yml; do sigmac --validate "$file" done</p></li> <li><p>name: Convert Rules for Splunk run: | mkdir converted-rules for file in sigma-rules/.yml; do sigmac -t splunk -c config/splunk-windows.yml "$file" > "converted-rules/$(basename "$file" .yml).spl" done</p></li> <li><p>name: Deploy to Splunk run: | Script to authenticate to Splunk API and deploy the .spl files ./scripts/deploy_to_splunk.sh converted-rules/
Step-by-step guide:
This workflow file is placed in the `.github/workflows/` directory. Every time a change is pushed to the `main` branch, it automatically: 1) Validates all Sigma rules, 2) Converts them to Splunk queries, and 3) Runs a custom script to deploy them via the Splunk REST API. This ensures that your SIEM’s detection content is always in sync with the version-controlled source of truth.
6. Cloud Security Hardening with Infrastructure-as-Code
DaC extends beyond SIEM rules to the configuration of the cloud environment itself. Tools like Terraform can enforce secure baselines.
Code Snippet (Terraform – Enable AWS GuardDuty):
Configure the AWS Provider
provider "aws" {
region = "us-east-1"
}
Enable GuardDuty in the master account
resource "aws_guardduty_detector" "master" {
enable = true
}
Create a S3 bucket for CloudTrail logs
resource "aws_s3_bucket" "cloudtrail_logs" {
bucket = "my-secure-cloudtrail-bucket"
}
Enable CloudTrail to log to the S3 bucket
resource "aws_cloudtrail" "main" {
name = "main-cloudtrail"
s3_bucket_name = aws_s3_bucket.cloudtrail_logs.id
include_global_service_events = true
is_multi_region_trail = true
enable_log_file_validation = true
}
Step-by-step guide:
This Terraform script ( `main.tf` ) hardens your AWS environment by enabling essential logging and threat detection services. It creates a GuardDuty detector, an S3 bucket for logs, and a multi-region CloudTrail trail with log file validation. Applying this code ensures a consistent, auditable security baseline across all your environments.
7. Querying Cloud Logs for Threat Hunting
With logs centralized in the cloud, you can use SQL-like queries to proactively hunt for threats. This is a sample query for AWS CloudTrail.
Code Snippet (SQL Query for AWS Athena):
-- Detect a user assuming multiple roles in a short timeframe, potentially indicating lateral movement. SELECT userIdentity.arn, eventSource, eventName, COUNT() AS assumption_count FROM cloudtrail_logs WHERE eventTime >= NOW() - INTERVAL '1' HOUR AND eventName = 'AssumeRole' GROUP BY userIdentity.arn, eventSource, eventName HAVING COUNT() > 5 ORDER BY assumption_count DESC;
Step-by-step guide:
This query runs in AWS Athena against your CloudTrail logs. It looks for a single user (userIdentity.arn) performing an unusually high number of `AssumeRole` operations within one hour. This pattern could indicate an attacker trying to move laterally through your AWS account. Saving this as a named query turns a manual hunting exercise into a repeatable, automated detection.
What Undercode Say:
- Automation is Non-Negotiable: The manual era of detection engineering is over. Scaling defense to match offensive capabilities requires the full automation, testing, and deployment rigor of software engineering.
- Context is King: Frameworks like OpenTIDE that integrate threat modeling directly with detection engineering will create more intelligent and context-aware detections, drastically reducing false positives and alert fatigue.
The shift to Detection-as-Code represents a fundamental maturation of the cybersecurity function. It moves security teams from a reactive stance to a proactive, engineering-centric discipline. By leveraging tools like Git, Sigma, and CI/CD pipelines, organizations can build a resilient, scalable, and auditable detection system. The integration with LLMs, as hinted in the source material, is the next frontier; AI can assist in generating detection logic from threat reports, further accelerating this automated defense lifecycle. The future belongs to those who code their defenses.
Prediction:
The widespread adoption of Detection-as-Code and AI-augmented frameworks like OpenTIDE will create a “defense-in-depth” gap between organizations. Those who embrace it will achieve security operations that are faster, more scalable, and predictive, automatically adapting to new threats. Those who do not will be overwhelmed by the volume of attacks and the manual effort required to keep pace, leading to increased dwell times and more frequent breaches. This will solidify DaC not as a best practice, but as a core requirement for enterprise resilience.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Adan %C3%A1lvarez – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
