Detection & SIEM

# Detection engineering - defender perspective

> Lab and authorised engagements only. This page is detection-engineering
> oriented: how blue teams write, test, and tune detections that survive
> real noise. Live red-team activity requires signed RoE and scoped consent.

## What separates good detections from noisy ones

- Tied to a specific TTP (MITRE ATT&CK technique), not a vendor tool
- Has a hypothesis ('we expect X to be rare; rare X is suspicious')
- Has both precision (low false positive) and recall (catches real cases)
- Has a documented response runbook
- Is testable in a lab with adversary emulation

## Common high-value detections

- Office app spawning powershell.exe or wscript.exe (T1059)
- Service or scheduled task created by a user account (T1053/T1543)
- Credential dumping signals (LSASS handle, MimiKatz strings)
- Cloud: console login from new geo / new device (T1078)
- Cloud: new IAM access key created (T1098)
- Network: beacons on long jitter intervals
- DNS: anomalously long domain names, low entropy, fast-flux behaviour

## Building a detection lifecycle

1. Hypothesis - 'attacker uses X technique'
2. Data source check - do we collect the events that prove or disprove?
3. Write the rule (Sigma, KQL, SPL, EQL)
4. Test in a lab (Atomic Red Team, MITRE Caldera)
5. Measure FP rate; tune
6. Document runbook + escalation
7. Sign off; ship; review every quarter

## Quality bars

- Mean time to detect (MTTD) target per severity
- Tabletops once per quarter for top scenarios
- Purple-team exercises that update rules, not just findings

## Tools (defender)

- Sigma (vendor-neutral rule format) + sigmac translators
- MITRE ATT&CK + DETECT navigation
- Sysmon (with SwiftOnSecurity or Olaf Hartong config) + your SIEM
- Atomic Red Team for repeatable tests
- Velociraptor / GRR / OSQuery for live response and hunting

## Engagement reporting

- For every red-team finding, propose at least one detection + one prevention
- Reports are graded on what blue teams can change Monday morning

# Defenders log + alert. As an attacker you respect the noise floor.
# As a tester, you intentionally MAKE noise sometimes so you can ask:
# "Did this fire an alert?". Track results in your report.