What to Log So an Incident Can Be Reconstructed

A significant share of incident investigations hinges not on the quality of the specialist but on whether there is anything to investigate. The most common sentence on day three of an investigation: "that log is only retained for 7 days." Yet the attacker typically entered weeks earlier.

This article covers what is worth collecting, how long to keep it, and what most organisations omit.

The principle

The goal is not to collect everything. Licensing is typically volume-based, so unnecessary logs cost money while obscuring what matters.

The goal is that after an incident you can answer four questions:

1. How did they get in? Initial entry point, with a timestamp.
2. How far did they get? Which systems were touched.
3. What did they take? Was there exfiltration, and how much.
4. When did it start? Because that determines how far back you must look.

Every logging decision traces back to these four questions.

By source: what to collect

Identity (the most important)

If you can choose one source, choose this. The overwhelming majority of attacks begin with credentials.

• Successful and failed sign-ins, with source IP and device
• Privilege changes, particularly membership of privileged groups
• Password resets and account creation
• MFA challenge outcomes, including denied requests
• Kerberos ticket requests (TGT and TGS), particularly unusual volumes

Endpoint

• Process creation with parent-child relationships. This is the single most valuable data point: it shows an office application spawning a command interpreter.
• Command-line arguments. Off by default, yet without them half the process log is useless.
• Service and scheduled task creation
• Outbound network connections tied to a process

Network

• Firewall allow and deny, with source and destination pairs
• VPN connect and disconnect
• DNS queries. An undervalued source: command-and-control traffic often shows up here first.
• Proxy logs, with outbound data volumes

Application and cloud

• Mail: mailbox rule creation (a classic sign of account takeover), bulk download, delegation
• File shares: large volumes read in a short window
• Administrative operations in cloud services

Retention

Two numbers must be set, and they are not the same.

The 90 days is not arbitrary. Attacker dwell time has been measured in weeks for years, and detection often starts from an external notification, therefore late. With 30-day retention it frequently proves impossible to establish how they got in.

The archive tier can be cheaper, slower storage. It need not be immediately searchable, but it must exist.

What almost everyone omits

Time synchronisation. If device clocks differ, correlation is useless. NTP everywhere, a consistent time zone, ideally logging in UTC. This sounds trivial and is still the most common problem at the start of an investigation.

Alerting on log deletion. An attacker's first act is erasing traces. Deleting logs or disabling logging should itself be an alert, because nobody does it in normal operation.

Copying logs off the host. A log left on the machine is in the attacker's hands. A log copied into the SIEM or separate storage is not. That difference decides whether there is anything to investigate.

Network devices. In many organisations servers are logged while switches, routers and edge appliances are not. Yet attackers enter precisely at the edge.

Your own security tools' logs. EDR, WAF and mail filters all log. These are the densest signal sources, because they are already filtered.

How much data is this

For rough orientation, per user per day:

• Identity: 5-15 MB
• Endpoint (with process logging): 20-60 MB
• Network: 10-40 MB, depending on traffic
• Mail and cloud: 5-20 MB

For a 200-person organisation this is roughly 10-25 GB per day if you collect everything. Hence the importance of prioritisation: identity and endpoint deliver most of the value, while retaining raw network traffic rarely pays back.

Check questions

You need answers to these now, before an incident:

1. If it emerged today that an attacker had been inside for two months, could you say how they got in?
2. Is there a log that an attacker with domain admin rights cannot delete?
3. Do clocks match across key systems?
4. Who receives the alert at three on Sunday morning, and what do they do with it?
5. Have you enabled command-line argument logging?

Wherever the answer is no, that is where to start. We covered SIEM deployment and the first 24 hours of an incident in separate articles, and designing the logging architecture is part of our IT security services.