Tālāk par izklājlapu sasaistes tabulām

Organizācijas reti darbojas tikai viena kiberdrošības ietvara ietvaros. SaaS pakalpojumu sniedzējs var tiekties pēc ISO 27001 sertifikācijas, saņemt klientu pieprasījumus pēc SOC 2 ziņojuma un tam var būt VDAR pienākumi attiecībā uz tā apstrādes darbībām. Var piemēroties arī NIS2 atkarībā no tā pakalpojumiem, nozares, lieluma un ieviešanas nacionālajā līmenī. Aizsardzības nozares piegādātājs saskaras ar citādu standartu un līgumisko prasību kombināciju, bet sastopas ar to pašu inženiertehnisko problēmu: pārklājošas prasības, kas tiek uzturētas kā savstarpēji nesaistīts darbs.

Izklājlapu sasaistes tabulas palīdz šo pārklāšanos identificēt. Tās kļūst mazāk uzticamas, kad rinda ar norādi „saistīts” tiek interpretēta kā „izpildīts” vai kad neviens nevar paskaidrot, kuras dokumentu versijas tika salīdzinātas.

Tehniskais mērķis nav likvidēt ietvaram specifisko detalizāciju. Mērķis ir izveidot atkārtoti izmantojamu sasaistu slāni, kas to saglabā: ko var koplietot, kas paliek nenosegts, no kurienes radusies attiecība un kas to pārskatījis.

Divas NIST iniciatīvas risina dažādas šīs problēmas daļas: National Online Informative References Program, ko dēvē par OLIR, un OSCAL Control Mapping Model. Izpratne par to lomām palīdz komandām pāriet no statiskām sasaistes tabulām uz uzturamu atbilstības infrastruktūru.

Sāciet, nošķirot prasības, kontroles un pierādījumus

Daudzi sasaistes projekti neizdodas, jo vienā izklājlapas kolonnā ievieto trīs dažādus objektus.

Prasība apraksta pienākumu, gaidas vai vēlamo rezultātu no avota dokumenta. Kontrole apraksta organizācijas atbildi: darbību, tehnisku mehānismu vai pārvaldības procesu. Pierādījumi pamato secinājumu par to, vai šī atbilde pastāv un darbojas, kā paredzēts.

Piemēram, vairāki ietvari var aplūkot piekļuves pārvaldību. Organizācijas kontrole varētu prasīt priviliģētās piekļuves ceturkšņa pārskatīšanu visā tās ražošanas vidē. Pierādījumi varētu ietvert pārskatīto kontu sarakstu, apstiprināšanas ierakstus, izņēmumu pieteikumus un pierādījumus, ka nepiemērotas atļaujas tika noņemtas.

Šiem objektiem nepieciešamas atsevišķas attiecības:

• Prasību savstarpējās sasaistes identificē pārklāšanos starp dokumentāriem avotiem.
• Prasību sasaistes ar kontrolēm apraksta, kā organizācija risina konkrētas gaidas.
• Kontroļu attiecības ar sistēmām nosaka, kur ieviešana darbojas.
• Pierādījumu attiecības parāda, kas pamato ieviešanu vai novērtējuma secinājumu.

Publicēta sasaistes tabula parasti palīdz ar pirmo attiecību. Tā nenosaka pārējās trīs.

Šī nošķiršana arī novērš neatbilstošus salīdzinājumus starp dažādiem apliecinājuma veidiem. ISO 27001 attiecas uz informācijas drošības pārvaldības sistēmu ar noteiktu tvērumu. SOC 2 ir apliecinājuma ziņojums, nevis sertifikācija. VDAR nosaka pienākumus atbilstoši apstrādes darbībām un organizācijas lomām. Sertifikāts vai ziņojums nepierāda atbilstību regulai.

Tāpēc tvērumam jāpavada sasaistes lēmums. Ražošanas vides piekļuves pārskatīšana var atbalstīt SaaS pakalpojuma novērtējumu, neko neliecinot par izslēgtu meitasuzņēmumu vai nesaistītu personāla sistēmu. Līdzīgs formulējums nevar pārvarēt šo robežu.

Ko sniedz OLIR: zināšanas par sasaistēm ar kontekstu

OLIR nodrošina standartizētu veidu, kā jomas ekspertiem aprakstīt attiecības starp atsauces dokumentu elementiem un atbalstītajiem NIST pamatdokumentiem. Pamatdokumenti var ietvert NIST Cybersecurity Framework, NIST SP 800-53 vai NIST AI Risk Management Framework.

Informatīvā atsauce varētu savienot nozares prasību ar NIST CSF 2.0 apakškategoriju. Tas ir apgalvojums par attiecību starp šiem elementiem, nevis pierādījums, ka organizācija ir ieviesusi kādu no tiem.

Programma pievieno šiem apgalvojumiem noderīgu kontekstu:

• Veidnes un konvencijas atbalstītajiem pamatdokumentiem
• Metadati, kas identificē sasaistītos dokumentus un iesniedzēju organizāciju
• Centralizēts publisks katalogs
• Melnraksta un galīgās publikācijas statusi
• Publiskas pārskatīšanas process
• Informācija par to, vai iesniedzējam pieder sasaistītais dokuments vai tas ir trešā puse

NIST nošķir trīs OLIR sasaistes stilus: konceptu sasaistes tabulas, kopu teorijas attiecību sasaistes un atbalstošo attiecību sasaistes. To mērķi atšķiras. Konceptu sasaistes tabula var palīdzēt cilvēkiem orientēties saistītās idejās, savukārt kopu teorijas attiecība var izteikt konkrētāku apgalvojumu par to, kā divi elementi pārklājas.

Ieviešanas plānošanā šī atšķirība ir svarīga. „Šie elementi attiecas uz reaģēšanu uz incidentiem” ir noderīgi atklāšanai, taču nepietiekami, lai izlemtu, vai viens process sedz citas prasības ziņošanas nosacījumus, adresātus vai termiņus.

Uztveriet OLIR publikācijas statusu un autorību kā pārskatīšanas ievaddatus. Izdevējam piederoša sasaiste var sniegt vērtīgu ieskatu paredzētajā nozīmē, taču tās atbilstība joprojām ir atkarīga no izskatāmajām versijām un tvēruma. Galīgo publikāciju nevajadzētu pārvērst iekšējā secinājumā, ka katrs sasaistītais pienākums ir izpildīts.

OLIR materiālu iegūšanas rezultātam jābūt avotu reģistram: izmantotā atsauce, tās statuss, dokumentu versijas, autors, iegūšanas datums un paredzētais lietojums. Glabājiet oriģinālu blakus jebkuram normalizētajam attēlojumam, lai pārskatītāji varētu rekonstruēt importu.

Ko sniedz OSCAL: aprēķināms attiecību modelis

OSCAL, Open Security Controls Assessment Language, nodrošina mašīnlasāmus modeļus kontroļu katalogiem, profiliem, sistēmu drošības plāniem, novērtēšanas plāniem, novērtējuma rezultātiem un saistītai atbilstības informācijai. Tā plašākais mērķis ir padarīt drošības dokumentāciju strukturētu un apmaināmu, nevis atkarīgu no dokumenta izkārtojuma.

OSCAL Control Mapping Model attēlo attiecības starp kontrolēm un kontroļu elementiem no dokumentāriem avotiem. Tas atbalsta mašīnlasāmus attēlojumus JSON, YAML vai XML formātā, ieskaitot attiecības smalkākā līmenī nekā vesela kontrole.

Modeļa attiecību vārdnīcā ietilpst equal-to, equivalent-to, subset-of, superset-of, intersects-with un no-relationship. Tiem nevajadzētu kļūt par savstarpēji aizstājamiem apzīmējumiem nozīmē „aptuveni līdzīgs”.

Virzienam ir nozīme. Avots, kas ir mērķa apakškopa, kļūst par virskopu, ja salīdzinājumu apgriež. Importētājs, kas samaina dokumentu pozīcijas, nepielāgojot attiecību, maina nozīmi.

Modelis var nošķirt sasaistes pamatus, piemēram, sintaktisku līdzību, semantisko nozīmi un funkcionālo rezultātu. Diviem apgalvojumiem var būt kopīga terminoloģija, bet tie var prasīt dažādas darbības; atšķirīgi formulēti apgalvojumi var kalpot līdzīgai drošības funkcijai.

Tas var attēlot arī papildu kontekstu par izcelsmi, atbildīgajām pusēm, statusu, ticamību, pārklājumu, nepilnībām un sasaistes metodēm. Daļa darbības informācijas var piederēt apkārtējai pārskatīšanas sistēmai, nevis konkrētam shēmas laukam. Ievērojiet NIST modeļa dokumentāciju attiecībā uz jūsu ieviesto attēlojumu un piefiksējiet modeļa vai shēmas versiju, ko izmanto jūsu rīki.

Mašīnlasāms nenozīmē automātiski pareizs. Shēmas validācija var pārbaudīt struktūru un atļautās vērtības. Tā nevar noteikt, vai analītiķa interpretācija par divām prasībām ir pamatota.

OLIR un OSCAL risina dažādas problēmas

OLIR ir programma, publicēšanas process, katalogs un sasaistes apgalvojumu avots. OSCAL nodrošina tehnisku attēlojumu attiecību glabāšanai, apmaiņai un apstrādei.

Tāpēc organizācija var izmantot OLIR kā vienu ārējo sasaistu avotu un OSCAL kā savu kanonisko iekšējo attēlojumu. Citi avoti var ietvert izdevēju nodrošinātas sasaistes tabulas, regulējuma analīzi, klientu prasības un iekšēji pārskatītas ekspertu sasaistes.

OSCAL tvērums ir plašāks nekā OLIR uz NIST orientētā iesniegšanas struktūra. Piemēroti katalogi vai profili var attēlot tiešas attiecības, piemēram, IT-Grundschutz pret ISO 27001, NIS2 pret iekšējo kontroļu bibliotēku vai klienta prasību pret organizācijas kontroli. Šādas attiecības ne vienmēr kvalificējas kā OLIR iesniegumi.

Praktiska arhitektūra izskatās šādi:

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

Turiet avotu apgalvojumus atsevišķi no iekšējiem pieņemšanas lēmumiem. Ārējs izdevējs var apgalvot līdzvērtību, kamēr iekšējais pārskatītājs secina, ka organizācijas tvērumam ir piemērota tikai daļēja atkārtota izmantošana. Saglabājiet abus ierakstus, nevis klusi pārrakstiet ārējo sasaisti.

Veidojiet sasaistu konveijeru ap skaidriem lēmumiem

Atrisiniet piemērojamību pirms formulējumu salīdzināšanas

Sāciet ar pienākumu un apliecinājuma mērķu reģistru. Katram avotam reģistrējiet piemērojamo versiju, organizācijas lomu, ietekmētos pakalpojumus, ģeogrāfisko kontekstu, novērtējuma robežu un iekļaušanas iemeslu.

Tas novērš, ka klienta gaidas tiek sajauktas ar likumā noteiktu pienākumu. Klients, uz kuru attiecas NIS2, var noteikt piegādes ķēdes prasības, nepadarot savu piegādātāju tieši pakļautu direktīvai. NIS2 piemērojamībai nepieciešama atsevišķa analīze saskaņā ar attiecīgajiem nacionālajiem tiesību aktiem.

Tāpat nepievienojiet katru SOC 2 kategoriju tikai tāpēc, ka tā pastāv. Reģistrējiet paredzēto uzdevuma tvērumu. ISO 27001 gadījumā saglabājiet pārvaldības sistēmas prasības, riska apstrādi un Piemērojamības paziņojuma lēmumus, nevis reducējiet standartu līdz A pielikuma kontrolsarakstam.

Rezultāts ir tvēruma matrica, kas pārskatītājiem norāda, kuras sasaistes varētu būt būtiskas, pirms viņi tērē laiku to interpretēšanai.

Normalizējiet dokumentus, nezaudējot to struktūru

Katru importēto identifikatoru sasaistiet ar pareizo dokumenta izdevumu. Saglabājiet punktu hierarhiju, kontroļu identifikatorus, apgalvojumu identifikatorus, ja tie pieejami, un sākotnējo atsauces vietu.

Noderīga iekšējā atslēga apvieno dokumenta identitāti, versiju un elementa identifikatoru. Tikai attēlojamais nosaukums nav drošs: identiskiem kontroļu numuriem dažādos izdevumos vai publikācijās var būt atšķirīga nozīme.

Ja nepieciešams, sadaliet saliktas prasības pārskatāmos elementos. Ja viena rindkopa prasa politiku, piešķirtus pienākumus, testēšanu un ziņošanu, viena visas rindkopas sasaiste var noslēpt trīs nenosegtas gaidas. Saglabājiet vecākelementa attiecību, lai lietotāji varētu rekonstruēt avota kontekstu.

Glabājot avota tekstu, ievērojiet publicēšanas un licencēšanas nosacījumus. Ja pilna teksta glabāšana nav piemērota, saglabājiet atļautos identifikatorus, atsauces un sākotnējās analītiskās piezīmes.

Ģenerējiet kandidātus, pēc tam pārskatiet apgalvojumus

Kandidātu ģenerēšanā var izmantot esošās sasaistes tabulas, kopīgu terminoloģiju, drošības mērķus vai MI atbalstītu analīzi. Tās rezultātam jābūt pārskatīšanas rindai, nevis apstiprinātai sasaistu kolekcijai.

Katram būtiskam apgalvojumam pārskatītājiem jāizvērtē faktiskie elementi un jāreģistrē:

• Attiecības veids un virziens
• Salīdzinājuma pamats
• Pieņēmumi un tvēruma ierobežojumi
• Kopīgās gaidas un nenosegtās atšķirības
• Avota izcelsme un sasaistes metode
• Pārskatītājs, lēmums un pārskatīšanas datums

Ticamība ir noderīga pārskatīšanas prioritizēšanai, taču tā nav pārklājuma procents. Pārskatītājs var būt ļoti pārliecināts, ka divas prasības pārklājas tikai daļēji. Turiet ticamību apgalvojumam atsevišķi no ieviešanas statusa un pierādījumu pietiekamības.

Arī kandidāta noraidīšana ir vērtīga. Dokumentēta no-relationship lēmuma saglabāšana palīdz novērst, ka nākotnes importi vai automatizēti ieteikumi atkārtoti piedāvā to pašu maldinošo atbilstību.

Validējiet gan struktūru, gan nozīmi

Pirms apstiprināšanas veiciet tehniskās pārbaudes: jābūt redzamām neatrisinātām atsaucēm, trūkstošām versijām, nederīgām attiecību vērtībām, dublikātiem un negaidītām virziena maiņām.

Pēc tam veiciet semantisko pārskatīšanu. Pajautājiet, vai attiecība saglabā dalībnieku, prasīto darbību, aizsargājamo objektu, laiku, nosacījumus un gaidāmo rezultātu. Juridisku prasību gadījumā iesaistiet kādu, kas ir kvalificēts pienākuma novērtēšanai, nevis paļaujieties tikai uz līdzību drošības jomā.

Izmantojiet darba plūsmas stāvokļus, piemēram, ierosināts, pārskatīšanā, apstiprināts noteiktam lietojumam, noraidīts un aizstāts. Tie ir praktiski darbības ieteikumi, nevis universālas likumā noteiktas prasības. Apstiprinājumā jānorāda, ko tas atļauj: atklāšanu, plānošanu, pierādījumu atkārtotu izmantošanu vai novērtējuma secinājuma pamatošanu.

Testējiet importus un eksportus kā inženiertehniskus komponentus

Pirms normalizēto sasaistu izmantošanas pārskatos izveidojiet nelielu regresijas testa kopu ar apzināti sarežģītiem gadījumiem: apgrieztu apakškopas attiecību, neatrisinātu apgalvojuma identifikatoru, diviem pretrunīgiem avotu apgalvojumiem un sasaisti ar aizstātu izdevumu. Katram gadījumam definējiet gaidāmo rezultātu. Importam neskaidri ieraksti jānovieto karantīnā, nevis klusi jāizvēlas jaunākais šķietamais dokuments vai jāatmet pretrunīgais apgalvojums.

Testējiet arī atkārtotus importus. Vienas un tās pašas kolekcijas divkārša importēšana nedrīkst radīt dublētu darbu vai pārrakstīt iekšēju apstiprinājumu. Izmantojiet stabilas identitātes un saglabājiet versiju vēsturi, lai mainīts ārējs apgalvojums kļūtu par pārskatīšanas notikumu, nevis neredzamu aizstāšanu.

Apmaiņai testējiet pilnu ciklu: eksportējiet apstiprinātu paraugu, importējiet to tīrā testa vidē un salīdziniet identifikatorus, virzienu, pamatojumu un izcelsmi. Ja darba plūsmas metadati nevar pārvietoties izvēlētajā attēlojumā, dokumentējiet pavadošo formātu un tā ierobežojumus. Pretējā gadījumā tehniski derīgs eksports var zaudēt tieši to kontekstu, kas padarīja sasaisti uzticamu.

Šie ir praktiski inženiertehniski aizsardzības pasākumi. Tie padara automatizāciju paredzamu, neizliekoties, ka programmatūras testi var validēt pamatā esošo juridisko vai drošības interpretāciju.

Veidojiet kopīgas kontroles, nesaplacinot ietvarus

Kad prasību attiecības ir saprastas, definējiet kopīgu kontroļu bibliotēku ap reālām darbības aktivitātēm. Tādas jomas kā identitāte, ievainojamību pārvaldība, reaģēšana uz incidentiem, piegādātāju apliecinājumi un atjaunošana ir noderīgi sākumpunkti.

Katrai kontrolei nepieciešams atbildīgs īpašnieks un ieviešanas apraksts, ko var izpildīt cits inženieris. „Piekļuve tiek regulāri pārskatīta” ir pārāk neskaidri. Norādiet aptvertās sistēmas un kontu veidus, pārskatītāju, biežumu, lēmumu kritērijus, izņēmumu procesu un radītos pierādījumus.

Nepieņemiet, ka „stingrākā prasība” automātiski izpilda visu pārējo. Prasības var būt nesalīdzināmas: ilgāka žurnālu glabāšana var palīdzēt apliecinājuma mērķim, vienlaikus radot privātuma jautājumus par nepieciešamību un piekļuvi. Augstāks pārskatīšanas biežums nevar aizstāt trūkstošu juridisko novērtējumu.

Izmantojiet kopīgu bāzes līniju ar skaidriem papildinājumiem:

Saskaņā ar VDAR apstrādes drošība ir balstīta uz risku. Kopīgas drošības kontroles var atbalstīt 32. pantu, taču likumīgajam pamatam, pārredzamībai, apstrādes darbību reģistriem, datu subjektu tiesībām, novērtējumiem par ietekmi uz datu aizsardzību (ja tie nepieciešami) un starptautiskai nosūtīšanai nepieciešams atsevišķs novērtējums. Aktīvu saraksts var sniegt informāciju apstrādes darbību reģistram, neaizstājot tā nolūkus, datu kategorijas, saņēmējus un glabāšanas informāciju.

ISO 27001 līdzīgi ietver pārvaldības sistēmas darbu, ko nevar secināt tikai no darbības kontrolēm. Tvērums, riska apstrāde, Piemērojamības paziņojums, iekšējais audits un vadības pārskats ir atsevišķi nododamie rezultāti.

Izmantojiet pierādījumus atkārtoti ar novērtējuma kontekstu

Centralizēta krātuve samazina dublēšanos tikai tad, ja pārskatītāji saprot, ko katrs artefakts pierāda.

Kā praktisku ieteikumu reģistrējiet pierādījumu īpašnieku, savākšanas datumu, aptverto periodu, ietekmētās sistēmas, avotu, versiju, piekļuves ierobežojumus un secinājumu, ko tie pamato. Turiet pamatā esošo artefaktu atsevišķi no novērtējuma apgalvojuma.

Ceturkšņa piekļuves pārskatīšanas eksports varētu parādīt, kādas atļaujas pastāvēja noteiktā datumā. Apstiprināšanas ieraksts parāda, kas tās pārskatīja. Novēršanas pieteikumi parāda, vai nepiemērotā piekļuve tika noņemta. Neviens no šiem artefaktiem atsevišķi ne vienmēr pierāda visu kontroli.

Arī laiks maina atkārtotu izmantošanu. SOC 2 Type II uzdevums pārbauda darbību noteiktā periodā, savukārt artefakts par konkrētu brīdi aptver šaurāku intervālu. Izstrādājot vākšanu, nošķiriet kontroles biežumu, novērtēšanas periodu un artefakta aktualitāti. Nesens ekrānuzņēmums nerekonstruē mēnešiem ilgi trūkstošus izpildes ierakstus.

Tikpat svarīgs ir novērtējuma tvērums. Pārliecinieties, ka pierādījumi aptver attiecīgo pakalpojumu, kopu, vidi un kontroles variācijas. Nošķiriet klienta pārvaldītās atļaujas no pakalpojuma sniedzēja pārvaldītās administratīvās piekļuves, nevis uzskatiet vienu eksportu par pierādījumu abiem.

Pierādījumi var saturēt sensitīvu informāciju vai personas datus. Piemērojiet atbilstošas piekļuves kontroles, samaziniet nevajadzīgu saturu un apzināti nosakiet glabāšanas laiku. Artefakta atkārtota izmantošana nenozīmē tā neierobežota oriģināla izplatīšanu katram pārskatītājam.

Rezultāts ir pierādījumu plāns katrai kopīgajai kontrolei: kas tiek vākts, kad, no kurienes, kas to dara un uz kādiem novērtējuma jautājumiem tas var palīdzēt atbildēt.

Saskaņojiet šo plānu ar kopīgu apliecinājumu kalendāru. Plānojiet saistītās intervijas ar īpašniekiem un pierādījumu pārbaudes kopā, ja to tvērumi sakrīt, vienlaikus saglabājot atsevišķus novērtējuma secinājumus. Pirms paļaušanās uz atkārtotu izmantošanu vienojieties par pierādījumu gaidām ar attiecīgajiem vērtētājiem. Kopīgs vākšanas process var atbalstīt vairākus uzdevumus, taču tas nevar piespiest katru vērtētāju pieņemt to pašu izlasi vai novērst papildu testēšanu. Periodiskām kontrolēm plānojiet vākšanu izpildes brīdī, nevis gaidiet, kamēr tuvojas audits.

Praktisks piemērs: viens incidentu process, vairāki ziņošanas lēmumi

Aplūkosim ilustratīvu SaaS organizāciju ar 45 darbiniekiem. Pieņemsim, ka tās ražošanas pakalpojums ietilpst ISO 27001 ISMS tvērumā, tā gatavojas SOC 2 Security uzdevumam un dažādās darbībās apstrādā personas datus gan kā pārzinis, gan kā apstrādātājs. Pieņemsim arī, ka piemērojamības novērtējums ir noteicis NIS2 pienākumus saskaņā ar attiecīgo nacionālo ieviešanu.

Šie ir scenārija pieņēmumi, nevis apgalvojumi par tipisku personāla skaitu, juridisko piemērojamību vai projekta piepūli.

Organizācija importē sasaistes kandidātus saistībā ar incidentu pārvaldību un definē kopīgu kontroli IR-01: ziņotie drošības notikumi tiek šķiroti, tiem tiek piešķirts incidenta īpašnieks, tie tiek izmeklēti, ierobežoti un dokumentēti līdz slēgšanai.

Šī kontrole ir noderīga visā programmā, taču sasaistes pārskatīšana identificē vairākus atšķirīgus elementus:

Tāpēc komanda sasaista konkrētus incidentu procesa elementus, nevis apgalvo, ka IR-01 pilnībā izpilda katru saistīto pienākumu.

Personas datu aizsardzības pārkāpumu gadījumā VDAR 33. pants nošķir lomas. Apstrādātājs bez nepamatotas kavēšanās paziņo pārzinim. Pārzinis bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad tam kļuvis zināms, izvērtē paziņošanu uzraudzības iestādei, ja vien nav maz ticams, ka pārkāpums radīs risku fizisku personu tiesībām un brīvībām. Augsts risks var prasīt paziņošanu datu subjektiem saskaņā ar 34. pantu, ievērojot tajā paredzētos izņēmumus.

Būtisku incidentu gadījumā saskaņā ar NIS2 23. pantu ES ziņošanas struktūra ietver agrīno brīdinājumu 24 stundu laikā, paziņojumu 72 stundu laikā un parasti galīgo ziņojumu viena mēneša laikā pēc paziņojuma. Organizācija pārbauda piemērojamos nacionālos un nozares noteikumus, nevis uzskata šo kopsavilkumu par savu pilnīgo ziņošanas procedūru.

Tāpēc incidenta ierakstā ir atsevišķi ierosinātāju novērtējumi un uzzināšanas laika zīmogi. Ja piemērojami vairāki pienākumi, to termiņi rit paralēli. Uz ISO orientēts ierobežošanas darbs neatliek juridisku ziņošanas lēmumu.

Pierādījumu paketē ietilpst pieteikuma vēsture, lēmumu žurnāls, saziņas apstiprinājumi, iesniegšanas ieraksti, ja paziņojums tika sniegts, un pamatojums, ja paziņojums nebija nepieciešams. Galda mācības pārbauda sazarojuma loģiku ar drošības, juridiskās, pakalpojumu darbības un komunikācijas dalībniekiem.

Sasaistes rezultāts ir precīzs: atkārtoti izmantot reaģēšanas mehānismu, saglabāt atšķirīgos ziņošanas pienākumus un novērtēt gan ieviešanu, gan pierādījumus. Atlikušās nepilnības kļūst par uzdevumiem ar īpašniekiem, piemēram, netestēts saziņas ceļš ar regulatoru vai trūkstošas eskalācijas instrukcijas no apstrādātāja pārzinim.

Padariet izmaiņu ietekmi par pilnvērtīgu darba plūsmu

Sasaistu bibliotēka kļūst neuzticama, ja tā reģistrē tikai sākotnējā iestatīšanā izmantotos ietvaru nosaukumus.

Kad avots mainās, salīdziniet vairāk nekā identifikatorus. Prasības var tikt sadalītas, apvienotas, pārdēvētas, paplašinātas vai pārvietotas bez acīmredzamas numerācijas norādes. Izveidojiet izmaiņu ierakstu dokumenta līmenī un identificējiet katru sasaisti, kas saistīta ar mainītajiem elementiem.

Praktiska atjaunināšanas secība ir šāda:

1. Saglabājiet iepriekšējo izdevumu un apstiprināto sasaistu kopu.
2. Importējiet jauno izdevumu ar atšķirīgiem identifikatoriem un versijas metadatiem.
3. Identificējiet mainītos elementus un ietekmētās attiecības.
4. Atzīmējiet ietekmētos pieņemšanas lēmumus pārskatīšanai.
5. Atkārtoti novērtējiet kontroles, pierādījumu plānus un ietvaram specifiskos papildinājumus.
6. Apstipriniet pārskatītos lēmumus un saglabājiet aizstāto vēsturi.

Darbības izmaiņām jāierosina tas pats process. Mākoņpakalpojumu sniedzēja pievienošana, identitātes arhitektūras maiņa vai pakalpojuma iekļaušana tvērumā var padarīt pierādījumu atkārtotu izmantošanu nederīgu pat tad, ja ietvars nav mainījies.

Atvasinātām sasaistēm nepieciešama īpaša piesardzība. OLIR var radīt Derived Relationship Mappings, salīdzinot, kā divi atsauces dokumenti attiecas uz kopīgu pamatdokumentu. NIST tos raksturo kā neautoritatīvus sākumpunktus, nevis pārbaudītas tiešās sasaistes tabulas. Ja A ir saistīts ar C un B ir saistīts ar C, tas nenozīmē, ka A un B ir līdzvērtīgi.

Izmantojiet atvasinātās attiecības izmeklēšanas prioritizēšanai. Neizplatiet atbilstības secinājumus pa grafu tikai tāpēc, ka pastāv ceļš.

Izmēģiniet sasaistu slāni, pirms migrējat visu

Izvēlieties vienu reprezentatīvu pakalpojumu un dažas kontroļu jomas ar gan būtisku pārklāšanos, gan redzamām atšķirībām. Piekļuves pārskatīšana, piegādātāju pārvaldība un reaģēšana uz incidentiem ir noderīgi kandidāti, jo tie atklāj tvēruma, īpašumtiesību, pierādījumu un juridiskās interpretācijas jautājumus.

Pilotprojektam jārada ierobežots pārbaudāmu nododamo rezultātu kopums:

• Piemērojamības un tvēruma reģistrs
• Versijēti avota dokumenti vai atļautas atsauces uz avotiem
• Pārskatīti sasaistes apgalvojumi ar izcelsmi un pamatojumu
• Kopīgas kontroles ar īpašniekiem un darbības procedūrām
• Ietvaram specifiski papildinājumi un neatrisinātu nepilnību uzdevumi
• Pierādījumu plāni un novērtējuma lēmumu paraugi
• Testēta atjaunināšanas procedūra

Novērtējiet pilotprojektu pēc tā, vai cits pārskatītājs var atkārtot tā secinājumus. Vai viņš var paskaidrot, kāpēc attiecība tika apstiprināta, atrast attiecīgo avotu, identificēt nenosegtās gaidas un redzēt, kuras sistēmas pierādījumi aptver?

Biežas kļūdas ir veselu kontroļu jomu sasaistīšana kā līdzvērtīgu, izņēmumu slēpšana komentāros, kopīgu kontroļu atstāšana bez galvenā īpašnieka un pierādījumu pieejamības jaukšana ar efektīvu darbību. Vēl viena kļūda ir lielas sasaistu bibliotēkas izveide, pirms pārbaudīts, vai tā atbalsta reālu novērtējumu.

Secani pamatota sākuma darba plūsma ir modelēt reprezentatīvo pakalpojumu un tā atbalstošos mērķa objektus, nosaukt īpašniekus un pārskatītājus un savienot esošos pierādījumus ar prasībām, kontrolēm un lēmumiem. Trūkstoši materiāli un neatrisināti jautājumi kļūst par uzdevumiem. MI atbalstīti ieteikumi paliek melnraksta darbs, līdz cilvēks pārbauda avotus un apstiprina lēmumu ar izsekojamu ierakstu. Secani savienoto pierādījumu un pārskatīšanas pieeja uztur sasaistes lēmumus piesaistītus to avotiem, īpašniekiem un ieviešanas kontekstam.

Konkrētu ietvaru pāri skatiet rakstā NIS2 un ISO 27001.

Jautājumi, kas ir svarīgi pirms ieviešanas

Vai pilotprojekta laikā varam saglabāt izklājlapas?

Jā. Izklājlapa var būt pārskatīšanas saskarne, ja tā saglabā versijas, virzienu, pamatojumu, tvērumu un izcelsmi. Ierobežojums nav pati tabula, bet gan vāja validācija, nesaistīti pierādījumi un sarežģīta izmaiņu pārvaldība. Definējiet datu modeli, pirms izvēlaties saskarni.

Vai MI vajadzētu apstiprināt sasaistes ar augstu ticamību?

Nē. Ticamība ģenerētam ieteikumam nav atbildīgs pārskatīšanas lēmums. Izmantojiet MI, lai izceltu kandidātus un atšķirības, un pēc tam pieprasiet cilvēka apstiprinājumu būtiskiem sasaistes un pierādījumu secinājumiem.

Ko mums darīt tālāk?

Paņemiet vienu esošas sasaistes tabulas rindu un rekonstruējiet tās pamatojumu. Identificējiet abas avotu versijas, izlasiet sasaistītos elementus, norādiet attiecību un virzienu, dokumentējiet nenosegto starpību un savienojiet to ar reālu kontroli un pierādījumu paketi. Ja šis ieraksts iztur neatkarīgu pārskatīšanu, atkārtojiet metodi visā pilotprojektā. Tas ir atkārtoti izmantojamas atbilstības infrastruktūras pamats.