Een responsplan voor cloudincidenten opstellen: aanpak in stappen

De incidentresponscyclus, aangepast voor de cloud

NIST SP 800-61 Rev. 3 presenteert incidentrespons niet langer als een zelfstandige cyclus van vier fasen. Het koppelt responsactiviteiten aan de CSF 2.0-functies: Govern, Identify, Protect, Detect, Respond en Recover. In de praktijk organiseren de meeste teams hun runbooks nog steeds rond de bekende fasen hieronder, en dat werkt prima zolang voorbereiding en geleerde lessen terugvloeien naar de governance.

Stap 1: bereid het plan, de mensen en het platform voor

Bepaal scope en governance

Leg vast welke omgevingen het plan dekt: elk cloudaccount, elk abonnement en elk project, plus de SaaS-platforms met bedrijfsdata (Microsoft 365, Google Workspace, Salesforce en vergelijkbare). Registreer dataclassificaties, want een lek van persoonsgegevens van klanten escaleert sneller dan een openbare testbucket.

Wijs een eigenaar voor het plan aan, een reviewcyclus (minstens jaarlijks, en na grote incidenten of architectuurwijzigingen) en de koppeling met uw plannen voor bedrijfscontinuïteit en disaster recovery. Onder NIS2 verplicht artikel 20 de bestuursorganen van essentiële en belangrijke entiteiten de maatregelen voor cyberbeveiligingsrisicobeheer goed te keuren en toezicht te houden op de uitvoering, dus goedkeuring op bestuursniveau is voor bedrijven binnen het toepassingsgebied niet langer optioneel.

Wijs rollen toe voordat u ze nodig hebt

Benoem voor elke rol een plaatsvervanger en houd een contactlijst buiten de reguliere kanalen bij. Als de aanvaller uw Microsoft 365-tenant in handen heeft, is Teams geen veilige crisisruimte.

Ontwerp het platform voor respons

• Centrale, manipulatiebestendige logging. Stuur CloudTrail, Azure-activiteitslogs, aanmeld- en auditlogs van Microsoft Entra ID, Google Cloud Audit Logs, VPC/NSG-flowlogs en DNS-logs naar een speciaal logaccount of -workspace waaruit productiebeheerders niets kunnen verwijderen. Gebruik object lock of onveranderlijke opslag voor het archief.
• Bewaartermijn die bij onderzoeken past. Als een datalek maanden duurt, zijn 30 dagen aan logs te weinig. Stel de bewaartermijn vast op basis van dataklasse en wettelijke vereisten.
• Break-glass-toegang. Houd een klein aantal noodaccounts met hardware-MFA, apart opgeslagen en bewaakt, zodat responders niet buitengesloten worden wanneer juist de identiteitsprovider wordt aangevallen.
• Vooraf ingerichte forensische capaciteit. Een apart forensisch account of abonnement met gereedstaande tooling, waar u snapshots kunt kopiëren voor analyse zonder productie aan te raken.
• Segmentatie en least privilege. Aparte accounts per omgeving, afgebakende rollen en service control policies beperken hoe ver een incident kan reiken.
• Onveranderlijke herstelpunten. Versiebeheerde back-ups tussen accounts en images waaruit u kunt herbouwen, beschermd tegen dezelfde inloggegevens waarmee productie draait.

Stap 2: detecteer en beoordeel cloudincidenten

Goede detectie in de cloud combineert native dreigingsdetectie van de provider met uw eigen correlatie. Native diensten kennen het platform; uw SIEM kent uw bedrijfscontext.

• Schakel Amazon GuardDuty, Microsoft Defender for Cloud of Google Security Command Center in voor elk account en elke regio, niet alleen voor productie.
• Stuur bevindingen en identiteitslogs door naar één SIEM, zodat een afwijkende aanmelding in Entra ID en een ongebruikelijke AWS API-aanroep van dezelfde gebruiker als één zaak verschijnen.
• Geef een melding bij gebeurtenissen met een sterk signaal: aanmelding als root of globale beheerder, nieuwe toegangssleutels voor bevoorrechte gebruikers, uitgeschakelde logging, openbare opslagbeleidsregels, nieuwe regio's in gebruik, plotselinge pieken in compute.
• Voeg threat intelligence toe, zodat meldingen die zijn gekoppeld aan bekende kwaadaardige infrastructuur bovenaan de wachtrij komen.

Een eenvoudige triagematrix

Voorbeeldrunbook: verdacht gebruik van een toegangssleutel

1. Bevestig de activiteit in het auditlog: bron-IP, user agent, regio's en API-aanroepen van de afgelopen uren.
2. Deactiveer de sleutel (nog niet verwijderen) en trek actieve sessies van de principal in.
3. Controleer waartoe de sleutel toegang had en wat die heeft gedaan: nieuwe gebruikers, rollen, sleutels, instanties, gelezen data.
4. Maak snapshots van getroffen instanties en exporteer de relevante logs naar het forensische account.
5. Informeer de incident commander, en juridische zaken als toegang tot data waarschijnlijk is.
6. Roteer alle geheimen die de principal kon lezen en verwijder daarna de persistentie die de aanvaller heeft aangemaakt.

Stap 3: bewaar bewijs op de cloudmanier

Forensisch onderzoek in de cloud draait vooral om snelheid en automatisering. Neem deze stappen op in elk runbook dat eindigt in beëindigen of herbouwen:

• Maak schijfsnapshots en, waar uw tooling dat ondersteunt, een geheugenopname voordat u een VM isoleert of stopt.
• Tag geïsoleerde resources met de incident-ID, zodat niemand bewijs "opruimt".
• Kopieer snapshots en logfragmenten naar het forensische account; leg vast wie ze wanneer heeft geraadpleegd.
• Houd alle systemen op gesynchroniseerde tijd (NTP, UTC in logs), zodat u gebeurtenissen over providers heen kunt correleren.
• Weet hoe u informatie bij uw provider opvraagt. Contracten met SaaS-leveranciers en MSSP's moeten vastleggen welke logs zij bewaren, hoe lang en hoe snel ze die overdragen.

De AWS Security Incident Response Guide loopt deze werkwijzen voor AWS in detail door; dezelfde principes gelden voor Azure en Google Cloud.

Stap 4: dam in, ruim op en herstel

Indamming op korte termijn

• Isoleer instanties door hun security group of NSG te vervangen door een deny-all-groep die alleen forensische toegang toestaat.
• Deactiveer sleutels, trek tokens en sessies in en forceer wachtwoord- en MFA-resets voor gecompromitteerde identiteiten.
• Blokkeer openbare toegang tot blootgestelde opslag; pas een expliciet deny-beleid of een service control policy toe als de aanvaller beheerdersrechten heeft.
• Voeg WAF-regels of rate limits toe voor aanvallen op applicatieniveau.

Indamming op lange termijn en opruimen

• Verwijder backdoor-gebruikers, -rollen, -sleutels, geplande taken, Lambda-functies of containerimages die de aanvaller heeft toegevoegd.
• Herbouw workloads vanuit bewezen goede images en infrastructure as code in plaats van ze ter plekke te "reinigen".
• Los de grondoorzaak op: de te ruime rol, het gelekte geheim in de CI/CD-pipeline, de niet-gepatchte image.
• Voeg een vangrail toe (policy-as-code, SCP, Azure Policy) zodat dezelfde misconfiguratie niet kan terugkeren.

Herstel en validatie

Herstel kritieke diensten eerst vanuit schone back-ups en controleer daarna de integriteit: draai tests, vergelijk de configuratie met IaC en controleer of toegangsbeleid is zoals bedoeld. Houd de getroffen accounts gedurende een vastgestelde periode, bijvoorbeeld 30 dagen, extra scherp in de gaten, omdat aanvallers vaak proberen terug te keren. Uw ontwerp voor cloud disaster recovery bepaalt hoe snel deze stap kan gaan.

Stap 5: communicatie, juridische zaken en wettelijke termijnen

Meldtermijnen beginnen te lopen wanneer u zich van het incident bewust wordt, niet wanneer het onderzoek eindigt. Neem ze met benoemde eigenaren in het plan op.

NIS2 is een richtlijn, dus het nationale recht bepaalt de exacte autoriteit en het meldformat; controleer de implementatie in uw land. Controleer ook klantcontracten: veel B2B-overeenkomsten kennen eigen meldtermijnen.

Bereid sjablonen voor interne updates, klantberichten en meldingen aan toezichthouders vooraf voor. Spreek een meldmatrix op basis van ernst af: wie wordt geïnformeerd bij kritiek, hoog, gemiddeld en laag, en hoe snel. Laat externe verklaringen altijd via juridische zaken lopen.

Stap 6: test, meet en verbeter

Oefeningen

• Tabletop-oefeningen minstens twee keer per jaar: loop een gelekte toegangssleutel, een gecompromitteerde globale beheerder of ransomware op cloud-VM's door met technische, juridische en communicatiemedewerkers aan tafel.
• Technische oefeningen minstens jaarlijks in een niet-productieaccount: voer de indammingsrunbooks echt uit en neem de tijd op.
• Herstelproeven die bewijzen dat u kunt herbouwen vanuit IaC en back-ups in een schoon account.

Metrics

Automatiseer de herhaalbare stappen

Automatisering haalt minuten van elk incident af. Veelvoorkomende kandidaten: een sleutel deactiveren die door GuardDuty is gemarkeerd, een instantie isoleren bij een bevinding met hoge ernst en een ticket openen met het bewijs erbij. In Azure doen playbooks van Microsoft Sentinel op basis van Logic Apps hetzelfde. Houd een menselijke goedkeuringsstap voor acties die een storing kunnen veroorzaken.

Platformnotities voor AWS, Azure en Google Cloud

AWS

• Gebruik een CloudTrail-trail voor de hele organisatie die alle regio's dekt, met managementgebeurtenissen en datagebeurtenissen voor gevoelige S3-buckets.
• Schakel GuardDuty in met een gedelegeerd beheerdersaccount en aggregeer bevindingen in AWS Security Hub.
• Stuur bevindingen met hoge ernst via Amazon EventBridge naar uw paging- of ITSM-tool, zodat een responder binnen minuten een melding krijgt.

Azure

• Schakel de relevante Microsoft Defender for Cloud-plannen in op alle abonnementen.
• Controleer toegang met aanmeld- en auditlogs van Microsoft Entra ID; gebruik Conditional Access om riskante aanmeldingen tijdens een incident te blokkeren.
• Gebruik analyseregels en playbooks van Microsoft Sentinel voor correlatie en respons.

Google Cloud

• Schakel Security Command Center in op organisatieniveau.
• Bewaar Cloud Audit Logs en VPC Flow Logs en exporteer ze naar een afgeschermd logproject.
• Google Security Operations (voorheen Chronicle) biedt SIEM en SOAR als u op Google standaardiseert.

Multi-cloud

De grootste zwakte bij multi-cloud is zichtbaarheid. Normaliseer logs van elke provider in één SIEM, hanteer één set ernstdefinities en schrijf runbooks die de equivalente actie op elk platform benoemen. Test de API-aanroepen waarvan uw automatisering afhangt, want providers wijzigen ze.

Hoe Opsio helpt

De SOC-dienst en managed detection and response van Opsio leveren 24/7-monitoring en -respons voor AWS- en Azure-omgevingen vanuit onze teams in Zweden en India. Wij helpen klanten hun plan te schrijven en te testen, centrale logging in te richten en de eerste indammingsstappen te automatiseren.

Voor Branäsgruppen, een van de grootste skiresortgroepen van Zweden, draait Opsio kritieke applicaties over meerdere Availability Zones met dagelijkse incrementele en wekelijkse volledige back-ups die 60 dagen worden bewaard. De casus Branäsgruppen meldt een gemiddelde van 2 dagen om kritieke problemen te identificeren en op te lossen en een uptime van applicaties van 99,9%+.

Veelgestelde vragen

Wat zijn de best practices voor incidentrespons in de cloud?

Schakel overal auditlogging in en sla die centraal op, volg NIST SP 800-61 Rev. 3, schrijf runbooks voor veelvoorkomende cloudincidenten, automatiseer het vastleggen van bewijs, dam in via identiteits- en netwerkcontroles, herbouw vanuit IaC en test het plan met regelmatige tabletop-oefeningen.

Hoe verschilt incidentrespons in de cloud van on-premises?

U deelt de verantwoordelijkheid met de provider, bewijs komt uit logs en API's in plaats van van fysieke schijven, resources kunnen in seconden verdwijnen en de meeste aanvallen gebruiken gestolen identiteiten. Indammen is meestal een IAM- of beleidswijziging in plaats van een server loskoppelen.

Wat hoort er in een sjabloon voor een responsplan voor cloudincidenten?

Scope en governance, rollen met plaatsvervangers en contactgegevens, ernstdefinities, logbronnen en bewaartermijnen, runbooks per incidenttype, omgang met bewijs, een meldmatrix met GDPR- en NIS2-termijnen, escalatiecontacten bij de provider, herstelstappen en een testschema.

Hoe integreert u incidentrespons met cloudbeveiligingstools?

Voer bevindingen van GuardDuty, Defender for Cloud of Security Command Center en identiteitslogs in één SIEM in, koppel elk type melding aan een runbook en automatiseer risicoarme eerste stappen zoals het deactiveren van een sleutel of het isoleren van een instantie, met menselijke goedkeuring voor ingrijpende acties.

Hoe vaak moet een responsplan voor cloudincidenten worden getest?

Houd minstens twee keer per jaar een tabletop-oefening, minstens één technische oefening per jaar en een extra review na elk groot incident of elke grote architectuurwijziging. Werk runbooks na elke test bij.