Een incidentresponsplan voor Workspace-beveiligingsincidenten zorgt dat je niet hoeft te improviseren als het misgaat. Het verschil tussen een beheersbaar incident en een ramp zit vaak in de eerste uren. Wie weet wat te doen, handelt snel; wie eerst moet uitzoeken wie verantwoordelijk is, verliest kostbare tijd.
De fases van incidentresponse
Een gangbaar model kent zes fases. Je doorloopt ze niet altijd strikt lineair, maar ze geven structuur aan je aanpak.
| Fase | Doel | Voorbeeld in Workspace |
|---|---|---|
| Voorbereiding | Plan, rollen en tooling klaar hebben | Incidentteam en toegang tot Admin-console en Vault |
| Detectie | Incident herkennen via alerts en logs | Alert center en beveiligingsdashboard |
| Indamming | Verspreiding stoppen, account schorsen | Account schorsen, sessies intrekken |
| Uitroeiing | Oorzaak wegnemen | Malafide filters en OAuth-apps verwijderen |
| Herstel | Veilig weer in productie brengen | Account vrijgeven na verificatie |
| Evaluatie | Leren en plan verbeteren | Tabletop-oefening en lessons learned |
Voorbereiding: de fase die telt
De meeste winst zit in de voorbereiding. Leg vooraf vast wie het incidentteam vormt, wie mag besluiten om een account te schorsen en hoe je communiceert. Zorg dat het team de juiste toegang heeft tot de Admin-console en Vault voordat er iets misgaat.
Rollen vastleggen
Bepaal vooraf wie de incidentcoordinator is, wie technisch handelt in de Admin-console, wie juridisch en communicatie afstemt en wie de eindbeslissingen neemt. Zonder duidelijke rollen ontstaat verwarring precies op het moment dat snelheid telt.
Detectie: hoe weet je dat er iets mis is
Detectie leunt op monitoring. Stel waarschuwingsregels in voor verdachte loginpogingen, massale downloads, nieuwe doorstuurregels en wijzigingen in beheerdersrechten. Het beveiligingsdashboard en het alert center in de Admin-console zijn je startpunt. Vanuit het alert center kun je vaak direct een aanbevolen actie uitvoeren, zoals het schorsen van het betrokken account.
Controleer altijd de filters
Een veelvoorkomend signaal van accountovername is een automatische doorstuurregel of filter die de aanvaller heimelijk instelt om mee te lezen. Controleer bij elk verdacht account altijd de Gmail-filters en doorstuurinstellingen. Een vergeten malafide filter laat de aanvaller terugkomen nadat je denkt het account te hebben beveiligd.
Indamming bij een gehackt account
Stel: een account is overgenomen. Snelheid is nu alles. Werk de stappen in vaste volgorde af zodat je niets overslaat.
Gehackt account indammen
- Schors het account direct in de Admin-console om verdere acties te stoppen.
- Reset het wachtwoord en forceer uitloggen op alle apparaten via Sessies intrekken.
- Controleer en verwijder malafide Gmail-filters, doorstuurregels en delegaties.
- Controleer recent toegevoegde app-wachtwoorden en OAuth-tokens en trek die in.
- Bekijk de audit-logs om te bepalen welke data is benaderd of gedeeld.
- Controleer of er onterecht beheerdersrechten zijn toegekend aan het account.
- Herstel de tweestapsverificatie en geef het account pas vrij na verificatie van de gebruiker.
Schorsen kan altijd terug
Een schorsing blokkeert alleen het inloggen. De mailbox, Drive-bestanden, gedeelde links en agenda-items blijven intact en je kunt het account later weer activeren. Twijfel je of je moet ingrijpen? Schors dan eerst en onderzoek daarna; je verliest geen data.
Uitroeiing en herstel
Na de indamming verwijder je de oorzaak. Dat kan een gecompromitteerde OAuth-app zijn, een phishing-link die nog rondgaat of een kwetsbare instelling. Pas daarna breng je het account of de dienst veilig terug in productie.
Documenteer tijdens het hele proces wat je doet en wanneer. Deze tijdlijn heb je nodig voor de evaluatie en mogelijk voor een datalekmelding. Zie de GDPR-checklist voor de 72-uurs meldplicht en forensisch onderzoek voor diepere analyse.
Evaluatie en verbetering
Na elk incident houd je een evaluatie. Wat ging goed, wat kon beter, welke detectie ontbrak? Verwerk de lessen in je plan, want een incidentresponsplan dat niet wordt bijgewerkt veroudert snel.
Een handige tijdlijn om aan te houden:
- Direct: incident indammen en team activeren.
- Binnen 24 uur: impact bepalen en melding overwegen.
- Binnen 72 uur: datalekmelding indienen indien vereist.
- Week 1: volledig herstel en verificatie.
- Week 2: evaluatie en lessons learned vastleggen.
- Doorlopend: plan en detectie bijwerken.
Hoe vaak moet ik het plan testen?
Minstens jaarlijks via een tabletop-oefening waarin je een scenario doorspeelt. Een ongetest plan blijkt in de praktijk vaak gaten te bevatten.
Wie mag besluiten een account te schorsen?
Leg dit vooraf vast. Vaak is dat de incidentcoordinator of een aangewezen beheerder. Bij twijfel gaat snelheid boven hierarchie, want je kunt een schorsing altijd terugdraaien.
Moet ik elk incident melden bij de toezichthouder?
Nee. Alleen datalekken met een risico voor betrokkenen meld je binnen 72 uur bij de Autoriteit Persoonsgegevens. Niet elk beveiligingsincident is een meldplichtig datalek.
Hoe behoud ik bewijs voor onderzoek?
Trek logs en relevante data uit Vault voordat bewaarregels ze verwijderen. Zet zo nodig een Vault-hold op de betrokken accounts om verwijdering te voorkomen.
Wat doe ik als meerdere accounts tegelijk zijn getroffen?
Behandel het als een breder incident: schaal je team op, schors alle verdachte accounts en zoek naar een gemeenschappelijke oorzaak, zoals een phishingcampagne of een lekgeraakte OAuth-app.
Met een geoefend plan, duidelijke rollen en werkende detectie verklein je de schade van elk incident. De techniek in Workspace om in te grijpen is er; het plan zorgt dat je die op het juiste moment gebruikt.