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