How it works

Each stage below is implemented. The pipeline is the shape of the engine rather than a diagram drawn afterwards, and every stage records enough for the next one to be explained.

Observation

GURDN reads interfaces, addresses, routes, resolvers, Wi-Fi association, VPN presence and firewall profile through the Windows APIs that own them. A background thread subscribes to the change notifications Windows publishes for interfaces, addresses and routes, and polls on an adaptive interval as a safety net.

Windows publishes no notification for resolver, firewall or wireless security changes, so those are found by polling. The window in which a change can be missed is therefore milliseconds for the notified surfaces and the polling interval for the rest, and a change that starts and finishes inside that window is not seen.

Every observation records whether it was collected, partly collected or unavailable, and why. Monitoring is itself monitored: a stalled or failing collector degrades the verdict instead of leaving the last good answer on screen.

Normalisation

Readings are converted into a stable internal shape, so that comparing two observations does not depend on formatting, ordering, or how Windows happened to phrase something on a particular build.

Baseline

Networks are remembered by a fingerprint built from the interface kind, the wireless network name, the gateway address and the gateway hardware address read from the neighbour table. The baseline is what that network looked like last time, so a change is judged against that network rather than against a universal idea of normal.

Where the gateway address cannot be resolved, the fingerprint rests on signals a nearby attacker can forge. GURDN reports the identity as weak rather than claiming it recognised the network.

Diff and correlation

Snapshots are diffed into typed changes, grouped into transitions, correlated, and recorded as coalesced events. Correlation is the step that makes the product useful: four ordinary changes arriving together are a different fact from four ordinary changes spread across a week.

Detection

Eleven rules evaluate each cycle against the baseline, the trust level of the network and what else changed at the same time. Every rule records a machine-readable decision, including when it could not decide and which inputs were missing. No rule concludes that an attack is under way, because no local observation establishes that.

Findings are kept separate from events. They merge on recurrence, resolve when the condition stops holding, and can be acknowledged or suppressed with a recorded reason, scope, expiry and evidence digest.

Trust and policy

Trust is what GURDN knows about a network from previous encounters, including the decision you made about it. A new network is never trusted by default, so the first connection to a hostile network is judged more strictly rather than less. Policy then decides what GURDN may propose and what it must ask about before acting.

Authorisation, response, verification, recovery

These have their own pages: authorisation, the response engine, verification and recovery.

Audit

What was observed, decided, authorised and done is recorded locally. Each entry digest covers the previous entry digest, so an edited or removed entry breaks the chain, and GURDN reports the first entry that fails to verify rather than declaring the whole record untrustworthy. Entries written before schema version 3 carry no chain digest and are skipped rather than reported as tampered.

This detects tampering. It does not prevent it: an attacker with write access to the machine has already won, and GURDN does not claim otherwise.