Winst:
- Mogelijkheid om AI-specifieke incidenttypen te classificeren en een responscyclus te ontwerpen
- Mogelijkheid om rollen, bevoegdheden en wettelijke rapportageverplichtingen vóór het evenement te definiëren
- Mogelijkheid om permanente verbetering tot stand te brengen met bedrijfscontinuïteit en schuldvrije postmortem
Hoe goed je het ook verdedigt, op een dag gaat er iets mis: een sleutel lekt, een injectie werkt, een provider crasht of een output schaadt een klant. Wat een volwassen instelling volwassen maakt, is niet de afwezigheid van gebeurtenissen, maar het voorbereid en snel zijn als er zich een gebeurtenis voordoet. In deze unit leren we een AI-specifiek incidentresponsplan, rollen, stappen en bedrijfscontinuïteit.
Waarom is incidentrespons anders bij AI?
Bij een klassiek beveiligingsincident is ‘het systeem afsluiten, isoleren’ vaak voldoende. Er zijn extra dimensies aan AI-gebeurtenissen: de gebeurtenis bevindt zich mogelijk niet in een code, maar in het gedrag van het model (bijvoorbeeld systematisch onjuiste/bevooroordeelde uitvoer); het bewijs staat in de prompt/responslogboeken; en "ongedaan maken" is soms niet mogelijk omdat de foutieve uitvoer al een beslissing is geworden. Daarom moet het AI-incidentenplan zowel klassieke beveiliging als modelgedrag omvatten.
Let op: Op het moment van het incident wordt er geen plan geschreven, maar uitgevoerd. Wie wie zal bellen, wie de bevoegdheid heeft om “het systeem te stoppen” en hoe de communicatie zal plaatsvinden, moet vóór de gebeurtenis worden besloten.
AI-gebeurtenistypen
- Datalek: PII of vertrouwelijke gegevens zijn uitgelekt (via prompt, log of output).
- Inbreuk op de beveiliging: gelekte sleutel, succesvolle injectie, ongeautoriseerde toegang.
- Schadelijke/bevooroordeelde output: Het model produceerde systematisch een onjuist, discriminerend of gevaarlijk antwoord.
- Servicestoring: provider is gecrasht of heeft de snelheidslimiet overschreden; Het systeem kan niet reageren.
- Misbruik: Het systeem is gebruikt voor een schadelijk doel waarvoor het niet is ontworpen.
Stap voor stap: Incidentresponscyclus
- Detectie. Een monitoringalarm, een gebruikersklacht of een auditbevinding brengt het incident aan het licht.
- Sorteer en prioriteer. Geef niveaus op basis van impact en spreiding (bijvoorbeeld P1 kritisch – P3 laag).
- Bevatten. Stop de verspreiding: trek de sleutel in, schakel de functie uit, zet het systeem op alleen-lezen.
- Uitroeien en herstellen. Verhelp de hoofdoorzaak, keer terug naar de veilige staat.
- Rapporteer het. Informeer tijdig wettelijke/contractuele meldplichten (zoals KVKK 72 uur) en betrokkenen.
- Onderzoek na de gebeurtenis (postmortem). Documenteer, zonder de schuld te geven, de hoofdoorzaak en de permanente oplossing.
Rollen en verantwoordelijkheden
Het moet duidelijk zijn wie wat doet bij een incident: incidentcommandant (enige persoon die de beslissing neemt), technische respons (stoppen/repareren van het systeem), communicatie (klant/management/toezichthouder), legal/compliance (meldplicht). In kleine teams kan één persoon meerdere rollen op zich nemen, maar de rollen moeten wel geschreven worden.
Vier kopieerbare sjablonen
Prompt voor gebeurtenisclassificatie:
Classificeer de volgende gebeurtenis: {{ event_description }} Identificeer: - Type: datalek / inbreuk op de beveiliging / kwaadwillige uitvoer / uitval / misbruik - Impact: hoeveel mensen/records, welke gegevensklasse, geld/compliance-gevolgen? - Verspreiding: gestopt of aan de gang? - Prioriteit: P1 / P2 / P3 + rechtvaardiging - Eerste controlestap: wat moet onmiddellijk worden gedaan?
Controlelijst voor eerste reactie (insluiting):
In de eerste 30 minuten wanneer het incident wordt bevestigd: - [ ] Schakel de betrokken functie/tool uit of stel deze in op alleen-lezen - [ ] Annuleer verdachte sleutels/sessies - [ ] Bewaar bewijsmateriaal (bevries relevante logboeken, noteer trace_id) - [ ] Breng de incidentcommandant en de vereiste rollen op de hoogte - [ ] Implementeer een tijdelijke veilige modus/back-upstroom
Melding conceptprompt:
Schrijf een concept interne melding voor het volgende incident: {{ incident_summary }}Moet bevatten: wat er is gebeurd (in niet-technische taal), wanneer het werd opgemerkt, welke gegevens/wie erdoor werd getroffen, wat er tot nu toe is gedaan, volgende stappen, van wie aanvullende informatie kan worden verkregen. Voeg geen speculaties of beschuldigingen toe.
Postmortaal skelet:
Beoordeling na het evenement (geen schuld): - Tijdlijn: detectie -> controle -> herstel (minuut) - Hoofdoorzaak: techniek + procesgrootte - Wat ging goed/wat ging slecht - Permanente oplossingen (wie, wanneer) - Monitoring/controle om deze gebeurtenis eerder dan later op te sporen
Zwakke prompt/sterke prompt
slechte aanpak
Sterke aanpak
Impromptu op het evenement zonder plan
Vooraf geschreven plan, rollen en bevoegdheden
Zeg eerst "wie is schuldig"
Eerst insluiting, daarna postmortem zonder schuld
Melding vertragen/overslaan
Kennisgeving binnen de wettelijke termijn (bijvoorbeeld 72 uur)
Wachten tot dezelfde gebeurtenis zich opnieuw voordoet
Permanente controle uit postmortem halen
Drie mini-hoesjes
Geval 1 – Gevangen binnen de 72-uurregel. Een medewerker van een bedrijf merkte op dat 1.200 klantgegevens in een logboek bleven staan als gevolg van een verkeerde configuratie. Dankzij het geschreven plan was de incidentcommandant duidelijk; Het team sloot de toegang binnen 40 minuten af en de wet deed de KVKK-melding binnen 72 uur. Tijdige melding verminderde het strafrechtelijke risico en de reputatieschade aanzienlijk.
Geval 2: de alleen-lezen veilige modus loste de storing op. De belangrijkste modelaanbieder ging 3 uur uit. Het bedrijfscontinuïteitsplan van het bedrijf omvatte het overstappen naar een back-upprovider en de "veilige modus" (alleen kritieke functies). Hoewel gebruikers de volledige functionaliteit verloren, overleefde het systeem; kritische operaties stopten niet.
Geval 3 — Postmortem voorkwam herhaling. Bij een succesvolle indirecte injectie lekten de gegevens van een andere gebruiker naar een assistent. Post-mortem zonder de schuld te geven toonde aan dat de hoofdoorzaak het gebrek aan <data>-isolatie was. Permanente oplossing toegevoegd (isolatie + outputscan + een regressietest); Dezelfde aanvalsklasse was opnieuw niet succesvol.
Tip: voer het postmortem uit zonder schuldgevoel. Het doel is niet om mensen te vinden, maar om het systeem zodanig te versterken dat hetzelfde incident zich niet nogmaals voordoet. Een schuldcultuur zorgt ervoor dat mensen dingen verbergen, en dit is het gevaarlijkst.
Veel voorkomende fouten
- Geen schriftelijk plan en rolverdeling voorbereiden vóór het evenement.
- Een ruzie/schuld krijgen voordat je de controle overneemt.
- Ontbrekende wettelijke meldingsplichten (KVKK/GDPR deadlines).
- Het systeem resetten zonder bewijsmateriaal (logs) te bewaren.
- Geen back-upprovider/veilige modus overwegen voor bedrijfscontinuïteit.
- Geen postmortem doen en ruimte laten voor herhaling van dezelfde gebeurtenis.
Samengevat
- Volwassenheid is niet de afwezigheid van gebeurtenissen; Het betekent dat je voorbereid en snel moet zijn als het gebeurt.
- AI-gebeurtenissen kunnen modelgedrag zijn in plaats van code; het bewijs staat in de prompt-/responslogboeken en ongedaan maken is niet altijd mogelijk.
- Reactiecyclus: detecteren, classificeren, bevatten, herstellen, rapporteren, postmortem.
- Rollen en bevoegdheden (incidentcommandant, technisch, communicatie, juridisch) moeten vóór het evenement schriftelijk worden vastgelegd.
- Back-upprovider/veilige modus voor bedrijfscontinuïteit; Schuldvrije postmortem en permanente correctie zijn essentieel voor de nasleep van de gebeurtenis.
Applicatie taak
Schrijf een concept-incidentresponsplan voor uw eigen AI-systeem: maak een lijst van de drie meest waarschijnlijke incidenttypen, identificeer een eerste controlelijst van 30 minuten en de rollen voor elk. Doe dan een tafeloefening: speel stap voor stap het “sleutel gelekte” scenario na en wijs eventuele ontbrekende/dubbelzinnige punten in uw plan aan en corrigeer deze.
controlelijst
- [ ] Er is een schriftelijk incidentresponsplan en rolverdeling.
- [ ] Het is duidelijk wie de bevoegdheid heeft om "het systeem te stoppen".
- [ ] De eerste controlelijst voor de insluiting van 30 minuten is gereed.
- [ ] Wettelijke meldingstermijnen en verantwoordelijke persoon zijn gedefinieerd.
- [ ] Back-upprovider/veilige modus gepland voor bedrijfscontinuïteit.
- [ ] Voor elk incident worden schuldvrije postmortale en permanente correcties uitgevoerd.