You do not need a SIEM to investigate an incident. You need the right logs switched on, kept for at least six months, protected from tampering and searchable without logging in to each machine.
The six categories below are our own grouping and not a standard. They rearrange the three tables in the NCSC introduction to logging for security purposes and add application logging from the OWASP guidance, plus Microsoft 365 detail from Microsoft's documentation.
Start from the questions
Choose log sources by the questions you will be asked in the first hours of an incident. The NCSC frames them broadly: what has happened, what is the impact, what should we do next, has remediation worked, and are our security controls working. Its tables break these into concrete questions, such as who has logged in remotely out of hours, or whether anyone has clicked a given link. If you cannot say which question a log serves, it comes later.
The minimum set
| Source | Question it answers | Where it comes from |
|---|---|---|
| Identity and remote access | Who logged in, from where, at what time? Were there failed attempts on internet-facing services? | Active Directory, LDAP, ADFS, VPN, remote desktop and VDI logs |
| Who received a message like this one, and who clicked the link? | SMTP servers, MS Exchange, mail scanning appliances, cloud provider APIs | |
| Endpoints and servers | Was this binary run, does this file exist, did anything odd happen on a host? | Windows EVTX, Syslog, Microsoft Sysmon, host agents |
| Firewall, DNS and proxy | Is any system talking to a suspect IP or domain? | Firewall or netflow logs, DNS logs, web proxy logs |
| Web server and application | What did the user do and what was the outcome? | Application code, web server |
| Assets and changes | Which device had this IP, what changed, who owns this server? | DHCP, router, firewall and switch logs, a CMDB |
Some details change what you collect. On the firewall, the NCSC says captured logs should account for Network Address Translation, so that you record both the internal and the external IP. DNS logs show the domain a user clicked but not the full URL, so treat them as a weaker substitute where you have no web proxy.
Host agents, including the free Microsoft Sysmon, can produce process information, DNS lookup events, file system changes and file hashes. They only cover what someone has installed and configured them on, so shadow IT, network devices, unsupported operating systems and hosts where malware has disabled the agent stay dark.
Web server logs are not application logging. The application knows the user's identity, roles and the outcome of an action, and infrastructure devices often do not.
Microsoft 365
If you use Microsoft 365, check Microsoft Purview before buying anything. Audit (Standard) is enabled by default for organisations with the appropriate subscription. You still have to assign permissions to search it, in the Purview portal or with the Search-UnifiedAuditLog cmdlet in Exchange Online PowerShell.
Standard keeps records for 180 days. Records generated before 17 October 2023 kept only 90. Audit (Premium) retains Microsoft Entra ID, Exchange, OneDrive and SharePoint records for one year by default.
Premium also provides the SensitivityLabel property on the MailItemsAccessed activity in Exchange Online. Users need a Premium licence for the system to generate those events, so settle licensing before an incident.
Retention and protection
The NCSC recommends a minimum of 6 months for logs that answer your incident questions. It adds that M-Trends 2018 put average detection time at 101 days, so keep longer if budget allows.
Local logs can fall short of this without anyone noticing. Open each one and read the date of the oldest entry. If it is younger than six months, the log may be too small or too busy to meet your target, so check the configured size or retention setting too.
Anyone who breaks in has a reason to alter the logs, so give the logging service the same care as any admin interface. Ask who can read the logs, who can write to them, and whether you would see a change. OWASP gives concrete measures for application logs:
- Put file-based logs on a separate partition from the operating system and user-generated content, with strict permissions on directories and files.
- Keep logs out of web-accessible locations. If that cannot be avoided, restrict access and serve them as plain text rather than HTML.
- When logging to a database, use an account used only for writing log data, with very restrictive permissions.
- Use a standard event format over a secure transport, such as the syslog message format over TLS.
Centralise only where it pays
The NCSC treats centralised and decentralised logging as a real choice. A central store means you do not visit each machine during an investigation, and it becomes more useful with every source added. Leaving logs in place works when they are already searchable and held long enough. Cloud mail services are the NCSC's example, where extraction rarely justifies the cost.
For a small team, a sensible split is to centralise endpoint, server, firewall and VPN logs, and leave well-served cloud services where they are. On Windows, Windows Event Forwarding sends logs from clients to a central store securely.
The NCSC also warns that a decentralised model can slowly degrade. Give someone the recurring task of confirming that each source is still producing logs, and write down who that is.
Where to start
- Take the concrete questions from the NCSC tables, such as who logged in remotely out of hours, or has anyone clicked this link. For each, name the system that would answer it.
- For every source, record where it is stored, how long it is kept and who can read or change it. Raise anything under six months.
- Check the defaults. If a source logs minimal detail, change the configuration to capture more. In Microsoft 365, confirm Audit is on and assign search permissions.
- Forward endpoint, server, firewall and VPN logs to one store with restricted write access, using Windows Event Forwarding or syslog over TLS.
- Run a drill: pick a suspect IP address and a phishing subject line and try to answer the questions from the logs alone. Fix the source where you got stuck first.
- If you cannot run the drill in-house, ask an incident response team or a managed security provider to help.
