24.5.4 Recovery procedures

The Four Phases of AI System Recovery

A structured recovery process prevents premature service restoration, which can lead to reinfection or further data compromise. We can break the process down into four distinct, sequential phases. Each phase must be completed and verified before proceeding to the next.

Phase 1: System Restoration

This phase is purely technical and focuses on bringing systems back online in a clean, isolated environment from a known-good state. Do not reconnect the system to the public internet or production networks at this stage.

• Infrastructure Restoration: Rebuild servers, containers, and services from “golden image” snapshots or infrastructure-as-code (IaC) templates. These must be from a point in time before the incident occurred.
• Model Rollback: Revert the deployed model to a previously validated and trusted version. Your MLOps pipeline should maintain a versioned model registry (e.g., using MLflow, DVC, or a cloud provider’s registry) to facilitate this. Never attempt to “clean” a potentially compromised model artifact.
• Data Integrity Checks: Restore databases and data stores from backups. After restoration, run cryptographic hash checks against a known-good manifest to ensure data files have not been tampered with.

# Pseudocode for validating a restored data snapshot
            
# Manifest created before the incident
known_good_manifest = {
    "user_profiles.csv": "sha256:abc123...",
    "transaction_data.parquet": "sha256:def456...",
    "product_images/": "sha256:ghi789..." # Hash of the directory contents
}

# Function to run after restoring from backup
function validate_restored_data(restored_path):
    for file, expected_hash in known_good_manifest.items():
        current_hash = calculate_hash(restored_path + file)
        if current_hash != expected_hash:
            print(f"CRITICAL: Hash mismatch for {file}!")
            # Trigger alert and halt recovery
            return False
    
    print("All restored data hashes match the manifest.")
    return True

Phase 2: Security Hardening

Before the system handles any production traffic, you must apply the fixes identified during the eradication phase. Restoring the system without hardening it is an invitation for a repeat incident.

• Patch Vulnerabilities: Apply all relevant security patches to operating systems, libraries (e.g., tensorflow, scikit-learn), and application code.
• Rotate Credentials: Invalidate all credentials associated with the compromised system. This includes API keys, database passwords, service account tokens, and user passwords.
• Strengthen Controls: Implement enhanced security configurations. This could mean stricter firewall rules, more granular IAM policies, or adding input validation and sanitization to the model’s API endpoint to prevent prompt injection.

Phase 3: Functional Validation & Monitoring

Here, you verify that the restored and hardened system is both secure and functional. This is a critical quality assurance step before full resumption.

• Performance Baselining: Test the system under a simulated load. Compare key metrics (latency, accuracy, error rates) against pre-incident baselines to ensure the model and infrastructure are performing as expected.
• Targeted Adversarial Testing: Conduct a focused, mini red team exercise to specifically test the vulnerability that was exploited. If the incident was a data poisoning attack, for example, attempt a similar poisoning technique in the staging environment to confirm your new defenses are effective.
• Monitoring Dry-Run: Observe the system’s logs and alerts in the isolated environment. Ensure your newly implemented monitoring rules are firing correctly and that there is no anomalous activity.

Phase 4: Full Operational Resumption

Only after the first three phases are successfully completed can you begin reintroducing the system into the production environment.

• Gradual Rollout: Instead of a “big bang” switch-on, use a canary release or blue-green deployment. Initially, route a small percentage of traffic (e.g., 5%) to the restored system.
• Intensive Monitoring: Closely watch performance dashboards, security alerts, and model behavior metrics as traffic increases. Look for any deviation from the expected norm.
• Stakeholder Communication: Following the communication plan, formally notify all stakeholders—including end-users, if applicable—that the service has been fully restored.
• Trigger Post-Mortem: Formally initiate the post-incident review process to capture lessons learned. The recovery phase is complete, but the incident lifecycle is not.