RCE cheat sheet

RPO (Recovery Point Objective) = maximum tolerable data loss measured in time; it is set by the business, not by the backup tooling.

RTO (Recovery Time Objective) = maximum tolerable downtime before service restoration; validate it with measured restore tests, not with backup success logs.

3-2-1 rule: at least 3 copies of data, on 2 different media types, with 1 copy offsite (modern extension adds 1 immutable or offline copy).

Backup types: full (baseline, highest storage), incremental (changed since last backup of any type), differential (changed since last full); restore chain length equals the number of incrementals since the last full.

Synthetic full = a new full reference point assembled from the previous full plus incrementals, avoiding a fresh production read.

Immutable backups use object-lock or WORM retention; a retention lock must outlive the longest expected attacker dwell time to be meaningful.

Snapshot is not a backup: snapshots typically live on the same array or account and are deleted or encrypted by an attacker with production credentials.

Verification hierarchy: job success < file-level checksum validation < automated test restore of an application or VM < full recovery exercise with measured RTO.

Retention/GFS: grandfather-father-son keeps daily, weekly, monthly, and yearly restore points; deduplication ratios shrink as retention grows because older blocks are reused.

Tier-0 assets: directory services, federation/identity providers, privileged access management, and the backup platform itself; compromise of Tier-0 invalidates every downstream control.

Phishing-resistant MFA = FIDO2/WebAuthn security keys or passkeys; push-notification and SMS OTP are bypassable by MFA fatigue and adversary-in-the-middle (AiTM) proxy kits.

Conditional access decision inputs: user/group, device compliance state, location or named network, application sensitivity, sign-in risk, and session controls.

Break-glass accounts: at least two cloud-only emergency accounts, excluded from conditional access, with long random credentials stored offline and monitored for any use.

Golden SAML and token-signing key theft let an attacker mint valid authentication tokens; response requires rotating the token-signing certificate and revoking all refresh tokens.

Identity recovery order: restore the identity provider first, then re-establish trust/federation, then privileged accounts, then standard users and service principals.

Service accounts and non-human identities need owners, credential rotation schedules, and scoping to least privilege; unowned API keys are a common persistence path.

Entra ID / cloud directory recovery relies on soft-delete windows (deleted objects and users) plus recycle-bin style restore; hard-deleted or aged objects require a separate backup.

Cyber recovery differs from disaster recovery: the adversary is still active, so the first step is containment and scoping, not restore.

Isolated recovery environment (clean room / vault): a separate network, separate credentials, and separate management plane from production, with no standing trust relationship back to production.

Recovery point triage: identify the last known-good backup by scanning restore points for indicators of compromise (ransomware notes, unexpected encryption, anomalous file extensions, new admin accounts).

Ransomware dwell time commonly precedes detonation, so the clean restore point is often days or weeks before the incident date; retention must cover that gap.

Order of restoration: identity/authentication, network and security tooling (logging, EDR, DNS), core infrastructure, then business applications and data.

Never rejoin a restored host to production before credential rotation and malware scan; restored systems often carry the persistence mechanism that caused the incident.

Recovery validation criteria: integrity check, malware scan, application owner sign-off, and confirmation that the restored data predates the compromise.

Tabletop and full-scale exercises should test decision authority, communications, isolation procedures, and measured RTO against the documented recovery plan.

Shared responsibility: the provider secures the cloud (physical, hypervisor, managed service availability); the customer secures what is in the cloud (data, identities, configuration, access).

SaaS data is not backed up by the vendor by default: Microsoft 365, Google Workspace, and Salesforce retention/recycle-bin windows are short and do not protect against malicious deletion by an authorized account.

Cloud-native protection options: provider snapshots (same account, fast but co-deletable), third-party backup to a separate account or region, and cross-account/cross-region replication.

Object storage immutability: S3 Object Lock (governance vs compliance mode) and Azure immutable blob policies; compliance mode cannot be shortened even by the root account.

Least-privilege backup roles: the backup service principal should not hold delete permissions on its own repository, and the production admin should not be able to delete backup storage.

SaaS recovery scope includes mailboxes, OneDrive/SharePoint sites, Teams channels, and metadata/permissions; restoring content without permissions breaks access.

Multi-tenant and API-based backup requires app registration with scoped consent; over-scoped consent is a common audit finding.

Cloud egress and restore throughput are billing and RTO factors: large restores may need request-based throttling increases from the provider.

Agent roles typically separate into discovery/inventory, protection (backup orchestration), detection/anomaly analysis, and recovery automation; each agent needs its own least-privilege credential.

Agent deployment requires outbound connectivity to the control plane (or an on-premises broker/gateway); document required ports, proxy exceptions, and certificate trust.

Agent health signals: heartbeat, last successful policy run, version currency, and credential expiry; a silent agent is a protection gap, not a neutral state.

Policy precedence: most specific scope wins (object > group > global); test precedence changes in a non-production scope before rollout.

Anomaly detection baselines normal change rates; tune thresholds per workload type to avoid alert fatigue, and route high-severity signals to the SOC runbook.

Agent upgrades should be staged: pilot group, verify policy execution and restore, then broad rollout; keep a rollback path to the prior agent version.

Audit and RBAC: separate platform admin, operator, and read-only auditor roles; every recovery action should be logged with actor, timestamp, and target.

Platform integrations (SIEM, SOAR, ticketing, identity provider) use API tokens that must be rotated and scoped; unused integrations should be disabled.