added

q5-ransomware-response/backup-recovery-strategy.md

@@ -0,0 +1,163 @@
+# Ghaymah Backup & Recovery Strategy
+
+## RPO and RTO Targets
+
+| Metric | Definition | Target for Ghaymah |
+|---|---|---|
+| **RPO** (Recovery Point Objective) | Maximum acceptable data loss (how old can a backup be?) | **1 hour** — automatic snapshots every hour |
+| **RTO** (Recovery Time Objective) | Maximum acceptable downtime (how fast must we recover?) | **4 hours** — from incident declaration to restored service |
+
+---
+
+## The 3-2-1 Backup Rule
+
+The **3-2-1 rule** is a commonly used backup best practice:
+
+```
+3 — Keep 3 copies of your data
+2 — Store them on 2 different types of media/storage
+1 — Keep 1 copy offsite (geographically separate location)
+```
+
+### How Ghaymah Implements 3-2-1
+
+```mermaid
+graph TD
+    subgraph Copy 1 - Primary
+        LIVE["💻 Production Instance"]
+        BS["🗄️ SSD Block Storage\n(Attached Volume)"]
+        LIVE --> BS
+    end
+
+    subgraph Copy 2 - Cloud Backup
+        OS["☁️ Ghaymah Object Storage\n(Separate Storage Tier)"]
+        BS -->|"Automated Hourly Backup\nRetention: 7 days hourly, 30 days daily"| OS
+    end
+
+    subgraph Copy 3 - Offsite Remote
+        OFF["🌍 Cold/Archive Storage\n(e.g., Secondary Regional Datacenter)"]
+        OS -->|"Daily Export\nRetention: 90 days"| OFF
+    end
+```
+
+---
+
+## Backup Schedule
+
+| Backup Type | Frequency | Retention | Storage Location |
+|---|---|---|---|
+| Ghaymah Object Storage backup | Every 1 hour | 7 days | Ghaymah Object Storage (separate from Block Storage) |
+| Daily backup | Every 24 hours at 02:00 | 30 days | Ghaymah Object Storage |
+| Weekly backup | Every Sunday at 03:00 | 90 days | Offsite / remote region |
+| Pre-deployment backup | Before every deployment | 30 days | Ghaymah Object Storage |
+
+---
+
+## Automated Snapshot Script
+
+```bash
+#!/bin/bash
+# backup-snapshot.sh — Run via cron every hour
+
+VOLUME_ID="vol-xxxx-replace-with-actual"
+SNAPSHOT_PREFIX="auto-backup"
+RETENTION_DAYS=7
+DATE=$(date +%Y%m%d-%H%M)
+
+echo "[$(date)] Creating snapshot for volume $VOLUME_ID"
+
+# Create snapshot (replace with actual Ghaymah CLI command)
+ghaymah-cli storage snapshot create \
+  --volume-id "$VOLUME_ID" \
+  --name "${SNAPSHOT_PREFIX}-${DATE}"
+
+# Clean up snapshots older than retention window
+ghaymah-cli storage snapshot list --volume-id "$VOLUME_ID" \
+  | awk -v cutoff="$(date -d "$RETENTION_DAYS days ago" +%s)" \
+    '$3 < cutoff {print $1}' \
+  | xargs -I{} ghaymah-cli storage snapshot delete --snapshot-id {}
+
+echo "[$(date)] Snapshot created: ${SNAPSHOT_PREFIX}-${DATE}"
+```
+
+Add to crontab:
+```bash
+# Run backup every hour at minute 0
+0 * * * * /opt/scripts/backup-snapshot.sh >> /var/log/backup.log 2>&1
+```
+
+---
+
+## Recovery Procedure
+
+### Standard Recovery (planned or scheduled)
+
+```bash
+# 1. List available snapshots
+ghaymah-cli storage snapshot list --volume-id vol-xxxx
+
+# 2. Create new volume from snapshot
+ghaymah-cli storage volume create-from-snapshot \
+  --snapshot-id snap-xxxx \
+  --name recovery-$(date +%Y%m%d)
+
+# 3. Detach old volume (if still attached)
+ghaymah-cli storage volume detach --instance-id inst-xxxx --volume-id vol-old
+
+# 4. Attach new volume
+ghaymah-cli storage volume attach --instance-id inst-xxxx --volume-id vol-new
+
+# 5. Mount and verify
+sudo mount /dev/sdb /mnt/data
+ls -la /mnt/data
+```
+
+### Emergency Recovery (ransomware or corruption)
+
+1. Use emergency-plan.md for first 60 minutes.
+2. Identify last clean snapshot from **before** the incident timestamp.
+3. Never mount suspicious volumes to production instances.
+4. Always verify restored data integrity before going live.
+
+---
+
+## Backup Integrity Verification
+
+Monthly verification test:
+
+```bash
+#!/bin/bash
+# verify-backup.sh — Monthly DR drill
+
+echo "=== Backup Verification Test ==="
+echo "Date: $(date)"
+
+# 1. Identify latest snapshot
+LATEST_SNAP=$(ghaymah-cli storage snapshot list --volume-id vol-xxxx \
+  | sort -k3 -r | head -1 | awk '{print $1}')
+
+# 2. Create test restore volume
+ghaymah-cli storage volume create-from-snapshot \
+  --snapshot-id "$LATEST_SNAP" \
+  --name test-restore-$(date +%Y%m%d)
+
+# 3. Attach to test instance (never production)
+ghaymah-cli storage volume attach --instance-id inst-test --volume-id vol-test
+
+# 4. Verify expected file structure
+EXPECTED_COUNT=$(cat /opt/backup-manifest/expected-file-count.txt)
+ACTUAL_COUNT=$(find /mnt/test-restore -type f | wc -l)
+
+echo "Expected files: $EXPECTED_COUNT"
+echo "Actual files:   $ACTUAL_COUNT"
+
+if [ "$ACTUAL_COUNT" -ge "$EXPECTED_COUNT" ]; then
+  echo "[PASS] Backup integrity verified"
+else
+  echo "[FAIL] File count mismatch — alert secops team"
+fi
+
+# 5. Cleanup test volume
+ghaymah-cli storage volume detach --instance-id inst-test --volume-id vol-test
+ghaymah-cli storage volume delete --volume-id vol-test
+```

q5-ransomware-response/emergency-plan.md

@@ -0,0 +1,130 @@
+# Emergency Plan — First 60 Minutes of Ransomware Incident
+
+> **Scenario:** All Block Storage files on Ghaymah cloud are encrypted with a ransom message.
+
+---
+
+## ⏱ Minute 0–5: Detect & Confirm
+
+**Trigger Indicators:**
+- Files renamed to `*.encrypted` or `*.locked`
+- Ransom note file: `READ_ME_TO_DECRYPT.txt`
+- Sudden spike in Block Storage write IOPS
+- Applications returning file-not-found errors
+
+**Immediate Actions:**
+1. Alert the security team and management — declare a P1 incident.
+2. Do NOT pay the ransom at this stage.
+3. Do NOT reboot or shut down the instance (preserves memory evidence).
+4. Take a forensic snapshot of the current Block Storage volume to preserve evidence. **Do not restore from this snapshot** — it may contain encrypted files. Restore from the last clean backup taken before the encryption event.
+
+```bash
+# Forensic snapshot — evidence preservation only
+ghaymah-cli storage snapshot create --volume-id vol-xxxx --name ransomware-forensic-$(date +%Y%m%d)
+```
+
+---
+
+## ⏱ Minute 5–15: Isolate
+
+**Goal:** Stop the ransomware from spreading to other systems.
+
+| Action | Method |
+|---|---|
+| Isolate the infected instance | Remove from load balancer pool immediately |
+| Block all outbound traffic | Apply deny-all egress firewall rule to the instance |
+| Revoke instance API credentials | Rotate IAM keys/tokens used by the instance |
+| Disconnect Block Storage | Detach volume to prevent further encryption |
+| Alert other teams | Notify DB admins, network team, management |
+
+```bash
+# Detach Block Storage volume
+ghaymah-cli storage volume detach --instance-id inst-xxxx --volume-id vol-xxxx
+
+# Apply deny-all network rule (Ghaymah firewall)
+ghaymah-cli network firewall add-rule \
+  --instance inst-xxxx \
+  --direction egress \
+  --action deny \
+  --priority 1
+```
+
+---
+
+## ⏱ Minute 15–30: Assess the Damage
+
+**Goal:** Understand the scope of encryption and identify the attack vector.
+
+1. **Check which files are encrypted:**
+   ```bash
+   # On a forensic copy only
+   find /mnt/forensic-copy -name "*.encrypted" -o -name "*.locked" | wc -l
+   ```
+
+2. **Identify ransomware family** (from ransom note + file extensions).
+
+3. **Check intrusion timeline** — review access logs from the past 48 hours:
+   ```bash
+   grep -i "POST\|PUT" /var/log/nginx/access.log | tail -500
+   journalctl --since "48 hours ago" | grep -E "error|fail|unauthorized"
+   ```
+
+4. **Identify the attack vector:**
+   - Phishing email with malicious attachment?
+   - Exposed RDP/SSH with weak credentials?
+   - Vulnerable web application?
+   - Compromised supply chain dependency?
+
+5. **Check for legitimate decryption tools:** Search security databases (NoMoreRansom.org) — some ransomware strains have free decryptors.
+
+---
+
+## ⏱ Minute 30–45: Begin Recovery
+
+**Goal:** Restore services from the last clean backup.
+
+1. Identify the last clean backup snapshot (before encryption):
+   ```bash
+   ghaymah-cli storage snapshot list --volume-id vol-xxxx
+   # Look for the last snapshot BEFORE the ransomware event timestamp
+   ```
+
+2. Create a new volume from the clean snapshot:
+   ```bash
+   ghaymah-cli storage volume create-from-snapshot \
+     --snapshot-id snap-clean-xxxx \
+     --name restored-volume-$(date +%Y%m%d)
+   ```
+
+3. Attach the restored volume to a clean, rebuilt instance.
+
+4. Verify data integrity before bringing services back online:
+   ```bash
+   # Check file counts match expected
+   find /mnt/restored -type f | wc -l
+   # Run application health checks
+   curl -f http://localhost:8080/health
+   ```
+
+---
+
+## ⏱ Minute 45–60: Restore Service & Communicate
+
+1. Re-add restored instance to the load balancer.
+2. Monitor for any re-infection indicators (file modification spikes).
+3. Send internal status update: scope, services affected, ETA for full recovery.
+4. Prepare customer/stakeholder disclosure notification (if PII was exposed).
+5. Preserve the forensic snapshot for later analysis and potential law enforcement reporting.
+
+---
+
+## Incident Commander Checklist
+
+- [ ] P1 alert sent to all stakeholders
+- [ ] Infected instance isolated (firewall + load balancer)
+- [ ] Block Storage detached
+- [ ] Forensic snapshot taken
+- [ ] Clean backup identified
+- [ ] Restoration in progress
+- [ ] Communication sent to affected parties
+- [ ] Legal/compliance team notified

q5-ransomware-response/prevention-plan.md

@@ -0,0 +1,167 @@
+# Comprehensive Ransomware Prevention Plan
+
+> Goal: Eliminate the key attack vectors that allow ransomware to reach and encrypt Ghaymah Block Storage.
+
+---
+
+## Prevention Layer 1: Access Control & Authentication
+
+### 1.1 Eliminate Password-Only Authentication
+- **Replace SSH passwords with SSH keys** for all server access.
+- Disable password-based SSH login:
+  ```bash
+  # /etc/ssh/sshd_config
+  PasswordAuthentication no
+  PermitRootLogin no
+  PubkeyAuthentication yes
+  ```
+- Restrict SSH access to a VPN or bastion host only.
+
+### 1.2 Enforce Multi-Factor Authentication (MFA)
+- Require MFA for:
+  - Cloud console / Ghaymah dashboard access
+  - All admin and privileged user accounts
+  - CI/CD pipeline credentials
+
+### 1.3 Principle of Least Privilege
+- Application containers and services should **never** have Block Storage mount access unless explicitly required.
+- Use separate IAM roles: one for read, one for write, none for delete by default.
+- Administrative access to cloud resources requires MFA + session time limit.
+
+---
+
+## Prevention Layer 2: Endpoint & System Hardening
+
+### 2.1 Keep Systems Patched
+```bash
+# Automate security updates (Ubuntu/Debian)
+sudo apt-get install unattended-upgrades -y
+sudo dpkg-reconfigure --priority=low unattended-upgrades
+```
+
+### 2.2 Restrict Executable Permissions
+- Mount Block Storage with `noexec` flag to prevent direct execution of files from storage:
+  ```bash
+  # /etc/fstab
+  /dev/sdb /mnt/data ext4 defaults,noexec,nosuid 0 2
+  ```
+- This means even if a ransomware binary is uploaded to Block Storage, it cannot run directly from there.
+
+### 2.3 Disable Unused Services
+```bash
+# Disable unnecessary services
+sudo systemctl disable --now telnet ftp rpcbind
+sudo ufw enable
+sudo ufw default deny incoming
+sudo ufw default allow outgoing
+sudo ufw allow 22/tcp    # SSH from known IPs only
+sudo ufw allow 443/tcp   # HTTPS
+```
+
+---
+
+## Prevention Layer 3: Network Security
+
+### 3.1 Segment the Network
+- Block Storage volumes should only be attached to authorized instances and protected from unauthorized access.
+- Use private subnets:
+  ```
+  Public subnet:  Load Balancer, API Gateway
+  Private subnet: Application Servers, Block Storage
+  Database subnet: PostgreSQL, Redis (no internet access)
+  ```
+
+### 3.2 Block Lateral Movement
+Apply Ghaymah network policies to prevent instances from communicating with each other unless explicitly needed:
+
+```yaml
+# Network policy: deny all east-west traffic by default
+# Only allow app-server → database on port 5432
+# Only allow app-server → block-storage on mount connection
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: deny-lateral-movement
+spec:
+  podSelector: {}
+  policyTypes:
+    - Ingress
+    - Egress
+  egress:
+    - to:
+        - podSelector:
+            matchLabels:
+              tier: database
+      ports:
+        - port: 5432
+```
+
+### 3.3 DNS Filtering & Egress Control
+- Implement DNS-based blocking to prevent ransomware C2 (command-and-control) communication.
+- Block outbound traffic to known malicious domains using a threat intelligence feed.
+- Allow-list only required outbound destinations (e.g., update servers, CDNs).
+
+---
+
+## Prevention Layer 4: Email & Social Engineering Defense
+
+| Control | Implementation |
+|---|---|
+| Email filtering | Block executable attachments (.exe, .bat, .ps1, .vbs) |
+| Link scanning | Scan all URLs in emails before delivery |
+| Phishing simulation | Run quarterly phishing drills with staff |
+| Security awareness training | Train all employees on ransomware recognition |
+| DMARC/SPF/DKIM | Prevent email spoofing using DNS mail security records |
+
+---
+
+## Prevention Layer 5: Monitoring & Early Detection
+
+### 5.1 File Integrity Monitoring (FIM)
+Monitor Block Storage for unusual file rename patterns:
+
+```bash
+# Install auditd for file system monitoring
+sudo apt-get install auditd -y
+
+# Watch for mass file renames (ransomware signature)
+auditctl -w /mnt/data -p wra -k file_modification
+
+# Alert on rename events
+ausearch -k file_modification | grep "rename"
+```
+
+### 5.2 SIEM Alerts (from Q4)
+Configure the SIEM (`siem.py`) to detect early ransomware indicators:
+- Sudden spike in Block Storage write IOPS (>1000 writes/minute)
+- Mass file extension changes
+- New processes accessing large numbers of files in seconds
+- Outbound connections to unknown external IPs from storage-tier containers
+
+### 5.3 Immutable Block Storage Snapshots
+Configure snapshots with **Object Lock** (immutable mode) so they cannot be deleted — even by an admin account — for a defined retention period:
+```bash
+# Example command — replace with actual Ghaymah immutable storage configuration
+ghaymah-cli storage bucket set-object-lock \
+  --bucket siem-backups \
+  --mode COMPLIANCE \
+  --retention-days 30
+```
+
+---
+
+## Prevention Checklist Summary
+
+| Priority | Control | Status |
+|---|---|---|
+| 🔴 Critical | SSH key-only authentication | Implement immediately |
+| 🔴 Critical | MFA for cloud console | Implement immediately |
+| 🔴 Critical | Least-privilege IAM roles | Implement immediately |
+| 🟠 High | Automated OS patching | This week |
+| 🟠 High | Network segmentation (public/private subnets) | This week |
+| 🟠 High | `noexec` on Block Storage mounts | This week |
+| 🟠 High | Immutable backup snapshots | This week |
+| 🟡 Medium | DNS filtering / egress control | This month |
+| 🟡 Medium | File Integrity Monitoring (FIM) | This month |
+| 🟡 Medium | Phishing simulation program | This quarter |
+| 🟢 Low | Security awareness training | This quarter |