RB-EVIDENCE-005: Snapshot-acquisitie van cloud-workloads

Documentbeheer

1. Vereisten

• Identificatie van de workload waarvan een snapshot moet worden gemaakt (instance-ID, container-/pod-ID, functienaam, service-ID)
• Toestemming om een snapshot van de workload te maken (de workload-eigenaar is geïnformeerd of er is break-glass-bevoegdheid)
• Schrijftoegang tot het cloudaccount / de subscription / het project / de tenancy waarin de workload draait
• Een aparte forensische bestemming (account / project / regio) waar snapshots worden opgeslagen - dit mag niet hetzelfde account / project zijn als dat van de getroffen workload
• Console of CLI van de cloudprovider voor het getroffen account
• Hashingtool (bijv. sha256sum) voor snapshots die buiten de cloud worden geëxporteerd

2. Stap-voor-stap-instructies

Veelgemaakte fouten

• Een snapshot maken nadat de workload is beëindigd - bij de meeste providers kan dat niet meer, en vluchtige status gaat verloren zodra de workload stopt
• Autoscaling de workload laten vervangen of beëindigen terwijl de snapshot loopt
• Snapshots opslaan in hetzelfde gecompromitteerde account / project, waar de aanvaller ze kan wijzigen of verwijderen
• Alleen de schijf vastleggen en het geheugen overslaan terwijl de provider geheugencapture ondersteunt - vluchtig bewijsmateriaal gaat verloren
• Vergeten snapshot-ID's en hashes vast te leggen, waardoor de chain of custody breekt

1. Bevestig de identiteit van de workload en de toestemming

   • Verifieer dat je de snapshot van de juiste workload maakt
   • Bevestig de toestemming van de workload-eigenaar of de Incident Commander
   • Bevestig dat de forensische bestemming klaar is om snapshots te ontvangen

2. Stel vast waarvan een snapshot moet worden gemaakt

   • Voor VM's: alle gekoppelde schijven / volumes; het geheugen als de provider live capture ondersteunt
   • Voor containers / pods: het bestandssysteem van de container (commit de draaiende container naar een image); de schrijfbare laag van de pod; gekoppelde volumes
   • Voor serverless functions: het uitgerolde package / image; eventuele gekoppelde opslag (EFS, persistent volumes); recente invocation-logs
   • Voor managed services: de providerspecifieke snapshot of export (bijv. RDS-snapshot, snapshot van een managed disk)

3. Zet automatische vervanging stil

   • Zit de workload in een autoscaling-groep, koppel hem dan los of zet de launch/terminate-processen van de groep stil
   • Is het een Kubernetes-pod, cordon dan de node en patch de controller (Deployment / StatefulSet) om opnieuw inplannen te voorkomen
   • Is het een serverless function, zet de concurrency dan op nul of schakel de trigger van de functie uit
   • Zo voorkom je dat de workload tijdens de snapshot wordt vernietigd

4. Maak de snapshots

   • Start de snapshots via de console of CLI van de cloudprovider
   • Voor geheugen: gebruik het live capture-mechanisme van de provider als dat er is (bijv. Azure VM live snapshot, GCP VM serial console capture)
   • Voor containers: commit de container naar een image; exporteer het image
   • Voor functions: download het deployment package of container-image van de functie
   • Bevestig dat elke snapshot geslaagd is voordat je verdergaat

5. Kopieer naar de forensische bestemming en leg metadata vast

   • Kopieer of deel elke snapshot naar de aparte forensische bestemming
   • Leg per snapshot vast: snapshot-ID, ID van de bronworkload, bronregio, grootte, tijdstip, SHA-256-hash (waar ondersteund) en de responder die hem heeft gemaakt
   • Bevestig dat de snapshots op de bestemming alleen-lezen of tegen schrijven beveiligd zijn
   • Verifieer de integriteit van de snapshots op de bestemming voordat je de acquisitie als afgerond beschouwt

3. Na afloop

• Leg snapshot-ID's, hashes, tijdstippen en de bestemmingslocatie vast in het incidentrecord
• Laat de Incident Commander weten dat de snapshots klaar zijn voor analyse

Bijdrager

Jayden Vo GitHub: https://github.com/jayden-vo

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.