RB-TRIAGE-011: Triage van alerts van het cloudplatform

Documentbeheer

Kenmerk	Waarde	Datum
Documentnaam	Triage van alerts van het cloudplatform	[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

Een alert van een cloud-native securitydienst (bijv. AWS GuardDuty, Microsoft Defender for Cloud, GCP Security Command Center, Oracle Cloud Guard of vergelijkbaar)
Leestoegang tot het cloudaccount / de subscription / het project / de tenancy waaruit de alert komt
Leestoegang tot de relevante auditlog van de cloud control plane (CloudTrail, Azure Activity, GCP Admin Activity, Oracle Audit)
Toegang tot de SIEM waarheen de cloudtelemetrie wordt doorgestuurd
Console of CLI van de cloudprovider voor het getroffen account
Console van de cloud-native securitydienst (die de alert gaf)

2. Stap-voor-stap-instructies

Veelgemaakte fouten

De alert sluiten voordat is gecontroleerd of de activiteit nog gaande is

Een alert over één resource los bekijken zonder aangrenzende resources te controleren die dezelfde identiteit, rol of VPC delen

Aannemen dat een onschuldig klinkende alert (bijv. Recon:EC2/Portscan) weinig risico heeft, terwijl die wijst op actieve verkenning vanaf een workload in handen van een aanvaller

Leg de details van de alert vast
- Leg alert-ID, brondienst, severity, type bevinding en tijdstip vast
- Leg het getroffen cloudaccount / de subscription / het project / de tenancy vast
- Leg de getroffen resource vast (instance-ID, container-/pod-ID, functienaam, storage bucket, database)
- Leg de identiteit vast die bij de activiteit hoort (gebruiker, rol, service account, workload identity)
- Leg de betrokken bron-IP's, regio's, user-agents en doeldiensten vast
Bevestig dat de alert echt is
- Controleer of het bron-IP / de user-agent / de regio overeenkomt met bekende betrouwbare infrastructuur (CI/CD, jump hosts, automatisering)
- Controleer of de actie gedocumenteerd of verwacht is (bijv. recente deployment, change-ticket, geplande job)
- Controleer in de log van de cloud control plane of dezelfde actor in de periode vóór de alert vergelijkbare activiteit uitvoerde
- Is de activiteit verwacht → sluit af als onschuldig, leg de onderbouwing vast en verlaat het runbook
Stel vast of de activiteit nog actief is
- Doorzoek de log van de cloud control plane op de identiteit uit de alert in de laatste 15 minuten
- Doorzoek de workload-telemetrie (EDR, OS-logs die naar de SIEM gaan) op lopende proces- of netwerkactiviteit
Stel de scope van de activiteit vast
- Maak een lijst van elke resource die de identiteit uit de alert in het incidentvenster heeft aangeraakt (log van de control plane)
- Maak een lijst van elke regio waarin de activiteit is waargenomen
- Maak een lijst van elke andere identiteit die mogelijk vanaf hetzelfde bron-IP / dezelfde sessie is gebruikt
Classificeer de activiteit
- Deel de alert in bij een van de volgende:
  - Afwijkend gedrag van een workload (cryptomining, reverse shell, onverwacht uitgaand verkeer)
  - Misbruik van de control plane (IAM-wijziging, aanmaken van resources, sabotage van securitydiensten)
  - Misbruik van credentials (gebruik van een credential vanuit een nieuwe regio / bron / user-agent)
  - Verkenning (portscan, aftasten van IMDS, opsommen van buckets / rollen)
  - Afwijkende toegang tot data (ongebruikelijk patroon van toegang tot buckets / databases)

3. Na afloop

Zorg dat alle details van de alert, de gebruikte queries en de bevindingen in het incidentticket zijn vastgelegd

Bijdrager

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

Heeft bijgedragen aan het Arcana Incident Response Documentation Framework.