ghaymah-exam-Mohamed-Ashraf-Helmi-SecOps/q5-Ransomware-IR-Plan/Ransomware_Incident_Response_Plan.md

# Ransomware Incident Response Plan
## Scenario: Encryption of ghaymah Block Storage Volumes

**Platform reference:** [ghaymah Block Storage](https://ghaymah.systems/products/storage/block)
**Document owner:** _[fill in — IT/Security Lead]_
**Last reviewed:** _[fill in date]_
**Classification:** Internal — Confidential

**Note on figures in this document:** ghaymah's published pricing page (ghaymah.systems) confirms backup frequency by compute/storage tier (daily backup from the g4.medium plan upward, hourly backup from g5.large upward, with formal availability SLAs of 99.9% and 99.95% on the g6.xlarge and g7.2xlarge tiers respectively). ghaymah does not publish a per-tier RPO/RTO table in absolute time units. Where this document specifies RPO/RTO targets below the confirmed backup cadence, those are industry-standard planning targets and should be validated against the organization's actual ghaymah support/SLA agreement before this plan is finalized.

---

## Table of Contents
1. [Emergency Contingency Plan — First 60 Minutes](#1-emergency-contingency-plan--first-60-minutes)
2. [ghaymah Backup & Recovery Strategy](#2-ghaymah-backup--recovery-strategy)
3. [Prevention Plan](#3-prevention-plan)
4. [Appendices](#4-appendices)

---

## 1. Emergency Contingency Plan — First 60 Minutes

**Goal of this phase:** Stop the spread, preserve evidence, activate the team, and confirm whether clean recovery points exist — *before* touching anything that could destroy forensic evidence or trigger the attacker's "detonation" logic further.

### Golden Rules for the First 60 Minutes
- **Do not** power off encrypted VMs unless actively spreading (frozen state may hold decryption keys in memory).
- **Do not** pay the ransom, contact the attacker, or negotiate — that's a legal/executive decision, not an engineering one.
- **Do not** restore from backup yet — you must confirm the backup itself isn't already compromised.
- **Do not** wipe or reformat any encrypted volume.
- **Assume** the intrusion started well before the note appeared — set a lookback window of at least 30 days for forensic review.

---

### Minute 0–5: Detect & Declare
| Action | Owner |
|---|---|
| Confirm this is ransomware, not corruption/hardware failure (check ransom note, file extension changes, mass rename patterns) | On-call engineer |
| Declare a **Sev-1 Security Incident** and open an incident channel (Slack/Teams war-room) | On-call engineer |
| Page the Incident Commander (IC), Security Lead, and Infrastructure Lead | On-call engineer |
| Start an **incident timeline log** (timestamped, append-only — Google Doc, Confluence, or paper) | IC |

### Minute 5–15: Contain — Stop the Spread
| Action | Owner |
|---|---|
| **Isolate affected Block Storage volumes**: detach from compute instances where possible instead of deleting/formatting | Infra Lead |
| **Network-isolate** affected VMs/instances (security group / firewall rule to deny all egress except management) | Infra Lead |
| Disable automated snapshot **deletion** jobs and lifecycle policies (ransomware / malicious actors often try to delete backups first) | Infra Lead |
| Rotate/revoke API keys, SSH keys, and ghaymah console credentials with access to storage and backup systems | Security Lead |
| Disable any service accounts or CI/CD pipelines with write access to Block Storage | Security Lead |
| Freeze IAM changes — no new users/roles until incident is scoped | Security Lead |

### Minute 15–30: Preserve Evidence
| Action | Owner |
|---|---|
| **Snapshot the encrypted volumes as-is** (even though encrypted) before any remediation — this preserves forensic evidence and a "ground truth" copy | Infra Lead |
| Capture the ransom note text, file extension pattern, and any attacker contact info (do not delete the note) | Security Lead |
| Pull access logs / audit logs for the storage service, IAM, and network for the last 30 days | Security Lead |
| Identify **patient zero** — the first resource/account showing anomalous access or encryption activity | Security Lead |

### Minute 30–45: Assess Backup Integrity
| Action | Owner |
|---|---|
| Identify the **last known-good backup/snapshot** timestamp (pre-encryption) | Infra Lead |
| Verify that backup is **immutable / air-gapped / offsite** and was not itself accessible to the compromised credentials | Infra Lead + Security Lead |
| Spin up an **isolated sandbox environment** (new project/tenant, no shared network) to test-restore one volume from that backup | Infra Lead |
| Scan the restored test volume for indicators of compromise (webshells, cron jobs, unknown binaries) before trusting it | Security Lead |

### Minute 45–60: Communicate & Decide Next Phase
| Action | Owner |
|---|---|
| Brief executives / stakeholders: scope, suspected entry point, whether clean backups exist, ETA for recovery decision | IC |
| Determine legal/regulatory obligations (breach notification timelines, e.g. GDPR 72h, sector-specific rules) | Legal/Compliance |
| Decide: **restore-from-backup path** vs. **rebuild-from-scratch path** vs. **negotiate/law-enforcement path** (executive + legal call) | IC + Legal |
| Open a ticket with **ghaymah support** to report the incident and request platform-side audit logs / assistance | Infra Lead |
| Schedule the next sync in 2 hours; move from "first 60 minutes" mode into structured Incident Response phases (Eradication → Recovery → Post-Incident) | IC |

---

## 2. ghaymah Backup & Recovery Strategy

### 2.1 Core Concepts

**RPO (Recovery Point Objective)** — the maximum acceptable amount of data loss, measured in time. If your RPO is 1 hour and the incident hits at 10:00, you should be able to recover to a state no older than 09:00.

**RTO (Recovery Time Objective)** — the maximum acceptable time to restore service after an incident. If your RTO is 4 hours, systems must be back online within 4 hours of the recovery decision.

RPO and RTO drive *how often* you snapshot/back up and *how fast* your restore process needs to be — they are not the same thing and should be set independently per workload tier.

### 2.2 ghaymah Plan-Tier Backup Cadence (Confirmed)

The following backup cadence and availability commitments are published on ghaymah's pricing page and are specific to the compute/storage plan selected. This is the confirmed baseline that any RPO/RTO planning must be built on.

| Plan | Monthly Cost | Backup Cadence | Availability SLA |
|---|---|---|---|
| g3.small | $1 | Not specified | Not specified |
| g4.medium | $2 | Daily backup | Not specified |
| g5.large | $4 | Hourly backup | Not specified |
| g6.xlarge | $8 | Hourly backup (inherited) | 99.9% |
| g7.2xlarge | $14 | Hourly backup (inherited) | 99.95% |
| Managed PostgreSQL add-on | $5 | Automatic backup | Not specified |

Additional block storage capacity is billed separately at approximately $0.10/GB/month and inherits the backup cadence of the attached plan tier.

**Action item:** Confirm with ghaymah support (i) the exact snapshot retention window per tier, (ii) whether cross-region or off-platform replication is available, and (iii) whether backup cadence can be increased above hourly for Tier 0 workloads under a custom/enterprise agreement. The confirmed cadence above (daily/hourly) does not by itself guarantee immutability or isolation from a compromised account — see Section 2.4.

### 2.3 Recommended RPO/RTO Tiers by Workload Criticality

Where a workload's business criticality demands a tighter recovery point than the plan tier's native backup cadence provides, this must be closed with supplementary measures (application-level replication, more frequent manual snapshots, or database write-ahead-log shipping) rather than assumed.

| Tier | Example Workload | Target RPO | Target RTO | How to Achieve It on ghaymah |
|---|---|---|---|---|
| **Tier 0 — Critical** | Production database, authentication systems | ≤ 15 min | ≤ 1 hr | Hourly platform snapshot is insufficient alone; supplement with continuous replication or WAL shipping at the application/database layer |
| **Tier 1 — Important** | Application servers, internal APIs | ≤ 4 hr | ≤ 4 hr | g5.large or higher (hourly backup) meets this natively |
| **Tier 2 — Standard** | Staging, internal tools | ≤ 24 hr | ≤ 24 hr | g4.medium or higher (daily backup) meets this natively |
| **Tier 3 — Low priority** | Development, sandbox | Best effort | ≤ 72 hr | g3.small with manual/on-demand snapshots is acceptable |

> This tiering is a planning framework, not a ghaymah-published SLA. Confirm achievable figures with ghaymah support based on volume size and any enterprise agreement in place.

### 2.3 The 3-2-1 Rule Applied to ghaymah Block Storage

**3 copies of data** — the original plus at least two backups:
1. **Primary** — the live ghaymah Block Storage volume attached to production.
2. **Secondary (on-platform)** — scheduled ghaymah volume **snapshots**, stored on ghaymah's snapshot/object backend, decoupled from the live volume.
3. **Tertiary (off-platform / offsite)** — periodic export of snapshots to a **separate cloud provider or on-prem object storage**, so a ghaymah-wide incident (or a compromise of your ghaymah account itself) can't take out all copies.

**2 different storage media/locations:**
- Keep at least one copy on infrastructure with a **different control plane / credential set** than production (e.g., a separate ghaymah project/tenant with isolated IAM, or a different provider entirely).
- Avoid a setup where the same compromised admin credentials that hit production also have delete rights on the backup copy — this is the #1 reason ransomware actors succeed at destroying backups.

**1 copy offsite / air-gapped:**
- At least one backup must be **logically or physically isolated** — not reachable via the same network path, API keys, or session tokens as production.
- Options: write-once/immutable object storage (WORM-style retention lock), a cold/offline export, or a backup vault account with MFA-protected, break-glass-only access.

### 2.4 Immutability & Isolation Checklist

- [ ] Enable **snapshot lifecycle policies** with a minimum retention window that malicious actors/insiders cannot shorten without a second-approver.
- [ ] Use a **separate ghaymah project/account** (or separate provider) for backup storage, with its own IAM — production service accounts should have **no delete permission** on backup storage.
- [ ] Enforce **MFA + break-glass approval** for any backup deletion or retention-policy change.
- [ ] Test restores on a **quarterly schedule minimum** (an untested backup is a hypothesis, not a plan).
- [ ] Maintain **immutable/WORM** storage for at least one backup generation where the platform supports it.
- [ ] Keep **at least 3 recovery points** spanning different days, so you can roll back past a slow/dormant encryption event (some ransomware sits for days before triggering).

### 2.5 ghaymah's Published Security Controls and Shared Responsibility Model

ghaymah publishes a security overview (ghaymah.systems/security) describing its baseline platform-level controls:

- Encryption at rest using AES-256 and encryption in transit using TLS 1.3.
- Continuous, 24/7 automated security monitoring.
- Regular third-party penetration testing.
- A formal identity and access management system for internal ghaymah operations.
- A published vulnerability disclosure / bug bounty channel (ghaymah.systems/security/report).
- A stated 99.9% service availability figure and a stated average detection time of under one minute, as self-reported metrics on the same page.

ghaymah explicitly states a **shared responsibility model**, which should be treated as authoritative for scoping this organization's own obligations:

**ghaymah's stated responsibility:**
- Securing the physical and virtual infrastructure.
- Protecting the core platform and managed services.
- Applying security updates and managing vulnerabilities at the platform level.
- Continuous monitoring and threat detection at the platform level.

**Customer's stated responsibility:**
- Securing applications and data deployed on the platform.
- Managing user identities and permissions within the customer's own environment.
- Encrypting sensitive data at the application layer where required.
- Implementing security best practices within the customer's own configuration.

**Implication for this plan:** platform-level controls (physical security, hypervisor security, core service patching) are ghaymah's responsibility and are outside this organization's direct control. Everything in Section 3 of this plan — identity and access management, network segmentation, credential hygiene, backup isolation — falls on the customer side of the shared responsibility line and is this organization's obligation to implement regardless of what ghaymah does at the platform level.

### 2.6 Recovery Workflow (Post-First-60-Minutes)

1. Confirm eradication of the intrusion vector (see Section 3) **before** restoring — restoring into a still-compromised environment just gets re-encrypted.
2. Restore to an **isolated, network-segmented environment** first — never restore directly back into the production network.
3. Scan restored volumes (AV/EDR + manual review of cron, startup scripts, SSH `authorized_keys`, new user accounts).
4. Rotate **all** credentials and keys associated with the affected environment, not just the obviously compromised ones.
5. Cut over traffic only after validation; keep the old (encrypted) volumes preserved for forensics per your legal/insurance requirements.
6. Conduct a **post-incident review** within 5 business days and update this document.

---

## 3. Prevention Plan

Per ghaymah's published shared responsibility model (Section 2.5), the measures in this section fall on the customer side of the line and are this organization's obligation to implement, independent of ghaymah's own platform-level controls.

### 3.1 Identity & Access Management
- Enforce **MFA on all ghaymah console and API access**, no exceptions for admin accounts.
- Apply **least privilege**: separate roles for "can attach/detach volumes," "can create snapshots," and "can delete snapshots/backups" — these should rarely be the same identity.
- Use **short-lived credentials/tokens** for automation (CI/CD, scripts) instead of long-lived static API keys.
- Quarterly **access review**: remove stale accounts, unused API keys, and over-provisioned roles.

### 3.2 Network Segmentation
- Segment production, staging, and backup networks — a compromised production host should **not** have a network path to backup infrastructure.
- Restrict Block Storage management-plane API access to a **bastion/jump host or VPN**, not the open internet.
- Apply egress filtering to detect/block unusual outbound traffic (common in ransomware C2 and data-exfiltration-before-encryption patterns).

### 3.3 Detection & Monitoring
- Enable and centrally ship **audit logs** (IAM changes, snapshot deletions, volume attach/detach events) to a SIEM or log aggregator that is **not** on the same account/tenant as production.
- Alert on high-signal events: bulk file rename/encryption patterns, mass snapshot deletion attempts, off-hours admin logins, privilege escalation.
- Deploy **EDR/anti-malware** on all compute instances attached to Block Storage volumes.
- Set up **canary files** in critical volumes — files that should never be touched; any modification triggers an immediate alert.

### 3.4 Patch & Configuration Management
- Maintain a patch SLA (e.g., critical CVEs patched within 72 hours) for OS and application layers on any instance with Block Storage attached.
- Disable unused management ports/services (RDP, SMB, exposed databases) — these are the most common ransomware entry points.
- Use infrastructure-as-code with version control so configuration drift is visible and revertible.

### 3.5 Backup Hardening (ties back to Section 2)
- Enforce the **3-2-1 rule** as a hard requirement for any production workload, verified in architecture reviews before go-live.
- Make backup deletion/retention changes **require a second approver** (four-eyes principle).
- Automated **restore testing** on a recurring schedule — track and report an actual measured RTO, not a theoretical one.

### 3.6 Human Factors
- Run **phishing simulations** and security awareness training at least twice a year — most ransomware still starts with a phished credential or malicious attachment.
- Maintain an **up-to-date contact tree** for the incident response team, including ghaymah support escalation contacts, legal counsel, cyber insurance provider, and (if applicable) national CERT.
- Run **tabletop exercises** simulating this exact scenario (encrypted Block Storage) at least once a year, timing the team against the first-60-minutes runbook in Section 1.

### 3.7 Governance
- Maintain **cyber insurance** with ransomware coverage, and know the notification requirements/timelines in advance.
- Establish a **pre-approved decision framework** for executives on the pay/don't-pay question — this should never be decided for the first time mid-incident.
- Review and update this document **after every incident and every tabletop exercise**, and at minimum annually.

---

## 4. Appendices

### 4.1 Incident Response Roles
| Role | Responsibility |
|---|---|
| Incident Commander (IC) | Overall decision authority, coordinates response, owns comms to execs |
| Infrastructure Lead | Containment, isolation, backup/restore execution |
| Security Lead | Forensics, evidence preservation, threat scoping |
| Legal/Compliance | Regulatory notification, law enforcement liaison, ransom decision input |
| Communications Lead | Internal/external/customer communication |

### 4.2 Key External Contacts

| Contact | Purpose | Details |
|---|---|---|
| ghaymah Support | Platform-level incident support, log access | ghaymah.systems/support · ghaymah.systems/create-ticket |
| ghaymah Security Team | Reporting a suspected platform-level vulnerability or breach | ghaymah.systems/security/report |
| Cyber Insurance Provider | Claims, breach coach, negotiator referral | _[fill in]_ |
| National/Sector CERT | Regulatory and threat intelligence | _[fill in]_ |
| External IR/Forensics Firm | Deep forensic investigation | _[fill in]_ |
| Legal Counsel | Notification obligations, ransom legality | _[fill in]_ |

Note: ghaymah's public support channels also list WhatsApp and Telegram as live support options in addition to the ticketing links above; confirm current escalation paths and after-hours coverage directly with ghaymah support, as these are not detailed in public documentation.

### 4.3 Revision History
| Date | Author | Change |
|---|---|---|
| _[fill in]_ | _[fill in]_ | Initial version |