Detection Engineering: Turning Logs Into Reliable Alerts

A SIEM full of logs is not a detection program

Most organizations that get breached had the evidence sitting in their logs the whole time. The telemetry was collected, indexed, and searchable. What was missing was a detection that fired on it, a person who saw the alert, and the confidence to act. Buying a SIEM solves the storage-and-search problem. It does almost nothing for the detection problem, because detections are content you build, tune, and maintain — not a switch you flip on.

This is the gap detection engineering fills. A SIEM is a platform; detection engineering is the discipline of writing the logic that turns raw telemetry into a small number of high-fidelity alerts an analyst can trust. Vendors ship a starter pack of generic rules, but out-of-the-box content is written for the average customer, not your environment. It fires constantly on your normal business activity, so analysts learn to ignore it, and the one alert that mattered drowns in the noise. Treating detection as a product you continuously engineer — with sources, code, tests, and metrics — is what separates a working program from an expensive log archive.

Log sources and coverage gaps

Detection quality is capped by the telemetry you feed in. You cannot detect what you do not collect, and most coverage gaps come from missing or misconfigured sources long before they come from weak rules. Before writing a single detection, map what you actually ingest against what attackers actually do. The sources that earn their keep:

• Endpoint (EDR/process telemetry). Process creation, command lines, parent-child relationships, and script execution. This is the single richest source for post-compromise behavior and the foundation most detections lean on.
• Identity and authentication. Sign-in logs, MFA challenges, privilege grants, and directory changes. Identity is the modern perimeter, and account abuse is the most common path in.
• Cloud control plane. API audit logs (CloudTrail and equivalents) that record who did what to your cloud environment. Misconfigurations and key abuse are invisible without them.
• Network and DNS. Firewall, proxy, VPN, and DNS query logs that expose command-and-control, exfiltration, and lateral movement.
• Email and SaaS. The delivery channel for most initial access, plus audit trails for the applications where your data actually lives.

Figure: detection is a pipeline — raw logs are only useful once they are normalized, enriched with context, and matched against tested logic before an analyst ever sees them.

The discipline here is honest coverage assessment. Endpoint agents that are not deployed everywhere, cloud accounts nobody onboarded, and verbose logging that got disabled to save on ingest costs are the blind spots attackers walk through. Audit your sources on a schedule: confirm every critical asset is reporting, that the right event categories are enabled, and that logs arrive within minutes. A detection that depends on a source that stopped reporting three weeks ago is worse than no detection, because it creates false confidence.

Detection-as-code and version control

The teams that scale detection stop clicking rules together in a console and start treating detections the way engineers treat software. Detection-as-code means every rule lives as a text definition — the query logic, metadata, severity, MITRE mapping, and response guidance — stored in Git and deployed through a pipeline. The payoff is concrete:

1. Version control and review. Every change is a pull request with an author, a reviewer, and a history. When a detection starts misbehaving, you can see exactly what changed and roll it back in one commit instead of guessing.
2. Testing before deployment. Rules are validated against sample events — both the malicious activity that should trigger them and the benign activity that should not — so a broken or overly broad rule is caught before it hits production and buries the queue.
3. Reuse and consistency. Detections become modular. A tested piece of logic for suspicious PowerShell can be templated across every relevant data source instead of being rewritten by hand each time.
4. Portability. Logic expressed in a vendor-neutral format (Sigma is the common standard) can be translated to different backends, so your investment survives a platform migration.

Detection-as-code also forces documentation to live next to the logic. Each rule carries what it detects, why it matters, the ATT&CK technique it covers, its known false-positive conditions, and the triage steps for an analyst. That context is the difference between an alert an on-call responder can action at 2 a.m. and one they escalate blindly.

Tuning to cut false positives

False positives are the tax that kills detection programs. When a rule fires on normal activity dozens of times a day, analysts stop reading it — and across the industry a large share of alerts go uninvestigated simply because there are too many. Tuning is not a one-time cleanup; it is continuous engineering. The workflow that works:

• Baseline before you deploy. Run a new detection in monitor-only mode against historical data first. If it would have fired 400 times last month, it is not ready for the analyst queue.
• Tune to the environment, not the alert. Suppress the specific known-good cause — a named service account, a sanctioned admin tool, a scheduled job — rather than raising the threshold until the rule barely fires. Blanket threshold hikes hide real attacks along with the noise.
• Enrich to add context, not volume. Joining an alert to asset criticality, user role, and threat intelligence lets you rank it instead of treating every hit as equal. The same behavior on a domain controller and on a test laptop are not the same event.
• Close the loop with analysts. Every dismissed alert is tuning feedback. Track why alerts are closed as false positives and feed that back into the rule.

The goal is not zero alerts — it is a manageable volume of alerts that are worth an analyst's time. A practical target is that the large majority of what reaches a human is worth investigating. This is exactly the discipline a mature security operations center is built around, and it is why a managed detection and response service that lives in the telemetry every day tunes faster than an internal team that touches the rules once a quarter.

Mapping detections to MITRE ATT&CK

Individual rules tell you nothing about your coverage. Mapping every detection to the MITRE ATT&CK framework — the industry catalog of adversary tactics and techniques — turns a pile of rules into a coverage map. Tagging each detection with the technique it addresses lets you answer the question that actually matters: where are the holes an attacker could walk through undetected?

This produces a heat map of your detection posture across the attack lifecycle — initial access, execution, persistence, privilege escalation, lateral movement, exfiltration. The value is in the honest reading of it:

• Find the gaps. Coverage clusters where telemetry is easy (endpoint execution) and thins where it is hard (persistence, defense evasion). The map makes those blind spots visible so you can prioritize closing them.
• Avoid false confidence. One rule tagged to a technique is not coverage of that technique. Attackers have many ways to achieve the same objective; a single brittle detection covers one variant. Depth matters, not just a green box.
• Prioritize by relevance. Weight coverage toward the techniques used by the threat actors who actually target your industry, rather than chasing every box on the matrix.

ATT&CK mapping also connects detection engineering directly to incident response: when an alert fires, its technique tag tells the responder where in the kill chain they are and what typically comes next.

Measuring detection quality

If you cannot measure your detections, you cannot manage them. A mature program tracks a small set of metrics and reviews them on a cadence:

• True-positive and false-positive rate per rule. Rules with a poor ratio get tuned or retired; noisy rules are a liability, not coverage.
• Mean time to detect and mean time to respond. How long from the malicious activity to the alert, and from the alert to containment. These are the numbers that correlate with breach cost — IBM's Cost of a Data Breach research consistently shows that faster identification and containment lowers the financial impact.
• Coverage against ATT&CK, tracked over time so you can show gaps closing.
• Detection health, meaning the share of rules actively firing on live data versus silently broken because a source changed format or stopped reporting.

Validate all of this adversarially. Purple-team exercises and breach-and-attack simulation run known techniques against your environment and confirm whether the detection you believe exists actually fires. It is common to discover that a rule tagged for a technique never triggers in practice. Testing is the only way to tell real coverage from wishful tagging.

Turning your logs into detections that work

A detection program is a living system: instrumented log sources, detections managed as code, continuous tuning, ATT&CK-mapped coverage, and metrics that prove it works. Standing that up and keeping it current as your environment and the threat landscape shift is ongoing engineering work, not a project that ends.

intSignal builds and runs detection engineering on top of your SIEM and delivers it as a managed detection and response service: instrumented coverage, detection-as-code, relentless tuning, and metrics you can defend to leadership. Talk to our security team and we will show you what your current logging is — and is not — catching today.