Log Source Onboarding: How to Prioritize What Gets Ingested Into Your SIEM

Every log source decision involves two variables: detection coverage value (how many meaningful detections does this source enable) and ingestion cost (what volume of data does it produce and how much does it cost to ingest, store, and query).

High-coverage, low-cost sources belong in every SIEM. Authentication logs, DNS query logs from a resolver, and Windows Security Event Log from domain controllers are examples: relatively compact data volume with high detection signal for authentication abuse, lateral movement, and command-and-control activity.

High-coverage, high-cost sources require selective deployment. Endpoint telemetry from EDR agents is highly valuable for process-level detection but can produce enormous volume from large endpoint fleets. Deploy with aggressive filtering at the collector, not at the SIEM, to ingest only the events that contribute to active detection rules.

Low-coverage, high-cost sources are the budget problem. Full packet capture, verbose application debug logs, and unfiltered firewall flow logs can consume enormous SIEM capacity while contributing minimal detection coverage. These belong in a cheaper long-term storage tier, not in the expensive interactive query tier.

Low-coverage, low-cost sources are the tricky category. They are cheap to ingest but may not be worth the parser development and maintenance overhead. Apply the standard: does at least one production detection rule depend on this source? If no, it does not belong in the SIEM regardless of cost.

Regardless of environment size or SIEM budget, the following log sources represent the minimum coverage floor. Organizations that have not ingested all five of these sources have critical blind spots in attack path detection.

Authentication logs from your identity provider (Active Directory, Okta, Azure AD) are the highest-value single data source in most environments. Failed and successful logons, MFA events, account lockouts, and privileged role assignments all flow through the authentication layer. Lateral movement, credential stuffing, and account takeover are all visible here if the logs are present and parsed correctly.

DNS query logs from your internal resolver are essential for command-and-control detection. Beaconing malware, DNS tunneling, and DGA domain lookups all appear in DNS query logs. Without this source, C2 communications can traverse the network indefinitely with no detection surface. Collect from the resolver itself, not from endpoint DNS client logs, to ensure complete coverage regardless of endpoint agent status.

Endpoint process execution logs from your EDR or Sysmon deployment cover the technique-level detail that authentication and network logs cannot provide. Process creation with command-line arguments is the single most useful data type for identifying attacker tools, living-off-the-land execution, and persistence mechanisms.

Cloud control plane logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) cover the administrative actions an attacker takes after compromising cloud credentials. API calls, IAM changes, S3 bucket policy modifications, and compute instance creation are all recorded here. This source is free to enable in all three major cloud providers and is often not ingested by default.

Firewall and proxy logs for outbound connections provide the network-level view that endpoint logs complement but cannot replace. Connections from systems where EDR is not deployed, traffic to unusual destinations, and high-volume outbound transfers are visible in firewall logs when endpoint visibility does not exist.

A log source roadmap converts the coverage-cost analysis into a sequenced plan with owners, timelines, and success criteria. Without a roadmap, log source onboarding happens reactively when someone notices a detection gap or when an incident reveals missing telemetry.

Step 1: Inventory current sources. Produce a complete list of all log sources currently ingesting into the SIEM, with current daily volume per source, active detection rules per source, and the last-verified date that the source is actually forwarding.

Step 2: Map to MITRE ATT&CK. For each source, identify which ATT&CK tactics it contributes detection coverage for. Use the MITRE ATT&CK data sources page as a mapping reference. Produce a heat map showing which tactics have coverage and which are blind spots.

Step 3: Identify tier-one gaps. Cross-reference the coverage map against the tier-one source list above. Any tier-one source not present is an immediate priority regardless of cost.

Step 4: Sequence remaining sources by coverage-cost ratio. For sources beyond tier one, rank by the number of ATT&CK techniques covered divided by estimated monthly ingestion cost. Prioritize the highest-ratio sources first.

Step 5: Assign owners and timelines. Each source requires an owner on the infrastructure or platform team that manages the source system, and an integration engineer on the security team who will write and validate the parser. Without both owners, the project will stall.

A log source with a broken or incomplete parser is worth almost nothing regardless of how much data it produces. Detection rules depend on normalized field names, and an alert that fires on a raw string match instead of a structured field is brittle and expensive to maintain.

Before declaring a log source onboarded, validate the parser against the following: all key fields are mapped to normalized schema fields (timestamp, src_ip, dst_ip, user, action, result), the parser handles all common event types from that source without producing null or unparsed records, and at least one detection rule is actively firing on correctly parsed events from the source.

Timestamp normalization is the most common parser failure. Logs from different sources arrive with different timestamp formats and time zones. A source whose timestamps are not normalized to UTC will corrupt your timeline analysis during incident investigations. Validate timestamp normalization before signing off on any new source.

Cardinality validation is worth running for high-volume sources. Check that the distribution of values in key fields (usernames, IP addresses, process names) matches expected environmental patterns. A parser that silently drops the username field for certain event types will produce detection gaps that are not obvious from log volume metrics.

Log source removal is the cost management lever that most security teams never pull. Sources onboarded during a compliance push, a vendor proof-of-concept, or a one-time incident investigation persist in the SIEM indefinitely because no one owns the decision to remove them.

A source removal review should happen quarterly. The decision criteria are: Does this source have any active production detection rules that depend on it? Has this source contributed to a confirmed true-positive alert in the last 90 days? Is there a higher-coverage alternative that renders this source redundant?

If the answer to all three is no, the source should be removed from the interactive SIEM tier and either archived in cold storage or removed entirely. The cost saving from removing high-volume, low-value sources can fund the onboarding of a tier-one source that was deferred due to budget.

When a source is removed, document the decision: which source, why it was removed, and who approved the decision. If a future incident reveals that the removed source would have provided relevant evidence, this documentation provides the context needed to evaluate whether the removal decision was correct.