Detection as Code

Security detections written as code — not just saved searches. Each detection in this repo is defined in YAML, mapped to a MITRE ATT&CK technique, and includes the Splunk SPL query, alert threshold, response action, and documentation all in one place.

The idea is simple: if your detections aren't version-controlled, they're not really managed. This repo treats alerts the same way developers treat code.

---

Why Detection as Code?

Most Splunk alerts live only inside the UI. That means:

• No version history — you don't know who changed what or when
• No peer review — a bad query goes live immediately
• No portability — migrating to a new environment means rebuilding everything

This repo fixes that. Every detection is a file you can review, test, and deploy.

---

Detections Included

Detection Name	MITRE Tactic	Technique	Severity	Status
Brute Force Login Attempts	Credential Access	T1110	High	✅
Suspicious PowerShell Execution	Execution	T1059.001	High	✅
New Local Admin Account Created	Persistence	T1136.001	Critical	✅
Windows Security Log Cleared	Defense Evasion	T1070.001	High	✅
Outbound Connection to Rare Country	Exfiltration	T1048	Medium	✅
Internal Port Scan Activity	Discovery	T1046	Medium	✅
Pass-the-Hash Indicator	Lateral Movement	T1550.002	Critical	✅
C2 Beacon Pattern Detected	Command & Control	T1071	High	✅

---

Repo Layout

detection-as-code/
├── README.md
├── detections/
│   ├── credential-access/
│   │   └── brute-force-login.yml
│   ├── execution/
│   │   └── suspicious-powershell.yml
│   ├── persistence/
│   │   └── new-local-admin.yml
│   ├── defense-evasion/
│   │   └── security-log-cleared.yml
│   ├── exfiltration/
│   │   └── outbound-rare-country.yml
│   ├── discovery/
│   │   └── internal-port-scan.yml
│   ├── lateral-movement/
│   │   └── pass-the-hash.yml
│   └── command-and-control/
│       └── c2-beacon-pattern.yml
└── docs/
    ├── detection-template.yml
    └── contributing-guide.md

---

Detection Format

Every detection follows the same YAML structure so they're easy to read and consistent across the repo.

# brute-force-login.yml

name: Brute Force Login Attempts
description: >
  Detects repeated failed login attempts against a single account in a short
  time window. Could indicate a password spray or brute force attack in progress.

mitre:
  tactic: Credential Access
  technique: T1110
  subtechnique: T1110.001

severity: High
status: production

splunk_query: |
  index=windows sourcetype=WinEventLog:Security EventCode=4625
  | bucket _time span=5m
  | stats count as failed_logins by _time, user, src_ip
  | where failed_logins >= 10
  | sort - failed_logins

threshold:
  field: failed_logins
  value: 10
  window: 5m

alert_action:
  - notify: SOC email
  - create_ticket: True
  - priority: P2

log_sources:
  - index: windows
  - sourcetype: WinEventLog:Security
  - event_id: 4625

false_positives:
  - Automated service accounts with expired passwords
  - Helpdesk bulk password resets
  - Users locked out after travel or device change

tune_suggestions: >
  If noisy, whitelist known service accounts or increase threshold to 20+
  failures. Also consider filtering by specific source IPs if internal
  scanning tools are triggering it.

created: 2024-09-01
last_updated: 2024-11-10
author: Solomon-CyberSec

---

Another Example — Windows Log Clearing

# security-log-cleared.yml

name: Windows Security Log Cleared
description: >
  Detects when the Windows Security event log is cleared (Event ID 1102).
  This is a strong indicator of an attacker trying to cover their tracks
  after a compromise. Legitimate clearing is rare and should always be
  tracked.

mitre:
  tactic: Defense Evasion
  technique: T1070
  subtechnique: T1070.001

severity: High
status: production

splunk_query: |
  index=windows sourcetype=WinEventLog:Security EventCode=1102
  | stats count by host, user, _time
  | sort - _time

threshold:
  field: count
  value: 1
  window: 1m

alert_action:
  - notify: SOC email
  - notify: Security Manager
  - create_ticket: True
  - priority: P1

log_sources:
  - index: windows
  - sourcetype: WinEventLog:Security
  - event_id: 1102

false_positives:
  - Scheduled log rotation by IT operations (should be documented)
  - Compliance-driven log clearing with change ticket

tune_suggestions: >
  Almost no false positives in practice. If you do see legitimate clearing,
  document the authorized accounts and create an exclusion only for those.

created: 2024-09-15
last_updated: 2024-11-10
author: Solomon-CyberSec

---

Tools & Environment

• Splunk Enterprise / Splunk Cloud — where detections run
• YAML — detection definition format
• MITRE ATT&CK v14 — tactic and technique mapping
• Log sources: Windows Security Events, Palo Alto firewall, Syslog

---

About

10 years in IT, 6 years in cybersecurity (network security, SIEM engineering, SOC operations). MS in Information Systems, CCNP Security.

Part of a broader portfolio covering threat detection, incident response, and security automation.

GitHub: Solomon-CyberSec