Sukurkite rizikų registrą, kuris keičia sprendimus

Rizikų registras pateisina savo vietą, kai keičia prioritetus, išteklius ar įgyvendinimą. Jis turėtų padėti inžinerijos vadovui nuspręsti, ar atidėti leidimą, apriboti teisę, finansuoti atkūrimo darbus ar priimti riziką apibrėžtam laikotarpiui. Raudonų, geltonų ir žalių įrašų sąrašo nepakanka.

Pradėkite nuo scenarijų, kuriuos verslas gali atpažinti, o ne nuo etikečių, tokių kaip „kibernetinė rizika“. Tada kiekvieną scenarijų susiekite su paveikta paslauga, vertinimo įrodymais, kontrolės priemonėmis, rizikos valdymo darbais ir atsakingu sprendimų priėmėju. Registras tampa naudingas, kai kas nors gali atsekti šią grandinę ir paaiškinti, kodėl kitas veiksmas svarbus.

Prieš kurdami registrą apibrėžkite sprendimus

Pradėkite nuo vieno produkto, verslo proceso ar valdomos paslaugos. Nustatykite jo kritines priklausomybes, svarbią informaciją, išorės teikėjus ir veiklos apribojimus. Sutelkta riba leidžia lengviau išbandyti metodą prieš taikant jį visoje organizacijoje.

Paklauskite žmonių, kurie naudos registrą, kokius sprendimus jiems reikia priimti. Platformos vadovui gali tekti rinktis tarp atkūrimo gerinimo ir pasenusio komponento pakeitimo. Klientų aptarnavimo vadovui gali tekti patvirtinti siauresnę prieigą nesutrikdant klientų aptarnavimo. CTO gali tekti nuspręsti, ar paleidimas gali vykti su nebaigtais rizikos valdymo darbais.

Prieš rinkdami balus apibrėžkite vertinimo metodą ir patvirtinimo taisykles. Praktiškai rekomenduojame dokumentuoti:

• Vertinimo laikotarpį, pavyzdžiui, riziką per artimiausius dvylika mėnesių.
• Tikimybės ir poveikio apibrėžtis, įskaitant tai, kaip tvarkomi prieštaringi poveikio aspektai.
• Rizikos apetitą ir veiklos tolerancijos ribas.
• Kas gali patvirtinti rizikos valdymo priemones ir priimti likutinę riziką.
• Peržiūrų intervalus ir įvykius, kuriems įvykus reikia pakartotinio vertinimo.

Rizikos apetitas išreiškia rizikos rūšis ir lygius, kurių organizacija yra pasirengusi siekti ar kuriuos išlaikyti. Tolerancija šią poziciją paverčia naudojamomis ribomis, pavyzdžiui, didžiausia priimtina prastova ar nekontroliuojamo klientų duomenų eksporto apribojimais.

ISMS, suderintoje su ISO/IEC 27001, rizikos vertinimą ir valdymą reglamentuoja 6.1.2 ir 6.1.3 punktai. 8.2 punktas reikalauja vertinimų suplanuotais intervalais ir tada, kai įvyksta ar siūlomi reikšmingi pokyčiai. Standartas nenustato vieno universalaus metinio tvarkaraščio ar balų matricos. Jūsų metodas turi veikti faktinėje ISMS apimtyje.

Kiekvienam įrašui suteikite pakankamai struktūros veiksmams pagrįsti

Registrą galima pradėti skaičiuoklėje. Jo naudingumas priklauso nuo ryšių, atsakomybės ir palaikymo, o ne nuo failo formato. Labiau susieti įrankiai tampa vertingi, kai dėl rankinio suderinimo šie ryšiai tampa nepatikimi.

Naudokite stabilų identifikatorių ir nedidelį laukų rinkinį, atsakantį į praktinius klausimus. Ilgus techninius įrodymus laikykite susietuose įrašuose, o ne kopijuokite į kiekvieną eilutę.

Atskirkite rizikos būseną nuo užduoties būsenos. „Rizikos valdymas vyksta“ nereiškia, kad rizika sumažėjo. „Priimta“ nereiškia, kad scenarijus išnyko. Uždarymą palikite tokioms aplinkybėms kaip paveiktos veiklos pabaiga ar scenarijaus nebeaktualumas, ir išsaugokite motyvus.

Taip pat pažeidžiamumas, neveikianti kontrolės priemonė ir rizika yra susiję, bet skirtingi įrašai. Trūkstamas pataisymas yra silpnybė. Nepavykusi diegimo patikra yra kontrolės priemonės problema. Rizika apibūdina, kas gali nutikti dėl šių sąlygų ir kodėl tai svarbu. Išsamius radinius susiekite su tuo scenarijumi, užuot kūrę atskirą organizacijos lygmens riziką kiekvienam skenerio rezultatui.

Scenarijus atraskite iš to, kaip paslauga veikia

Rizikoms nustatyti naudokite architektūros ir veiklos įrodymus. Į sutelktą diskusiją pakvieskite inžinerijos, saugumo, paslaugų savininkų, klientų aptarnavimo ir atitinkamų verslo funkcijų atstovus. Vien politikos retai atskleidžia, kur teisės platesnės nei numatyta, kur atkūrimas priklauso nuo vieno žmogaus ar kur tiekėjas tapo kritine priklausomybe.

Naudingi įvesties duomenys – duomenų srautų diagramos, prieigos peržiūros, incidentų įrašai, atkūrimo testai, tiekėjų vertinimai, pažeidžiamumų radiniai, pakeitimų pasiūlymai ir neišspręstos audito pastabos. Grėsmių modeliavimas gali padėti komandoms išnagrinėti pasitikėjimo ribas ir tikėtinus gedimų kelius.

Naudingas scenarijus atitinka šį modelį: įvykis per nustatomą silpnybę paveikia konkrečią paslaugą ir sukelia nurodytas pasekmes.

Pavyzdžiui: kompromituota pagalbos tarnybos paskyra leidžia eksportuoti klientų įrašus, nes teisės per plačios, o tai sukelia neteisėtą atskleidimą ir reagavimo darbus. Tai labiau įgyvendinama nei „paskyros kompromitavimas“. Taip nustatomas ir atakos kelias, ir kontrolės priemonės, galinčios jį nutraukti.

Žvelkite plačiau nei konfidencialumas. Įtraukite sutrikimus, sugadintus įrašus, nepavykusį atkūrimą, tiekėjų veiklos sutrikimus, piktnaudžiavimą administracinėmis teisėmis ir nepasiekiamą kompetenciją. DI funkcijų atveju apsvarstykite, ar pagal neteisingus rezultatus gali būti imamasi veiksmų, ar jautri informacija gali patekti į netinkamą paslaugą ir ar agentas gali veikti viršydamas numatytus įgaliojimus.

Scenarijų dublikatus šalinkite atsargiai. Dvi paslaugos gali naudoti tą patį tapatybės teikėją, tačiau turėti skirtingas pasekmes ir rizikos valdymo galimybes. Ir atvirkščiai, keli radiniai gali prisidėti prie vieno eksporto scenarijaus. Sujunkite, kai sprendimas ir atsakingas asmuo bendri; atskirkite, kai skiriasi verslo pasekmės ar rizikos valdymo sprendimai.

Aptikimo spragas fiksuokite kaip darbą. Jei niekas nežino, kurie klientai naudoja eksporto funkciją, šis neapibrėžtumas turėtų tapti tyrimo užduotimi, o ne išgalvotu poveikio įverčiu.

Vertinkite riziką nesukurdami tariamo tikslumo

Nustatykite bendrą vertinimo kalbą

Tikimybei ir poveikiui reikia apibrėžčių, kurias vertintojai galėtų taikyti nuosekliai. Vertindami tikimybę atskirkite grėsmės aktyvumą nuo tikimybės, kad visas scenarijus pavyks. Dažni sukčiavimo bandymai automatiškai nereiškia dažno masinio atskleidimo: kelią veikia autentifikavimas, teisės, sesijų kontrolė ir eksporto apribojimai.

Poveikis turėtų atspindėti verslo rezultatą. Kai svarbu, atsižvelkite į paslaugos nutraukimą, atskleidimą, vientisumo praradimą, reagavimo išlaidas, sutartines pasekmes ir žalą paveiktiems žmonėms. Dokumentuokite agregavimo taisyklę. Jei metodas naudoja aukščiausią reikšmingą poveikio aspektą, tai nurodykite; kitaip vidurkis gali paslėpti rimtą konfidencialumo pasekmę už mažesnių veiklos padarinių.

Paprasta ranginė matrica gali padėti atlikti pirminį rūšiavimą. Tačiau sudauginus du kategorijų skaičius gaunamas indeksas, o ne išmatuota tikimybė ar piniginis nuostolis. Nesudėkite šių balų per visas paslaugas ir nevadinkite rezultato bendra organizacijos rizika. Įvertinimą naudokite kartu su pagrindimu, skubumu, neapibrėžtumu ir rizikos valdymo priklausomybėmis.

Vertinimus kalibruokite kartu. Paprašykite savininkų nepriklausomai įvertinti kelis tipiškus scenarijus, palyginkite jų motyvus ir išspręskite skirtumus remdamiesi apibrėžtimis. Tai naudingiau nei leisti kiekvienam padaliniui susikurti savo „aukšto“ interpretaciją.

Atskirkite prigimtinę, dabartinę likutinę ir tikslinę likutinę riziką

Aiškiai apibrėžkite prigimtinės rizikos bazinį lygį. Jis gali apibūdinti scenarijų be pasirinktų saugumo kontrolės priemonių, tačiau vis tiek turėtų nurodyti numatomą paslaugos architektūrą ir verslo veiklą. Kitaip vertintojai gali įsivaizduoti nesuderinamas „be kontrolės priemonių“ versijas.

Dabartinė likutinė rizika atspindi kontrolės priemones, kurios įgyvendintos ir pagrįstos atitinkamais veiksmingumo įrodymais. Tikslinė likutinė rizika yra tikėtina rizika po siūlomo rizikos valdymo. Abi laikykite matomas: planuojamas prieigos apribojimas neturi mažinti šiandieninio įvertinimo.

Ne kiekviena kontrolės priemonė keičia abu aspektus. Stipresnis autentifikavimas gali sumažinti tikimybę. Siauresnės eksporto teisės gali apriboti atskleidžiamų duomenų kiekį. Išbandytos reagavimo procedūros gali suvaldyti pasekmes po aptikimo. Aprašykite mechanizmą, o ne taikykite visuotinį procentinį sumažinimą vien todėl, kad kontrolės priemonė egzistuoja.

Išsaugokite neapibrėžtumą ir kiekybinę analizę taikykite atrankiai

Užfiksuokite prielaidas, įrodymų datas, aprėpties spragas ir pasitikėjimo lygį. „Ankstesnių incidentų nebuvo“ yra silpnas įrodymas, kai žurnalai negali aptikti įvykio. Žemas pasitikėjimas turėtų paskatinti tyrimą; jis neturėtų automatiškai lemti aukščiausio balo.

Brangiems rizikos valdymo sprendimams kokybinį vertinimą papildykite scenarijais grįsta finansine analize. Įvykių dažnumui ir pasekmėms naudokite intervalus, nustatykite pagrindinius išlaidų veiksnius ir patikrinkite, kaip sprendimas keičiasi esant skirtingoms prielaidoms. Modeliavimas gali padėti ištirti šiuos intervalus, tačiau negali ištaisyti nepagrįstų įvesties duomenų.

Iliustraciniam skaičiavimui tarkime, kad įvykio dažnumas yra nuo 0,05 iki 0,2 per metus, o nuostoliai – nuo 100 000 € iki 400 000 € vienam įvykiui. Sudauginus kraštines reikšmes gaunamas apytikslis metinis intervalas nuo 5 000 € iki 80 000 €. Tai įvestis diskusijai, o ne prognozė ar pagrindas ignoruoti retus, bet rimtus padarinius. Paaiškinkite, kokie papildomi įrodymai leistų susiaurinti intervalą.

Susiekite kontrolės priemones su gedimo keliu

Kontrolės priemonių susiejimas turėtų paaiškinti priežastingumą. Pagalbos tarnybos paskyros scenarijuje autentifikavimas skirtas paskyros perėmimui, autorizacija riboja prieinamus įrašus, eksporto apribojimai riboja duomenų ištraukimą, o stebėsena padeda aptikti. Politika, kurioje pripažįstamos prieigos atsakomybės, yra svarbi, tačiau neįrodo, kad šie techniniai apribojimai veikia.

Palaikykite ryšius „daug su daug“: viena tapatybės kontrolės priemonė gali palaikyti kelias rizikas, o viena rizika gali priklausyti nuo kelių kontrolės priemonių. Įtraukite apimtį ir priklausomybes. Autentifikavimo kontrolės priemonė, apimanti darbuotojus, bet neapimanti tiekėjų paskyrų, negali pagrįsti tos pačios išvados abiem grupėms.

Įvertinkite tris atskirus klausimus:

• Projektavimas: ar kontrolės priemonė nutrauktų ar suvaldytų scenarijų, jei veiktų taip, kaip numatyta?
• Įgyvendinimas: ar ji įdiegta visose atitinkamose sistemose, tapatybėse ir darbo eigose?
• Veikimas: ar dabartiniai įrodymai rodo, kad ji ir toliau veikia?

Prieigos apribojimų atveju įrodymai gali apimti vaidmenų apibrėžtis, faktinius priskyrimus, neigiamus autorizacijos testus ir atliktus pašalinimus. Atkūrimo atveju atsarginių kopijų konfigūracija įrodo mažiau nei atkūrimo testas su vientisumo patikromis ir išmatuotu atkūrimo rezultatu. Eksporto stebėsenos atveju parodykite, kad įvykis užfiksuojamas, įspėjimas pasiekia reaguojantį asmenį ir šis gali jį ištirti.

Kartu su įrodymais išsaugokite jų kilmę: šaltinį, surinkimo laiką, apimtį, peržiūrėtoją ir apribojimus. Įrodymų amžius priklauso nuo konteksto. Konfigūracijos eksportas gali pasenti po diegimo; pratybų rezultatas gali išlikti naudingas, kol nepasikeičia architektūra ar atsakomybės.

Nemažinkite likutinės rizikos tiesiogiai proporcingai atliktoms užduotims. Trys atliktos užduotys iš keturių nereiškia 75 % sumažėjimo. Trūkstama užduotis gali įgyvendinti vienintelę atskleidimą ribojančią kontrolės priemonę. Po patikrintų pakeitimų peržiūrėkite scenarijų, tada užfiksuokite, kodėl išvada pasikeitė.

Pasirinkite rizikos valdymo būdą ir aiškiai įvardykite kompromisą

Įprasti rizikos valdymo būdai – vengti, mažinti, pasidalyti ar perduoti ir priimti riziką. Juos galima derinti, tačiau kiekvienam reikia nurodyto tikslo.

Vengimas užbaigia ar pakeičia riziką kuriančią veiklą. Jis nebūtinai panaikina kiekvieną susijusią riziką. Pašalinus funkciją gali atsirasti rankinių procesų, kuriuos reikia įvertinti atskirai.

Mažinant riziką reikėtų apsvarstyti prevencines kontrolės priemones ir pasekmes ribojančias priemones. Palyginkite inžinerines sąnaudas, veiklos trikdžius, priklausomybes, tikėtiną naudą ir laiką iki poveikio. Neatidėliotinas apribojimas gali būti geresnis už stipresnį architektūrinį pakeitimą, kurio negalima įgyvendinti kelis mėnesius; registre turėtų būti užfiksuoti abu etapai.

Sutartinis perdavimas ir draudimas nepanaikina visų veiklos pasekmių. Tiekėjo žalos atlyginimo įsipareigojimas neatkurs jūsų paslaugos, o draudimas neatšauks atskleidimo. Kai tvarkomi asmens duomenys, perdavus veiklą išorės teikėjui lieka su vaidmeniu susijusios prievolės pagal BDAR; 28 ir 32 straipsniai išlieka svarbūs susitarimams su duomenų tvarkytojais ir saugumo priemonėms.

Priėmimas yra aktyvus sprendimas, o ne biudžeto nebuvimas ar vėluojanti užduotis. Užfiksuokite verslo pagrindimą, dabartinius įrodymus, išliekančią riziką, tvirtinančią instituciją, trukmę ir sąlygas, kurioms esant reikia peržiūros. Išlaidos svarbios, tačiau tai ne vienintelis kriterijus: teisinės prievolės, įsipareigojimai klientams ir pasekmės gali atmesti kitaip patogią galimybę.

Kiekvienam rizikos valdymo veiksmui priskirkite už įgyvendinimą atsakingą asmenį, išteklių įsipareigojimą, tikslinę datą, priklausomybę ir užbaigimo testą. Rizikos savininkas lieka atsakingas už bendrą vertinimą ir atsaką; užduočių savininkai įgyvendina atskirus pakeitimus. Įgaliotas peržiūrėtojas pagal organizacijos taisykles patvirtina rizikos valdymo sprendimą ir bet kokią išliekančią riziką.

Eskalavimą apibrėžkite prieš darbams sustojant. Pavyzdžiui, praleistas etapas, turintis įtakos artėjančiam paleidimui, turėtų sukelti sprendimą dėl paleidimo, o ne tiesiog termino perkėlimą. Užfiksuokite ir atmestas alternatyvas, ypač kai jos paaiškina, kodėl pasirinkta laikina rizikos valdymo priemonė.

Pavyzdys: pagalbos tarnybos paskyros eksporto rizika

Toliau pateikiamas pavyzdys yra iliustracinis. Tarkime, programinės įrangos paslauga turi dvidešimt pagalbos tarnybos naudotojų, klientų įrašai prieinami per pagalbos konsolę, o masinio eksporto funkcija paveldėta iš ankstesnio veiklos modelio. Vieningas prisijungimas įdiegtas, tačiau masinio eksporto teisės suteiktos plačiai. Esami žurnalai fiksuoja eksportus, nors nė vienas įspėjimas nebuvo išbandytas.

Scenarijus toks: užpuolikas kompromituoja pagalbos tarnybos sesiją ir, pasinaudodamas perteklinėmis teisėmis, eksportuoja klientų įrašus, sukeldamas neteisėtą atskleidimą ir reagavimo į klientus darbus.

Už riziką atsakingas paslaugos savininkas. Tapatybių vadovas atsako už autentifikavimo pakeitimus, taikomosios programos komanda – už autorizaciją, o saugumo operacijų komanda – už aptikimo testavimą.

Taikant šios hipotetinės organizacijos penkių lygių metodą, prigimtinės rizikos įvertinimas yra tikimybė 4 ir poveikis 4. Dabartinės likutinės rizikos įvertinimas yra tikimybė 3 ir poveikis 4: esamas autentifikavimas suteikia tam tikrą apsaugą, tačiau dėl plačių teisių išlieka didelis atskleidimo kelias. Pasitikėjimas vidutinis, nes sesijų apsaugos priemonės ir didžiausias eksporto kiekis dar nebuvo išbandyti. Šie skaičiai yra iliustraciniai kategorijų įvertinimai, o ne tikimybės.

Komanda palygina tris galimybes: pašalinti masinius eksportus, apriboti juos patvirtintiems naudotojams arba išlaikyti esamą prieigą su stipresne stebėsena. Pagalbos tarnyba įrodo teisėtą riboto eksporto poreikį. Savininkas pasirenka mažinimą – apribotą prieigą, stipresnį autentifikavimą likusiems privilegijuotiems naudotojams ir išbandytus eksporto įspėjimus.

Tarkime, įgyvendinimui reikia dvylikos inžinerinio darbo dienų per keturias savaites. Šie skaičiai yra planavimo prielaidos, o ne rinkos etalonai. Registras susieja darbą su įgyvendinimo planu ir užfiksuoja tarpinius apribojimus, kol įgyvendinimas nebaigtas.

Tikslinis likutinės rizikos įvertinimas yra tikimybė 2 ir poveikis 3, su sąlyga, kad tai bus patikrinta. Jis lieka tikslu, kol testai bus sėkmingi. Po diegimo peržiūrėtojas aptinka, kad senesnis galinis taškas apeina naująjį kiekio apribojimą. Todėl poveikio įvertinimas lieka 4, o apėjimas tampa blokuojančia rizikos valdymo užduotimi.

Ištaisius ir pakartotinai išbandžius, savininkas iš naujo įvertina visą kelią. Bet kuriai likusiai rizikai suteikiamas aiškus patvirtinimas ir peržiūros data. Nauja eksporto integracija, nepavykusi prieigos peržiūra ar reikšmingas prieinamų įrašų skaičiaus padidėjimas sukelia ankstesnį pakartotinį vertinimą. Registras dabar pakeitė įgyvendinimą, eiliškumą ir patvirtinimą – o ne vien užfiksavo susirūpinimą.

Sukurkite stebėsenos ciklą, kuris lemia sprendimus

Suplanuotos peržiūros išlieka naudingos, tačiau pokyčiai tarp peržiūrų turi pasiekti savininką. Susiekite veiklos signalus su scenarijais, kuriuos jie veikia. Svarbūs sukėlėjai – nepavykę prieigos pašalinimai, nauji tiekėjai, architektūros pokyčiai, incidentai, nepavykę kontrolės priemonių testai ir nauja grėsmių informacija.

Kiekvienam sukėlėjui apibrėžkite jo šaltinį, paveiktą apimtį, nukreipimą, tikėtiną reagavimo laiką ir peržiūrėtoją. Praktiškai rekomenduojame atskirti skubią riziką, reikalaujančią neatidėliotinų veiklos veiksmų, nuo įprasto įrodymų atnaujinimo. Nelaukite rizikos posėdžio, kad suvaldytumėte aktyvų incidentą.

Stebėsenos dažnumas turėtų atspindėti, kaip greitai keičiasi kontrolės priemonė ir kokios reikšmingos būtų gedimo pasekmės. Automatinės konfigūracijos patikros gali būti vykdomos dažnai; atkūrimo pratyboms ar tiekėjų peržiūrai reikia kitokio ritmo. „Nuolatinis“ turėtų apibūdinti nuolat vykstantį veiklos procesą, o ne reikšti, kad kiekviena kontrolės priemonė tikrinama kas sekundę.

Numatykite ir pačios stebėsenos gedimų tvarkymą. Atjungtas šaltinis ar pasenęs inventorius turėtų būti rodomas kaip nežinoma aprėptis, o ne kaip veikianti kontrolės priemonė. Šalinkite pasikartojančius įspėjimus ir grupuokite bendrus gedimus, kad savininkai gautų veiksmams tinkamą kontekstą, o ne dešimtis vienodų pranešimų.

Gavę signalą užfiksuokite, kas pasikeitė, kurie scenarijai buvo apsvarstyti, koks buvo neatidėliotinas veiksmas ir ar pakartotinis vertinimas pakeitė rizikos valdymo sprendimą. Nepavykusi prieigos peržiūra gali pateisinti tyrimą automatiškai nekeičiant kiekvieno susieto balo. Ir atvirkščiai, patvirtinta perteklinė prieiga prie jautrių įrašų gali iš karto paneigti esamą likutinės rizikos vertinimą.

Nuolatinė kontrolės priemonių stebėsena vertingiausia, kai jos rezultatai pasiekia tiek kontrolės priemonių vykdytojus, tiek už susijusią riziką atsakingus savininkus.

DI naudokite vertinimams rengti, o ne tvirtinti

DI gali padėti parengti scenarijų juodraščius, suderinti įrodymus, apibendrinti pokyčius, nustatyti galimus kontrolės priemonių susiejimus ir pasiūlyti prioritetus. Jo rezultatai turėtų likti peržiūrimu juodraščiu.

Pradėkite nuo siauros darbo eigos, kurios rezultatus galima patikrinti. Reikalaukite nuorodų į šaltinius ir atskirkite išgautus faktus nuo išvestinių išvadų. Tikrinkite trūkstamą aprėptį, prieštaringus įrašus, pasenusius dokumentus ir nepagrįstas prielaidas. Nušlifuota santrauka nėra įrodymas, kad pagrindiniai šaltiniai sutampa.

Nustatydami pažeidžiamumų prioritetus, šalia išorinių signalų naudokite verslo kontekstą. Rimtumas apibūdina galimas technines pasekmes; išnaudojimo tikimybė ir patvirtintas išnaudojimas rodo skirtingus grėsmės aktyvumo aspektus. Nė vienas jų nepasako, ar paveiktas komponentas įdiegtas, pasiekiamas, privilegijuotas ar yra kritinės paslaugos dalis. DI gali padėti koreliuoti, tačiau inventoriaus ir atvirumo patikros išlieka būtinos.

Tiekėjų žvalgybai reikia panašios disciplinos: atskirkite faktus apie jūsų sutartinį teikėją ir paslaugą nuo spėlionių apie susijusią įmonę. Elgsenos analitika taip pat reikalauja atsargumo, nes neįprasta veikla automatiškai nėra kenkėjiška, o darbuotojų stebėsena gali kelti privatumo ir darbo teisės klausimų.

Valdykite ir pačią DI darbo eigą. Taikykite mažiausių privilegijų principą, ribokite jautrius įvesties duomenis, išsaugokite peržiūrimą išvesties istoriją ir apibrėžkite, kada modelio ar užklausos pakeitimas reikalauja pakartotinio testavimo. Istoriniai incidentų duomenys gali užkoduoti akląsias zonas: prastai stebimos paslaugos gali atrodyti saugesnės vien todėl, kad buvo užfiksuota mažiau įvykių.

Prognoziniai rezultatai turėtų būti hipotezės su atsakingais asmenimis ir patikrinimo užduotimis. Sugeneruotas balas turėtų likti pasiūlymu, kol nebus patikrintas pagal sutartą metodą. Atsakingas savininkas patvirtina vertinimą ir rizikos valdymą.

DI naudojimas rizikos darbui automatiškai nepaverčia sistemos didelės rizikos sistema pagal ES dirbtinio intelekto aktą. Klasifikacija priklauso nuo naudojimo atvejo ir vaidmens; 9 straipsnio rizikos valdymo reikalavimai taikomi didelės rizikos sistemoms. Dėl taikymo ir terminų žr. dabartinę Komisijos apžvalgą. NIST AI RMF siūlo savanoriškas valdysenos gaires, o ne atitikties garantiją.

Praneškite apie sprendimų seką ir išbandykite, ar registras veikia

Inžinerijai reikia paveiktų sistemų, blokuojančių priklausomybių, patikrinimo kriterijų ir artėjančių sprendimų. Vadovybei reikia esminės rizikos, rizikos valdymo galimybių, išteklių prašymų ir pokyčių nuo ankstesnės peržiūros. Abu vaizdai turėtų kilti iš to paties pagrindinio vertinimo.

Išsaugokite vertinimų istoriją, o ne ją perrašykite. Išsaugokite ankstesnę išvadą, naujus įrodymus, pasikeitusias prielaidas, peržiūrėtoją, patvirtinimą ir datą. Priimtas rizikas laikykite matomas, įskaitant artėjančias galiojimo pabaigos datas ir nebegaliojančias sąlygas.

Naudingi veiklos rodikliai – sprendimo laukiančių rizikų amžius, vėluojantys rizikos valdymo etapai, laikas nuo esminio pokyčio iki pakartotinio vertinimo ir reikšmingų scenarijų, pagrįstų dabartiniais kontrolės priemonių įrodymais, dalis. Rodiklius lyginkite su savo baziniu lygiu. Įrašų ar sugeneruotų rekomendacijų skaičiai daugiausia apibūdina aktyvumą, o ne geresnius sprendimus. ISMS rodikliai turėtų padėti atskleisti sustojusią atsakomybę ir nepagrįstas išvadas.

Secani ISMS darbo erdvėje susieja rizikas, reikalavimus, kontrolės priemones ir įrodymus. Pirmajai sutelktai apimčiai sumodeliuokite palaikančias sistemas ir teikėjus, esamus įrodymus pridėkite prie kontrolės priemonių ar sprendimų, kuriuos jie pagrindžia, o spragas paverskite užduotimis su atsakingais asmenimis. DI pasiūlymus tikrinkite pagal jų šaltinius ir išsaugokite žmonių patvirtinimus, komentarus ir laiko žymas. Dokumentacijoje aprašyta ši į įrodymus orientuota darbo eiga.

Pradėkite nuo penkių reikšmingų scenarijų. Kiekvienam patvirtinkite savininką, dabartinio vertinimo pagrindimą, rizikos valdymo sprendimą, patikrinimo įrodymus ir kitos peržiūros sukėlėją. Tada vieną iš jų pateikite tikrame planavimo posėdyje ir paklauskite, kas turėtų pasikeisti. Jei atsakymas yra teisių riba, įgyvendinimo eiliškumas, finansuota užduotis ar aiškus priėmimo sprendimas, registras atlieka naudingą darbą.