I work the alerts, and I write the detections that raise them.

Blue team. Most of my hours go where a SOC actually lives: Sysmon and Windows event logs, AD authentication, PowerShell activity, Splunk searches that start as a hunch and end as a rule.

Cloud isn't a separate track for me — it's another log source on the same console. A role session hitting CloudTrail from an address that has no business holding those credentials is the same investigation I'd run on a workstation, with different field names. Being able to follow the attacker across both is the part that stopped me being a beginner.

The loop I enjoy: run the technique in my lab, find it in the logs, write it in Sigma or SPL, then break my own rule until it survives contact with normal traffic. Half of detection engineering turns out to be deleting rules that were never going to fire cleanly. Everything below is the working record of that.

enterprise-threat-detection-soc-lab — My SOC lab, end to end: endpoint and cloud telemetry ingestion, custom Splunk SPL detections, attack emulation mapped to ATT&CK. The whole pipeline, not a rule in isolation.

SOC-Log-Analysis-Datasets — Windows, web, firewall, and cloud logs with attack vectors embedded, MIT licensed. Made it because practice data with known ground truth is annoyingly hard to find.

CLI-Threat-Analyzer — Python terminal tool that parses logs, digests threat-intel reports, and inspects suspicious files. Built to delete the copy-paste half of triage.

mitre-attack-study-guide — Offline single-page ATT&CK v19 reference and study tool. Writing it was how I actually learned the matrix.

soc-analyst-writeups — Investigations from alert to verdict, including the ones I called wrong on the first pass.

In progress: a hybrid purple-team SOAR that closes the loop — emulate, detect, respond automatically, measure what the response missed.

Techniques I've run end to end: executed the behaviour, pulled the telemetry, wrote the rule, tuned out the noise.

Last row, roughly as it ships:

title: CloudTrail Logging Disabled
status: experimental
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventSource: cloudtrail.amazonaws.com
    eventName:
      - StopLogging
      - DeleteTrail
  condition: selection
level: high
falsepositives:
  - Trail rebuilt by IaC — correlate against the deploy pipeline identity before escalating

No threshold on that one. If someone turns off the recorder, the first event is the incident.

SIEM & Detection

Endpoint & Identity

Triage & Analysis

Network & Traffic

Cloud Telemetry

Automation & Tooling

Frameworks & Process

Scope before anything else. One host or many, one identity or many. That answers whether this is a ticket or an incident.

Look for what disproves me. Writing down the benign explanation first stops me from building a story around the first suspicious field I see.

Enrich, then escalate. Identity, owner, change history, reputation. An escalation with no context is a forwarded email.

Verdict with a confidence level. "Likely benign, medium confidence, here's what would change my mind" hands off cleanly. "Suspicious" doesn't.

Every false positive is a tuning ticket. A rule nobody trusts is worse than no rule.

• Growing the lab's detection library and writing each case up as I close it
• Splunk Core Certified Power User, in progress
• Rebuilding public detection rules in my own environment to find where mine are weaker

_{Open to SOC analyst and detection engineering work — remote or relocating. Happy to walk through any case file in soc-analyst-writeups.}