B13 // DETECTION ENGINEERING

Detection Library

Detection engineering at BELISARIUS13 focuses on turning observed adversary behavior into testable, explainable and reproducible defensive logic.

SIGMA ELASTIC KQL SURICATA MITRE ATT&CK DETECTION-AS-CODE
DETECTION PHILOSOPHY

Detection is an engineering process.

A rule is not considered useful simply because it matches an event. It must be tied to a hypothesis, tested against known behavior and revalidated after tuning.

01 // BEHAVIOR

Start with attacker behavior

Define what activity should be visible before writing detection logic.

02 // TELEMETRY

Know the evidence source

Identify which endpoint, network, identity or cloud telemetry should contain the behavior.

03 // TEST

Generate known activity

Execute controlled activity so the detection can be tested against a known ground truth.

04 // TUNE

Measure signal quality

Document false positives, environmental assumptions and tuning decisions.

VALIDATION PIPELINE

Detection lifecycle

Every BELISARIUS13 detection should move through the same validation workflow before it is marked as complete.

01 HYPOTHESIS Define the behavior.
02 TELEMETRY Locate the evidence.
03 DETECT Write detection logic.
04 TEST Generate known activity.
05 TUNE Reduce noise.
06 VALIDATE Retest and document.
DETECTION SCHEMA

What every detection documents

The library uses a consistent structure so a detection can be understood, tested and maintained by someone other than the original author.

01

Detection Hypothesis

What behavior are we attempting to identify and why is it suspicious?

02

ATT&CK Mapping

Technique, sub-technique and tactical context associated with the behavior.

03

Telemetry Source

Events, fields, logs and sensors required for the detection to function.

04

Detection Logic

Sigma rule, Elastic query, KQL query, Suricata signature or other logic.

05

Test Procedure

How the controlled activity is generated and what evidence is expected.

06

False Positives

Known benign behavior and environmental conditions that may trigger it.

07

Tuning Notes

Changes made to improve fidelity while preserving useful coverage.

08

Validation Result

Whether the rule fired, what was observed and whether retesting succeeded.

DETECTION DOMAINS

Planned detection packs

Detection content will be populated progressively as each Purple Team campaign generates real lab telemetry.

ENDPOINT PLANNED

Windows Detection Pack

Process execution, PowerShell, persistence, authentication, service creation and suspicious system activity.

Sysmon Windows Events Sigma Elastic
NETWORK PLANNED

Network Detection Pack

Reconnaissance, suspicious DNS, beacon-like activity, protocol misuse and network indicators generated during lab attacks.

Suricata Wireshark PCAP
WEB PLANNED

Web Detection Pack

Suspicious HTTP activity, exploitation attempts and application behavior captured during controlled web-security scenarios.

HTTP OWASP Elastic
CLOUD PLANNED

Azure Detection Pack

Identity anomalies, suspicious control-plane activity, risky configuration changes and cloud workload security events.

KQL Entra ID Azure Logs Defender
LIBRARY STATUS

Detection coverage

The framework is ready. Detection content will move from planned to validated as the lab campaigns are executed.

LIBRARY // INITIALIZATION

Detection engineering framework established

The repository structure, validation methodology and documentation model are being established before Campaign-01 begins generating endpoint telemetry.

FRAMEWORK READY
ENDPOINT RULES PLANNED
NETWORK RULES PLANNED
CLOUD RULES PLANNED
VALIDATED 00 Detections will only be counted after controlled testing and retest.
DETECTION TEMPLATE

Future detection entries

Each validated detection will eventually have its own technical page using the same engineering schema.

$ detect --validate TXXXX
hypothesis → telemetry → query → test → tune → retest
B13 // DETECTION ENGINEERING Behavior first. Detection second. Validation always.