Fingerprint Drift

Scope

Drift matters because it changes the environment people think they are operating. This public guide keeps the practical operating interpretation and strips private implementation detail.

Step-by-step guides for policy setup, drift response, and baseline management.

Verified against code as of 2026-03-18 (USS Titan remediation).

Related documents: - Architecture: docs/architecture/fingerprint-drift.md - Functional: docs/functional/fingerprint-drift.md - Alert management: docs/manual/alerts-monitoring.md

Creating a Fingerprint Policy

• name (unique per org)
• enabled_categories: choose from 21 built-in categories
• check_interval_hours (default 24, minimum 1): how often to check for drift
• drift_alert_severity (default “warning”): override computed severity
• auto_resolve_after_clean_runs (default 3): consecutive clean checks before auto-resolve acknowledged drift

• Optional config_watchlist: file/registry paths to hash-compare

• Tier 1 (critical): services, listening_ports, local_accounts, domain_status, network_interfaces

• Tier 2 (warning): dns_config, firewall_status, scheduled_tasks, security_status, certificates, config_watchlist, custom_scripts, environment_variables, startup_programs, network_shares
• Tier 3 (info): patched_packages, disk_space, system_info, outbound_connectivity, printers, processes

Assigning Policies to Hosts

Capturing a Baseline

• Dispatches a fingerprint_check job to the agent
• Creates or replaces the host’s baseline
• Automatic capture: hosts with a policy but no baseline are auto-captured (up to 20 per sweep)

Responding to Drift Events

• Only from open status (attempting to acknowledge a non-open event returns 400)
• Acknowledged events auto-resolve after auto_resolve_after_clean_runs consecutive clean checks
• Only from open or acknowledged status
• The current fingerprint becomes the new baseline
• Drift event resolved, corresponding alert resolved
• Only from open or acknowledged status
• For when an operator has fixed drift externally (e.g., reimaged host) and doesn’t want to wait for the next clean check
• Resolves the corresponding event alert
• Only from open or acknowledged status
• Suppressed events stay in alerts (not auto-resolved) — use for known/expected drift that should remain visible
• Bulk operations (UI): Select multiple drift events via checkboxes and bulk-acknowledge or bulk-resolve

Auto-resolve behavior: - Open drift events: auto-resolve on the next clean check - Acknowledged drift events: auto-resolve after N consecutive clean checks (configurable per policy) - Suppressed events: NEVER auto-resolve (must be manually resolved or accepted)

Understanding Severity Mapping

Drift severity is computed from the highest-tier change detected: - Critical: new local account added, service removed, domain status changed, new low-port listener, firewall disabled - High: service changed, local account privilege changed, network interface removed/state changed - Medium: DNS config changed, scheduled task changed, security status changed, config watchlist changed - Low: disk space change, outbound connectivity change, informational data changes

Policy tier_overrides can reclassify any category to a different tier.

Managing Drift Corrections

Drift corrections are available in the Corrections tab at Security > Baselines (requires fingerprints.view).

1. View corrections: Table showing host, category, action, status, triggered/completed timestamps
2. Filter: By host, organization, status, category, or search text. Host and correction search run server-side so matches are complete across paged data.
3. Retry failed corrections: Click retry on failed or pending records (requires fingerprints.manage)
4. Detail view: Expand a correction to see drift summary (rendered with StateDiffViewer), dispatched jobs, and outcomes. Host group name is resolved (not shown as raw ID).

If dashboard summary, organizations, policies, Hosts, Drift Events, or Corrections loading fails, the page shows an inline error banner with a Retry action so operators can recover without losing context.

Correction status lifecycle: - pending: Jobs dispatched, waiting for completion - in_progress: Some jobs completed, others still running - completed: All jobs succeeded — a follow-up fingerprint_check is automatically dispatched to verify the fix worked - failed: One or more jobs failed — no follow-up check; operator can retry

Auto-Accept for Informational Drift

When a drift correction policy has auto_approve: true, Tier 3 (informational) drift events are automatically accepted as new baselines without operator intervention. This only applies when ALL changed categories are Tier 3 (e.g., disk_space, printers, processes). Mixed-tier drift always requires manual review.

Triggering Workflows on Drift Events

Fingerprint drift events fire unified event alerts via the event alert adapter (event_source="fingerprint_drift"). To trigger automated workflows on drift detection:

1. Create an alert rule with event_source = "fingerprint_drift"
2. Configure the rule to trigger a workflow or runbook
3. The alert rule system supports filtering by severity, host group, and other criteria

This allows integration with the automation/workflow engine for automated escalation, change request creation, or remediation runbook execution.