Добици:
- Способност да се класификују типови инцидената специфичних за вештачку интелигенцију и дизајнира циклус одговора
- Способност дефинисања улога, овлашћења и законских обавеза извештавања пре догађаја
- Способност успостављања трајног побољшања уз континуитет пословања и постмортем без кривице
Без обзира колико добро то браните, једног дана ће нешто поћи наопако: кључ ће процурити, ињекција ће радити, провајдер ће се срушити или ће излаз нанети штету купцу. Оно што зрелу институцију чини зрелом није одсуство догађаја, већ спремност и брза припрема када се догађај деси. У овој јединици ћемо научити план реаговања на инциденте специфичан за вештачку интелигенцију, улоге, кораке и континуитет пословања.
Зашто је одговор на инциденте другачији у АИ?
У класичном безбедносном инциденту често је довољно „угасите систем, изолујте“. Постоје додатне димензије за АИ догађаје: догађај можда није у коду, већ у понашању модела (нпр. систематски нетачан/пристрасан излаз); доказ се налази у дневнику промпта/одговора; а "поништити" понекад није могуће јер је погрешан излаз већ постао одлука. Стога, план инцидената АИ треба да покрије и класичну безбедност и модел понашања.
Пажња: У тренутку инцидента план није написан, већ се спроводи. Ко ће кога звати, ко има овлашћења да „заустави систем” и како ће се комуникација одвијати мора се одлучити пре догађаја.
Типови АИ догађаја
- Цурење података: ПИИ или поверљиви подаци су процурили (преко упита, евиденције или излаза).
- Кршење безбедности: процурео кључ, успешно убризгавање, неовлашћени приступ.
- Штетан/пристрасан резултат: Модел је систематски производио нетачан, дискриминаторски или опасан одговор.
- Прекид услуге: Провајдер се срушио или достигао ограничење брзине; Систем не може да одговори.
- Злоупотреба: Систем је коришћен у штетне сврхе за које није дизајниран.
Корак по корак: Циклус одговора на инциденте
- Детецтион. Аларм за праћење, жалба корисника или налаз ревизије открива инцидент.
- Сортирајте и одредите приоритете. Наведите нивое на основу утицаја и ширења (нпр. П1 критичан – П3 низак).
- Садржи. Зауставите ширење: опозовите кључ, искључите функцију, повуците систем да буде само за читање.
- Искоренити и опоравити. Поправите основни узрок, вратите се у безбедно стање.
- Пријавите то. Обавестите благовремено о законским/уговорним обавезама обавештавања (као што је КВКК 72 сата) и онима на које то утиче.
- Преглед након догађаја (постмортем). Без окривљавања, документујте основни узрок и трајно решење.
Улоге и одговорности
Требало би да буде јасно ко шта ради у инциденту: командир инцидента (једина особа која доноси одлуку), технички одговор (заустављање/поправка система), комуникације (купац/менаџмент/регулатор), правни/усаглашеност (обавеза извештавања). У малим тимовима једна особа може преузети неколико улога, али улоге морају бити написане.
Четири шаблона за копирање
Упит за класификацију догађаја:
Класификујте следећи догађај: {{ евент_десцриптион }}Идентификујте:- Тип: цурење података / кршење безбедности / злонамерни излаз / прекид рада / злоупотреба- Утицај: колико људи/записа, која класа података, новац/последице усаглашености?- Ширење: заустављено или у току?- Приоритет: П1 / П2 / П3: шта треба одмах урадити - први контролни корак?
Контролна листа за први одговор (задржавање):
У првих 30 минута када је инцидент потврђен:- [ ] Онемогућите захваћену функцију/алатку или је поставите на само за читање- [ ] Откажите сумњиве кључеве/сесије- [ ] Сачувајте доказе (замрзните релевантне евиденције, запис траце_ид)- [ ] Обавестите командира инцидента и потребне улоге- [ ] Поставите / вратите привремени безбедни режим
Упозорење о нацрту обавештења:
Напишите нацрт интерног обавештења за следећи инцидент: {{ инцидент_суммари }}Мора да садржи: шта се догодило (на нетехничком језику), када је примећено, на које податке/ко је то утицало, шта је до сада урађено, следеће кораке, од кога се могу добити додатне информације. Немојте укључивати спекулације или оптужбе.
Постмортем скелет:
Преглед након догађаја (без кривице):- Временски оквир: откривање -> контрола -> опоравак (у минуту)- Основни узрок: техника + величина процеса- Шта је прошло добро / шта је лоше- Трајне исправке (ко, када)- Надгледање/контрола да би се овај догађај ухватио пре него касније
Слаба порука / јака промпт
лош приступ
Снажан приступ
Импровизација на догађају без плана
Унапред написани план, улоге и овлашћења
Прво реци "ко је крив"
Прво задржавање, а затим постмортем без кривице
Одлагање/прескакање обавештења
Обавештење у законском року (нпр. 72 сата)
Чекајући да се исти догађај понови
Извлачење трајне контроле из постмортема
Три мини кућишта
Случај 1 — Ухваћен у оквиру правила 72 сата. Запослени у једној компанији приметио је да је 1.200 података о клијентима остало изложено у дневнику због погрешне конфигурације. Захваљујући писаном плану, командант инцидента је био јасан; Тим је затворио приступ за 40 минута, а закон је обавестио КВКК у року од 72 сата. Правовремено пријављивање значајно је смањило ризик од криминала и репутацију.
Случај 2 — Безбедни режим само за читање решио је нестанак. Главни добављач модела је нестао на 3 сата. План континуитета пословања компаније укључивао је прелазак на провајдера резервних копија и „безбедни режим“ (само критичне функције). Иако су корисници изгубили пуну функционалност, систем је преживео; критичне операције нису престајале.
Случај 3 — Постмортем је спречио понављање. Успешно индиректно убризгавање је процурило податке другог корисника до помоћника. Обдукција без окривљавања показала је да је основни узрок недостатак <података> изолације. Додата трајна поправка (изолација + скенирање излаза + регресиони тест); Иста класа напада поново није била успешна.
Савет: Обавите обдукцију без кривице. Циљ није проналажење људи, већ јачање система на начин који неће дозволити поновни исти инцидент. Култура кривице доводи до тога да људи крију ствари, а то је најопасније.
Уобичајене грешке
- Не припрема писани план и расподелу улога пре догађаја.
- Улазак у свађу/окривљавање пре преузимања контроле.
- Недостају обавезе правног обавештавања (КВКК/ГДПР рокови).
- Ресетовање система без очувања доказа (логова).
- Не узимајући у обзир провајдера резервних копија/безбедни режим за континуитет пословања.
- Не радити обдукцију и оставити простор да се исти догађај понови.
Укратко
- Зрелост није одсуство догађаја; То значи бити спреман и брз када се то догоди.
- АИ догађаји могу бити у понашању модела пре него у коду; доказ се налази у евиденцији одзива/одговора и поништавање није увек могуће.
- Циклус одговора: открити, класификовати, задржати, опоравити, пријавити, постмортем.
- Улоге и овлашћења (командант инцидента, технички, комуникациони, правни) треба да буду у писаној форми пре догађаја.
- Добављач резервних копија/безбедни режим за континуитет пословања; Постмортем без кривице и трајна корекција су од суштинског значаја за последице догађаја.
Задатак апликације
Напишите нацрт плана реаговања на инциденте за свој систем вештачке интелигенције: наведите три највероватнија типа инцидента, идентификујте почетну контролну листу од 30 минута и улоге за сваки. Затим урадите стону вежбу: Одиграјте сценарио „процурели кључ“ корак по корак и укажите и исправите све недостајуће/двосмислене тачке у вашем плану.
контролна листа
- [ ] Постоји писани план реаговања на инцидент и расподела улога.
- [ ] Јасно је ко има овлашћења да „заустави систем“.
- [ ] Прва контролна листа за задржавање од 30 минута је спремна.
- [ ] Дефинисани су рокови правног обавештавања и одговорно лице.
- [ ] Добављач резервних копија/безбедни режим планиран за континуитет пословања.
- [ ] За сваки инцидент се врши обдукција без кривице и трајна корекција.