RECOVERED vs VERIFIED

Why this distinction gets skipped under pressure

Once a service starts responding normally again, the immediate pressure to restore business operations tends to override the slower, more deliberate work of confirming that the actual root cause was found and fixed, not just that the symptom went away.

What verification actually involves

Checking file integrity against a known-good state, confirming no unauthorized accounts or scheduled tasks were left behind, and reviewing logs for the specific mechanism that allowed the incident, rather than assuming a restart or restore fixed everything.

For how verification fits into a complete recovery, see our server breach incident response guide.

How Server Warden separates the two states

On the product page, Server Warden describes a closed loop: observe, detect, correlate, contain, recover, verify. The page states the rule directly: a restart or a rollback is not proof. VERIFIED is earned only after independent checks of health, hashes, listeners, firewall, identity and checks specific to the scenario that was run.

The Security Lab shows the same idea in a timeline that moves through detected, correlated, recovered and verified, with a Recovery Proof and evidence behind it. Its explanation is simple: a command can succeed and the server can still not be back to normal, so separate checks of the files, services and network involved in that incident run after the action. Only when those pass does the result become VERIFIED.

One point the Lab is explicit about: every run on that page is synthetic. No host is probed, nothing on any machine is restored, and enforcement is reported as observed rather than achieved. It demonstrates the model; it does not assess your server. For that, the site offers the free read-only audit.

Checking the same things by hand

On any server you can approximate the same categories of check. CISA's incident response playbook says recovery should include enhanced vigilance to confirm that no signs of adversary activity remain, and suggests considering an independent test or review of the response activity. Some starting points:

debsums -c
rpm -Va
ss -tulpn
awk -F: '($3 == 0) {print $1}' /etc/passwd

The first two compare installed package files with their recorded checksums (Debian family and RPM family respectively). Be aware that the debsums manual page itself calls the tool of limited use as a security tool: an attacker with root can alter files and the records together, and files outside packages are not covered. A rebuild from a trusted image, or file integrity monitoring with a baseline stored elsewhere, is stronger evidence.

The third lists listening sockets to compare with what you expect; the fourth is the UID 0 check. Add a review of every account's authorized_keys, the active firewall ruleset and scheduled tasks. If any check fails, the incident is not closed: contain again and return to analysis.

Related terms: Incident response, Containment, File integrity monitoring, Read-only audit.