Baselines & Presets

A baseline is just a list of which settings are on. This page shows the ready-made lists we ship, how to build your own, and which one to pick. In a hurry? Use spydi_Workstation_Minimal for Windows 10/11 and spydi_Server_Minimal for everything server-shaped, and come back later.

The model

The settings table (LoggingBaseline.Settings.ps1) is the single source of truth: every channel, audit subcategory, registry value and SMB audit setting, each with a plain-language purpose, a tier, a scope, behaviour category tags and - where it matters - a volume/stability risk note.

Everything else is a selection of that table:

Selection mechanism	When to use
Tier switches (-IncludeHighVolume, -IncludeOptional)	Fastest route to the recommended baseline
A selection CSV from New-LoggingBaseline.ps1	Per-setting control, per-role baselines, review in Excel/git
A shipped preset (presets\*.csv)	Start from a published reference baseline

One selection drives everything: Enable, Test, the Intune pack, the WEF subscription, the GPO pack and the ATT&CK coverage report all accept the same -BaselineFile.

Tiers

Tier	Default	Contents
Core	applied	everything with low or justified volume
HighVolume	ask first	process creation + command line, PowerShell script block + module logging, WFP connections, sensitive privilege use
Optional	ask first	PowerShell transcription, Crypto-DPAPI debug channel, IPsec Driver auditing

The split exists so volume decisions are made by a human with the impact in front of them - Export-AttackCoverage.ps1 quantifies what the HighVolume tier buys (117 additional ATT&CK techniques over Core: 162 -> 279 of the 284-technique native ceiling; see the mapping page).

Building a baseline

.\New-LoggingBaseline.ps1

Walks every item: recommendation shown as the default (Enter accepts), risk notes in yellow, a accepts defaults for the rest of a section, t shows the baseline tree - every item's include/exclude state plus a per-category coverage count, with uncovered categories in red. The output CSV is plain text: flip Selected between Y/N in Excel, commit it per server role, and you have reviewable, versioned logging baselines.

Audit any CSV later:

.\New-LoggingBaseline.ps1 -Show -BaselineFile .\FileServerBaseline.csv

Shipped presets

presets\ contains published reference baselines expressed as selections, faithful to the scripts in Yamato's EventLog-Baseline-Guide:

Preset	Source	Items selected
ASD.csv	Australian Signals Directorate	25
Microsoft_Client.csv	Microsoft client OS recommendation	15
Microsoft_Server.csv	Microsoft server OS recommendation	17

Faithfulness limits (stated, not hidden): the kit applies its own Success/Failure flags and channel sizes, which superset the references in places (one exception: ASD sizes Security at 2 GB versus the kit's 1 GB); five ASD subcategories cannot be expressed because Yamato's own baseline excludes them (Process Termination, Group Membership, and the SACL-dependent File System / Kernel Object / Registry). The presets are regenerated by tools\New-PresetBaselines.ps1 and CI fails if the committed CSVs drift from the settings table.

WELA's matching -Baseline names (ASD, Microsoft_Client, Microsoft_Server) serve as the independent verifier for these presets.

Per-role presets

The kit's recommended starting point per host role - Core plus the high-value items that role can afford, with every hold-back justified by the settings table's own Risk notes. These are starting points pending pilot volume data, not final answers: run the pilot week, check the numbers, and adjust your copy.

Preset	Selection	Observable techniques
role_Workstation.csv	Core + process creation/cmdline + script block logging + WFP connections; DC-only items deselected	265 of 472 mapped = 93% of the 284 native ceiling
role_MemberServer.csv	as Workstation, without WFP connections	263 of 472 = 93% of ceiling
role_DomainController.csv	as MemberServer, plus the DC-scope subcategories	273 of 472 = 96% of ceiling

The reasoning per decision (volume and behaviour characterisations come from the settings table's Risk notes, themselves sourced from Microsoft's advanced audit policy documentation and the Yamato guide):

Item	Wks	Member	DC	Why
Process creation + command line	✓	✓	✓	Highest single detection value; volume scales with process churn - watch RDS/build hosts in the pilot
Script block logging (4104)	✓	✓	✓	Moderate volume, de-obfuscated code, generally safe fleet-wide per its Risk note
WFP connections (5156/5157)	✓	-	-	Client connection volume is modest; documented High volume on connection-heavy servers and DCs
Module logging (4103)	-	-	-	The heaviest setting in the kit; opt-in after a pilot, everywhere
Sensitive Privilege Use	-	-	-	Known to flood with backup agents; opt-in per server role after a pilot
DC-scope subcategories	-	-	✓	Only generate events on domain controllers
Optional tier (transcription, DPAPI debug, IPsec Driver)	-	-	-	Situational by definition

Usage is identical to any baseline CSV:

.\New-LoggingBaseline.ps1 -Show -BaselineFile .\presets\role_Workstation.csv
.\Enable-LoggingBaseline.ps1 -BaselineFile .\presets\role_MemberServer.csv -WhatIf
.\New-IntuneRemediationPack.ps1 -BaselineFile .\presets\role_Workstation.csv -OutDir .\Intune\Workstation

To customise a role, copy the CSV, flip Selected values in Excel, and keep your copy in version control - the shipped presets are regenerated from the settings table and CI rejects drift, so edit copies, not the originals.

spydi baselines - the blended recommendation

The spydi_* presets blend the four references this kit tracks - ASD, Microsoft Client, Microsoft Server and Yamato - into one opinionated pair of axes: role (Server covers servers, domain controllers and WEF collectors in one preset, with DC-only items runtime-gated; Workstation covers Windows 10/11) and volume (Minimal vs Heavy). The one picture that shows what you're choosing between:

Each arrow is the decision: what you add, by event ID, when you step up a tier.

Preset	Observable techniques (native ceiling 284)
spydi_Workstation_Minimal.csv	263 of 472 = 93% of ceiling
spydi_Workstation_Heavy.csv	269 of 472 = 95%
spydi_Server_Minimal.csv	273 of 472 = 96%
spydi_Server_Heavy.csv	279 of 472 = 98% - the full native reach

Every group traced to its sources (A = ASD, C = Microsoft Client, S = Microsoft Server, Y = Yamato) and key events - and for the full per-setting breakdown with real Minimal/Heavy membership per item, see the Reference page:

Group	Key events	Refs	Minimal	Heavy
Channels sized + enabled (kit Core set)	4104, 7045, 104, task/WMI/Defender logs	Y (A sizes Sec/Sys/App)	✓	✓
Account logon + Kerberos (DC)	4776, 4768/4769/4771	A,C,S,Y	✓	✓
Account and group management	4720-4767, 4727-4764	A,C,S,Y	✓	✓
Logon/logoff set	4624/4625/4648, 4634, 4672, 4778/4779	A,C,S,Y	✓	✓
Policy change + system set	4719, 4706, 4616, 4697, 5038	A,C,S,Y	✓	✓
Process creation + command line	4688	A,C,S,Y	✓	✓
Script block logging	4104	A,Y	✓	✓
IPsec Driver	4960-4963, 4965, 5478-5485 (per Microsoft)	C,S	✓	✓
DS Access/Changes (Server preset; DC-gated)	4662, 5136	S,Y	✓	✓
NTLM + SMB (2025) auditing	8001-8004, 3021/3022, 31998/31999	Y, Microsoft docs	✓	✓
WFP connections	5156/5157	Y	-	✓
Sensitive privilege use	4673/4674	Y	-	✓
Module logging	4103	A	-	✓

Notes, stated plainly:

• Minimal is the deploy-with-confidence set: everything unanimous plus the three highest-signal additions. Heavy accepts real volume for the last stretch of coverage and richer content (4103 command output, network flow context) - pilot Heavy on one host per role first, per the safety page.
• Module logging appears only in Heavy, on ASD's authority - it is the kit's heaviest setting.
• Selection CSVs carry item choices, not sizes: the Security log stays at the kit's 1 GB (ASD suggests 2 GB; raise it in LoggingBaseline.Settings.ps1 if you take that view).
• A GPO pack generated from a spydi_Server_* preset includes the DC-only subcategories. They are inert on member servers and collectors (those events only generate on DCs), but if your GPO hygiene prefers clean scoping, generate per-OU packs from a copy with the DC rows flipped to N. Enable/Test/Intune gate these at runtime automatically; WEF subscriptions are channel-only and unaffected.
• The ASD subcategories the kit cannot express (Process Termination, Group Membership, SACL-dependent File System/Kernel Object/Registry) are the same ones listed under the ASD reference preset above.
• Sources beyond the four: ASD's 2024 joint Best practices for event logging and threat detection validates this set at the practice level (PowerShell logging, command line capture, centralised collection); NIST SP 800-92 / CSF and CIS Benchmarks are governance or licence-restricted comparisons, cited rather than vendored; a DISA STIG preset is a roadmap candidate (public domain, subcategory-level).

Deviations from the Yamato sources

A handful of deliberate differences from the upstream scripts, each with a reason. Everything else is faithful.

Item	Yamato/WELA does	This kit does	Why
RestrictSendingNTLMTraffic	WELA configure sets 2 (Deny all)	1 (Audit all)	2 blocks outgoing NTLM, which is enforcement and can break connectivity. Logging change only.
AuditNTLMInDomain	WELA sets 2	7 (audit all, DC only)	7 is Microsoft's documented "enable all" value for this setting.
PowerShell policy registry paths	Batch writes only Wow6432Node	Both native and Wow6432Node paths	Group Policy writes the native path; 64-bit PowerShell reads it. Both paths cover both host bitnesses.
PrintService/Operational	Batch sizes it but never enables it	Enabled	The log is disabled by default; sizing a disabled log records nothing.
AD CS AuditFilter	WELA restarts CertSvc automatically	Sets value, warns, never restarts	Service restarts belong in a change window, not a script side effect.
Other Policy Change Events	Guide text says leave off (5447 noise); both Yamato scripts enable it	Enabled (Core), noise note attached	Follows the scripts; drop it if 5447 floods after the pilot week.

WELA's configure command is deliberately never called by the kit: it prompts interactively, restarts CertSvc itself, and sets the NTLM deny value. All changes go through Enable-LoggingBaseline.ps1.