Cloud Incident Response: AWS, Azure en GCP — Grondbeginselen

Waarom Cloud IR Anders Is

Incident response in cloudomgevingen is niet zomaar traditionele IR uitgevoerd op virtuele machines. De cloud introduceert fundamentele architecturale verschillen die de manier veranderen waarop onderzoeken worden gevoerd, bewijs wordt verzameld en indamming wordt uitgevoerd. Wie cloud IR behandelt als "hetzelfde maar op afstand" mist bewijsmateriaal, verprutst de indamming en vernietigt forensische artefacten.

Efemere infrastructuur is het meest verstorende verschil. In een on-premises omgeving staat een gecompromitteerde server op een rack, beschikbaar voor imaging en analyse voor onbepaalde tijd. In de cloud worden instanties op- en neergeschaald met auto-scaling groups, draaien containers minuten voordat ze worden vervangen, en voeren serverloze functies milliseconden uit. Het bewijsmateriaal dat u nodig hebt, kan letterlijk ophouden te bestaan in de tijd tussen detectie en het begin van uw onderzoek. Cloud IR moet snel zijn, en bij voorkeur geautomatiseerd, om bewijs vast te leggen voordat het verdwijnt.

API-gestuurde operaties betekenen dat bijna alles wat een aanvaller doet — en bijna alles wat u doet als reactie — een API-aanroep is. Het aanmaken van een instantie, het aanpassen van een beveiligingsgroep, data-exfiltratie uit een opslagbucket, privilege escalation via rolovername — dit zijn allemaal API-operaties die worden (of zouden moeten worden) gelogd. Dit is zowel een uitdaging als een voordeel. De uitdaging is het enorme volume en de complexiteit van API-logs. Het voordeel is dat cloudomgevingen een completere audittrail kunnen bieden dan de meeste on-premises omgevingen ooit bereiken, mits logging correct is geconfigureerd.

Identiteit is de perimeter. In traditionele omgevingen definiëren netwerksegmentatie en firewalls beveiligingsgrenzen. In de cloud is IAM het primaire controlevlak. Een aanvaller met geldige IAM-credentials kan resources benaderen ongeacht netwerklocatie. Cloud IR-onderzoeken richten zich daardoor sterk op identiteit: welke credentials zijn gecompromitteerd, welke rechten verleenden ze, welke acties zijn ondernomen en welke resources zijn benaderd.

Multi-region en multi-account complexiteit voegt onderzoeksomvang toe die niet bestaat in traditionele omgevingen. Een enkele gecompromitteerde IAM-gebruiker kan resources hebben benaderd in meerdere regio's, meerdere accounts en meerdere services. Het onderzoek moet al deze omvatten — een gecompromitteerde access key in us-east-1 kan zijn gebruikt om data te exfiltreren uit een bucket in eu-west-1 en crypto-mining instanties te starten in ap-southeast-1.

Het Gedeelde Verantwoordelijkheidsmodel

Voordat u een cloud-incident onderzoekt, moet u begrijpen waarvoor u verantwoordelijk bent — en waarvoor niet. Elke grote cloudleverancier hanteert een gedeeld verantwoordelijkheidsmodel dat beveiligingsverplichtingen verdeelt tussen de aanbieder en de klant. De verdeling varieert per servicetype:

Infrastructure as a Service (IaaS)

Voor IaaS (EC2, Azure VMs, Compute Engine) is de cloudleverancier verantwoordelijk voor de fysieke infrastructuur, hypervisor en host-besturingssysteem. U bent verantwoordelijk voor alles daarboven: het gastbesturingssysteem, applicatiestack, data, identiteitsbeheer, netwerkconfiguratie en firewallregels. Dit betekent dat OS-niveau forensics (bestandssystemen, processen, geheugen) uw verantwoordelijkheid is, maar dat u geen toegang hebt tot de hypervisor of onderliggende hardware. Bewijsverzameling moet plaatsvinden via API's en in-guest tooling.

Platform as a Service (PaaS)

Voor PaaS (RDS, Azure App Service, Cloud SQL) beheert de aanbieder daarnaast de runtime, middleware en het besturingssysteem. Uw forensische zichtbaarheid is beperkt tot applicatielogs, data en IAM. U kunt geen image maken van het onderliggende OS van een beheerde database — u kunt alleen werken met de logs en toegangsregistraties die de service biedt.

Software as a Service (SaaS)

Voor SaaS (Microsoft 365, Google Workspace, Salesforce) beheert de aanbieder alles behalve data en gebruikerstoegang. Uw onderzoeksomvang is beperkt tot auditlogs, gebruikersactiviteit en data. Dit is cruciaal om te begrijpen: u kunt geen geheugendump opvragen van de server waarop uw SaaS-applicatie draait.

Tijdens een incident moet u mogelijk de ondersteuning van de cloudleverancier voor incident response inschakelen. AWS, Azure en GCP bieden allemaal IR-ondersteuning via hun enterprise-ondersteuningsplannen, en sommige bieden speciale security IR-teams voor grote incidenten. Weet hoe u deze teams bereikt vóórdat een incident plaatsvindt.

Kritieke Logbronnen per Leverancier

De basis van cloud IR is logdata. Elke aanbieder biedt een distinct stelsel van logdiensten, en de namen, formaten en standaardconfiguraties verschillen aanzienlijk. Zorg dat deze zijn ingeschakeld en bewaard vóór een incident — retroactief inschakelen genereert geen historische data.

Amazon Web Services (AWS)

• CloudTrail: Registreert API-aanroepen in uw AWS-account. Dit is de belangrijkste logbron voor AWS IR. Elke API-aanroep — wie hem deed, van waar, wanneer en met welke parameters — wordt gelogd. Zorg dat CloudTrail is ingeschakeld in alle regio's (aanvallers opereren regelmatig in regio's die u niet gebruikt), met management events en optioneel data events (S3 object-niveau operaties, Lambda-aanroepen) ingeschakeld. Trail-logs moeten worden afgeleverd in een gecentraliseerde, onveranderlijke Amazon S3 bucket met Object Lock ingeschakeld om manipulatie te voorkomen.
• VPC Flow Logs: Leggen IP-verkeersmetadata vast (bron/doel-IP, poort, protocol, bytes, actie) voor netwerkinterfaces in uw VPC's. Geen pakketopnames — alleen metadata. Schakel in op VPC-niveau voor volledige dekking. Essentieel voor het detecteren van data-exfiltratie, laterale beweging en command-and-control verkeer.
• GuardDuty: De beheerde dreigingsdetectiedienst van AWS die CloudTrail, VPC Flow Logs en DNS-logs analyseert om bevindingen te genereren voor verdachte activiteit — verkenning, instantiecompromittering, credentialcompromittering en data-exfiltratie. GuardDuty-bevindingen zijn vaak het initiële detectiepunt voor cloud-incidenten.
• S3 Access Logs / S3 CloudTrail Data Events: Registreren toegang tot Amazon S3 objecten. Cruciaal voor het onderzoeken van data-exfiltratie. S3 access logs bieden gedetailleerde informatie op verzoeksniveau; CloudTrail data events bieden API-niveau records van GetObject, PutObject en DeleteObject operaties.
• CloudWatch Logs: Gecentraliseerde logaggregatie voor applicatielogs, Lambda-functielogs en aangepaste logstreams. Amazon EC2-instanties vereisen de CloudWatch-agent om OS-niveau logs door te sturen.
• Route 53 DNS Query Logs: Registreren DNS-query's aan Route 53 Resolver. Nuttig voor het detecteren van DNS-gebaseerde data-exfiltratie en C2-communicatie.

Microsoft Azure

• Azure Activity Log: Registreert besturingsvlakoperaties (resource aanmaken, aanpassen, verwijderen) in uw Azure-abonnement. Equivalent aan CloudTrail management events. Standaard 90 dagen bewaard — exporteer naar een Log Analytics workspace of opslagaccount voor langere bewaring.
• Entra ID (Azure AD) Sign-in Logs en Audit Logs: Registreren gebruikersauthenticatiegebeurtenissen (geslaagde en mislukte aanmeldingen, MFA-uitdagingen, evaluaties van voorwaardelijke toegang) en directorywijzigingen (gebruikersaanmaken, rollenbenoemingen, applicatieregistraties). Cruciaal voor het onderzoeken van identiteitscompromittering. Sign-in Logs bevatten risicodetecties — onmogelijke reizen, anonieme IP, onbekende aanmeldingseigenschappen.
• NSG Flow Logs: Network Security Group flow logs, equivalent aan VPC Flow Logs. Registreren toegestaan en geweigerd verkeer op het niveau van de netwerkbeveiligingsgroep. Schakel versie 2 in voor aanvullende velden inclusief overgedragen bytes.
• Microsoft Defender for Cloud: Beheer van beveiligingshouding en dreigingsdetectie. Genereert beveiligingswaarschuwingen voor verdachte activiteit in Azure-resources, vergelijkbaar met GuardDuty.
• Key Vault Audit Logs: Registreren toegang tot geheimen, sleutels en certificaten. Essentieel bij het onderzoeken of credentials opgeslagen in Key Vault zijn benaderd door een gecompromitteerde identiteit.
• Azure Storage Analytics Logs: Registreren lees-, schrijf- en verwijderoperaties op Azure Storage. Schakel diagnostische instellingen in op opslagaccounts om deze events vast te leggen.

Google Cloud Platform (GCP)

• Google Cloud Audit Logs — Admin Activity: Registreren administratieve operaties (resource aanmaken, IAM-beleidswijzigingen, configuratiewijzigingen). Standaard ingeschakeld, kan niet worden uitgeschakeld, 400 dagen bewaard. Equivalent aan CloudTrail management events.
• Google Cloud Audit Logs — Data Access: Registreren lees-/schrijfoperaties op data. Niet standaard ingeschakeld voor de meeste services (moet expliciet worden geconfigureerd). Kan een hoog volume genereren — schakel selectief in voor gevoelige resources. Standaard 30 dagen bewaard.
• VPC Flow Logs: Registreren netwerkverkeersmetadata voor VPC-subnetten. Vergelijkbaar met AWS VPC Flow Logs. Schakel in op subnetniveau. Configureerbare steekproefsnelheid en aggregatie-interval.
• Cloud DNS Logs: Registreren DNS-query's. Nuttig voor het detecteren van DNS-tunneling en C2-communicatie.
• Security Command Center: Het geïntegreerde security- en risicobeheerplatform van GCP. De Premium-versie bevat dreigingsdetectie (Event Threat Detection, Container Threat Detection) die bevindingen genereert voor verdachte activiteit.

Cloudspecifieke Aanvalspatronen

Cloudomgevingen introduceren aanvalsvectoren die niet bestaan in traditionele infrastructuur. Het begrijpen van deze patronen is essentieel voor effectief onderzoek.

• Gecompromitteerde IAM-credentials: De meest voorkomende cloud-aanvalsvector. Credentials lekken via coderepositories, phishing, misbruik van de metadataservice (SSRF naar de instantiemetadataservice op 169.254.169.254) of gecompromitteerde CI/CD-pipelines. Eenmaal verkregen opereert de aanvaller met de rechten die de credentials verlenen — wat in omgevingen met te permissieve IAM-beleidslijnen verwoestend kan zijn.
• Fout geconfigureerde opslagbuckets: Publieke Amazon S3 buckets, Azure Blob containers en GCS-buckets blijven gevoelige data blootstellen. De aanval kan zo eenvoudig zijn als het oplijsten van een openbaar toegankelijke bucket en het downloaden van de inhoud. Controleer bucket-policies, ACL's en de "Block Public Access"-instellingen (AWS) of equivalente controls.
• Privilege escalation via rolkoppeling: Een aanvaller met beperkte rechten ontdekt dat hij een meer bevoorrechte rol kan overnemen, die een nog meer bevoorrechte rol kan overnemen, of nieuwe credentials met verhoogde rechten kan aanmaken. In AWS manifesteert dit zich als sts:AssumeRole-ketens. In GCP als service account impersonation-ketens. Het CloudTrail- of Audit Log-record toont het escalatiepad.
• Resource hijacking: Gecompromitteerde cloud-accounts worden regelmatig gebruikt om cryptocurrency-mining instanties te starten. De aanvaller start de grootste beschikbare instantietypen in meerdere regio's. De eerste indicator is vaak een piek in het cloud-factureringsdashboard of een factureringsmelding. Tegen de tijd dat u onderzoek doet, heeft de aanvaller mogelijk al honderden instanties opgestart.
• Data-exfiltratie via snapshot of export: In plaats van data te downloaden via netwerkverbindingen (wat DLP of flow log-meldingen kan triggeren), kunnen aanvallers een EBS snapshot, RDS snapshot of opslagbucket delen met een extern account dat ze beheren. Dit is een API-operatie, geen netwerkoverdracht — het verschijnt alleen in CloudTrail of equivalente logs, niet in VPC Flow Logs.
• Laterale beweging via service accounts: Cloudworkloads krijgen service accounts of instantieprofielen met IAM-rollen toegewezen. Het compromitteren van een workload geeft de aanvaller toegang tot de rechten van de rol — wat vaak toegang omvat tot andere clouddiensten, databases, opslag en secrets managers.

Indamming in de Cloud

Cloud-indammingsstrategieën verschillen fundamenteel van on-premises aanpakken. U kunt een server niet fysiek loskoppelen. U kunt niet naar een rack lopen en een netwerkkabel uittrekken. Alles wordt gedaan via API-aanroepen, en elke actie moet zorgvuldig worden overwogen op het effect op bewijsbewaring.

Identiteitsindamming

Bij gecompromitteerde IAM-credentials richt indamming zich op het intrekken van toegang met behoud van de audittrail:

• Actieve sessies intrekken: In AWS voegt u een inline-beleid toe dat alle acties weigert voor sessies die zijn uitgegeven vóór de huidige tijd (met de aws:TokenIssueTime conditiesleutel). In Azure trekt u alle refresh tokens in voor de gecompromitteerde gebruiker via Entra ID. In GCP trekt u OAuth-tokens in voor het service account.
• Credentials roteren: Deactiveer en vervang access keys (verwijder niet — de key ID is nodig voor CloudTrail-correlatie). Reset wachtwoorden. Genereer nieuwe service account-sleutels.
• IAM-beleidslijnen beperken: Pas een alles-weiger-beleid toe op de gecompromitteerde entiteit. Verwijder de gebruiker of rol niet — dit vernietigt de IAM-beleidsgeschiedenis en breekt de audittrail. Voeg in plaats daarvan een restrictief beleid toe dat alle rechten overschrijft.
• Persistentiemechanismen controleren en verwijderen: Controleer op door aanvallers aangemaakte access keys, overgenomen rollen, federatieconfiguraties, OAuth-applicaties en service account-sleutels die alternatieve toegangspaden bieden.

Netwerkindamming

• Beveiligingsgroep aanpassen: Vervang de beveiligingsgroep van de instantie door een geïsoleerde beveiligingsgroep die geen inkomend of uitgaand verkeer toestaat (behalve van het IP-adres van uw forensisch onderzoeksteam). In AWS treden wijzigingen in beveiligingsgroepen onmiddellijk in werking, maar verbreken geen bestaande verbindingen — u moet mogelijk de netwerkinterface herstarten.
• Network ACL's: Pas weigerregels toe op subnetniveau voor bredere isolatie. NACL's zijn stateless en treden onmiddellijk in werking, ook voor bestaande verbindingen.
• WAF-regels: Als de aanvalsvector een webapplicatie is, implementeer dan WAF-regels om de IP-adressen van de aanvaller of schadelijke verzoekpatronen te blokkeren terwijl het onderzoek voortgaat.

Compute-indamming

Het cruciale principe voor compute-indamming is: maak eerst een snapshot voordat u actie onderneemt, en beëindig nooit een instantie die u niet heeft bewaard.

• Schijfsnapshots aanmaken: Maak vóór elke indammingsactie een snapshot van alle volumes die zijn gekoppeld aan de gecompromitteerde instantie. Dit bewaart de bestandssysteemstatus op het moment van onderzoek. In AWS gebruikt u create-snapshot voor elk EBS-volume. In Azure maakt u een schijfsnapshot. In GCP maakt u een persistent disk snapshot.
• Instantiemetadata vastleggen: Registreer de configuratie van de instantie, beveiligingsgroepen, IAM-rol, user data, tags en netwerkinterfaces. Deze metadata kan veranderen tijdens indamming of herstel en kan later niet worden hersteld.
• Isoleer, beëindig niet: Verplaats de instantie naar een quarantaine-VPC of subnet zonder internettoegang en zonder toegang tot andere productieresources. Stop of beëindig de instantie niet — vluchtig bewijs (draaiende processen, netwerkverbindingen, geheugen) gaat verloren wanneer de instantie stopt. Als geheugenacquisitie nodig is, installeer dan een geheugenacquisitietool (zoals LiME voor Linux) en leg de geheugendump vast voordat u de instantie stopt.

Opslagindamming

• Versiebeheer inschakelen: Als nog niet ingeschakeld, schakel versiebeheer in op gecompromitteerde opslagbuckets om te voorkomen dat de aanvaller bewijs permanent verwijdert.
• Toegangsbeleid beperken: Pas bucket-policies aan om alle toegang te weigeren behalve van de IP-adressen en IAM-identiteiten van het onderzoeksteam.
• Object Lock inschakelen: Voor Amazon S3 buckets met cruciaal bewijsmateriaal, schakel Object Lock in compliance-modus in om verwijdering of aanpassing te voorkomen, zelfs door het rootaccount.

Bewijsverzameling

Bewijsverzameling in de cloud kent unieke uitdagingen die proactieve voorbereiding vereisen. U kunt logging niet retroactief inschakelen, bewaring niet verlengen of beëindigde instanties niet herstellen.

Voorbereiding vóór het Incident

• Schakel logging overal in, voordat u het nodig heeft. CloudTrail in alle regio's (inclusief regio's die u niet gebruikt). VPC Flow Logs op alle VPC's. DNS-query logging. Data access auditlogs op gevoelige resources. Cloudleverancier beveiligingsdiensten (GuardDuty, Defender, SCC). De meest voorkomende bevinding na een incident is "het log dat we nodig hadden was niet ingeschakeld."
• Centraliseer en bescherm logopslag. Stuur alle logs naar een gecentraliseerde, onveranderlijke opslaglocatie — een Amazon S3 bucket met Object Lock, een Log Analytics workspace met onveranderlijke bewaring, of een GCS-bucket met een bewaarbeleid. Gebruik een apart, beperkt account (een "security"- of "log archive"-account) dat niet toegankelijk is vanuit de productieomgeving. Als de aanvaller uw productieaccount compromitteert maar niet uw log-archief, is uw bewijs bewaard.
• Verleng standaard bewaartermijnen. Standaard bewaring voor veel cloudlogs is 90 dagen of minder. Veel inbreuken worden pas na maanden gedetecteerd. Configureer bewaartermijnen van minimaal 365 dagen voor beveiligingsrelevante logs. De kosten van logopslag zijn verwaarloosbaar vergeleken met de kosten van een inbreukonderzoek met ontbrekend bewijs.
• Pre-stage IR-rollen en -toegang. Maak speciale IR IAM-rollen met break-glass toegang tot onderzoeksrelevante services en resources. Deze rollen moeten slapend zijn tijdens normale operaties en alleen worden geactiveerd tijdens incidenten. Documenteer het activeringsproces. Test het voordat u het nodig heeft.

Verzameling Tijdens het Incident

Bij het verzamelen van bewijs tijdens een actief incident, volg deze prioriteitsvolgorde om het meest vluchtige bewijs als eerste vast te leggen:

1. Geheugen van draaiende instantie — meest vluchtig, verloren bij stoppen/beëindigen
2. Netwerkstatus van draaiende instantie — actieve verbindingen, luisterende poorten
3. Processtatus van draaiende instantie — proceslijsten, open bestanden
4. Schijfsnapshots — persistent maar mogelijk aangepast door de aanvaller
5. Cloud API-logs — persistent indien correct geconfigureerd en bewaard
6. IAM-beleidslijnen en configuraties — kunnen worden aangepast tijdens incident
7. Netwerkconfiguraties — beveiligingsgroepen, NACL's, routetabellen

Voor elk stuk verzameld bewijs, registreert u een bewaarderingsketen: wat is verzameld, wanneer, door wie, van waar en hoe. Gebruik cryptografische hashes (SHA-256) om integriteit te verifiëren. Bewaar bewijs op een speciale, toegangsgecontroleerde, onveranderlijke opslaglocatie gescheiden van de gecompromitteerde omgeving.

Cloud IR-toolkit

Een groeiend ecosysteem van tools ondersteunt cloud incident response. Het samenstellen van uw toolkit vóór een incident is essentieel — u wilt geen tools evalueren tijdens een crisis.

AWS

• AWS IR Playbooks (aws-incident-response-playbooks): Open-source playbooks voor veelvoorkomende AWS-incidentscenario's — gecompromitteerde IAM-credentials, blootgestelde Amazon S3 buckets, gecompromitteerde Amazon EC2 instanties.
• Prowler: Open-source beveiligingsbeoordelingstool die uw AWS-omgeving evalueert aan de hand van honderden controles op basis van CIS-benchmarks, PCI-DSS en AWS-best practices. Nuttig voor het identificeren van misconfiguraties die de aanval mogelijk maakten.
• ScoutSuite: Multi-cloud beveiligingsauditingtool die configuratiedata verzamelt van AWS, Azure en GCP en beveiligingsrisico's identificeert. Genereert een uitgebreid rapport van uw cloud-beveiligingshouding.
• CloudTrail Lake: De beheerde CloudTrail-querydienst van AWS die SQL-gebaseerde analyse van CloudTrail-events mogelijk maakt. Nuttig voor complexe query's over grote hoeveelheden auditdata tijdens onderzoeken.

Azure

• AzureHound: Open-source tool voor het in kaart brengen van Azure AD en Azure Resource Manager-relaties, nuttig voor het begrijpen van privilege escalation-paden en laterale bewegingsmogelijkheden.
• Microsoft Incident Response tools: Het IR-team van Microsoft gebruikt en documenteert publiek tools voor Azure-onderzoek, inclusief KQL-query's voor Sentinel en Log Analytics.
• Azure Resource Graph: Maakt het mogelijk om resourceconfiguraties te bevragen over abonnementen heen. Nuttig voor het snel beoordelen van de omvang van een incident in een grote Azure-omgeving.

GCP

• Security Command Center (Premium): Biedt dreigingsdetectie (Event Threat Detection, Container Threat Detection), kwetsbaarheidsscanning en activumsinventaris. De onderzoeksomgeving ondersteunt forensische query's over auditlogs.
• GCP Policy Analyzer: Analyseert IAM-beleidslijnen om te bepalen welke identiteiten toegang hebben tot welke resources. Essentieel voor het begrijpen van de blast radius van een gecompromitteerd service account.

Cross-Cloud

• Steampipe: Open-source tool die cloud-API's blootstelt als SQL-tabellen, waardoor SQL-query's mogelijk zijn over AWS, Azure, GCP en tientallen andere clouddiensten. Krachtig voor multi-cloud onderzoeksquery's.
• CloudQuery: Open-source cloud-activumsinventaris die cloudconfiguratie en auditdata synchroniseert naar een database voor analyse. Nuttig voor het bouwen van een bevraagbare inventaris van uw cloudomgeving.
• Cartography: Open-source tool van Lyft die een grafiekdatabase maakt van uw cloudinfrastructuur en relaties in kaart brengt tussen resources, identiteiten en netwerkpaden. Onmisbaar voor het begrijpen van laterale bewegingspaden en blast radius-analyse.

Cloud IR-gereedheid Opbouwen

Organisaties die effectief reageren op cloud-incidenten zijn degenen die zich vóór het incident hebben voorbereid. Cloud IR-gereedheid is geen eenmalig project — het is een doorlopende praktijk die moet evolueren naarmate uw cloudomgeving groeit en verandert.

• Schakel logging uitgebreid in. Als er één actie is die u neemt na het lezen van dit artikel, laat het deze zijn: audit elk cloud-account en zorg ervoor dat alle beveiligingsrelevante logging is ingeschakeld, gecentraliseerd en minimaal 365 dagen bewaard. Deze ene stap heeft meer impact op uw IR-capaciteit dan welke andere ook.
• Houd cloudarchitectuurdiagrammen bij. Tijdens een incident moeten responders snel de omgeving begrijpen — welke accounts bestaan, welke services zijn ingezet, hoe ze verbinding maken, waar gevoelige data zich bevindt. Geautomatiseerde tools zoals CloudQuery, Steampipe of native cloud-activumsinventarissen kunnen up-to-date architectuurkaarten genereren.
• Pre-stage geautomatiseerde bewijsverzameling. Schrijf en test scripts die automatisch schijfsnapshots, instantiemetadata, geheugendumps en logexports vastleggen. Wanneer een incident optreedt, is handmatige bewijsverzameling te traag voor efemere omgevingen. Automatisering zorgt voor consistente, volledige en tijdige verzameling.
• Voer cloudspecifieke tabletop-oefeningen uit. Traditionele tabletop-oefeningen gaan vaak uit van on-premises infrastructuur. Ontwerp oefeningen die specifiek het vermogen van uw team testen om te onderzoeken in cloudomgevingen — gecompromitteerde IAM-credentials, blootstelling van publieke buckets, crypto-mining in ongebruikte regio's, cross-account laterale beweging.
• Stel cloudleverancier IR-contacten vast. Weet hoe u het security IR-team van uw cloudleverancier bereikt voordat u ze nodig heeft. Voor AWS is dit het AWS Customer Incident Response Team (CIRT). Voor Azure is dit Microsoft DART. Voor GCP is dit het Google Cloud Incident Response team. Begrijp welke ondersteuning uw contractniveau u biedt.

"In cloud IR begint het incident response-proces maanden voor het incident. De logging die u vandaag inschakelt, de bewaring die u vandaag configureert en de IR-rollen die u vandaag pre-staget bepalen of u effectief kunt onderzoeken wanneer een inbreuk plaatsvindt."

Cloudomgevingen veranderen de praktijk van incident response fundamenteel, maar de kernprincipes blijven hetzelfde: bereid u van tevoren voor, detecteer snel, dam beslist in, bewaar bewijs zorgvuldig en leer van elk incident. Organisaties die cloud IR behandelen als een eigen discipline — niet als een bijgedachte geplakt op hun bestaande IR-programma — zijn degenen die cloud-incidenten aanpakken met de snelheid en precisie die deze omgevingen vereisen.