Better Windows ServicesAuditing Windows services
An audit is not a list of what is on the machine. It is the difference between what is on the machine and what was supposed to be - and nothing on a stock Windows records the second half.
Three questions, and what answers them
What changed since this machine was built?
A snapshot taken at deployment, and a diff against the machine tonight. Configuration is reported apart from what merely started or stopped, so the one start type somebody changed is not buried under forty services that happen to be running.
bws snapshot diff baseline.json --live
Why does staging differ from production?
Take a snapshot on each and diff the two files - anywhere, without either machine present. The files carry the machine name and the account that took them.
bws snapshot diff staging.json production.json
What is on here that should not be?
Queries that find the shapes worth looking at: a service whose binary is gone, one that is not signed, one running although it is disabled, one asking for debug rights.
file:missing, signed:no, mismatch:running
The nightly shape
# the day the machine goes into service
bws snapshot create C:\baselines\web01.json --note "after the build"
# every night, from a scheduled task
bws snapshot diff C:\baselines\web01.json --live --exit-code --json > C:\logs\drift.json
# 0 - nothing differs
# 5 - something differs, and drift.json says what
# 3 - it ran and could not read everything, so the answer is partialExit code 5 is what makes this an audit rather than a report nobody reads: the task is silent until the machine drifts, and the night it does, somebody is paged.
Take the baseline from an elevated session. Without administrator rights the manager lists fewer entries and refuses more of what it lists. The snapshot records whether the account that took it was an administrator, so the comparison can say that rather than reporting entries as removed that nobody removed - but a baseline missing half the machine is still a baseline missing half the machine.
What a snapshot is worth in evidence
- It is JSON with one field per line, so it goes into a repository and
git diffreads it. An auditor who does not have this tool can still read the file, and a version control system already answers when. - It holds what the snap-in never showed: the launch path and arguments, the hash and signer of the file, the dependencies both ways, the triggers, the required privileges, the SID type and the security descriptor.
- It says what it could not read. A field this session had no rights to is recorded as not read - never as empty - so a later comparison can say not compared instead of quietly calling it unchanged.
- It is a description of the whole machine. File it accordingly: it is written with whatever permissions its directory already has, and the tool narrows nothing.
What this does not give you
Worth knowing before you build a process on it.
- It does not say who. The event log is not read yet. A baseline and a diff answer what changed and roughly when it was noticed, not which account did it.
- There is no stock Windows baseline. Which of these are not from a clean install is not counted, so the baseline has to be one you took.
- There is no restore. A diff tells you what drifted, and putting it back is by hand or by script from the commands the diff shows you.
- One machine at a time. There is no remote management - the answer for a fleet is a snapshot per machine, collected however you already collect files.