Phase 2 · Log Intelligence & Infrastructure Validation
Most organizations manage logs as a cost problem. The question is always how to reduce ingestion volume to fit the SIEM budget. That framing misses what logs actually are — intelligence. Every log source is a collection asset. Every field within a log is a data point that either supports detection, supports investigation, or holds future analytical value. Managing logs as a cost without understanding their intelligence value is the equivalent of cutting reconnaissance assets before an operation to save budget.
The log conversation in most organizations goes like this: the SIEM bill is too high, someone proposes cutting sources that "aren't generating detections," and those sources get removed. What that conversation never includes is a structured assessment of what adversary technique coverage those sources provide, what their investigation value has been in past incidents, and what their potential value becomes if the threat landscape shifts. Decisions made without that analysis are security decisions made without intelligence — and the consequences surface only after the next incident, when the data needed to answer the critical forensic questions isn't there.
Log analysis reveals three separate problems that most programs treat as one. The first: do you have the log source? The second: within that source, do you have the right fields configured for behavioral detection? The third — and the one most programs miss entirely: is the source actually sending what it's supposed to send?
These are not the same problem. A Windows Security Event Log exists but without the correct audit policy configured, you will get authentication events but not process creation, command line arguments, or parent-child process relationships. The log exists. The behavioral detection cannot be built. Solving one does not solve the other. And both are different from the question of whether the log is actually flowing — whether the agent is running, whether the pipeline is intact, whether the data is arriving.
Coverage inventory — what are you collecting at all? This is the floor, not the ceiling. Existence tells you nothing about quality or detection value. Most gap analyses start and stop here.
Field-level analysis — within each source, are the fields needed for behavioral detection configured? Audit policy, log level, verbosity. A source without the right fields is intelligence that cannot be acted on.
Pipeline integrity — agents fail silently. Expected vs. actual log volume. If a critical host stops sending and nobody notices, your detection coverage looks complete on paper while being blind in practice.
Before recommending any log source be cut, three distinct dimensions must be evaluated. Detection value today — which adversary techniques does this source support detecting, at what level of the Pyramid of Pain? Investigation value today — has this source been used as a pivot point in past incident investigations, and what would those investigations have missed without it? Future value — if the threat landscape shifts, if a new adversary technique emerges, if your organization's infrastructure changes, does this source become more valuable?
Each dimension has a different answer. A log source with low detection value may have high investigation value — it may be the data point that allowed analysts to reconstruct the lateral movement path in the last incident. A log source with low current value in both dimensions may become critical in twelve months when a new adversary technique emerges that relies specifically on the events it captures. These are not hypothetical considerations — they are real tradeoffs that require intelligence to evaluate. The cost question comes after the intelligence question. Not before.
The question that changes the conversation: When someone proposes cutting a log source to reduce SIEM costs, the right response is not "we need those logs." The right response is: "Show me the adversary technique that source covers, show me its investigation value in our last three incidents, and show me what our detection blind spot will be if we remove it." That is an intelligence-led conversation. The budget conversation happens after — not instead of — the intelligence conversation.
Your endpoint agent was deployed six months ago. Last Tuesday it silently stopped sending. Your SIEM shows complete coverage because it does not know what it does not know. Three of your critical servers have gone dark, and your detection coverage now has gaps that look complete on every dashboard you have.
Agent health monitoring, expected versus actual log volume tracking, and automated alerting when a source goes unexpectedly silent are not operational niceties — they are fundamental to knowing whether your security program is actually functioning. Without them, your coverage map is a picture of what you intended to collect, not what you are actually collecting. And critically: sophisticated adversaries deliberately suppress logging before they move laterally. An unexpected drop in log volume from a specific host is itself a detection signal — the absence of expected data — but only if you are monitoring for it. Most programs are not.
Your past incident investigations contain the most actionable validation data for your log strategy. Which sources were analysts actually pivoting from during investigations? Which sources were supposed to provide visibility into the attack chain but were absent or incomplete? Which sources provided unexpected value that wasn't anticipated at deployment?
This data — pivot rates, coverage gaps identified during active investigations, sources that answered forensic questions versus sources that were assumed to answer them — should directly inform your log strategy review. It tells you not what you theoretically need, but what has actually mattered when it counted. Organizations that treat DFIR purely as a crisis response function and never mine their investigation data for log strategy intelligence are wasting their most accurate source of ground truth about log value.
The output of thorough log intelligence analysis is a defensible, prioritized log strategy — not a cost reduction plan. For each log source: its detection coverage mapped to specific adversary techniques, its investigation value validated against actual incident history, its field-level completeness assessed against detection requirements, its pipeline health confirmed as active and complete, and its adaptability score against the expected threat landscape over the next twelve to eighteen months. Gaps identified here become requirements that feed directly into detection engineering. Sources confirmed as low-value on all dimensions can be decommissioned with a documented rationale. Everything else is intelligence — and intelligence has a cost that is justified by the risk it addresses.
The reframe that changes the budget conversation: Logs are not a security cost. They are organizational intelligence. The same data that enables behavioral detection of lateral movement also answers IT operations questions, supports compliance auditing, informs capacity planning, and provides the forensic substrate that makes incident response possible. Security teams that fight for log budgets on security grounds alone lose that argument regularly. Frame the value correctly — and the conversation changes.