Daugiau nei skaičiuoklių atitikmenų lentelės

Organizacijos retai veikia pagal vieną kibernetinio saugumo sistemą. SaaS paslaugų teikėjas gali siekti ISO 27001 sertifikavimo, gauti klientų prašymų pateikti SOC 2 ataskaitą ir turėti BDAR įpareigojimų dėl savo tvarkymo veiklos. Priklausomai nuo paslaugų, sektoriaus, dydžio ir nacionalinio įgyvendinimo, jam taip pat gali būti taikoma NIS2. Gynybos tiekėjas susiduria su kitokiu standartų ir sutartinių reikalavimų deriniu, tačiau ta pačia inžinerine problema: persidengiantys reikalavimai tvarkomi kaip atskiri, nesusiję darbai.

Skaičiuoklių atitikmenų lentelės padeda nustatyti šį persidengimą. Jos tampa mažiau patikimos, kai eilutė „susijęs“ aiškinama kaip „įvykdytas“ arba kai niekas negali paaiškinti, kurių dokumentų versijos buvo lyginamos.

Techninis tikslas nėra panaikinti sistemoms specifines detales. Tikslas yra sukurti pakartotinai naudojamą susiejimų sluoksnį, kuris jas išsaugo: kuo galima dalytis, kas lieka neapimta, iš kur kilo ryšys ir kas jį peržiūrėjo.

Dvi NIST iniciatyvos sprendžia skirtingas šios problemos dalis: National Online Informative References Program, žinoma kaip OLIR, ir OSCAL Control Mapping Model. Jų vaidmenų supratimas padeda komandoms pereiti nuo statiškų atitikmenų lentelių prie palaikomos atitikties infrastruktūros.

Pradėkite atskirdami reikalavimus, kontroles ir įrodymus

Daugelis susiejimo projektų žlunga, nes į tą patį skaičiuoklės stulpelį sudeda tris skirtingus objektus.

Reikalavimas aprašo šaltinio dokumente nustatytą įpareigojimą, lūkestį ar siekiamą rezultatą. Kontrolė aprašo organizacijos atsaką: veiklą, techninį mechanizmą ar valdymo procesą. Įrodymai pagrindžia išvadą apie tai, ar toks atsakas egzistuoja ir veikia taip, kaip numatyta.

Pavyzdžiui, kelios sistemos gali reglamentuoti prieigos valdymą. Organizacijos kontrolė gali reikalauti kas ketvirtį peržiūrėti privilegijuotą prieigą visoje gamybinėje aplinkoje. Įrodymai galėtų apimti peržiūrėtą paskyrų inventorių, patvirtinimų įrašus, išimčių užklausas ir įrodymą, kad netinkami leidimai buvo pašalinti.

Šiems objektams reikia atskirų ryšių:

• Reikalavimo ir reikalavimo susiejimai nustato dokumentinių šaltinių persidengimą.
• Reikalavimo ir kontrolės susiejimai aprašo, kaip organizacija atsako į lūkestį.
• Kontrolės ir sistemos ryšiai nustato, kur įgyvendinimas veikia.
• Įrodymų ryšiai parodo, kas pagrindžia įgyvendinimo ar vertinimo išvadą.

Paskelbta atitikmenų lentelė paprastai padeda nustatyti pirmąjį ryšį. Ji nenustato kitų trijų.

Šis skirtumas taip pat neleidžia netinkamai lyginti skirtingų užtikrinimo rūšių. ISO 27001 susijęs su apibrėžtos taikymo srities informacijos saugumo valdymo sistema. SOC 2 yra atestavimo ataskaita, o ne sertifikatas. BDAR nustato įpareigojimus pagal tvarkymo veiklą ir organizacijos vaidmenis. Sertifikatas ar ataskaita neįrodo atitikties reglamentui.

Todėl taikymo sritis turi keliauti kartu su susiejimo sprendimu. Gamybinės prieigos peržiūra gali pagrįsti SaaS paslaugos vertinimą, bet nieko nepasakyti apie neįtrauktą dukterinę bendrovę ar nesusijusią personalo sistemą. Panaši formuluotė šios ribos neperžengia.

Ką suteikia OLIR: susiejimų žinios su kontekstu

OLIR suteikia standartizuotą būdą dalykinės srities ekspertams aprašyti ryšius tarp etaloninių dokumentų elementų ir palaikomų NIST pagrindinių (focal) dokumentų. Pagrindiniai dokumentai gali būti NIST Cybersecurity Framework, NIST SP 800-53 arba NIST AI Risk Management Framework.

Informacinė nuoroda gali susieti pramonės reikalavimą su NIST CSF 2.0 subkategorija. Tai teiginys apie ryšį tarp šių elementų, o ne įrodymas, kad organizacija įgyvendino kurį nors iš jų.

Programa prie šių teiginių prideda naudingo konteksto:

• Šablonus ir konvencijas palaikomiems pagrindiniams dokumentams
• Metaduomenis, nurodančius susietus dokumentus ir pateikusią organizaciją
• Centralizuotą viešą katalogą
• Juodraščio ir galutinio paskelbimo būsenas
• Viešos peržiūros procesą
• Informaciją apie tai, ar pateikėjas yra susieto dokumento savininkas, ar trečioji šalis

NIST skiria tris OLIR susiejimo stilius: sąvokų atitikmenų lenteles, aibių teorijos ryšių susiejimus ir palaikančiųjų ryšių susiejimus. Jų paskirtis skiriasi. Sąvokų atitikmenų lentelė gali padėti žmonėms orientuotis susijusiose idėjose, o aibių teorijos ryšys gali išreikšti konkretesnį teiginį apie tai, kaip du elementai persidengia.

Įgyvendinimo planavimui šis skirtumas svarbus. „Šie elementai susiję su reagavimu į incidentus“ yra naudinga aptikimui, tačiau nepakanka nuspręsti, ar vienas procesas apima kito reikalavimo pranešimo sąlygas, gavėjus ar terminus.

OLIR paskelbimo būseną ir autorystę traktuokite kaip peržiūros įvestis. Leidėjui priklausantis susiejimas gali suteikti vertingų įžvalgų apie numatytą prasmę, tačiau jo tinkamumas vis tiek priklauso nuo nagrinėjamų versijų ir taikymo srities. Galutinis paskelbimas neturėtų būti verčiamas vidine išvada, kad kiekvienas susietas įpareigojimas įvykdytas.

OLIR medžiagos gavimo rezultatas turėtų būti šaltinių registras: naudota nuoroda, jos būsena, dokumentų versijos, autorius, gavimo data ir numatytas naudojimas. Originalą saugokite kartu su bet kokiu normalizuotu atvaizdavimu, kad tikrintojai galėtų atkurti importą.

Ką suteikia OSCAL: apskaičiuojamas ryšių modelis

OSCAL, Open Security Controls Assessment Language, suteikia mašininio nuskaitymo modelius kontrolių katalogams, profiliams, sistemų saugumo planams, vertinimo planams, vertinimo rezultatams ir susijusiai atitikties informacijai. Platesnis jo tikslas yra padaryti saugumo dokumentaciją struktūrizuotą ir keičiamą, o ne priklausomą nuo dokumento išdėstymo.

OSCAL Control Mapping Model atvaizduoja ryšius tarp dokumentinių šaltinių kontrolių ir kontrolių elementų. Jis palaiko mašininio nuskaitymo atvaizdavimus JSON, YAML ar XML formatu, įskaitant ryšius smulkesniu lygmeniu nei visa kontrolė.

Modelio ryšių žodynas apima equal-to, equivalent-to, subset-of, superset-of, intersects-with ir no-relationship. Jie neturėtų tapti tarpusavyje pakeičiamomis „apytiksliai panašu“ etiketėmis.

Kryptis svarbi. Šaltinis, kuris yra tikslinio elemento poaibis, tampa viršaibiu, kai palyginimas apverčiamas. Importuoklis, kuris sukeičia dokumentų pozicijas nepakoreguodamas ryšio, pakeičia prasmę.

Modelis gali atskirti susiejimo pagrindus, tokius kaip sintaksinis panašumas, semantinė prasmė ir funkcinis rezultatas. Du teiginiai gali turėti bendrą terminologiją, bet reikalauti skirtingų veiksmų; skirtingai suformuluoti teiginiai gali atlikti panašią saugumo funkciją.

Jis taip pat gali atvaizduoti papildomą kontekstą apie kilmę, atsakingas šalis, būseną, pasitikėjimo lygį, aprėptį, spragas ir susiejimo metodus. Kai kuri veiklos informacija gali priklausyti aplinkinei peržiūros sistemai, o ne konkrečiam schemos laukui. Įgyvendinamam atvaizdavimui vadovaukitės NIST modelio dokumentacija ir užfiksuokite savo įrankių naudojamą modelio ar schemos versiją.

Mašininio nuskaitymo formatas nereiškia automatinio teisingumo. Schemos validavimas gali patikrinti struktūrą ir leistinas reikšmes. Jis negali nustatyti, ar analitiko dviejų reikalavimų aiškinimas yra pagrįstas.

OLIR ir OSCAL sprendžia skirtingas problemas

OLIR yra programa, paskelbimo procesas, katalogas ir susiejimo teiginių šaltinis. OSCAL pateikia techninį atvaizdavimą ryšiams saugoti, keistis jais ir juos apdoroti.

Todėl organizacija gali naudoti OLIR kaip vieną išorinį susiejimų šaltinį, o OSCAL kaip savo kanoninį vidinį atvaizdavimą. Kiti šaltiniai gali būti leidėjų pateiktos atitikmenų lentelės, reguliavimo analizė, klientų reikalavimai ir viduje peržiūrėti ekspertų susiejimai.

OSCAL taikymo sritis platesnė nei OLIR į NIST orientuota pateikimo struktūra. Tinkami katalogai ar profiliai gali atvaizduoti tiesioginius ryšius, pavyzdžiui, IT-Grundschutz su ISO 27001, NIS2 su vidine kontrolių biblioteka arba kliento reikalavimą su organizacijos kontrole. Tokie ryšiai nebūtinai tinka OLIR pateikimui.

Praktinė architektūra atrodo taip:

External and internal mapping sources
                 ↓
Source preservation and import
                 ↓
Document, version, and identifier resolution
                 ↓
Normalized mapping collections
                 ↓
Technical validation and expert review
                 ↓
Controls, implementations, evidence, and assessments
                 ↓
Gap analysis and change-impact work

Šaltinių teiginius laikykite atskirai nuo vidinių priėmimo sprendimų. Išorinis leidėjas gali teigti lygiavertiškumą, o vidinis tikrintojas gali padaryti išvadą, kad organizacijos taikymo sričiai tinka tik dalinis pakartotinis naudojimas. Išsaugokite abu įrašus, o ne tyliai perrašykite išorinį susiejimą.

Kurkite susiejimų konvejerį aplink aiškius sprendimus

Nustatykite taikymą prieš lygindami formuluotes

Pradėkite nuo įpareigojimų ir užtikrinimo tikslų registro. Kiekvienam šaltiniui užfiksuokite taikomą versiją, organizacijos vaidmenį, paveiktas paslaugas, geografinį kontekstą, vertinimo ribą ir įtraukimo priežastį.

Taip kliento lūkestis nebus supainiotas su įstatymine pareiga. Klientas, kuriam taikoma NIS2, gali nustatyti tiekimo grandinės reikalavimus, nepadarydamas savo tiekėjo tiesiogiai pavaldaus direktyvai. NIS2 taikymui reikia atskiros analizės pagal atitinkamą nacionalinę teisę.

Taip pat nepridėkite kiekvienos SOC 2 kategorijos vien todėl, kad ji egzistuoja. Užfiksuokite numatytą užduoties apimtį. ISO 27001 atveju išsaugokite valdymo sistemos reikalavimus, rizikos valdymą ir Taikymo pareiškimo sprendimus, o ne susiaurinkite standartą iki A priedo kontrolinio sąrašo.

Rezultatas yra taikymo srities matrica, kuri tikrintojams parodo, kurie susiejimai gali būti svarbūs, prieš jiems skiriant laiko juos aiškinti.

Normalizuokite dokumentus neprarasdami jų struktūros

Kiekvieną importuotą identifikatorių susiekite su tinkamu dokumento leidimu. Išsaugokite skyrių hierarchiją, kontrolių identifikatorius, teiginių identifikatorius, kai jie yra, ir pradinę nuorodos vietą.

Naudingas vidinis raktas sujungia dokumento tapatybę, versiją ir elemento identifikatorių. Vien rodomas pavadinimas yra nesaugus: identiški kontrolių numeriai skirtinguose leidimuose ar leidiniuose gali turėti skirtingas prasmes.

Kai reikia, sudėtinius reikalavimus suskaidykite į peržiūrimus elementus. Jei viena pastraipa reikalauja politikos, paskirtų atsakomybių, testavimo ir pranešimų, vienas visos pastraipos susiejimas gali paslėpti tris neapimtus lūkesčius. Išsaugokite tėvinį ryšį, kad naudotojai galėtų atkurti šaltinio kontekstą.

Saugodami šaltinio tekstą, laikykitės paskelbimo ir licencijavimo sąlygų. Kai viso teksto saugoti netinka, išsaugokite leidžiamus identifikatorius, nuorodas ir originalias analitines pastabas.

Generuokite kandidatus, tada peržiūrėkite teiginius

Kandidatams generuoti galima naudoti esamas atitikmenų lenteles, bendrą terminologiją, saugumo tikslus ar DI padedamą analizę. Rezultatas turėtų būti peržiūros eilė, o ne patvirtintų susiejimų rinkinys.

Kiekvienam reikšmingam teiginiui tikrintojai turėtų išnagrinėti faktinius elementus ir užfiksuoti:

• Ryšio tipą ir kryptį
• Palyginimo pagrindą
• Prielaidas ir taikymo srities apribojimus
• Bendrus lūkesčius ir neapimtus skirtumus
• Šaltinio kilmę ir susiejimo metodą
• Tikrintoją, sprendimą ir peržiūros datą

Pasitikėjimo lygis naudingas nustatant peržiūros prioritetus, tačiau tai nėra aprėpties procentas. Tikrintojas gali būti labai tikras, kad du reikalavimai persidengia tik iš dalies. Pasitikėjimą teiginiu laikykite atskirai nuo įgyvendinimo būsenos ir įrodymų pakankamumo.

Kandidato atmetimas taip pat vertingas. Išsaugotas dokumentuotas no-relationship sprendimas padeda neleisti būsimiems importams ar automatizuotiems pasiūlymams pakartotinai pateikti to paties klaidinančio atitikmens.

Validuokite ir struktūrą, ir prasmę

Prieš patvirtinimą atlikite techninius patikrinimus: turi būti matomos neišspręstos nuorodos, trūkstamos versijos, netinkamos ryšių reikšmės, dublikatai ir netikėti krypties apvertimai.

Tada atlikite semantinę peržiūrą. Paklauskite, ar ryšys išsaugo veikėją, reikalaujamą veiksmą, saugomą objektą, laiką, sąlygas ir laukiamą rezultatą. Teisiniams reikalavimams įtraukite asmenį, kvalifikuotą įvertinti įpareigojimą, o ne remkitės vien panašumu saugumo srityje.

Naudokite darbo proceso būsenas, tokias kaip pasiūlyta, peržiūrima, patvirtinta apibrėžtam naudojimui, atmesta ir pakeista nauja. Tai praktinės veiklos rekomendacijos, o ne visuotiniai įstatyminiai reikalavimai. Patvirtinime turėtų būti nurodyta, ką jis leidžia: aptikimą, planavimą, įrodymų pakartotinį naudojimą ar vertinimo išvados pagrindimą.

Testuokite importus ir eksportus kaip inžinerinius komponentus

Prieš įtraukdami normalizuotus susiejimus į ataskaitas, sukurkite nedidelį regresijos testų rinkinį su sąmoningai sudėtingais atvejais: apverstu poaibio ryšiu, neišspręstu teiginio identifikatoriumi, dviem prieštaraujančiais šaltinių teiginiais ir susiejimu su pakeistu leidimu. Kiekvienam atvejui apibrėžkite tikėtiną rezultatą. Importas turėtų izoliuoti dviprasmiškus įrašus, o ne tyliai pasirinkti naujausiai atrodantį dokumentą ar atmesti prieštaraujantį teiginį.

Testuokite ir pakartotinius importus. Tą patį rinkinį importavus du kartus, neturėtų atsirasti dubliuoto darbo ar būti perrašytas vidinis patvirtinimas. Naudokite stabilias tapatybes ir išsaugokite pakeitimų istoriją, kad pasikeitęs išorinis teiginys taptų peržiūros įvykiu, o ne nematomu pakeitimu.

Keitimuisi duomenimis testuokite visą ciklą: eksportuokite patvirtintą pavyzdį, importuokite jį į švarią testinę aplinką ir palyginkite identifikatorius, kryptį, pagrindimą ir kilmę. Jei darbo proceso metaduomenys negali keliauti pasirinktu atvaizdavimu, dokumentuokite lydimąjį formatą ir jo apribojimus. Kitaip techniškai galiojantis eksportas gali prarasti būtent tą kontekstą, kuris susiejimą darė patikimą.

Tai praktinės inžinerinės apsaugos priemonės. Jos padaro automatizavimą nuspėjamą, neapsimetant, kad programinės įrangos testai gali patvirtinti pagrindinį teisinį ar saugumo aiškinimą.

Kurkite bendras kontroles nesuplokštindami sistemų

Supratę reikalavimų ryšius, apibrėžkite bendrą kontrolių biblioteką aplink realią veiklą. Tokios sritys kaip tapatybės, pažeidžiamumų valdymas, reagavimas į incidentus, tiekėjų užtikrinimas ir atkūrimas yra naudingi atspirties taškai.

Kiekvienai kontrolei reikia atsakingo asmens ir įgyvendinimo aprašymo, kurį galėtų įvykdyti kitas inžinierius. „Prieiga peržiūrima reguliariai“ yra per daug miglota. Nurodykite apimamas sistemas ir paskyrų tipus, tikrintoją, periodiškumą, sprendimų kriterijus, išimčių procesą ir sukuriamus įrodymus.

Neprisiimkite, kad „griežčiausias reikalavimas“ automatiškai patenkina visa kita. Reikalavimai gali būti nepalyginami: ilgesnis žurnalų saugojimas gali padėti siekti užtikrinimo tikslo, tačiau sukelti privatumo klausimų dėl būtinumo ir prieigos. Didesnis peržiūrų dažnumas negali pakeisti trūkstamo teisinio vertinimo.

Naudokite bendrą bazinį lygį ir aiškius papildymus:

Pagal BDAR tvarkymo saugumas grindžiamas rizika. Bendros saugumo kontrolės gali padėti vykdyti 32 straipsnį, tačiau teisiniam pagrindui, skaidrumui, tvarkymo įrašams, asmenų teisėms, poveikio duomenų apsaugai vertinimams, kai jie privalomi, ir tarptautiniams perdavimams reikia atskiro vertinimo. Turto inventorius gali padėti sudaryti tvarkymo įrašą, bet nepakeičia jo tikslų, duomenų kategorijų, gavėjų ir saugojimo informacijos.

ISO 27001 taip pat apima valdymo sistemos darbą, kurio negalima išvesti vien iš veiklos kontrolių. Taikymo sritis, rizikos valdymas, Taikymo pareiškimas, vidaus auditas ir vadovybės peržiūra yra atskiri rezultatai.

Pakartotinai naudokite įrodymus per vertinimo kontekstą

Centrinė saugykla sumažina dubliavimą tik tada, kai tikrintojai supranta, ką įrodo kiekvienas artefaktas.

Kaip praktinę rekomendaciją užfiksuokite įrodymų atsakingą asmenį, surinkimo datą, apimamą laikotarpį, paveiktas sistemas, šaltinį, versiją, prieigos apribojimus ir išvadą, kurią jie pagrindžia. Pagrindinį artefaktą laikykite atskirai nuo vertinimo teiginio.

Ketvirtinės prieigos peržiūros eksportas gali parodyti, kokie leidimai egzistavo tam tikrą dieną. Patvirtinimo įrašas parodo, kas juos peržiūrėjo. Taisymo užklausos parodo, ar netinkama prieiga buvo pašalinta. Nė vienas iš šių artefaktų atskirai nebūtinai įrodo visą kontrolę.

Laikas taip pat keičia pakartotinį naudojimą. SOC 2 Type II užduotis nagrinėja veikimą per laikotarpį, o tam tikro momento artefaktas apima siauresnį intervalą. Projektuodami rinkimą, atskirkite kontrolės periodiškumą, vertinimo laikotarpį ir artefakto aktualumą. Nauja ekrano kopija neatkuria mėnesius trūkstamų vykdymo įrašų.

Vertinimo taikymo sritis yra tokia pat svarbi. Patvirtinkite, kad įrodymai apima atitinkamą paslaugą, populiaciją, aplinką ir kontrolės variantą. Kliento valdomus leidimus atskirkite nuo paslaugų teikėjo valdomos administracinės prieigos, o ne laikykite vieną eksportą abiejų įrodymu.

Įrodymuose gali būti jautrios informacijos ar asmens duomenų. Taikykite tinkamas prieigos kontroles, sumažinkite nereikalingą turinį ir sąmoningai apibrėžkite saugojimą. Artefakto pakartotinis naudojimas nereiškia, kad jo neribotas originalas platinamas kiekvienam tikrintojui.

Rezultatas yra įrodymų planas kiekvienai bendrai kontrolei: kas renkama, kada, iš kur, kas renka ir į kokius vertinimo klausimus tai gali padėti atsakyti.

Suderinkite šį planą su bendru užtikrinimo kalendoriumi. Susijusius pokalbius su atsakingais asmenimis ir įrodymų patikrinimus planuokite kartu, kai jų taikymo sritys sutampa, tačiau išlaikykite atskiras vertinimo išvadas. Prieš remdamiesi pakartotiniu naudojimu, lūkesčius dėl įrodymų suderinkite su atitinkamais vertintojais. Bendras rinkimo procesas gali palaikyti kelias užduotis, bet negali priversti kiekvieno vertintojo priimti tos pačios imties ar panaikinti papildomo testavimo. Periodinių kontrolių įrodymus planuokite rinkti vykdymo metu, o ne laukti, kol artės auditas.

Išnagrinėtas pavyzdys: vienas incidentų procesas, keli sprendimai dėl pranešimų

Panagrinėkime iliustracinę SaaS organizaciją, turinčią 45 darbuotojus. Tarkime, kad jos gamybinė paslauga patenka į ISO 27001 ISMS taikymo sritį, ji rengiasi SOC 2 Security užduočiai ir skirtingose veiklose tvarko asmens duomenis ir kaip duomenų valdytoja, ir kaip duomenų tvarkytoja. Taip pat tarkime, kad taikymo vertinimu nustatytos NIS2 pareigos pagal atitinkamą nacionalinį įgyvendinimą.

Tai scenarijaus prielaidos, o ne teiginiai apie tipišką personalo skaičių, teisinį taikymą ar projekto pastangas.

Organizacija importuoja susiejimo kandidatus, susijusius su incidentų valdymu, ir apibrėžia bendrą kontrolę IR-01: praneštų saugumo įvykių rūšiavimas, incidento atsakingo asmens paskyrimas, tyrimas, suvaldymas ir dokumentavimas iki uždarymo.

Ši kontrolė naudinga visoje programoje, tačiau susiejimo peržiūra nustato kelis atskirus elementus:

Todėl komanda susieja konkrečius incidentų proceso elementus, o ne teigia, kad IR-01 visiškai įvykdo kiekvieną susijusį įpareigojimą.

Asmens duomenų saugumo pažeidimų atveju BDAR 33 straipsnis atskiria vaidmenis. Duomenų tvarkytojas nepagrįstai nedelsdamas praneša duomenų valdytojui. Duomenų valdytojas nepagrįstai nedelsdamas ir, jei įmanoma, per 72 valandas nuo sužinojimo įvertina pranešimą priežiūros institucijai, nebent pažeidimas neturėtų kelti pavojaus asmenų teisėms ir laisvėms. Dėl didelio pavojaus pagal 34 straipsnį gali tekti informuoti asmenis, atsižvelgiant į jame numatytas išimtis.

Reikšmingiems incidentams pagal NIS2 direktyvos 23 straipsnį ES pranešimo struktūra apima ankstyvąjį įspėjimą per 24 valandas, pranešimą per 72 valandas ir paprastai galutinę ataskaitą per vieną mėnesį nuo pranešimo. Organizacija patikrina taikomas nacionalines ir sektorines taisykles, o ne laiko šią santrauką išsamia savo pranešimo procedūra.

Todėl incidento įraše laikomi atskiri paskatų vertinimai ir sužinojimo laiko žymos. Kai taikomos kelios pareigos, jų terminai skaičiuojami lygiagrečiai. Į ISO orientuotas suvaldymo darbas neatideda teisinio sprendimo dėl pranešimo.

Įrodymų pakete yra užklausos istorija, sprendimų žurnalas, komunikacijos patvirtinimai, pateikimo įrašai, kai buvo pranešta, ir motyvai, kai pranešti nereikėjo. Stalo pratybose šakojimosi logika išbandoma kartu su saugumo, teisės, paslaugų veiklos ir komunikacijos dalyviais.

Susiejimo rezultatas yra tikslus: pakartotinai naudoti reagavimo mechanizmą, išsaugoti atskirus pranešimo įpareigojimus ir vertinti tiek įgyvendinimą, tiek įrodymus. Likusios spragos tampa užduotimis su atsakingais asmenimis, pavyzdžiui, neišbandytas kontaktų su reguliavimo institucija kelias ar trūkstamos duomenų tvarkytojo eskalavimo duomenų valdytojui instrukcijos.

Padarykite pakeitimų poveikį pirmos klasės darbo procesu

Susiejimų biblioteka tampa nepatikima, jei joje užfiksuoti tik pradinio sąrankos metu naudoti sistemų pavadinimai.

Kai šaltinis pasikeičia, lyginkite ne tik identifikatorius. Reikalavimai gali būti suskaidyti, sujungti, pervadinti, išplėsti ar perkelti be akivaizdaus numeracijos signalo. Sukurkite dokumento lygmens pakeitimų įrašą ir nustatykite kiekvieną su pakeistais elementais susijusį susiejimą.

Praktinė atnaujinimo seka:

1. Išsaugokite ankstesnį leidimą ir patvirtintą susiejimų rinkinį.
2. Importuokite naują leidimą su atskirais identifikatoriais ir versijos metaduomenimis.
3. Nustatykite pakeistus elementus ir paveiktus ryšius.
4. Paveiktus priėmimo sprendimus pažymėkite peržiūrai.
5. Iš naujo įvertinkite kontroles, įrodymų planus ir sistemoms specifinius papildymus.
6. Patvirtinkite peržiūrėtus sprendimus ir išsaugokite pakeistų versijų istoriją.

Veiklos pokyčiai turėtų inicijuoti tą patį procesą. Pridėjus debesijos paslaugų teikėją, pakeitus tapatybių architektūrą ar įtraukus paslaugą į taikymo sritį, įrodymų pakartotinis naudojimas gali tapti negaliojantis net tada, kai sistema nepasikeitė.

Išvestiniams susiejimams reikia ypatingo atsargumo. OLIR gali sukurti išvestinius ryšių susiejimus (Derived Relationship Mappings), lygindama, kaip du etaloniniai dokumentai susiję su bendru pagrindiniu dokumentu. NIST juos apibūdina kaip neautoritetingus atspirties taškus, o ne patikrintas tiesiogines atitikmenų lenteles. Jei A susijęs su C, o B susijęs su C, tai nenustato, kad A ir B yra lygiaverčiai.

Išvestinius ryšius naudokite tyrimo prioritetams nustatyti. Neskleiskite atitikties išvadų per grafą vien todėl, kad egzistuoja kelias.

Išbandykite susiejimų sluoksnį bandomuoju projektu prieš perkeldami viską

Pasirinkite vieną reprezentatyvią paslaugą ir kelias kontrolių sritis, kuriose yra ir reikšmingas persidengimas, ir matomi skirtumai. Prieigos peržiūros, tiekėjų valdymas ir reagavimas į incidentus yra naudingi kandidatai, nes jie atskleidžia taikymo srities, atsakomybės, įrodymų ir teisinio aiškinimo klausimus.

Bandomasis projektas turėtų duoti apibrėžtą patikrinamų rezultatų rinkinį:

• Taikymo ir taikymo srities registrą
• Versijuojamus šaltinių dokumentus arba leidžiamas šaltinių nuorodas
• Peržiūrėtus susiejimo teiginius su kilme ir pagrindimu
• Bendras kontroles su atsakingais asmenimis ir veiklos procedūromis
• Sistemoms specifinius papildymus ir neišspręstų spragų užduotis
• Įrodymų planus ir vertinimo sprendimų pavyzdžius
• Išbandytą atnaujinimo procedūrą

Bandomąjį projektą vertinkite pagal tai, ar kitas tikrintojas gali atkurti jo išvadas. Ar jis gali paaiškinti, kodėl ryšys buvo patvirtintas, rasti atitinkamą šaltinį, nustatyti neapimtus lūkesčius ir matyti, kurias sistemas apima įrodymai?

Dažnos klaidos: ištisos kontrolių sritys susiejamos kaip lygiavertės, išimtys slepiamos komentaruose, bendros kontrolės paliekamos be pagrindinio atsakingo asmens, įrodymų buvimas painiojamas su veiksmingu veikimu. Kita klaida yra sukurti didelę susiejimų biblioteką prieš patikrinant, ar ji palaiko realų vertinimą.

„Secani“ pagrįstas pradinis darbo procesas yra sumodeliuoti reprezentatyvią paslaugą ir ją palaikančius tikslinius objektus, įvardyti atsakingus asmenis ir tikrintojus bei susieti esamus įrodymus su reikalavimais, kontrolėmis ir sprendimais. Trūkstama medžiaga ir neišspręsti klausimai tampa užduotimis. DI padedami pasiūlymai lieka juodraščiu, kol žmogus patikrina šaltinius ir patvirtina sprendimą su atsekamu įrašu. „Secani“ susietų įrodymų ir peržiūros požiūris išlaiko susiejimo sprendimus pririštus prie jų šaltinių, atsakingų asmenų ir įgyvendinimo konteksto.

Konkrečią sistemų porą rasite straipsnyje NIS2 ir ISO 27001.

Klausimai, svarbūs prieš įgyvendinimą

Ar bandomojo projekto metu galime toliau naudoti skaičiuokles?

Taip. Skaičiuoklė gali būti peržiūros sąsaja, jei ji išsaugo versijas, kryptį, pagrindimą, taikymo sritį ir kilmę. Apribojimas yra ne pati lentelė, o silpnas validavimas, atskirti įrodymai ir sudėtingas pakeitimų valdymas. Prieš rinkdamiesi sąsają, apibrėžkite duomenų modelį.

Ar DI turėtų tvirtinti didelio pasitikėjimo susiejimus?

Ne. Pasitikėjimas sugeneruotu pasiūlymu nėra atskaitingas peržiūros sprendimas. Naudokite DI kandidatams ir skirtumams atskleisti, o reikšmingoms susiejimo ir įrodymų išvadoms reikalaukite žmogaus patvirtinimo.

Ką turėtume daryti toliau?

Paimkite vieną esamos atitikmenų lentelės eilutę ir atkurkite jos samprotavimą. Nustatykite abiejų šaltinių versijas, perskaitykite susietus elementus, nurodykite ryšį ir kryptį, dokumentuokite neapimtą skirtumą ir susiekite jį su realia kontrole bei įrodymų paketu. Jei šis įrašas atlaiko nepriklausomą peržiūrą, pakartokite metodą visame bandomajame projekte. Tai yra pakartotinai naudojamos atitikties infrastruktūros pagrindas.