What to Do After Suspected System Drift

Direct Answer

Short answer

When you suspect drift, do not start with cleanup. Start with state capture, baseline-aware comparison, and triage. The first objective is to preserve decision quality, not to move fast blindly.

Use a staged workflow: immediate containment and evidence capture, then structured review, then deliberate remediation. This reduces the chance of destroying context or introducing new unknowns. If you need the baseline-first foundation before incident mode, start with How to Know What Changed on Your Linux System.

AI Extract

Key takeaway

• When to use this: unexplained behavior, suspicious persistence signs, post-automation anomalies, or integrity uncertainty before sensitive actions.
• Do now: capture facts and compare against trusted baseline.
• Do next: classify drift and prioritize actions by impact.
• Do not do yet: destructive cleanup before evidence review.
• This page does not claim: guaranteed compromise detection or full incident-response replacement.

Definitions

Shared vocabulary for incident moments

• Suspected drift: unexpected state difference requiring review.
• Trusted baseline: accepted known-good reference.
• Compare evidence: structured delta from baseline to current state.
• Repair planning: explicit, review-gated action planning after evidence analysis.

Checklist

Do now / do next / do not do yet

Do now

1. Capture current state and run compare against the trusted baseline.
2. Record timestamps, affected paths, and command outputs.
3. Pause high-risk actions until trust state is clarified.

auditwalk scan run
auditwalk compare run --format json
auditwalk doctor run --format json

Do next

1. Classify drift into expected, ambiguous, and high-risk buckets.
2. Correlate suspicious findings with recent operator activity, updates, and automation.
3. Create a repair plan only after triage and context checks.

Do not do yet

1. Do not delete artifacts before collecting evidence.
2. Do not reset trust baseline to “make alerts go away.”
3. Do not assume absence of one indicator equals safety.

Evidence Table

Triage by signal class

Limits

Where responders lose signal quality

• Skipping baseline validation makes comparison less trustworthy.
• Jumping to remediation can destroy useful evidence for root-cause analysis.
• Treating one command output as a full security verdict creates blind spots.

Sources

References

• NIST SP 800-137 overview: Continuous Monitoring
• Google Search Central: Helpful, reliable, people-first content
• AuditWalk doctor run, AuditWalk Repair, AuditWalk Troubleshooting