Baseline First: What Two Defensive Projects Changed in How I Think About Detection

Why I Built These Projects

This week was driven by a single question: how do defensive systems actually fail in practice? I wanted to move beyond tool familiarity and focus on the mechanics that determine whether detection is reliable, explainable, and worth trusting. That led me to work on two parallel efforts—one focused on telemetry transport and visibility, the other on how detections reason about normal behavior.

Both projects were intentionally scoped to avoid shortcuts. I wanted to see raw data, control the pipeline, and be forced to explain every decision the system made. The goal wasn’t coverage or speed—it was clarity.

What I Expected Going In

Logging Pipeline Assumptions

I expected the Azure logging pipeline to be mostly about configuration and connectivity. Once logs were flowing, I assumed detection would be the hard part. In my head, ingestion felt like a solved problem as long as the platform was supported.

Detection Assumptions

For the baseline engine, I expected the complexity to come from scoring logic. I assumed that once metrics were chosen, anomaly detection would mostly be a tuning exercise.

What Actually Happened

Both assumptions were wrong in useful ways. The logging pipeline repeatedly failed for reasons unrelated to detection logic—deployment structure, packaging decisions, buffering behavior, and payload shape mattered more than expected. Most issues surfaced before a single alert was even possible.

On the detection side, the baseline engine forced an uncomfortable realization: without an explicit definition of normal, anomaly scoring is guesswork. Missing baselines weren’t edge cases—they were the dominant failure mode. Explainability made those gaps impossible to ignore.

• Logging pipelines break more often from deployment and packaging issues than from logic errors
• Control-plane telemetry is high-signal but slower and noisier than expected
• Nested and irregular payloads force early normalization decisions
• Baselines fail silently when training data is insufficient or poorly bucketed
• Explainability exposes weak assumptions immediately

What Worked and What Didn’t

What worked was resisting abstraction. Avoiding vendor add-ons and treating baselines as durable artifacts made the systems easier to reason about, even when they were incomplete. Separating transport, normalization, scoring, and alerting clarified where responsibility actually lives.

What didn’t work was assuming progress equaled correctness. Dashboards with no data, commands that technically ran, and alerts that fired without context all looked fine until I forced known signals through the system. Validation mattered more than implementation speed.

• Raw logs preserved flexibility and investigative value
• Event buffering simplified reliability and testing
• Robust statistics reduced noise but increased data requirements
• Contextual bucketing improved signal at the cost of coverage
• Early validation prevented false confidence

If you can’t explain why an alert fired, you don’t have a detection—you have a guess.

How My Mental Model Changed

I now think of detection as a supply chain problem. Telemetry quality, transport reliability, baseline coverage, and explainability all determine whether an alert is meaningful. Detection logic sits surprisingly late in that chain.

Baselines aren’t just math—they’re operational commitments. If you choose high specificity, you’re also choosing higher data hygiene and longer training windows. If you want explainable outcomes, you must accept reduced coverage.

What I’m Carrying Forward

Going forward, I’m treating baselines and logging pipelines as first-class defensive artifacts. They deserve versioning, validation, and explicit tradeoff documentation. Alerts come last, not first.

These projects reinforced that defensive security isn’t about catching everything—it’s about building systems you can trust when something matters.