DI grįsta atitiktis

Nuo dokumentų iki struktūrizuotos atitikties darbo erdvės

DI grįsta atitiktis reiškia DI naudojimą struktūrizuotame, peržiūrimame atitikties procese, o ne tiesiog pokalbių roboto pridėjimą prie dokumentų saugyklos. Veikimo principas paprastas: DI pagreitina parengimą ir analizę, žmonės tvirtina svarbius sprendimus, o įrodymai lieka susieti su kiekvienu pagrįstu teiginiu.

Technologijų vadovui architektūrinis klausimas yra tai, ar sistema gali atvaizduoti faktines organizacijos kontrolės priemones. Politika aprašo numatytą elgseną. Konfigūracijos eksportas parodo nustatymą. Užbaigta prieigos peržiūra įrodo veiklą. Tai skirtingų rūšių įrodymai, o sklandaus teksto generavimas nepadaro jų tarpusavyje pakeičiamų.

Naudinga darbo erdvė susieja reikalavimus, kontrolės priemones, sistemas, įrodymus, atsakingus asmenis, užduotis ir sprendimus. Tokia struktūra leidžia komandoms pakartotinai naudoti pagrįstą informaciją skirtingose sistemose, nepainiojant panašių reikalavimų su lygiavertėmis prievolėmis.

Kodėl atskiri sistemų projektai sukuria techninę skolą

Organizacijos dažnai laiko politiką dokumentuose, įrodymus aplankuose, rizikas skaičiuoklėse, o taisymo užduotis projektų įrankiuose. Tada audito aprašymai atkuriami iš šių išsklaidytų šaltinių. Pridėjus dar vieną sistemą, dažnai sukuriama dar viena tos pačios informacijos kopija.

Pasekmės neapsiriboja administraciniu darbu. Atskiros komandos gali duoti inžinieriams prieštaringus nurodymus dėl to paties prieigos kontrolės proceso. Viename vertinime gali būti naudojamas pasenęs architektūros aprašymas, o kitame – dabartinė versija. Nušlifuota ataskaita gali paslėpti neišspręstą įgyvendinimo spragą.

Praktinė alternatyva yra bendras kontrolės priemonių modelis su konkrečioms sistemoms skirtais vaizdais. Įgyvendinimą palaikykite vieną kartą, pridėkite tinkamus įrodymus ir atskirai įvertinkite, kuriuos reikalavimus jis pagrindžia. Taip sumažinami dubliuojami prašymai, neištrinant taikymo srities, vertinimo laikotarpių ar teisinių pareigų skirtumų.

Prieš prašydami DI susieti kontrolės priemones, apibrėžkite taikymą

Pradėkite nuo organizacinių ribų: kuri paslauga, juridinis asmuo, sistemos, vietos ir paslaugų teikėjai įtraukti? Užfiksuokite sistemos versiją ir priežastį, kodėl taikoma kiekviena prievolė. Kitaip DI gali pateikti įtikinamus susiejimus reikalavimams, kurie nepatenka į faktinę taikymo sritį.

Skirtumai svarbūs:

• BSI IT-Grundschutz, kuris yra pagrindinis Secani dokumentuotų darbo eigų dėmesio objektas, sujungia informacijos saugumo metodiką su modulių kompendiumu. Sumodeliuokite į taikymo sritį patenkančius tikslinius objektus ir parinkite taikomus modulius, o ne laikykite kompendiumo visuotiniu kontroliniu sąrašu.
• ISO/IEC 27001 susijęs su apibrėžtos taikymo srities informacijos saugumo valdymo sistema. Jo valdymo sistemos reikalavimai, rizikos tvarkymas, taikymo pareiškimas, vidaus auditas ir vadovybės peržiūra išlieka atskiri rezultatai.
• NIS2 įgyvendinama per nacionalinę teisę. Taikymas priklauso nuo sektoriaus, dydžio, paslaugų ir įtraukimo taisyklių; sertifikavimas neįrodo atitikties.
• DORA pirmiausia taikomas tam tikriems finansų subjektams. IRT paslaugų teikėjams gali tekti sutartinių prievolių, o paskirtiems ypatingos svarbos paslaugų teikėjams taikomas atskiras priežiūros režimas.
• BDAR prievolės priklauso nuo duomenų tvarkymo ir organizacinių vaidmenų. Vien saugumo įrodymai neįrodo atitikties šiam reglamentui.

Taikymą laikykite patvirtintais įvesties duomenimis, o ne modelio tyliai padaryta išvada. Neaiškiais atvejais sukurkite aiškią aiškinimo užduotį su atsakingu peržiūrėtoju.

Prieš generuodami dokumentus, sukurkite įrodymų modelį

Praktinis minimalus modelis turėtų atskirti reikalavimą, įgyvendintą kontrolės priemonę, pagrindžiančius įrodymus ir peržiūros sprendimą. Įkeltas failas pats savaime nėra kontrolės priemonė, o patvirtinta politika neįrodo, kad procedūra nuosekliai veikia.

Priklausomybės taip pat priklauso modeliui. Klientams skirta programa gali priklausyti nuo tapatybių teikėjo, debesijos infrastruktūros ir valdomos pagalbos komandos. Vienos priklausomybės įrodymai neturi būti automatiškai laikomi visos paslaugos įrodymu.

Tokia struktūra padaro silpną aprėptį matomą: prieigos politika gali būti aktuali, o peržiūros įrašų trūkti, arba konfigūracijos ekrano nuotrauka gali apimti tik vieną aplinką.

DI naudokite susiejimų kandidatams, o ne automatiniam lygiavertiškumui

DI gali padėti išgauti susijusias ištraukas, siūlyti ryšius, nustatyti trūkstamą pagrindimą ir rengti kontrolės priemonių aprašymų juodraščius. Pateikite jam identifikuotas šaltinių versijas ir faktinį įgyvendinimą, o ne vien kontrolės priemonių pavadinimus.

Naudingas susiejimo pasiūlymas paaiškina, kuri dalis sutampa, kokie įrodymai pagrindžia šią sankirtą ir kas lieka neišspręsta. Ryšiai dažnai yra „daug su daug“: viena kontrolės priemonė pagrindžia kelis reikalavimus, o vienam reikalavimui reikia kelių kontrolės priemonių.

Incidentų valdymas gerai iliustruoja šią ribą. Bendras reagavimo procesas gali pagrįsti kelias sistemas, tačiau pranešimo slenksčiai, gavėjai, paleidikliai ir terminai gali skirtis. Pakartotinai naudojant veiklos procesą, neįvykdoma kiekviena pranešimo pareiga.

Prieš tvirtindami pakartotinį naudojimą, peržiūrėtojai turėtų patikrinti trūkstamą taikymo sritį, prieštaringus šaltinius, pasenusias nuorodas ir nepagrįstus teiginius. Išsaugokite pagrindimą kartu su ryšiu, kad vėlesnį sistemos ar įgyvendinimo pakeitimą būtų galima įvertinti apgalvotai. Mūsų veiklos rizikos registro vadove tas pats peržiūrimos pagalbos principas taikomas scenarijams ir sprendimams dėl rizikos tvarkymo.

Įrodymų rinkimui ir dokumentų rengimui reikia skirtingų apsaugos priemonių

Įrodymus rinkite iš autoritetingų sistemų kontroliuojamu procesu, nesvarbu, ar tai rankiniai eksportai, ar įvertintas surinkimo mechanizmas. Užfiksuokite, kas juos surinko, kada ir kokią visumą jie apima. Nemanykite, kad DI palaikantis produktas automatiškai turi prieigą prie veiklos sistemų.

DI padedamas išgavimas turėtų išsaugoti šaltinio ištrauką ar įrašą, pagrindžiantį kiekvieną išvadą. Ypač atidžiai peržiūrėkite, kai dokumentuose yra prieštaringų teiginių, ekrano nuotraukose nėra datų arba eksportuotuose duomenyse nėra kai kurių paskyrų. Trūkstami įrodymai turėtų lemti klausimą ar užduotį, o ne išgalvotą teiginį, kad kontrolės priemonė veikia.

Generuojamiems dokumentams naudokite nuoseklią rengimo struktūrą: paskirtis, taikymo sritis, įgyvendinimas, atsakingas asmuo, įrodymai, išimtys ir peržiūros būsena. Atskirkite numatytas procedūras nuo stebimo veikimo. Ataskaitose turėtų būti naudojamos peržiūrėtos kontrolės priemonės ir atskleidžiamos reikšmingos spragos, o ne juodraščių pasiūlymai paverčiami galutiniu užtikrinimu.

Įkelta medžiaga taip pat turi būti laikoma nepatikimais įvesties duomenimis. Dokumentuose įterpti nurodymai neturi pakeisti peržiūros darbo eigos ar leisti atlikti veiksmų. Skaitymo prieiga analizei neturėtų reikšti leidimo keisti kontrolės priemones, tvirtinti sprendimus ar platinti ataskaitas.

Pavyzdys: viena prieigos peržiūra, keli panaudojimai

Panagrinėkime iliustracinę SaaS komandą, dokumentuojančią vieną gamybinę paslaugą. Tarkime, kad ji turi patvirtintą prieigos politiką, datuotą tapatybių teikėjo eksportą, ketvirtinių peržiūrų įrašus ir atvirą užduotį pašalinti dvi nereikalingas administratorių paskyras. Jokių sutaupymų ar produkto veikimo rezultatų nedaroma prielaidų.

Pirmiausia komanda apibrėžia ribas: gamybinės paskyros įtrauktos; atskira tyrimų aplinka neįtraukta. Tada ji susieja politiką su numatytu peržiūros procesu, o užbaigtus įrašus – su peržiūros veikla.

DI pasiūlo prieigos kontrolės aprašymą ir sistemų susiejimų kandidatus. Peržiūrėtojas nustato tris problemas:

• Eksportas apima žmonių paskyras, bet ne paslaugų tapatybes.
• Peržiūros įrašai rodo sprendimus, tačiau dviejų administratorių paskyrų panaikinimo įrodymų trūksta.
• Politikoje nurodytos ketvirtinės peržiūros, o viena užbaigta peržiūra vėlavo.

Peržiūrėtojas patvirtina pagrįstą aprašymą, atmeta teiginį, kad peržiūrima visa privilegijuota prieiga, ir sukuria užduotis paslaugų tapatybių aprėpčiai ir panaikinimo patikrinimui. Konkrečioms sistemoms skirti susiejimai išlaiko šiuos apribojimus.

Rezultatas yra peržiūrėtas kontrolės priemonės įrašas su apibrėžtais įrodymais ir atviru taisymu. Jis naudingesnis nei keli įtikinamai skambantys aprašymai, nes inžinieriai žino, ką taisyti, o auditoriai gali patikrinti, kas pagrindžia teiginį.

Atitikties palaikymą grįskite įvykiais

Nuolatinė atitiktis turėtų reikšti įrodymų ir sprendimų palaikymą, kai įvyksta susiję pokyčiai. Ji neturėtų reikšti, kad DI nuolat įrodo kiekvienos kontrolės priemonės veiksmingumą.

Praktiškai rekomenduojama suplanuotas peržiūras derinti su pokyčių paleidikliais: naujas paslaugų teikėjas, pakeistas autentifikavimo sprendimas, atnaujinta sistema, pasibaigęs įrodymų laikotarpis ar reikšmingas incidentas. Nustatykite paveiktas kontrolės priemones, susiejimus, atsakingus asmenis ir ataskaitas, o prireikus paprašykite naujų įrodymų.

Būsenas laikykite atskirai: pasiūlyta, laukiama įrodymų, peržiūrėta, patvirtinta ir atviras taisymas neturėtų susilieti į vieną žalią indikatorių. Sekite tokius rodiklius kaip vėluojančios peržiūros, nepagrįsti teiginiai, neišspręstos išimtys ir įrodymų amžius. Jie aiškiau nei dokumentų skaičius atskleidžia darbo krūvį ir užtikrinimo kokybę.

Apsaugokite pačią atitikties darbo erdvę

Atitikties medžiaga atskleidžia architektūrą, silpnąsias vietas, vidinius procesus ir kartais asmens duomenis. Talpinimo vietą vertinkite kartu su paslaugų teikėjo prieiga, subtvarkytojais, saugojimu, ištrynimu, modelio naudojimo sąlygomis ir taikoma perdavimo tvarka. Vien duomenų buvimo vieta ES ar Vokietijoje neįrodo suverenumo ar atitikties BDAR.

Taikykite mažiausių privilegijų prieigą ir atskirkite rengimą nuo tvirtinimo. Prieš įkeldami įrodymus, apsaugokite prisijungimo duomenis ir nereikalingą asmeninę informaciją. Reikalaukite reikšmingų pakeitimų atsekamumo ir nustatykite, kaip peržiūrėtojai ginčija DI išvadą. Žmogaus patvirtinimas turi reikšti pagrindimo patikrinimą ir neapibrėžtumo išsprendimą, o ne mechanišką eilės patvirtinimą.

Pradėkite nuo vienos peržiūrimos darbo eigos

Secani palaiko tikslinę pradžią: sumodeliuokite paslaugą ar organizacinį padalinį naudodami tikrus tikslinius objektus, susiekite jo sistemas ir išorės paslaugų teikėjus, įvardykite atsakingus asmenis ir peržiūrėtojus. Įkelkite esamą politiką, eksportus, ekrano nuotraukas ir aprašymus; susiekite juos su reikalavimais, kontrolės priemonėmis, sistemomis ar sprendimais, kuriuos jie pagrindžia. DI padedamus pasiūlymus naudokite kaip juodraščius, tikrinkite jų šaltinius ir išsaugokite komentarus, patvirtinimus bei laiko žymas. Trūkstamus ar pasenusius įrodymus paverskite užduotimis, o ne palikite juos palaidotus dokumentuose.

Pirmajam ciklui pasirinkite vieną kontrolės priemonių grupę ir trumpą peržiūros ritmą. Prieš plėsdami reikalaukite aiškaus įgyvendinimo aprašymo, aktualių pagrindžiančių įrodymų, peržiūrėtų susiejimų ir paskirstytų spragų. Secani dokumentacijoje paaiškinama ši pradinė darbo eiga. Sėkmė yra atsekamas sprendimas, kurį kitas peržiūrėtojas gali atkartoti, o ne vien didesnis sugeneruoto teksto rinkinys.