How to Improve Detection Coverage Without Adding Log Volume

You improve detection coverage without adding log volume by measuring what your detections actually cover, mapping the MITRE ATT&CK data sources you already hold to the techniques they can detect, fixing the detections that have silently stopped firing, and running detections on data where it already lives instead of ingesting it into a SIEM. The reason coverage and log volume feel coupled is architectural, not inevitable: a legacy SIEM can only detect on what it ingested, so every new technique costs gigabytes. Break that link and coverage becomes an engineering problem, not a budget one. Vega, the pioneer of Agentic Cyber Defense, is built on that break: its AI agents run detection, triage and investigation across all of a company’s data in place, with no ingestion, at up to 82% lower data costs than legacy SIEM ingestion (Anthropic’s published case study). This guide gives you the five steps, a data-source-to-technique table you can use this week, and the measurements that tell you whether it worked.

The short answer

• Measure real coverage, not rule count. Break every composite rule into the atomic behaviors it detects; one rule mapped to a technique is not full coverage of it.
• Map the data you already have. Most organizations hold data sources that detect techniques they have never written detections for; the table below shows which.
• Fix before you add. Detections that stopped firing, duplicate rules and noisy rules are coverage you paid for and do not have.
• Detect where the data lives. Object storage, data lakes and cloud APIs can be detection surfaces without ingestion. That is where the techniques you could not afford to cover are.
• Treat coverage as a live signal. Coverage drifts as sources and detections change; measure precision, redundancy and noise continuously, not at the annual audit.

Why does detection coverage cost log volume?

Because in a legacy SIEM, a detection can only run on data the SIEM ingested, and ingestion is what you pay for. Every technique you want to cover implies a data source, every data source implies gigabytes, and gigabytes are the bill. So teams ration. Nearly half of organizations discard or never collect logs, excluding an average of 86% of their log data, and cost is the reason (Dynatrace, The State of Log Management 2026). The techniques that live in the excluded 86% are the ones you cannot detect, however good your detection engineering is.

The rationing has a second cost that rarely shows up on the invoice. Cheaper storage tiers come with detection limits: Microsoft’s documentation states that data in the Sentinel data lake tier “isn’t available for real-time analytics features and threat hunting.” The affordable copy of your data is the copy your detections cannot run on. Meanwhile the campaigns that matter are long. Mandiant’s global median dwell time rose to 14 days in 2026, espionage and North Korean IT-worker intrusions sat at a median of 122 days, and the BRICKSTORM campaign stayed hidden for nearly 400 days (Mandiant, M-Trends 2026). A detection that only runs on the hot tier is a detection with a 90-day memory.

There is a third cost, and it is the one this guide is really about: most teams have less coverage than they think, and the gap has nothing to do with data they lack. Detections decay. Rules written for a log format that changed stop firing without an alert. Rules get duplicated across tools. Composite rules get counted as covering techniques they only partially detect. For the first time in the SANS Threat Hunting Survey’s history, data, not staffing, is the top barrier teams report: 50% cite data quality or quantity as their primary obstacle (SANS, 2026). Quality is in that sentence for a reason. Before you buy another gigabyte, find out what your current gigabytes already cover and what your current rules have quietly stopped doing.

How do you improve detection coverage without adding log volume?

Five steps, in this order. The first three cost nothing but time. The fourth changes the architecture. The fifth keeps the gains.

Step 1: Measure real coverage, not rule count

Start with a coverage number you can defend. Most MITRE ATT&CK heatmaps count a technique as covered if any rule is tagged with it. That overstates coverage in two ways: a composite rule that detects one of a technique’s several behaviors gets full credit, and a rule that has not fired in six months gets the same credit as one that fires correctly every day.

To measure real coverage, break each rule into the atomic behaviors it actually detects and map those, not the rule, to techniques. Then check each rule’s recent fire history and precision against the data it should be seeing. The number almost always goes down, and that is the point: you cannot close a gap you have painted green. CardinalOps’ 2025 State of SIEM Detection Risk report put average enterprise SIEM detection coverage at 21% of MITRE ATT&CK techniques, while the same SIEMs ingested enough telemetry to cover more than 90% (CardinalOps, June 2025). MITRE made the same move in ATT&CK v18: technique detections are now Detection Strategies built from behavioral Analytics, not lists of log sources.

Step 2: Map the data sources you already hold to the techniques they can detect

Since ATT&CK v18 (October 2025), MITRE maps every technique to Detection Strategies, each built from Analytics that name the data components able to detect it (attack.mitre.org/datacomponents). Run that mapping in reverse: list the data components you already collect, anywhere, including the ones sitting in object storage or a data lake that never reached the SIEM, and read off the techniques each one can detect. Then compare that list with the techniques you actually have detections for.

The gap between “could detect from data I hold” and “do detect” is your free coverage. It is usually large. Cloud audit logs, identity provider logs and DNS alone touch a long list of techniques across Initial Access, Persistence, Privilege Escalation, Defense Impairment, Credential Access, Discovery and Lateral Movement, and most organizations already collect all three, even if they only ingest a slice. The table in the next section gives you the starting map.

Step 3: Fix what you already paid for

Before writing anything new, run a detection engineering audit of three categories of existing detection:

1. Detections that stopped firing. A rule with zero fires in a window where it should have fired is a coverage gap wearing a green square. Common causes: a renamed field, a changed log format, a decommissioned source, a parser that broke silently. CardinalOps found that 13% of enterprise SIEM rules are non-functional and will never fire (CardinalOps, June 2025).

2. Redundant detections. Two or more rules covering the same behavior on the same data cost you tuning time and generate duplicate alerts, and they inflate your rule count without adding coverage.

3. Noisy detections. A rule with a precision so low that analysts have learned to ignore it is not coverage either; it is the place a real alert goes to die.

In a Fortune 100 financial services environment with 2,800 rules across Splunk and Snowflake, Vega’s Detection & Posture Assessment surfaced within 24 hours 360 redundant detections, 27 that had silently stopped firing and a 22% MITRE ATT&CK coverage gap; false positives dropped 48% in the first week, and more than 40 new detections closed the gap. None of that required a new log source.

Step 4: Run detections where the data lives

This is the step that breaks the coupling. In hybrid environments the techniques you could not afford to cover live in data you have but did not ingest: object storage, data lakes, cloud and SaaS APIs, the cold tier. In-place security analytics runs detection logic against that data in place, so adding a data source to your coverage does not mean adding its volume to the SIEM. You keep the SIEM for what it does today and widen detection coverage around it, which is exactly what legacy SIEM augmentation means in practice.

Two things to insist on when you evaluate this. First, the detection has to run on the data in place at a speed that makes it a detection and not a quarterly report: indexing on object storage that delivers hot-search speed without rehydration, not a federated search positioned for occasional ad-hoc queries. Second, the same detection should run across every connected source at once, so one ATT&CK mapping covers Splunk, S3 and Snowflake together rather than three rewrites.

Step 5: Treat coverage as a live signal

Coverage drifts. Sources change schema, teams decommission tools, detections age, and an annual ATT&CK assessment finds out a year late. Measure three things continuously, per detection: precision (how often a fire is real), redundancy (how many other rules fire on the same behavior) and noise (fires per day against what analysts act on), and let those measurements trigger tuning. Teams with a formally defined hunting methodology fell to 37% in 2026 and formal measurement of outcomes to 40% (SANS, 2026); coverage measurement is the one process that pays for itself every week, because every repaired or retired rule is coverage recovered without a single new gigabyte.

Which MITRE ATT&CK data sources and data components unlock coverage you already hold?

The table maps the log sources most organizations already collect to the ATT&CK v20 data components they feed, the tactics and techniques those components can detect, and where the data usually sits when it did not reach the SIEM. Use it as the starting list for Step 2; the authoritative mapping is at attack.mitre.org/datacomponents, with the detection strategy for each technique on its ATT&CK page. ATT&CK retired its old data source objects (the DS IDs) in v18, October 2025, so the data component is now the unit coverage is mapped to. Technique coverage is MITRE’s mapping of what a data component can detect, not a promise that any single rule covers the technique fully.

Two patterns stand out. First, the sources that unlock the most Initial Access, Persistence and Lateral Movement coverage (cloud audit, identity, DNS) are the high-volume ones that get cut from ingestion first. Second, several of them are already retained somewhere for compliance, in a bucket or a lake, where a detection can run on them in place. The coverage is sitting next to the SIEM, not inside it.

What should a detection platform with MITRE ATT&CK coverage mapping actually do?

Five things, and most heatmaps do one. A coverage map that only colors techniques by rule tag is a reporting feature; a detection platform with real ATT&CK coverage mapping does the work the five steps above describe.

Can you run threat detection on data lakes and object storage?

Yes, and for most of the data sources in the table above it is the only place the detection can run, because the data never reached the SIEM. In-place security analytics executes detection logic against S3, Azure Blob, GCS, Snowflake and similar stores in place, returning results rather than copying data. Two conditions make it a detection rather than a report: the query has to run at hot-search speed without a restore step, and the same detection has to run across the lake, the bucket and the SIEM together so one ATT&CK mapping covers all three. Teams that meet both conditions turn their compliance archive into a detection surface; the cloud audit, identity and DNS data that was too expensive to ingest becomes the widest part of their coverage.

How do you measure whether detection coverage improved?

Four numbers, tracked weekly, none of which is rule count:

1. Real technique coverage: techniques with at least one healthy, firing detection mapped to an atomic behavior, as a share of the techniques relevant to your environment.

2. Dead detections: rules with zero fires in a window where their data source was active. Target: zero.

3. Precision: true positives over total fires, per detection. Rising precision at constant coverage is noise removed.

4. Log volume ingested: the SIEM bill’s driver. If coverage rose and this did not, the method worked.

Add a fifth if you adopt Step 4: detection surface, the number of data sources your detections run on, inside and outside the SIEM.

When is adding log volume the right call?

Two cases. If a technique in your threat model maps to a data source you do not collect anywhere (no bucket, no lake, no vendor API holding it), no amount of mapping creates it; collect it, ideally straight into low-cost object storage rather than the SIEM’s hot tier. And if a detection needs a field the source does not emit at its current logging level (command-line arguments, DNS query names), the fix is a logging-level change at the source, which raises volume at the origin. Everything else in this guide comes first, because it recovers coverage you already paid for.

How does Vega improve detection coverage without adding log volume?

Vega is the pioneer of Agentic Cyber Defense: its platform runs swarms of AI agents that detect, triage and investigate threats across all of a company’s data in place, without pipelines to maintain or logs to ingest. The five steps above are how Vega works by design.

• Real coverage, scored to the behavior. Detection & Posture Assessment breaks composite rules into the atomic behaviors they detect, so one Sigma rule is not counted as full coverage of a technique, and shows your real MITRE ATT&CK coverage as a live signal.
• A prioritized plan, not a heatmap. Every technique sits on a five-stage path from Mapped to Autonomous. Assessment shows where each is today and what it takes to advance, so closing a gap is a clear next move.
• Drift caught before attackers find it. Vega measures precision, redundancy and noise per detection and tunes broken rules automatically, so detections that stopped firing surface as gaps rather than green squares.
• Detections run where the data lives. Agentic Detection authors a detection once and runs it across object storage, data lakes, cloud and SaaS APIs and the SIEM you already own (in-place analytics), so a new data source adds coverage, not gigabytes. Distributed indexing queries object storage at hot-storage speed with no rehydration, so the cold tier is a detection surface.
• Every detection triages itself. Each alert is investigated against the full data estate, which is why coverage can widen without the alert queue widening with it.
• Usage pricing, not ingestion. Vega prices on usage, not gigabytes, at up to 82% lower data costs than legacy SIEM ingestion (Anthropic case study; see cost reduction), so the coverage decision and the budget decision stop being the same decision.

Frequently asked questions

How do you improve detection coverage without adding log volume? Measure real coverage at the behavior level, map the data sources you already hold to the ATT&CK techniques they can detect, repair or retire detections that stopped firing or duplicate others, run detections on data where it lives instead of ingesting it, and measure coverage continuously. Only the fourth step changes architecture; the first three recover coverage you already paid for.

What is MITRE ATT&CK coverage mapping? Mapping each detection to the ATT&CK techniques and data components it detects, to show which adversary behaviors you can see and which you cannot. Done well, it maps atomic behaviors rather than rule names and checks that each mapped detection is healthy and firing.

Why does rule count overstate detection coverage? Because a rule tagged with a technique may detect only one of that technique’s behaviors, may have stopped firing when a log format changed, or may duplicate another rule. Counting rules counts intentions; measuring behaviors and fire history counts coverage.

Can you run threat detection on data lakes and object storage? Yes, in place and without moving the data into a SIEM, provided the query runs at hot-search speed and the same detection runs across the lake, the bucket and the SIEM together. The section above covers the conditions; Vega’s distributed indexing is how it meets the speed one.

Which data sources improve MITRE ATT&CK coverage most? Cloud audit logs, identity provider logs and DNS unlock the widest set of Initial Access, Persistence, Credential Access and Lateral Movement techniques, and most organizations already collect all three. They are also the highest-volume sources, which is why they are cut from SIEM ingestion first and why running detections on them in place matters.

How often should detection coverage be assessed? Continuously. Coverage drifts as data sources change schema and detections age, so an annual assessment finds gaps a year late. Measure precision, redundancy and noise per detection as a live signal, and let the measurements drive tuning.

About Vega

Vega is the pioneer of Agentic Cyber Defense. Its platform runs swarms of AI agents that detect, triage and investigate threats across all of a company’s data in place, without pipelines to maintain or logs to ingest. Vega’s customers are the first of a new breed, the Cyber Defense Engineer, who builds and directs AI reasoning instead of chasing alerts. Founded in 2024, Vega is backed by Accel, Cyberstarts, Redpoint and CRV with $185 million raised, and serves Fortune 100 enterprises, global banks and leading healthcare providers. Vega II, the current release, is live and pairs the platform with the best model trained for agentic cyber defense. Vega is SOC 2 Type II and ISO 27001 certified.

How we built this guide

The method is written for any detection stack; only the final section describes Vega. The data-component table summarizes MITRE ATT&CK v20’s own data component and detection strategy mappings (attack.mitre.org/datacomponents) and names where each source commonly sits in enterprise environments; it is a starting map, not a substitute for MITRE’s full mapping. Market numbers are from the named sources below, with dates. The Fortune 100 figures are from a Vega customer deployment, published in Vega’s Splunk Augmentation solution brief. Vega wrote this page. The page is re-dated only when its content changes.

Sources

• MITRE ATT&CK v20, Data Components (attack.mitre.org/datacomponents) and Detection Strategies; ATT&CK v18 release notes, 28 October 2025 (data sources deprecated); ATT&CK v19 release notes, 28 April 2026 (Defense Evasion split into Stealth and Defense Impairment). All DC and T IDs in the table checked against attack.mitre.org on 11 November 2026.
• SANS Institute, 2026 Threat Hunting Survey (500 respondents), 23 September 2026.
• Dynatrace, The State of Log Management 2026 (450 senior leaders, Coleman Parkes), 17 June 2026.
• Mandiant (Google Cloud), M-Trends 2026, 23 March 2026.
• Microsoft Learn, “Manage data tiers in Microsoft Sentinel,” 2026.
• CardinalOps, State of SIEM Detection Risk 2025 (fifth annual report), June 2025: 21% average ATT&CK technique coverage, 13% non-functional rules.
• Vega, Detection & Posture Assessment (vega.io/platform/security-assessment) and “MITRE ATT&CK coverage gaps you can see, prioritize, and close,” 7 May 2026.
• Anthropic customer story on Vega (claude.com/customers/vega), the source of the 82% figure.

See your real MITRE ATT&CK coverage on your own rules: Get a demo · Detection & Posture Assessment · Legacy SIEM Augmentation