Uz MI veidota atbilstība

No dokumentiem līdz strukturētai atbilstības darbvietai

Uz MI veidota atbilstība nozīmē MI izmantošanu strukturētā, pārskatāmā atbilstības procesā, nevis vienkārši tērzēšanas robota pievienošanu dokumentu krātuvei. Darbības princips ir vienkāršs: MI paātrina sagatavošanu un analīzi, cilvēki apstiprina nozīmīgus lēmumus, un pierādījumi paliek saistīti ar katru pamatoto apgalvojumu.

Tehnoloģiju direktoram arhitektūras jautājums ir, vai sistēma spēj attēlot organizācijas faktiskās kontroles. Politika apraksta paredzēto rīcību. Konfigurācijas eksports parāda iestatījumu. Pabeigta piekļuves pārskatīšana apliecina darbību. Tie ir dažādi pierādījumu veidi, un raita teksta ģenerēšana nepadara tos savstarpēji aizstājamus.

Noderīga darbvieta sasaista prasības, kontroles, sistēmas, pierādījumus, īpašniekus, uzdevumus un lēmumus. Šī struktūra ļauj komandām atkārtoti izmantot pamatotu informāciju dažādos ietvaros, nesajaucot līdzīgas prasības ar līdzvērtīgiem pienākumiem.

Kāpēc atsevišķi ietvaru projekti rada tehnisko parādu

Organizācijas bieži uztur politikas dokumentos, pierādījumus mapēs, riskus izklājlapās un novēršanas uzdevumus projektu rīkos. Pēc tam audita apraksti tiek atjaunoti no šiem izkliedētajiem avotiem. Jauna ietvara pievienošana bieži rada vēl vienu tās pašas informācijas kopiju.

Sekas sniedzas tālāk par administratīvo slogu. Atsevišķas komandas var sniegt inženieriem pretrunīgus norādījumus par vienu un to pašu piekļuves kontroles procesu. Vienā novērtējumā var izmantot novecojušu arhitektūras aprakstu, bet citā – pašreizējo versiju. Noslīpēts ziņojums var slēpt neatrisinātu ieviešanas nepilnību.

Praktiskā alternatīva ir kopīgs kontroļu modelis ar ietvariem specifiskiem skatiem. Uzturiet ieviešanu vienreiz, pievienojiet atbilstošus pierādījumus un atsevišķi izvērtējiet, kuras prasības tā atbalsta. Tas samazina dublējošus pieprasījumus, neizdzēšot atšķirības tvērumā, novērtēšanas periodos vai juridiskajos pienākumos.

Definējiet piemērojamību, pirms lūdzat MI sasaistīt kontroles

Sāciet ar organizācijas robežu: kurš pakalpojums, juridiskā persona, sistēmas, atrašanās vietas un pakalpojumu sniedzēji ir iekļauti? Reģistrējiet ietvara versiju un iemeslu, kāpēc katrs pienākums ir piemērojams. Pretējā gadījumā MI var radīt ticamas sasaistes prasībām, kas ir ārpus faktiskā tvēruma.

Atšķirības ir svarīgas:

• BSI IT-Grundschutz, kas ir viens no galvenajiem Secani dokumentēto darba plūsmu fokusiem, apvieno informācijas drošības metodoloģiju ar moduļu kompendiju. Modelējiet tvērumā ietilpstošos mērķa objektus un izvēlieties piemērojamos moduļus, nevis uzskatiet kompendiju par universālu kontrolsarakstu.
• ISO/IEC 27001 attiecas uz informācijas drošības pārvaldības sistēmu ar definētu tvērumu. Tās pārvaldības sistēmas prasības, riska apstrāde, piemērojamības paziņojums, iekšējais audits un vadības pārskats paliek atsevišķi nododami rezultāti.
• NIS2 tiek īstenota ar nacionālajiem tiesību aktiem. Piemērojamība ir atkarīga no nozares, lieluma, pakalpojumiem un iekļaušanas noteikumiem; sertifikācija neapliecina atbilstību.
• DORA galvenokārt attiecas uz noteiktām finanšu vienībām. IKT pakalpojumu sniedzējiem var rasties līgumiski pienākumi, savukārt izraudzītajiem kritiskajiem pakalpojumu sniedzējiem ir atsevišķs pārraudzības režīms.
• VDAR pienākumi ir atkarīgi no apstrādes un organizatoriskajām lomām. Drošības pierādījumi vieni paši neapliecina atbilstību regulai.

Uzskatiet piemērojamību par apstiprinātu ievaddatu, nevis par secinājumu, ko modelis izdara klusībā. Neskaidros gadījumos izveidojiet skaidru interpretācijas uzdevumu ar atbildīgu pārskatītāju.

Izveidojiet pierādījumu modeli, pirms ģenerējat dokumentus

Praktiskam minimālajam modelim būtu jānošķir prasība, ieviestā kontrole, pamatojošie pierādījumi un pārskatīšanas lēmums. Augšupielādēts fails pats par sevi nav kontrole, un apstiprināta politika nepierāda, ka procedūra darbojas konsekventi.

Modelī jāiekļauj arī atkarības. Klientiem paredzēta lietotne var būt atkarīga no identitātes pakalpojumu sniedzēja, mākoņinfrastruktūras un pārvaldītas atbalsta komandas. Vienas atkarības pierādījumus nedrīkst automātiski uzskatīt par pierādījumu visam pakalpojumam.

Šī struktūra padara redzamu vāju pārklājumu: piekļuves politika var būt aktuāla, kamēr pārskatīšanas ieraksti trūkst, vai konfigurācijas ekrānuzņēmums var aptvert tikai vienu vidi.

Izmantojiet MI kandidātu sasaistēm, nevis automātiskai līdzvērtībai

MI var palīdzēt izgūt attiecīgos fragmentus, ieteikt attiecības, identificēt trūkstošu pamatojumu un sagatavot kontroļu aprakstu melnrakstus. Nodrošiniet tam identificētas avotu versijas un faktisko ieviešanu, nevis tikai kontroļu nosaukumus.

Noderīgs sasaistes priekšlikums izskaidro, kura daļa pārklājas, kuri pierādījumi pamato šo pārklāšanos un kas paliek neatrisināts. Attiecības bieži ir daudzi pret daudziem: viena kontrole atbalsta vairākas prasības, savukārt vienai prasībai nepieciešamas vairākas kontroles.

Incidentu pārvaldība ilustrē šo robežu. Kopīgs reaģēšanas process var atbalstīt vairākus ietvarus, taču ziņošanas sliekšņi, saņēmēji, ierosinātāji un termiņi var atšķirties. Darbības procesa atkārtota izmantošana neizpilda katru paziņošanas pienākumu.

Pārskatītājiem pirms atkārtotas izmantošanas apstiprināšanas būtu jāpārbauda trūkstošs tvērums, pretrunīgi avoti, novecojušas atsauces un nepamatoti apgalvojumi. Saglabājiet pamatojumu kopā ar attiecību, lai vēlākas ietvara vai ieviešanas izmaiņas varētu saprātīgi izvērtēt. Mūsu darbības riska reģistra ceļvedis piemēro to pašu pārskatītas palīdzības principu scenārijiem un apstrādes lēmumiem.

Pierādījumu vākšanai un melnrakstu sagatavošanai nepieciešami atšķirīgi aizsardzības pasākumi

Vāciet pierādījumus no autoritatīvām sistēmām kontrolētā procesā neatkarīgi no tā, vai tas ietver manuālus eksportus vai izvērtētu vākšanas mehānismu. Reģistrējiet, kas tos savāca, kad un kādu kopu tie aptver. Nepieņemiet, ka produktam ar MI automātiski ir piekļuve darbības sistēmām.

Ar MI atbalstītai izgūšanai būtu jāsaglabā avota fragments vai ieraksts, kas pamato katru secinājumu. Pārskatiet īpaši rūpīgi, ja dokumentos ir pretrunīgi apgalvojumi, ekrānuzņēmumiem nav datuma vai eksportētajos datos nav iekļauti daži konti. Trūkstošiem pierādījumiem būtu jārada jautājums vai uzdevums, nevis izdomāts apgalvojums, ka kontrole darbojas.

Ģenerētai dokumentācijai izmantojiet konsekventu melnraksta struktūru: nolūks, tvērums, ieviešana, īpašnieks, pierādījumi, izņēmumi un pārskatīšanas statuss. Nošķiriet paredzētās procedūras no novērotās darbības. Ziņojumos būtu jāizmanto pārskatītas kontroles un jāatklāj būtiskas nepilnības, nevis jāpārvērš melnraksta ieteikumi galīgā pārliecībā.

Arī augšupielādētie materiāli jāuzskata par neuzticamu ievadi. Dokumentos iegulti norādījumi nedrīkst ignorēt pārskatīšanas darba plūsmu vai atļaut darbības. Lasīšanas piekļuve analīzei nedrīkst nozīmēt atļauju mainīt kontroles, apstiprināt lēmumus vai izplatīt ziņojumus.

Praktisks piemērs: viena piekļuves pārskatīšana, vairāki lietojumi

Aplūkosim ilustratīvu SaaS komandu, kas dokumentē vienu ražošanas pakalpojumu. Pieņemsim, ka tai ir apstiprināta piekļuves politika, datēts identitātes pakalpojumu sniedzēja eksports, ceturkšņa pārskatīšanas ieraksti un atvērts uzdevums noņemt divus nevajadzīgus administratoru kontus. Netiek pieņemti nekādi ietaupījumi vai produkta veiktspēja.

Komanda vispirms definē robežu: ražošanas konti ir iekļauti; atsevišķa pētniecības vide ir izslēgta. Pēc tam tā sasaista politiku ar paredzēto pārskatīšanas procesu un pabeigtos ierakstus ar pārskatīšanas darbību.

MI ierosina piekļuves kontroles aprakstu un kandidātu sasaistes ar ietvariem. Pārskatītājs konstatē trīs problēmas:

• Eksports aptver cilvēku kontus, bet ne pakalpojumu identitātes.
• Pārskatīšanas ieraksti parāda lēmumus, taču abiem administratoru kontiem trūkst noņemšanas pierādījumu.
• Politikā noteiktas ceturkšņa pārskatīšanas, taču viena pabeigtā pārskatīšana bija nokavēta.

Pārskatītājs apstiprina pamatoto aprakstu, noraida apgalvojumu, ka visa priviliģētā piekļuve tiek pārskatīta, un izveido uzdevumus pakalpojumu identitāšu pārklājumam un noņemšanas pārbaudei. Ietvariem specifiskās sasaistes saglabā šos ierobežojumus.

Rezultāts ir pārskatīts kontroles ieraksts ar ierobežotiem pierādījumiem un atvērtu novēršanu. Tas ir noderīgāks par vairākiem pārliecinošiem aprakstiem, jo inženieri zina, kas jālabo, un auditori var pārbaudīt, kas pamato apgalvojumu.

Padariet atbilstības uzturēšanu notikumu vadītu

Nepārtrauktai atbilstībai būtu jānozīmē pierādījumu un lēmumu uzturēšana, kad notiek būtiskas izmaiņas. Tai nevajadzētu nozīmēt, ka MI nepārtraukti pierāda katras kontroles efektivitāti.

Kā praktisku rekomendāciju apvienojiet plānotas pārskatīšanas ar izmaiņu ierosinātājiem: jauns pakalpojumu sniedzējs, mainīts autentifikācijas risinājums, pārskatīts ietvars, beidzies pierādījumu periods vai nozīmīgs incidents. Nosakiet skartās kontroles, sasaistes, īpašniekus un ziņojumus un, ja nepieciešams, pieprasiet jaunus pierādījumus.

Saglabājiet statusus atsevišķus: ierosināts, gaida pierādījumus, pārskatīts, apstiprināts un atvērta novēršana nedrīkst saplūst vienā zaļā indikatorā. Izsekojiet tādus rādītājus kā nokavētas pārskatīšanas, nepamatoti apgalvojumi, neatrisināti izņēmumi un pierādījumu vecums. Tie skaidrāk atklāj darba slodzi un pārliecības kvalitāti nekā dokumentu skaits.

Aizsargājiet pašu atbilstības darbvietu

Atbilstības materiāli atklāj arhitektūru, vājās vietas, iekšējos procesus un dažkārt personas datus. Izvērtējiet mitināšanas vietu kopā ar pakalpojumu sniedzēja piekļuvi, apakšapstrādātājiem, glabāšanu, dzēšanu, modeļu izmantošanas noteikumiem un piemērojamo nosūtīšanas kārtību. Datu atrašanās vieta ES vai Vācijā viena pati nenodrošina suverenitāti vai atbilstību VDAR.

Piemērojiet mazāko privilēģiju piekļuvi un nošķiriet melnrakstu sagatavošanu no apstiprināšanas. Pirms pierādījumu augšupielādes aizsargājiet akreditācijas datus un nevajadzīgu personas informāciju. Pieprasiet izsekojamību būtiskām izmaiņām un nosakiet, kā pārskatītāji apstrīd MI secinājumu. Cilvēka apstiprinājumam jānozīmē pamatojuma pārbaude un nenoteiktības novēršana, nevis rindas noklikšķināšana.

Sāciet ar vienu pārskatāmu darba plūsmu

Secani atbalsta mērķtiecīgu sākumu: modelējiet pakalpojumu vai organizatorisko vienību, izmantojot reālus mērķa objektus, sasaistiet tās sistēmas un ārējos pakalpojumu sniedzējus un nosauciet īpašniekus un pārskatītājus. Augšupielādējiet esošās politikas, eksportus, ekrānuzņēmumus un aprakstus; sasaistiet tos ar prasībām, kontrolēm, sistēmām vai lēmumiem, kurus tie atbalsta. Izmantojiet ar MI atbalstītus ieteikumus kā melnrakstus, pārbaudiet to avotus un saglabājiet komentārus, apstiprinājumus un laika zīmogus. Pārvērtiet trūkstošos vai novecojušos pierādījumus uzdevumos, nevis atstājiet tos apraktus dokumentos.

Pirmajam ciklam izvēlieties vienu kontroļu grupu un īsu pārskatīšanas ritmu. Pirms paplašināšanas pieprasiet skaidru ieviešanas aprakstu, aktuālus pamatojošos pierādījumus, pārskatītas sasaistes un piešķirtas nepilnības. Secani dokumentācija izskaidro šo sākuma darba plūsmu. Panākums ir izsekojams lēmums, ko nākamais pārskatītājs var atkārtot, nevis tikai lielāks ģenerēta teksta apjoms.