Logging That Actually Helps an Investigation

After a breach, investigators want to answer a short list of questions. How did the attacker get in? When? Which accounts and systems did they touch? What data did they access or take? Are they still here?

Every one of those answers comes from logs. Organizations that have the right logs can scope an incident precisely, contain it with confidence and give regulators, customers and leadership clear answers. Organizations without them are left guessing, and often have to assume the worst.

Why investigations stall

Common problems responders run into:

• Logs were never turned on. Many systems log little by default, and some detailed logging requires an explicit setting or a higher license tier.
• Logs were overwritten. Local logs roll over quickly. By the time an intrusion is discovered, weeks or months later, the early evidence is gone.
• Logs are scattered. Evidence spread across dozens of systems with different formats and time zones is slow to correlate.
• Clocks disagree. Without time synchronization, sequences of events become unreliable.
• Logs were tampered with. Attackers clear logs to cover their tracks, especially when logs are kept only on the systems they compromise.

The logs that matter most

Identity and authentication. Sign-ins, failed attempts, MFA events, privilege changes, account creation and group membership changes, from directory services and cloud identity providers. Identity logs are often the backbone of an investigation.

Endpoints. Process creation with command lines, PowerShell and script activity, service and scheduled task creation, and security tool alerts. Endpoint detection and response tools provide much of this. These logs reveal living-off-the-land activity that leaves no malware behind.

Network edge. VPN connections, firewall decisions, proxy and DNS logs. These show where attackers connected from and where data went.

Cloud and software as a service. Administrative actions, API calls, configuration changes, and access to storage and data. Cloud audit logs are often off or short-lived by default.

Email. Message traces, mailbox rule changes, and mailbox access, essential for phishing and business email compromise investigations.

Critical applications and data stores. Who accessed sensitive records and when.

What federal policy requires

In August 2021, OMB issued memorandum M-21-31, Improving the Federal Government's Investigative and Remediation Capabilities Related to Cybersecurity Incidents. It defines event logging maturity tiers, from EL0 (not effective) through EL1 (basic), EL2 (intermediate) and EL3 (advanced), and specifies which log types agencies must collect. It also sets retention expectations: for many log categories, 12 months in active storage and 18 months in cold storage. The memorandum makes clear that logs must be available to support investigations, not merely generated.

For defense contractors, DFARS 252.204-7012 requires preserving images of affected systems and relevant monitoring and packet capture data for at least 90 days after reporting a cyber incident, and NIST SP 800-171 includes audit and accountability requirements for systems handling CUI.

Making logs useful

1. Centralize. Send logs to a central platform, such as a SIEM or log analytics service, outside the reach of attackers who compromise individual systems.
2. Synchronize time. Use reliable time sources everywhere and record time zones consistently.
3. Protect integrity. Restrict who can change or delete logs, and use write-once storage or forwarding to a separate environment for critical logs.
4. Retain long enough. Intrusions are often discovered long after they begin. Keep logs for at least as long as policy requires, and longer for the most important sources where you can.
5. Know what normal looks like. Baselines of normal administrative activity make anomalies stand out.
6. Test with real questions. Run exercises that ask investigators to answer the core questions using only the logs you have. Gaps become obvious quickly.
7. Manage cost deliberately. Not every log needs the same treatment. Keep high-value logs searchable, move bulk logs to cheaper storage, and drop noise that will never be used.

From logging to detection

The same logs that support investigations also power detection. Alerts on impossible travel, new administrator accounts, unusual PowerShell use or large data transfers depend on the right data arriving centrally and quickly. Logging and monitoring programs should be designed together.

Frequently asked questions

How long should we keep logs? Follow applicable requirements first. Beyond that, longer retention for identity, endpoint and edge logs pays off, because intrusions are frequently discovered months after they begin.

Is a SIEM required? Some form of central collection and search is essential. The tool matters less than collecting the right data and using it.

What is the first logging gap to close? Often it is centralized identity and endpoint process logging, because they answer the most investigation questions.

How CDT can help

CDT designs logging and monitoring that hold up in an investigation. Our managed security and continuous monitoring services collect and watch the logs that matter, our cyber hunt teams use them to find attackers who evaded alerts, and our incident response team knows exactly which evidence an investigation needs.