Backup Security

---
name: backup-security
description: "Expert routing agent for backup security. Covers ransomware protection, 3-2-1-1-0 rule, immutable backups, air-gapped vaults, and backup verification. Routes to Veeam, Rubrik, Cohesity, and Commvault agents. WHEN: \"backup security\", \"ransomware recovery\", \"immutable backup\", \"air-gapped backup\", \"3-2-1-1-0\", \"backup encryption\", \"cyber vault\", \"backup testing\", \"RTO RPO\", \"clean restore point\". Do NOT use for vendor-specific questions -- use the `veeam`, `rubrik`, `cohesity`, or `commvault` skill."
license: MIT
---

# Backup Security

This skill covers backup security: data protection strategy, ransomware resilience, and secure backup architecture. It points to platform-specific sibling skills for product-level implementation and provides cross-platform concepts and strategy directly.

## How to Approach Tasks

When you receive a request:

1. **Identify scope** -- Is this conceptual (strategy, framework, rules) or product-specific (Veeam config, Rubrik policy, etc.)?

2. **Classify the request type:**
   - **Framework/Strategy** -- Apply 3-2-1-1-0, RPO/RTO, backup architecture directly
   - **Ransomware recovery** -- Load `references/concepts.md`, apply ransomware recovery workflow
   - **Product-specific** -- Read the appropriate sibling skill below
   - **Audit/Assessment** -- Load `references/concepts.md`, evaluate against best practices

3. **Load context** -- Read `references/concepts.md` for fundamental backup security knowledge.

4. **Recommend** -- Provide actionable guidance with specific configurations and verifiable outcomes.

## Technology Agent Routing

Read the sibling skill when the user specifies a product or platform:

| Platform | Route to | Trigger Keywords |
|---|---|---|
| Veeam Data Platform | `veeam` | "Veeam", "VBR", "Veeam Backup & Replication", "hardened Linux repository", "SureBackup", "Secure Restore" |
| Rubrik Security Cloud | `rubrik` | "Rubrik", "CDM", "Rubrik Cloud Data Management", "Polaris", "Rubrik Security Cloud" |
| Cohesity DataProtect | `cohesity` | "Cohesity", "DataProtect", "FortKnox", "DataLock", "SpanFS" |
| Commvault Cloud | `commvault` | "Commvault", "CommServe", "Metallic", "HyperScale X", "Cloud Rewind", "Cleanroom Recovery" |

When no specific product is mentioned, provide vendor-neutral guidance and note product-specific options.

## Core Backup Security Concepts

### The 3-2-1-1-0 Rule

The evolution of the classic 3-2-1 backup rule:

| Component | Requirement | Purpose |
|---|---|---|
| **3** | Three copies of data | Redundancy -- one primary + two backups |
| **2** | Two different storage media types | Media failure diversity (disk + tape, or disk + cloud) |
| **1** | One copy offsite | Geographic resilience (disaster, site outage) |
| **1** | One immutable or air-gapped copy | Ransomware resilience -- cannot be deleted/modified |
| **0** | Zero errors in verified restores | Confirmation backups are actually usable |

The "0 errors" requirement is often overlooked. Untested backups have an unknown recovery probability.

### Immutable Backups

Immutability means backup data cannot be modified or deleted for a defined retention period, regardless of credentials or privileges.

**Implementation approaches:**

| Method | Mechanism | Vendors |
|---|---|---|
| Hardened Linux repository | SSH-less, single-use creds, `chattr +i` filesystem immutability | Veeam |
| Immutable filesystem | Custom filesystem rejects writes/deletes from all interfaces including admin | Rubrik |
| S3 Object Lock | WORM governance/compliance mode on S3-compatible storage | Veeam, Commvault, Cohesity |
| Azure Immutable Blob Storage | Time-based retention policies on blob containers | Veeam, Commvault |
| DataLock WORM | SpanFS-level immutable snapshots | Cohesity |
| Tape (WORM media) | Physical write-once media | Any product with tape support |

**Governance vs. Compliance mode (S3 Object Lock):**
- Governance: Privileged users with `s3:BypassGovernanceRetention` can override
- Compliance: No one, including root, can delete before retention expiry

For ransomware protection, use **compliance mode** or hardware-enforced immutability.

### Air-Gapped Backups

Air gapping isolates backup data from production networks to prevent ransomware reaching it via network paths.

**Physical air gap:** Media (tape, RDX, external disk) physically disconnected and stored offsite. Highest isolation; manual process.

**Logical air gap:** Automated isolation via:
- Cloud cyber vaults (Cohesity FortKnox, Commvault Cloud Rewind target)
- Veeam Object Storage with immutability + separate credentials
- Rubrik archive tiers with access-controlled cloud credentials
- Network-isolated backup infrastructure with firewall-enforced segmentation

**Critical requirements for logical air gap:**
- Credentials for the isolated copy must NOT be accessible from production infrastructure
- Management plane for the isolated copy should be separate from production management
- Ideally, no persistent network path from production to the vault (connect only during scheduled backup windows)

### Ransomware Recovery Workflow

When ransomware is confirmed or suspected:

1. **Isolate infected systems** -- Disconnect from network immediately. Do not power off (preserves memory forensics). Contain blast radius.

2. **Identify the infection timeline** -- Determine when encryption began. Ransomware typically dwells for 2-6 weeks before detonation. Look for:
   - Anomaly detection alerts from backup platform (Rubrik, Cohesity DataHawk)
   - File entropy analysis
   - Backup anomaly reports

3. **Identify a clean restore point** -- Find the last backup created BEFORE the dwell period began, not just before detonation. Restoring to just before encryption may restore a still-infected system.

4. **Scan backups for malware** -- Before restoring, scan backup data:
   - Veeam: Secure Restore (mount and scan with AV engine)
   - Rubrik: Threat Hunting (YARA rules, IOC scanning)
   - Cohesity: CyberScan (automated vulnerability/malware scanning)
   - Commvault: Cleanroom Recovery (isolated restore environment)

5. **Restore to a clean environment** -- Restore to isolated network segment, not directly back to production. Verify system behavior before reconnecting.

6. **Verify data integrity** -- Confirm restored data is complete and uncorrupted. Check application functionality.

7. **Reconnect and harden** -- Patch the initial access vector before returning to production. Review backup infrastructure for signs of compromise.

### Recovery Objectives

| Metric | Definition | Design Considerations |
|---|---|---|
| **RPO** (Recovery Point Objective) | Maximum acceptable data loss (in time) | Determines backup frequency. RPO = 4h means backup every ≤4h |
| **RTO** (Recovery Time Objective) | Maximum acceptable downtime | Determines recovery technology. Minutes = instant recovery; hours = traditional restore |
| **RTTO** (Recovery Time Test Objective) | How long it takes to TEST recovery | Often ignored; must be < RTO or testing is impractical |

**Technology alignment:**
- RPO minutes / RTO minutes: Replication + instant VM recovery (Veeam Instant Recovery, Rubrik Live Mount)
- RPO hours / RTO hours: Disk-to-disk backup with local repository
- RPO days / RTO days: Tape or deep archive (disaster recovery tier)

### Backup Encryption

**At-rest encryption:**
- AES-256 standard for backup data encryption
- Hardware-based (self-encrypting drives) vs. software-based (backup application)
- Key management: Encryption keys must NOT be stored on the same system/repository as the backup data

**In-transit encryption:**
- TLS 1.2+ for all backup data in motion
- Verify certificate validation is enforced (not self-signed bypass)

**Key management principles:**
- Use a dedicated key management system (HashiCorp Vault, AWS KMS, Azure Key Vault)
- Implement key rotation policies
- Test decryption with the current keys as part of backup verification
- If ransomware encrypts your backup encryption keys, recovery is impossible

### Backup Infrastructure Attack Surface

Attackers specifically target backup infrastructure because eliminating backups forces ransom payment.

**Attack vectors to protect:**
- Backup server OS (patch, harden, minimal software)
- Backup console credentials (MFA, least privilege, 4-eyes authorization)
- Repository credentials (use dedicated service accounts, rotate)
- Network paths to repositories (firewall, VLAN isolation)
- Backup encryption keys
- Cloud storage credentials for offsite copies

**Hardening principles:**
- Dedicate backup infrastructure -- no general-purpose workloads on backup servers
- Implement MFA on all backup console access
- Use 4-eyes authorization for destructive operations (deletion, disabling jobs)
- Monitor for unusual backup deletions, job disabling, or policy modifications
- Keep backup software patched (backup servers are high-value attack targets)

### Backup Verification

Unverified backups have unknown recoverability. Verification approaches:

| Method | What It Tests | How Often |
|---|---|---|
| Checksum validation | Data integrity during backup write | Every backup job |
| Mount/instant recovery test | Data is readable and mountable | Weekly or per policy |
| Application-level test | Application comes up, data is consistent | Monthly or quarterly |
| Full DR test | Complete recovery within RTO | Annually |

- Veeam: SureBackup (automated VM recovery in isolated virtual lab)
- Rubrik: Live Mount (instant mount for verification)
- Cohesity: DataProtect test failover
- Commvault: Cleanroom Recovery (automated isolated recovery)

## Reference Files

- `references/concepts.md` -- Deep dive on backup security fundamentals: 3-2-1-1-0 rule details, immutable backup implementations, air gap architectures, ransomware recovery workflow, RTO/RPO frameworks, encryption best practices, and secure restore testing procedures.