You're staring at a SIEM dashboard at 2:47 AM. A single metric has spiked — failed SSH attempts, outbound DNS queries, maybe PowerShell execution frequency — and the alert fires. Now, is it an attack? A misconfigured script? The nightly backup running late?
Here's the thing most detection engineering guides skip: an IOC doesn't "occur" because a metric crosses a threshold. An IOC is evidence. The metric crossing its baseline is just the trigger that made you look.
What Is an IOC Really
Indicator of Compromise. Three words that get tossed around like they mean the same thing as "alert" or "signature." They don't.
An IOC is a forensic artifact — a file hash, a domain, an IP address, a registry key, a mutex name — that indicates a specific threat actor or malware family was present. Worth adding: it's retrospective. You find it after something happened, or you hunt for it because threat intel said "APT29 uses this C2 domain Not complicated — just consistent..
But in modern detection engineering, people use "IOC" as shorthand for "anything weird that crossed a threshold." That's not wrong per se — language shifts — but it blurs a critical distinction.
The metric vs. the artifact
When your detection rule fires because "process execution count for powershell.Now, exe exceeds 50 per minute per host," the metric (execution frequency) exceeded its normal bounds (baseline). Which means that's an anomaly. The IOC would be the specific command line arguments, the parent process chain, the downloaded payload hash — the artifacts that let you say "this is Cobalt Strike" or "this is a red team exercise But it adds up..
The anomaly got your attention. The IOCs let you classify, respond, and share.
Why This Distinction Matters
Conflating anomalies with IOCs breaks workflows in three ways That's the part that actually makes a difference..
First, triage paralysis. If every threshold breach gets labeled "IOC detected," your analysts waste cycles enriching noise. "High CPU on server 42" isn't an IOC. "High CPU + XMRig hash + mining pool domain" is.
Second, threat intel pollution. Now, you push "excessive PowerShell" to your TIP as an IOC. That's why other orgs ingest it. Their detection rules fire on legitimate admin activity. On the flip side, confidence scores tank. The feed gets ignored.
Third, response misalignment. Anomaly response is "investigate.Think about it: " IOC response is "block, isolate, hunt laterally. " Different playbooks. Different urgency. Different stakeholders.
How Baseline-Driven Detection Actually Works
Let's walk through the lifecycle of a metric exceeding its bounds — because that's the engine under the hood of most modern detection.
Establishing the baseline
You can't know "abnormal" without "normal." Baselines come in flavors:
Static thresholds — "alert if failed logins > 10/min." Simple. Brittle. The admin scripting a password rotation triggers it every Tuesday.
Rolling statistical baselines — mean + 3 standard deviations over a 14-day window. Adapts to growth. Still assumes Gaussian distribution, which network traffic rarely follows That alone is useful..
Seasonal/behavioral baselines — "this host typically runs 2-5 PowerShell scripts between 9-5 on weekdays, near zero weekends." Captures rhythm. Requires enough history and entity resolution.
Peer-group baselines — "this domain controller behaves like other DCs in the fleet." Great for spotting compromised accounts. Falls apart if the whole fleet is misconfigured the same way Small thing, real impact. And it works..
The trigger moment
Metric exceeds bounds → event generated → enrichment → correlation → alert.
That's the happy path. In practice:
- The metric spikes. The rule fires.
- Enrichment pulls: user, host, process tree, geoIP, threat intel hits, MITRE tags.
- Correlation checks: has this user done this before? Has this host? Is there a matching vuln scan? A recent phishing click?
- Alert drops in the queue. Or doesn't, because the correlation score stayed below threshold.
Where it goes sideways
Baseline drift. The marketing team adopts a new analytics tool that spawns 200 short-lived processes/minute. Your "process spawn rate" baseline slowly absorbs it. Three months later, malware doing the same thing flies under the radar.
Blind spots. You baseline DNS query volume. Attacker uses DNS tunneling with low volume, high entropy. Your metric never exceeds bounds. You miss it.
Cardinality explosion. You baseline "unique destinations per host per hour." Works for 5,000 endpoints. At 50,000, your time-series DB chokes. You downsample. Fidelity drops Surprisingly effective..
Common Mistakes / What Most People Get Wrong
Treating every anomaly as an IOC
We covered this. Day to day, an IOC is an answer. But it bears repeating: an anomaly is a question. Don't file the question in your threat intel platform.
Baseline = "normal" = "safe"
A compromised host behaving "normally" for a compromised host — beaconing every 60 seconds, low volume — won't exceed bounds if the baseline learned that behavior during dwell time. This is the "boiling frog" problem. Fix: periodic baseline reset, or peer-group comparison that flags "this host looks like itself but not like its peers.
One metric to rule them all
"Alert on high entropy.Real detection stacks layers: rare process + network connection + unsigned binary + user hasn't run this before. In real terms, " Single-metric rules generate noise. " "Alert on rare process.The metric exceeding bounds is just one layer.
Ignoring the "so what"
Metric exceeded bounds. Here's the thing — alert fired. Day to day, analyst looks. Because of that, sees "legitimate admin tool. " Closes alert. Why did the admin tool run at 3 AM from a service account? If you don't capture that context in the alert, the next analyst asks the same question. That said, document the rationale for the baseline. Document the expected false positives. Make the alert self-explanatory.
Practical Tips / What Actually Works
Baseline per entity, not globally
"Average failed logins across the org" is useless. Plus, "Failed logins for this service account" catches the brute force. Entity-centric baselines scale with cardinality-aware storage (TimescaleDB, ClickHouse, OpenSearch with composite aggregations).
Use multiple time windows
Short window (5 min) for burst detection. Here's the thing — long (24 hr) for low-and-slow. On top of that, medium (1 hr) for sustained anomalies. A metric can exceed bounds in one window and not others — that pattern is itself signal The details matter here..
Enrich at write time, not read time
Don't make the analyst query VirusTotal, passive DNS, and CMDB from the alert. Enrich the event when the metric breaches. Attach: "this IP appeared in 3 threat
Adaptive Baselines — the “living” reference
Static snapshots quickly become stale as workloads evolve. Techniques such as exponential smoothing, Bayesian updating, or quantile‑tracking (e.g.Also, an adaptive baseline updates its parameters in near‑real‑time, weighting recent observations more heavily while still retaining a memory of longer‑term trends. Consider this: , T‑digest) let the reference line bend with legitimate change and snap back when a true deviation appears. Pair this with a “drift detector” that flags when the underlying distribution shifts beyond a configurable tolerance; at that point the system can either auto‑re‑baseline or raise a separate “baseline‑health” alert, preventing silent failures That alone is useful..
Peer‑group Normalisation
Instead of a single global baseline, compare each entity against a cohort of similar peers. That's why a database server that routinely talks to a handful of internal APIs will look anomalous if measured against a web‑front‑end baseline, even though its behavior is perfectly normal for its class. By aggregating metrics per role, geography, or technology stack, the comparison becomes context‑aware, dramatically reducing false positives while preserving sensitivity to genuine outliers But it adds up..
Multi‑dimensional Scoring
A solitary metric rarely tells the whole story. In real terms, build a lightweight scoring engine that fuses several dimensions—entropy, volume, destination diversity, process lineage, and time‑of‑day—into a composite risk score. Thresholds can be tuned per‑entity, and the score itself can be visualised in dashboards, allowing analysts to see why a particular event crossed the line rather than merely that it did.
Basically where a lot of people lose the thread.
Automated Baseline Review Cycle
Even adaptive baselines need periodic human validation. On top of that, schedule quarterly reviews where a random sample of baselines is inspected for drift, data quality issues, or mis‑aligned entity definitions. On the flip side, automate the generation of baseline health reports that surface metrics such as “percentage of traffic covered by baseline,” “average drift interval,” and “last manual adjustment. ” These reports become the feedback loop that keeps the entire detection stack honest It's one of those things that adds up..
Integration with SOAR Playbooks
When a metric breach occurs, trigger a SOAR (Security Orchestration, Automation, and Response) workflow that automatically pulls in the enriched context—threat intel, asset criticality, recent user activity—and suggests concrete next steps (e.g.Plus, , isolate host, capture memory dump, query external reputation services). By embedding the response directly into the detection pipeline, the time from alert to mitigation shrinks from hours to minutes Most people skip this — try not to..
Measuring Detection Effectiveness
Baselining is only as good as the outcomes it enables. Track key performance indicators such as:
- True Positive Rate (TPR) – proportion of genuine malicious activities correctly flagged.
- False Positive Rate (FPR) – alerts that stem from benign behavior.
- Mean Time to Detect (MTTD) – elapsed time between malicious activity start and alert generation.
- Mean Time to Respond (MTTR) – time from alert to containment.
Regularly review these KPIs, adjust baselines, and iterate on scoring logic. The goal is a virtuous cycle where each detection improvement informs more precise baselines, which in turn sharpen future detection.
Conclusion
Effective baselining is not a one‑time configuration but a disciplined, evolving practice. So by treating baselines as living references, anchoring them to the right entities, and layering multiple time windows and contextual signals, organizations can pierce the veil of low‑volume, high‑entropy attacks that otherwise slip past static thresholds. Avoid the trap of conflating anomalies with indicators of compromise; instead, capture the full context needed to transform a question into an actionable answer. When baselines are per‑entity, enriched at write time, and coupled with adaptive, peer‑aware scoring, the noise diminishes and the signal becomes unmistakable. Now, the ultimate measure of success is not the sheer number of alerts, but the speed and accuracy with which security teams can act on those alerts. In this way, a well‑crafted baselining strategy becomes the foundation upon which a resilient, detection‑first security posture is built.
