Detection Engineering with Sigma: From Rule to Production

Most SOC teams drown in alerts — yet still miss real threats. The problem is rarely the tools. It's the detection rules. Generic, vendor-supplied rules create noise. Custom rules built for your environment deliver actual security.

What is Sigma?

Sigma is an open, platform-agnostic format for writing detection rules. Think of it as YARA for log data. You write the rule once in YAML, then convert it to KQL (Sentinel), SPL (Splunk), Lucene (Elastic), or other SIEM formats.

Example: Detecting Kerberoasting

Kerberoasting is a common technique for stealing service account passwords from Active Directory. Here's what a Sigma rule looks like:

```yaml title: Kerberoasting Activity Detected status: stable logsource: product: windows service: security detection: selection: EventID: 4769 TicketEncryptionType: '0x17' TicketOptions: '0x40810000' filter: ServiceName|endswith: '$' condition: selection and not filter level: high tags:

• attack.credential_access
• attack.t1558.003

```

This rule catches TGS requests with RC4 encryption (0x17) that are not targeting machine accounts — a classic Kerberoasting pattern.

Detection-as-Code

Detection rules should be treated like code:

• Version control — All rules in Git with pull requests and code review
• Testing — Validate rules against known attack scenarios before production
• CI/CD — Automatic conversion and deployment to SIEM on merge
• Documentation — Each rule has a clear description, MITRE ATT&CK mapping, and response playbook

How to Build a Detection Program

1. Map the Threat Landscape

Start with MITRE ATT&CK and identify techniques relevant to your industry and infrastructure. Don't try to cover everything — prioritize based on risk.

2. Inventory Log Sources

You can only detect what you log. Map which log sources you have (Windows Event Log, Sysmon, firewall, proxy, AD) and identify gaps.

3. Write Targeted Rules

Focus on high-fidelity detections with low false positive rates. One good rule that catches real attacks is better than a hundred that generate noise.

4. Tune Continuously

After deployment, monitor alerts and adjust thresholds. Whitelist known processes. Measure detection rate and mean time to detect (MTTD).

5. Threat Hunting

Use hypothesis-driven threat hunting to find what rules miss. Findings from threat hunts become new detection rules — a continuous improvement cycle.

Common Mistakes

• Rules that are too broad — cause alert fatigue and SOC analysts who ignore alerts
• Missing context — in alerts — the analyst doesn't know what to do next
• No testing — — rules that were never validated against real attacks
• Static rules — — the threat landscape changes but the rules don't

ForSec builds detection programs from the ground up — from log mapping and rule development to CI/CD pipelines and continuous tuning. Get in touch to discuss how we can strengthen your detection capabilities.