RB-CONTAIN-015: Isolatie van cloud-workloads

Documentbeheer

Kenmerk	Waarde	Datum
Documentnaam	Isolatie van cloud-workloads	[Datum invullen]
Versie	[Versienummer invullen]	[Datum invullen]
Eigenaar	[Eigenaar/team invullen]	[Datum invullen]
Status	[Draft/Approved/Retired]	[Datum invullen]
Volgende reviewdatum	[Volgende reviewdatum invullen]	[Datum invullen]
Goedkeuringen	[Goedkeurder(s) invullen]	[Datum invullen]
Wijzigingsoverzicht	Eerste versie	[Datum invullen]

1. Vereisten

Identificatie van de getroffen cloud-workload (instance-ID, container-/pod-ID, functienaam, service-ID)
Toestemming om de workload te isoleren (de workload-eigenaar is geïnformeerd of er is break-glass-bevoegdheid)
Schrijftoegang tot het cloudaccount / de subscription / het project / de tenancy
Vooraf gedefinieerde "quarantaine"-security group / NSG / firewallregel (weigert alle inkomend en uitgaand verkeer behalve toegang voor onderzoekers)
Bestemming voor snapshots (account / regio / project waar snapshots worden opgeslagen)
Console of CLI van de cloudprovider voor het getroffen account
Toegang tot de SIEM / logs van de cloud control plane voor verificatie
Snapshots zijn al gemaakt voordat de isolatie begint (zie RB-EVIDENCE-005: Snapshot-acquisitie van cloud-workloads)

2. Stap-voor-stap-instructies

Veelgemaakte fouten

De netwerkinterface loskoppelen (wat ook lopende status kan vernietigen) in plaats van te isoleren met een quarantaine-security group

De instance role gekoppeld laten — de aanvaller kan met de credentials van de rol API-aanroepen blijven doen, ook na netwerkisolatie

De workload tijdens de isolatie beëindigen — laat hem draaien voor forensische analyse

Bevestig de identiteit van de workload en de toestemming
- Verifieer dat de identificatie van de workload overeenkomt met de scope van het incident
- Bevestig de toestemming van de workload-eigenaar of de Incident Commander
- Informeer afhankelijke diensten / on-call-eigenaren vóór de isolatie als de workload in productie draait
Leg de status vóór de isolatie vast
- Leg de huidige security group / NSG, instance role / managed identity, het publieke IP, de gekoppelde volumes en de draaistatus van de workload vast
- Leg eventuele lidmaatschappen van load balancers / target groups vast
- Leg een eventueel lidmaatschap van een autoscaling-groep vast (zodat de groep de workload niet ongemerkt vervangt)
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 functie uit
Trek de credentials van de instance / workload in
- Koppel de instance role / managed identity / workload identity los van de workload of vervang die
- Trek actieve sessies in die aan de rol zijn uitgegeven (bijv. AWS aws iam delete-access-key voor eventuele access keys, en koppel daarna een deny-all-sessiebeleid aan de rol om lopende sessies ongeldig te maken)
- Roteer alle credentials waar de workload bij kon (items in de secrets manager, omgevingsvariabelen, hardcoded credentials)
Isoleer de workload op netwerkniveau
- Vervang de security group / NSG van de workload door de vooraf gedefinieerde quarantaineregels
- Bevestig dat de nieuwe regels actief zijn door de actuele koppeling van security group / NSG te controleren
- Pas bij Kubernetes een NetworkPolicy toe die alle inkomend/uitgaand verkeer weigert behalve vanuit de namespaces van onderzoekers
Verifieer de isolatie
- Bevestig in de log van de cloud control plane dat de instance role geen nieuwe API-aanroepen meer doet
- Bevestig vanaf de workload (als die via het onderzoekerspad bereikbaar is) dat uitgaand netwerkverkeer is geblokkeerd
- Bevestig in de SIEM dat de workload geen nieuwe alerts meer genereert
Draag over voor vervanging
- Start bij workloads in productie de vervanging vanuit betrouwbare IaC / images (zie RB-RECOVERY-002: Schone herinstallatie van systemen) zodat de continuïteit van de dienst is hersteld
- Laat de geïsoleerde workload draaien voor forensische analyse totdat het onderzoek klaar is; beëindig hem niet voortijdig

3. Na afloop

Leg alle isolatieacties en tijdstippen vast in het incidentrecord
Laat de Incident Commander en het Cloud Security-/platformteam weten dat de isolatie is afgerond

Bijdrager

Firstname Lastname GitHub: https://github.com/account

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.