log sources that matter for incident response
A guide to the log sources that matter most for incident response: authentication, EDR, DNS, firewall and proxy, email gateway, and cloud audit trails, plus retention and coverage checks. Use when building logging coverage or preparing for investigations. Triggers: 'log sources', 'what to log for IR', 'incident response logging'. Not for: log pipeline engineering or SIEM query writing.
log sources that matter for incident response
TL;DR
You cant investigate what you didnt log. The sources that solve most incidents are auth logs, EDR telemetry, DNS, firewall and VPN records, email gateway logs, and cloud audit trails. Get these six into one place with at least 90 days retention and you can answer nearly any "what happened" question.
log sources that matter for incident responseUse this when
- you are building or auditing logging coverage before an incident happens
- an investigation stalled because a key log source was missing
- leadership asks what logging the security program needs
- you are deciding what goes into the SIEM first on a limited budget
Not for this skill when
- you need help writing detection queries (that is a different skill)
- you are architecting the log pipeline itself (forwarders, parsing, storage tiers)
- the question is about application debug logging, not security telemetry
- you need compliance-specific retention rules (check with counsel)
Steps
- Collect authentication logs: your identity provider, Active Directory, and VPN. They answer who logged in, from where, with what result. This is the source that answers "how did they get in" for most incidents.
- Collect EDR telemetry: process execution, file writes, and network connections per host. It answers what ran on the box. If you can only afford one paid security tool, this is usually the one.
- Collect DNS logs: every domain resolved by your resolvers. DNS answers the command-and-control question even when the traffic itself was encrypted, because the lookup happens in the clear.
- Collect firewall and proxy logs: connections allowed and blocked, URLs visited. They answer what moved where, which is how you scope data exfiltration.
- Collect email gateway logs: inbound mail with headers, attachments, and URLs. They answer the phishing-entry question: who got the message, who clicked, what came in.
- Collect cloud audit trails: CloudTrail and its equivalents on other clouds. Every management API call is recorded. They answer what changed in the cloud and by whom.
- Check your coverage for blind spots. Find hosts that stopped sending logs:
index=edr
| stats latest(_time) as last_seen by host
| sort last_seen
| head 20Expected: hosts at the top went quiet longest ago. Any host whose last_seen is more than an hour old is a blind spot to fix before the incident, not during it.
- Set retention: 90 days hot and searchable, a year in cheap storage. Most incidents are discovered weeks after they start, and "the logs aged out" is a painful sentence to say in a postmortem.
- Test the whole thing. Pick a past incident and confirm you can reconstruct it end to end from the logs. If you cant, fix the gap now while it is cheap.
Variant: log sources for a SaaS-heavy shop
When everything lives in SaaS, the priority list shifts: SaaS admin audit logs first (who changed what in each app), then identity provider logs, then CASB or proxy records of SaaS usage. Endpoint EDR still matters for the laptops.
Variant: log sources for container workloads
Add the orchestrator audit log (who deployed what), container runtime events, and image registry pull logs. Containers are ephemeral, so ship these logs off the host in real time or they vanish with the pod.
Variant: log sources when you have no EDR
Fall back to OS-native telemetry: Sysmon on Windows, auditd on Linux, unified logs on macOS. It is noisier and harder to query than EDR, but it answers the same "what ran" question.
Why this happens
Investigations stall when logs are missing, scattered across consoles, or already rotated away. Centralization plus retention is the whole game: every "what happened" question is really "which log answers this, and do we still have it."
Edge cases and pitfalls
- Log volume costs real money. Sample or filter the noisiest sources, but never auth logs and never EDR.
- Clocks must be synced. If hosts drift, your timeline lies to you. Enforce NTP everywhere and note the time zone on every timestamp.
- Privacy rules may limit what you can log in some regions. Document what you cant collect so nobody assumes it exists.
- Forwarders break silently. The coverage check in step 7 should run on a schedule, not just once.
- Dont log credentials or tokens into these sources. Scrub them at collection time or your log platform becomes the juiciest target you own.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstYmR91IC34_BlqjQMTNw0Q
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.