Pelnas:
- Gebėjimas klasifikuoti DI būdingus incidentų tipus ir sukurti atsako ciklą
- Gebėjimas apibrėžti vaidmenis, įgaliojimus ir teisinius pranešimo įsipareigojimus prieš renginį
- Gebėjimas sukurti nuolatinį tobulėjimą, užtikrinant veiklos tęstinumą ir be priekaištų po mirties
Nesvarbu, kaip gerai ginsite, vieną dieną kažkas nutiks negerai: nutekės raktas, veiks injekcija, suges paslaugų teikėjas arba išvestis pakenks klientui. Brandžią instituciją brandina ne įvykių nebuvimas, o pasiruošimas ir greitas įvykiui įvykus. Šiame skyriuje sužinosime DI specifinį reagavimo į incidentus planą, vaidmenis, veiksmus ir veiklos tęstinumą.
Kodėl DI atsakas į incidentus skiriasi?
Klasikinio saugumo incidento atveju dažnai pakanka „išjungti sistemą, izoliuoti“. Yra papildomų DI įvykių dimensijų: įvykis gali būti ne kode, o modelio elgesyje (pvz., sisteminga neteisinga / šališka išvestis); įrodymas yra raginimo / atsakymo žurnaluose; o "anuliuoti" kartais neįmanoma, nes klaidinga išvestis jau tapo sprendimu. Todėl AI incidentų planas turėtų apimti ir klasikinį saugumą, ir modelio elgesį.
Dėmesio: Įvykio metu planas nerašomas, jis vykdomas. Kas kam skambins, kas turi įgaliojimus „stabdyti sistemą“ ir kaip bus bendraujama, turi būti nuspręsta prieš renginį.
AI įvykių tipai
- Duomenų nutekėjimas: AII arba konfidencialūs duomenys nutekėjo (per raginimą, žurnalą arba išvestį).
- Saugumo pažeidimas: nutekėjo raktas, sėkminga injekcija, neteisėta prieiga.
- Kenksminga / šališka produkcija: modelis sistemingai davė neteisingą, diskriminacinį ar pavojingą atsaką.
- Paslaugos nutraukimas: teikėjas susidūrė arba viršijo greičio ribą; Sistema negali atsakyti.
- Piktnaudžiavimas: sistema buvo naudojama žalingiems tikslams, kuriems ji nebuvo sukurta.
Žingsnis po žingsnio: reagavimo į incidentus ciklas
- Aptikimas. Stebėjimo aliarmas, vartotojo skundas arba audito išvada atskleidžia incidentą.
- Rūšiuoti ir nustatyti prioritetus. Nurodykite lygius pagal poveikį ir sklaidą (pvz., P1 kritinis – P3 žemas).
- Sudėtyje. Sustabdykite plitimą: atšaukkite raktą, išjunkite funkciją, patraukite sistemą į tik skaitymo režimą.
- Išnaikinti ir atkurti. Ištaisykite pagrindinę priežastį, grįžkite į saugią būseną.
- Pranešti apie tai. Laiku informuoti apie teisinius / sutartinius pranešimo įsipareigojimus (pvz., KVKK 72 val.) ir tuos, kurie yra paveikti.
- Apžiūra po įvykio (postmortem). Nekaltindami dokumentuokite pagrindinę priežastį ir nuolatinį sprendimą.
Vaidmenys ir pareigos
Turėtų būti aišku, kas ką daro incidento metu: incidento vadas (vienintelis asmuo, priimantis sprendimą), techninis atsakas (sistemos stabdymas / taisymas), ryšiai (klientas / vadovybė / reguliuotojas), teisinė / atitiktis (prievolė pranešti). Mažose komandose vienas žmogus gali imtis kelių vaidmenų, tačiau vaidmenys turi būti parašyti.
Keturi kopijuojami šablonai
Įvykio klasifikavimo raginimas:
Klasifikuokite šį įvykį: {{ event_description }}Nustatyti:- Tipas: duomenų nutekėjimas / saugos pažeidimas / kenkėjiška produkcija / gedimas / piktnaudžiavimas- Poveikis: kiek žmonių / įrašų, kokia duomenų klasė, pinigai / atitikties pasekmės? - Platinimas: sustabdytas ar tęsiamas? - Prioritetas: P1 / P2 / P3: + kas turėtų būti atliekama nedelsiant?
Pirmojo atsakymo (sulaikymo) kontrolinis sąrašas:
Per pirmąsias 30 minučių, kai incidentas patvirtinamas:- [ ] Išjunkite paveiktą funkciją / įrankį arba nustatykite tik skaitymo režimą - [ ] Atšaukti įtartinus raktus / seansus- [ ] Išsaugoti įrodymus (užšaldyti atitinkamus žurnalus, įrašyti trace_id)- [ ] Pranešti incidento vadui ir reikiamiems vaidmenims- [ ] Įdiegti laikiną saugųjį režimą / atsarginę kopiją.
Pranešimo juodraščio raginimas:
Parašykite vidinio pranešimo projektą apie šį incidentą: {{ incident_summary }}Turi būti nurodyta: kas atsitiko (ne technine kalba), kada buvo pastebėta, kokie duomenys/kas buvo paveiktas, kas buvo padaryta iki šiol, tolesni veiksmai, iš ko galima gauti papildomos informacijos. Neįtraukite spėlionių ar kaltinimų.
Pomirtinis skeletas:
Peržiūra po įvykio (be priekaištų):- Laiko juosta: aptikimas -> kontrolė -> atkūrimas (kas minutę) - Pagrindinė priežastis: technika + proceso dydis - Kas sekėsi gerai / kas blogai - Nuolatiniai pataisymai (kas, kada) - Stebėjimas / kontrolė, kad šis įvykis būtų užfiksuotas anksčiau nei vėliau
Silpnas raginimas / stiprus raginimas
prastas požiūris
Stiprus požiūris
Ekspromtu renginyje be plano
Iš anksto parašytas planas, vaidmenys ir autoritetai
Pirmiausia pasakykite "kas kaltas"
Iš pradžių izoliavimas, paskui pomirtinis be priekaištų
Atidėti / praleisti pranešimą
Pranešimas per teisinį laikotarpį (pvz., 72 valandos)
Laukiama, kol pasikartos tas pats įvykis
Nuolatinės kontrolės ištraukimas iš pomirtinio
Trys mini dėklai
1 atvejis – užfiksuotas per 72 valandų taisyklę. Vienos įmonės darbuotojas pastebėjo, kad dėl netinkamos konfigūracijos žurnale buvo palikta 1 200 klientų įrašų. Rašyto plano dėka incidento vadas buvo aiškus; Komanda uždarė prieigą per 40 minučių, o įstatymas pateikė KVKK pranešimą per 72 valandas. Savalaikis pranešimas žymiai sumažino nusikalstamumo riziką ir žalą reputacijai.
2 atvejis – tik skaitymo saugus režimas pašalino gedimą. Pagrindinis modelio tiekėjas išėjo 3 valandoms. Į įmonės veiklos tęstinumo planą buvo įtrauktas perėjimas prie atsarginės kopijos tiekėjo ir „saugiojo režimo“ (tik svarbios funkcijos). Nors vartotojai prarado visas funkcijas, sistema išliko; kritinės operacijos nesustojo.
3 atvejis – po mirties išvengta pasikartojimo. Sėkmingai atlikus netiesioginę injekciją, asistentui nutekėjo kito vartotojo duomenys. Nekaltinimas po mirties parodė, kad pagrindinė priežastis buvo <duomenų> izoliacijos trūkumas. Pridėtas nuolatinis pataisymas (izoliavimas + išvesties nuskaitymas + regresijos testas); Tos pačios klasės puolimas vėl nebuvo sėkmingas.
Patarimas: atlikite postmortem be priekaištų. Siekiama ne surasti žmones, o sustiprinti sistemą taip, kad nepasikartotų tas pats incidentas. Kaltinimo kultūra verčia žmones slėpti dalykus, ir tai yra pavojingiausia.
Dažnos klaidos
- Prieš renginį rašytinio plano ir vaidmenų pasiskirstymo neparengimas.
- Prieš perimdami kontrolę, įsivelkite į ginčą / kaltinimą.
- Trūksta teisinių pranešimo įsipareigojimų (KVKK/BDAR terminai).
- Sistemos atstatymas neišsaugant įrodymų (logų).
- Verslo tęstinumui neatsižvelgiama į atsarginės kopijos teikėją / saugųjį režimą.
- Nedaryti pomirtinio tyrimo ir palikti vietos tam pačiam įvykiui pasikartoti.
Apibendrinant
- Branda nėra įvykių nebuvimas; Tai reiškia, kad reikia pasiruošti ir greitai, kai tai atsitiks.
- AI įvykiai gali būti modelio elgesys, o ne kodas; įrodymas yra greito atsakymo žurnaluose ir atšaukimas ne visada įmanomas.
- Reagavimo ciklas: aptikti, klasifikuoti, sulaikyti, atkurti, pranešti, po mirties.
- Vaidmenys ir įgaliojimai (incidento vadas, techniniai, ryšių, teisiniai) turi būti pateikti raštu prieš renginį.
- Atsarginės kopijos teikėjas / saugus režimas, užtikrinantis veiklos tęstinumą; Nekaltinamas pomirtinis ir nuolatinė korekcija yra būtini įvykio pasekmėms.
Taikymo užduotis
Parašykite savo dirbtinio intelekto sistemos reagavimo į incidentus plano projektą: nurodykite tris labiausiai tikėtinus incidentų tipus, nurodykite pradinį 30 minučių izoliavimo kontrolinį sąrašą ir kiekvieno vaidmenis. Tada atlikite pratimą ant stalo: žingsnis po žingsnio žaiskite „rakto nutekėjimo“ scenarijų ir nurodykite bei pataisykite visus trūkstamus / dviprasmiškus jūsų plano punktus.
kontrolinis sąrašas
- [ ] Yra surašytas reagavimo į incidentą planas ir vaidmenų paskirstymas.
- [ ] Aišku, kas turi įgaliojimus „stabdyti sistemą“.
- [ ] Pirmųjų 30 minučių sulaikymo kontrolinis sąrašas paruoštas.
- [ ] Nustatyti teisinio pranešimo terminai ir atsakingas asmuo.
- [ ] Atsarginės kopijos teikėjas / saugusis režimas planuojamas veiklos tęstinumui.
- [ ] Kiekvienam incidentui atliekama postmortem ir nuolatinė korekcija be priekaištų.