Jednotka 10 / 11

Reakce na incidenty a kontinuita podnikání

zisky:

  • Schopnost klasifikovat typy incidentů specifické pro AI a navrhnout cyklus odezvy
  • Schopnost definovat role, pravomoci a zákonné oznamovací povinnosti před akcí
  • Schopnost zavést trvalé zlepšování s kontinuitou podnikání a bez viny po smrti

Bez ohledu na to, jak dobře to budete bránit, jednoho dne se něco pokazí: klíč unikne, injekce bude fungovat, poskytovatel se zhroutí nebo výstup poškodí zákazníka. To, co činí zralou instituci zralou, není absence událostí, ale připravenost a rychlost, když k události dojde. V této jednotce se naučíme plán reakce na incidenty specifický pro AI, role, kroky a kontinuitu podnikání.

Proč je reakce na incidenty v AI jiná?

Při klasickém bezpečnostním incidentu často stačí „vypnout systém, izolovat“. Události AI mají další dimenze: událost nemusí být v kódu, ale v chování modelu (např. systematický nesprávný/zaujatý výstup); důkaz je v protokolech výzev/odpovědí; a "zrušit" někdy není možné, protože chybný výstup se již stal rozhodnutím. Proto by měl plán incidentů AI pokrývat jak klasické zabezpečení, tak chování modelu.

Pozor: V době incidentu není plán sepsán, je realizován. Kdo komu zavolá, kdo má pravomoc „zastavit systém“ a jak bude probíhat komunikace, se musí rozhodnout ještě před akcí.

Typy událostí AI

  • Únik dat: Únik osobních údajů nebo důvěrných údajů (prostřednictvím výzvy, protokolu nebo výstupu).
  • Narušení bezpečnosti: Uniklý klíč, úspěšné vložení, neoprávněný přístup.
  • Škodlivý/objektivní výstup: Model systematicky produkoval nesprávnou, diskriminační nebo nebezpečnou reakci.
  • Výpadek služby: Poskytovatel havaroval nebo překročil rychlostní limit; Systém nemůže reagovat.
  • Zneužívání: Systém byl použit ke škodlivému účelu, pro který nebyl navržen.

Krok za krokem: Cyklus odezvy na incident

  1. Detekce. Monitorovací alarm, stížnost uživatele nebo nález auditu odhalí incident.
  2. Třídit a upřednostňovat. Uveďte úrovně na základě dopadu a šíření (např. P1 kritické – P3 nízké).
  3. Obsahovat. Zastavte šíření: zrušte klíč, vypněte funkci, přepněte systém do režimu pouze pro čtení.
  4. Vymýtit a obnovit. Opravte hlavní příčinu, vraťte se do bezpečného stavu.
  5. Nahlaste to. Včas informovat zákonné/smluvní oznamovací povinnosti (např. KVKK 72 hodin) a dotčené osoby.
  6. Vyšetření po události (postmortem). Bez kladení viny zdokumentujte hlavní příčinu a trvalou opravu.

Role a odpovědnosti

Mělo by být jasné, kdo co při incidentu dělá: velitel incidentu (jediná osoba, která rozhoduje), technická reakce (zastavení/oprava systému), komunikace (zákazník/vedení/regulátor), právní předpisy/dodržování (povinnost hlásit). V malých týmech může jeden člověk zastávat několik rolí, ale role musí být napsané.

Čtyři kopírovatelné šablony

Výzva ke klasifikaci události:

Klasifikujte následující událost: {{ event_description }}Identifikujte:- Typ: únik dat / narušení zabezpečení / škodlivý výstup / výpadek / zneužití- Dopad: kolik lidí/záznamů, jaká datová třída, peníze/důsledky pro dodržování předpisů?- Šíření: zastavené nebo probíhající?- Priorita: P1 / P2 / P3 + zdůvodnění- První kontrolní krok: co je třeba udělat okamžitě?

Kontrolní seznam první reakce (uzavření):

Během prvních 30 minut, kdy je incident potvrzen:- [ ] Vypněte dotčenou funkci/nástroj nebo jej nastavte na pouze pro čtení- [ ] Zrušte podezřelé klíče/relace- [ ] Zachovejte důkazy (zmrazení příslušných protokolů, zaznamenejte trace_id)- [ ] Informujte velitele incidentu a požadované role- [ ] Nasaďte dočasný bezpečný režim / postup zálohování

Výzva konceptu oznámení:

Napište návrh interního oznámení pro následující incident: {{ incident_summary }}Musí obsahovat: co se stalo (netechnickým jazykem), kdy to bylo zaznamenáno, jaká data/kdo byl ovlivněn, co bylo dosud provedeno, další kroky, od koho lze získat další informace. Nezahrnujte spekulace nebo obvinění.

Posmrtná kostra:

Kontrola po události (bez výčitek):- Časová osa: detekce -> kontrola -> obnova (minimálně)- Hlavní příčina: technika + velikost procesu- Co šlo dobře / co se nepovedlo- Trvalé opravy (kdo, kdy)- Monitorování/kontrola, abyste tuto událost zachytili dříve než později

Slabá výzva / Silná výzva

špatný přístup

Silný přístup

Improvizované na akci bez plánu

Předem napsaný plán, role a pravomoci

Nejprve řekněte „kdo je vinen“

Nejprve zadržení, pak posmrtně bez viny

Upozornění na zpoždění/přeskočení

Oznámení v zákonné lhůtě (např. 72 hodin)

Čekání, až se stejná událost bude opakovat

Získání trvalé kontroly z postmortem

Tři mini pouzdra

Případ 1 – Chycen během pravidla 72 hodin. Zaměstnanec jedné společnosti si všiml, že 1 200 záznamů zákazníků zůstalo v protokolu odhaleno kvůli nesprávné konfiguraci. Díky sepsanému plánu měl velitel incidentu jasno; Tým uzavřel přístup do 40 minut a zákon provedl oznámení KVKK do 72 hodin. Včasné nahlášení významně snížilo riziko trestné činnosti a poškození pověsti.

Případ 2 – Výpadek vyřešil nouzový režim pouze pro čtení. Hlavní poskytovatel modelu vypadl na 3 hodiny. Plán firemní kontinuity zahrnoval přechod na poskytovatele zálohování a „bezpečný režim“ (pouze kritické funkce). Přestože uživatelé ztratili plnou funkčnost, systém přežil; kritické operace se nezastavily.

Případ 3 – Posmrtné zabránění opakování. Úspěšná nepřímá injekce unikla asistentovi data jiného uživatele. Neobviňování posmrtně ukázalo, že hlavní příčinou byla nedostatečná izolace <data>. Přidána trvalá oprava (izolace + výstupní skenování + regresní test); Stejná třída útoku opět nebyla úspěšná.

Tip: Proveďte pitvu bez viny. Cílem není najít lidi, ale posílit systém způsobem, který nedovolí opakovat stejný incident. Kultura viny způsobuje, že lidé věci skrývají, a to je nejnebezpečnější.

Časté chyby

  • Nepřipravovat písemný plán a rozdělení rolí před akcí.
  • Dostat se do hádky/obvinění před převzetím kontroly.
  • Chybějící zákonné oznamovací povinnosti (lhůty KVKK/GDPR).
  • Resetování systému bez uchování důkazů (logů).
  • Neuvažuje se o poskytovateli zálohování/bezpečném režimu pro kontinuitu podnikání.
  • Nedělat pitvu a ponechat prostor pro opakování stejné události.

V souhrnu

  • Zralost není nepřítomnost událostí; Znamená to být připraven a rychle, když se to stane.
  • Události AI mohou být spíše v chování modelu než v kódu; důkaz je v protokolech výzev/odpovědí a zvrácení není vždy možné.
  • Cyklus odezvy: detekovat, klasifikovat, obsahovat, obnovovat, hlásit, posmrtně.
  • Role a pravomoci (velitel incidentu, technické, komunikační, právní) by měly být písemné před akcí.
  • Poskytovatel zálohování/bezpečný režim pro kontinuitu podnikání; Posmrtná pitva bez viny a trvalá náprava jsou nezbytné pro následky události.

Aplikační úkol

Napište návrh plánu reakce na incidenty pro svůj vlastní systém AI: uveďte tři nejpravděpodobnější typy incidentů, určete úvodní 30minutový kontrolní seznam a role pro každý z nich. Pak proveďte stolní cvičení: Přehrajte si scénář „uniklý klíč“ krok za krokem a ukažte a opravte všechny chybějící/nejednoznačné body ve vašem plánu.

kontrolní seznam

  • [ ] Existuje písemný plán reakce na incidenty a rozdělení rolí.
  • [ ] Je jasné, kdo má pravomoc „zastavit systém“.
  • [ ] Prvních 30 minut kontrolního seznamu je připraven.
  • [ ] Jsou definovány zákonné oznamovací lhůty a odpovědná osoba.
  • [ ] Poskytovatel zálohování/bezpečný režim plánovaný pro kontinuitu provozu.
  • [ ] U každého incidentu se provádí bezúhonná posmrtná a trvalá náprava.