hawkinsops.com · Detection Engineering · Security Operations
Signal Architecture
Two-Lane System Model  ·  Lab Environment
Architecture Overview  ·  as of 03-25-2026
🧠
LANE 1 · CONTENT LAYER
Detection Engineering
Detection logic across multiple formats
Detection Formats
σ
Sigma Rules
Vendor-agnostic detection logic across all mapped MITRE ATT&CK tactics. Portable — translates into Wazuh XML and Splunk SPL.
103
rules
Coverage spans Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, and C2. Each rule verified against repo — counts are script-generated.
↳ Sigma rules translated/adapted → Wazuh XML where applicable
Wazuh XML Rules
Custom rule blocks running natively in Wazuh Manager. Direct detection content — separate from AutoSOC runtime ingestion.
29
rule blocks
Includes both Sigma-translated rules and native custom rules targeting Wazuh-specific telemetry (syscheck, syscollector, vulnerability detection). All deployed to Wazuh Manager config.
Splunk SPL Detections
Parallel detection format. Splunk is an investigation lane — not the live ingestion backbone of AutoSOC.
79
detections
Includes EventID 4688 process creation analysis, regex field extraction, and the independent threat hunt that correctly classified 375 Codex AI tool instances spawning pwsh.exe as tool behavior.
Supporting Content
📋 IR Playbooks
7-step structured format · linked to triage outputs · reproducible evidence capture
10
playbooks
Portfolio Output
Published to GitHub + hawkinsops.com
Proof credibility Portability demo Detection depth Format coverage Verified counts
⚠ Architectural Note
Splunk is not upstream of Wazuh. These are parallel detection content lanes — they share the same skill domain, not the same data path.
LANE 2 · RUNTIME LAYER
AutoSOC Live Pipeline
Wazuh-driven · unattended · deterministic · auditable
Alert Source
🖥
Lab Endpoints · Wazuh Manager · Wazuh Indexer
Monitored lab hosts · agent-reported telemetry · home lab environment
Lab Active
Runtime Stages — click to expand
STAGE 01Ingest
Alert Polling
poll-alerts.py
Scheduled pull from Wazuh Indexer API. Raw alert objects ingested into pipeline state for triage processing.
STAGE 02Triage
Policy-Driven Disposition
triage.py
Deterministic rule application — every alert gets a verdict. No ambiguous states passed forward.
Triage Outcomes
AUTO_CLOSE_BENIGN
AUTO_CLOSE_KNOWN_FP
ESCALATE
STAGE 03Redact
Redaction Gate
redact.py
Mandatory. PII and host identifiers sanitized before any output is assembled. Cannot be bypassed.
STAGE 04Pack
Evidence Pack Assembly
assemble-pack.py
Standardized escalation artifact. JSON structure, redacted fields, linked to triage decision record.
STAGE 05Reconcile
Ledger Integrity Check
reconciliation.py
All output counts verified against repo state. Mismatch count: 0. Cannot publish until PASS.
STAGE 06Gate
Coverage + Heartbeat Gate
coverage-check.py
All lab hosts must report heartbeat SUCCESS. Coverage gate must pass or publish is blocked. See proof.html for current coverage status.
STAGE 07Publish
Repo + Portfolio Staging
generate-metrics.js · run-factory.ps1
Outputs staged to repo. Metrics pushed to hawkinsops.com. Proof artifacts locked to canonical snapshot.
Pipeline Stats · as of 04-07-2026
324,074
Total Cases
as of 04-07-2026
~88%
Auto-Close
8,574
Escalations
as of 04-07-2026
Coverage Gate
📤
Auditable Outputs
hawkinsops.com GitHub proof_pack/ ops-metrics.json VERIFIED_COUNTS.md
The accurate one-sentence description
"My detection engineering spans Sigma, Splunk SPL, and Wazuh XML — but the live AutoSOC runtime pipeline is Wazuh-driven: Wazuh alerts are polled, triaged, redacted, packaged, and staged into auditable outputs through a scheduled, unattended pipeline that enforces reconciliation and coverage gates before anything publishes."
Detection content
AutoSOC runtime
Gate / status
Governance / redaction
Portfolio / proof
Verify the system — explore the proof
All counts are script-generated. Reproduction commands documented in the repo.