Logging Without a SIEM: The Small-Business Detection Baseline

Most small businesses do not find out they were breached by reading their own logs. They find out when a customer calls, when the bank flags fraud, or when an extortion note lands in the inbox. By the time an incident responder asks for the evidence, there is usually none worth reading: Windows kept a few days of defaults, the firewall overwrote its buffer last Tuesday, and nothing was ever being copied somewhere an attacker could not also delete.

The frustrating part is that this is a solved problem, and the fix is mostly free. It does not get solved because almost all of the advice assumes you already run a SIEM and have an analyst watching it. You do not, and you are not going to buy one this year. So here is the version for the rest of us: what to actually log, how long to keep it, and where to put it, using tools that cost nothing or close to it.

Who this is for, and who can skip it

If you already have a managed SIEM, a detection engineer, and alerting you have tested, none of this is news and you can close the tab. This is written for the 20-to-200-person company whose entire logging strategy is whatever Microsoft and the firewall vendor left switched on by default. That is the band where one compromised laptop becomes a domain-wide ransomware event, and where the only question that matters afterward - what did the attacker touch, and when - has no answer because nobody was recording.

Logging will not stop an attack. What it buys you is the ability to answer that question in hours instead of never, to scope a breach instead of rebuilding every machine on suspicion, and to satisfy a cyber-insurance carrier or a customer contract that increasingly demands you retain security logs at all. The joint international guidance CISA co-signed, Best Practices for Event Logging and Threat Detection, says the quiet part out loud: default retention is usually too short, and the logs you most need are the ones covering privileged accounts and critical systems like domain controllers. Almost nobody collects those by default.

Start where the attacker lands: Windows

Most intrusions against a small business touch a Windows endpoint or server within minutes. The default audit policy tells you a machine exists and not much more. Before you spend a dollar, turn on the audit categories that earn their keep. Microsoft publishes the full baseline in its Audit Policy Recommendations; the short list that matters on a small network:

The audit categories worth enabling

• Logon and Account Logon - successful and failed sign-ins (Event IDs 4624, 4625, 4768-4776). This is how you catch password spraying and a stolen credential being reused at 3 a.m.
• Process creation with the command line (4688 with command-line auditing on) - the single highest-value Windows log for spotting an attacker living off the land with built-in tools.
• User and group management (4720, 4728, 4732, 4756) - a brand-new admin account, or a user quietly added to Domain Admins.
• Object access on the shares that hold your real data - scoped to those shares, not every file on the network, or you will bury the signal you came for.

You can push these through a Group Policy object once you are happy with them. To test on a single machine first, set them directly from an elevated prompt:

:: Enable the high-value Windows audit categories (run elevated)
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable

:: Record the full command line with every 4688 process-creation event
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" ^
    /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Then add Sysmon, the free Sysinternals tool. Sysmon records process creation with file hashes, network connections, and file and registry changes to its own dedicated event log, and since early 2026 it ships as a built-in optional feature on Windows 11. Pair it with a maintained community ruleset and you get endpoint forensics that rival paid EDR for after-the-fact reconstruction, at no license cost:

:: Install Sysmon with a maintained community config (run elevated)
sysmon -accepteula -i sysmonconfig.xml

:: Confirm it is recording to its own channel
wevtutil gl "Microsoft-Windows-Sysmon/Operational"

One caution: Sysmon with a wide-open config is a firehose. Start from a curated ruleset that filters the routine noise, or the volume will make centralizing it later more expensive than it needs to be.

Your cloud is already logging - go turn it on and pull it

For most small businesses, the data that would actually hurt to lose does not live on a server in a closet. It lives in Microsoft 365 or Google Workspace: the email, the files, the identities. The good news is that those platforms already log almost everything. The trap is that the records age out fast and nobody is exporting them.

Microsoft 365 keeps a unified audit log that is on by default for enterprise tenants, but per Microsoft's audit log documentation, non-E5 licenses retain those records for only 180 days, and E5 for a year. If you have ever had to prove how a business-email-compromise actor got in, 180 days is the difference between a clear answer and a shrug. Two moves close most of the gap.

The Microsoft 365 logging moves

• Confirm the unified audit log is on and that a named person holds the Audit Logs role, so the data exists and someone can actually pull it.
• Export the events that matter - sign-ins, inbox rule creation, OAuth app consent grants, and admin role changes - on a schedule, into storage you control, so they outlive the retention window.

# Confirm the unified audit log is enabled
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Pull the two events that catch most business-email-compromise:
# attacker-created inbox rules and rogue OAuth app consents
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -Operations "New-InboxRule","Set-InboxRule","Consent to application" |
    Export-Csv .\m365-bec-signals.csv -NoTypeInformation

Inbox rule creation and new OAuth consent grants are the two events that surface the majority of business-email-compromise cases, because that is how the attacker keeps reading mail and keeps access after the password reset. If you log nothing else in the cloud, log those two.

Put the logs somewhere the attacker cannot reach

A log that only lives on the machine that generated it is evidence the attacker deletes on the way out. Centralizing is the whole game: a compromised host cannot rewrite history that already left it. The network sources worth forwarding alongside your Windows and cloud events are the boring, high-yield ones - firewall allow and deny at the perimeter, VPN authentication, and internal DNS queries, which catch the command-and-control callouts the endpoints sometimes miss.

You do not need Splunk to collect any of this. Two no-cost paths cover most small businesses.

The free centralization options

• Windows Event Forwarding (WEF) - built into Windows, free, and agentless. Point your endpoints at one collector server and subscribe to the Security and Sysmon channels. No third-party software on the endpoints at all.
• CISA Logging Made Easy - CISA rebuilt and re-released LME as a no-cost, self-hosted log management and threat-detection stack aimed squarely at organizations with limited resources and no security team. It bundles collection, storage, and dashboards, and its install guide even walks you through deploying Sysmon.

:: On the collector server: enable the Windows Event Collector service
wecutil qc /q

:: On every source host (push this via GPO once tested):
winrm quickconfig -q
:: then create a source-initiated subscription for the Security
:: and Microsoft-Windows-Sysmon/Operational channels

On retention, keep security-relevant logs for at least a year if you can spare the disk, and treat 90 days as the absolute floor. Disk is cheap; the inability to reconstruct an intrusion that started four months ago is not. If you want a structured, vendor-neutral way to decide which sources to prioritize as you grow, CISA's Guidance for SIEM and SOAR Implementation lays out an ingestion-priority order you can follow long before you own an actual SIEM.

Pick three log sources and start centralizing

You will not do all of this in a week, and you should not try. Pick the three sources that map to how a real attack on your business would actually unfold: Windows sign-ins and process creation, Microsoft 365 inbox-rule and consent events, and firewall plus VPN authentication. Turn them on, forward them to one collector you control - Windows Event Forwarding or CISA's Logging Made Easy - and set retention to a year. That single step moves you from learning about a breach from a customer to learning about it from your own data.

The commands are the easy part. The hard part is deciding what is worth watching and then keeping it running after the project that turned it on is over. That is the part we do every day. Red Hound helps small teams stand up proportionate logging and detection - the right sources, centralized cheaply, with the handful of alerts that actually warrant a phone call - and reviews what you already collect for the gaps an attacker would walk through. If your current logging strategy is whatever shipped switched on, this is the conversation to have before the incident, not during it.