Nuo skenavimų iki įrodymų: ISO 27001:2022, NIS2, DORA

Pirmadienį 08:16 val. iš interneto pasiekiamame taikomosios programos serveryje ką tik aptiktas kritinis nuotolinio kodo vykdymo pažeidžiamumas. Infrastruktūros komanda teigia, kad tiekėjo pataisa jau prieinama. Taikomosios programos savininkas įspėja, kad serveris palaiko pajamoms kritiškai svarbią klientų darbo eigą. Teisės skyrius klausia, ar išnaudojimas galėtų sukelti pranešimo pareigą pagal NIS2, DORA arba GDPR. CISO pareigas einanti Marija atsidaro audito kalendorių ir pamato tikrąją problemą: ISO 27001:2022 priežiūros auditas prasideda kitą savaitę, NIS2 pasirengimo peržiūra jau vyksta, o didelis fintech klientas paprašė DORA įrodymų.

Skenavimo priemonė rodo raudoną indikatorių. Užduočių lenta rodo veiklą. Skaičiuoklė rodo pastangas. Tačiau nė vienas iš šių dalykų savaime neįrodo kontrolės priemonės veikimo.

Būtent šią spragą daugelis organizacijų pastebi per vėlai. Pažeidžiamumų skenavimas nėra tas pats, kas auditui parengtas pažeidžiamumų valdymas. Skenavimas parodo, kad kažkas gali būti negerai. Audito įrodymai pagrindžia, kad organizacija žinojo, kokį turtą turi, įvertino riziką, priskyrė savininkystę, veikė pagal politiką, kontroliavo pakeitimus, dokumentavo išimtis, patikrino rezultatus ir peržiūrėjo baigtį.

ISO/IEC 27001:2022, NIS2 ir DORA kontekste ši įrodymų grandinė yra tokia pat svarbi kaip ir techninis ištaisymas. Skenavimo priemonė pradeda istoriją. Turto registras, pažeidžiamumų registras, užduotis, rizikos sprendimas, pakeitimo įrašas, pataisų žurnalas, patikrinimo įrodymai, išimties patvirtinimas ir vadovybės peržiūra ją užbaigia.

Clarysec požiūris paprastas: pažeidžiamumų valdymas neturi būti mėnesinis techninis ritualas. Jis turi būti valdoma įrodymų darbo eiga.

Kodėl skenavimo ataskaitos nėra pakankami audito įrodymai

Pažeidžiamumų skenavimas yra konkretaus momento techninės būklės fiksavimas. Jis gali nustatyti CVE, trūkstamą pataisą, nebepalaikomą biblioteką, pasiekiamą paslaugą arba silpną konfigūraciją. Tai naudinga, bet nepakankama.

Auditorius užduos kitokius klausimus:

• Ar paveiktas turtas buvo taikymo srityje?
• Kas yra turto ir verslo paslaugos savininkas?
• Ar pažeidžiamumas buvo įvertintas pagal pasiekiamumą, išnaudojamumą, verslo poveikį ir duomenų jautrumą?
• Ar taisomieji veiksmai buvo atlikti per nustatytą terminą?
• Jei taisomieji veiksmai buvo atidėti, kas priėmė liekamąją riziką?
• Ar pataisa buvo įdiegta taikant kontroliuojamą pakeitimų valdymą?
• Ar ištaisymas buvo patikrintas pakartotiniu skenavimu arba techniniu patikrinimu?
• Ar įrodymai buvo išsaugoti ir peržiūrėti vadovybės?

Skenavimo eksportų aplankas retai atsako į šiuos klausimus. ISO 27001:2022 audito metu auditorius tikrina, ar ISVS veikia taip, kaip suprojektuota. Pagal NIS2 valdymo organai privalo patvirtinti ir prižiūrėti kibernetinio saugumo rizikos valdymo priemones. Pagal DORA finansų subjektams reikia dokumentuotos IRT rizikos valdymo sistemos, incidentų gyvavimo ciklo, atsparumo testavimo ir IRT trečiųjų šalių rizikos kontrolės priemonių. Pagal GDPR klausimas tampa toks: ar tinkamos techninės ir organizacinės priemonės apsaugojo asmens duomenis ir ar galima įrodyti atskaitomybę.

ISO/IEC 27001:2022 4.1–4.4 punktai reikalauja, kad organizacija suprastų savo kontekstą, suinteresuotąsias šalis, reikalavimus ir ISVS taikymo sritį. Pažeidžiamumų ir pataisų valdymas negali būti projektuojamas izoliuotai. Jis turi atspindėti klientų sutartis, reguliavimo institucijas, debesijos priklausomybes, išorines IRT paslaugas, duomenų apsaugos įsipareigojimus ir kritines paslaugas.

ISO/IEC 27001:2022 6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, kontrolės priemonių parinkimo, Taikytinumo pareiškimo ir rizikos savininko patvirtinimo dėl liekamosios rizikos. Tai reiškia, kad pažeidžiamumų įrodymai turi būti susieti su rizikų registru, rizikos tvarkymo planu ir SoA.

ISO/IEC 27005:2022 sustiprina šį modelį, skatindamas organizacijas į rizikos vertinimo bazinį pagrindą sujungti A priedo reikalavimus, sektoriaus įpareigojimus, reglamentus, sutartis, vidaus taisykles ir esamas kontrolės priemones. Jame taip pat pabrėžiami tikėtinumo, pasekmių, teisinių prievolių, tiekėjų santykių, poveikio privatumui ir poveikio trečiosioms šalims kriterijai. Praktikoje pažeidžiamumas nėra vien CVSS skaičius. Tai rizikos įvykis, susietas su turtu, įpareigojimais, suinteresuotosiomis šalimis ir verslo pasekmėmis.

Reglamentavimo spaudimas pataisų įrodymams

Šiuolaikinis kibernetinio saugumo reglamentavimas vis mažiau toleruoja neformalų pataisų diegimą.

NIS2 taikoma daugeliui vidutinių ir didelių subjektų aukšto kritiškumo ir kritiniuose sektoriuose, taip pat gali būti taikoma tam tikriems subjektams nepriklausomai nuo dydžio. Jos taikymo sritis apima skaitmeninės infrastruktūros teikėjus, tokius kaip debesijos paslaugos, duomenų centrų paslaugos, turinio pristatymo tinklai, viešųjų elektroninių ryšių paslaugų teikėjai, patikimumo užtikrinimo paslaugos, DNS ir TLD paslaugos, taip pat IRT paslaugų valdymo teikėjus, įskaitant valdomų paslaugų teikėjus ir valdomo saugumo paslaugų teikėjus. Ji taip pat apima svarbius skaitmeninių paslaugų teikėjus, tokius kaip internetinės prekyvietės, interneto paieškos sistemos ir socialinių tinklų platformos.

NIS2 Article 20 kibernetinį saugumą priskiria valdymo organų atsakomybei. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų tvarkymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, saugų kūrimą, saugią priežiūrą, pažeidžiamumų tvarkymą ir atskleidimą, veiksmingumo vertinimą, kibernetinę higieną, prieigos kontrolę, turto valdymą ir autentifikavimą. Article 23 nustato etapais vykdomą reikšmingų incidentų pranešimo procesą, įskaitant ankstyvąjį įspėjimą per 24 valandas, pranešimą per 72 valandas ir, kai taikoma, galutinę ataskaitą per vieną mėnesį.

DORA nuo 2025 m. sausio 17 d. sukuria tiesiogiai taikomą skaitmeninio operacinio atsparumo taisyklių rinkinį finansų subjektams. Ji apima IRT rizikos valdymą, reikšmingų IRT incidentų pranešimą, operacinio atsparumo testavimą, dalijimąsi kibernetinių grėsmių žvalgyba, IRT trečiųjų šalių rizikos valdymą ir kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrą. Articles 5 ir 6 IRT rizikos valdyseną priskiria valdymo organui ir reikalauja dokumentuotos, integruotos ir reguliariai peržiūrimos IRT rizikos valdymo sistemos. Article 8 sustiprina poreikį identifikuoti IRT palaikomas verslo funkcijas, informacijos išteklius, IRT turtą ir priklausomybes. Articles 17–20 reikalauja su IRT susijusiems incidentams taikyti aptikimą, registravimą, klasifikavimą, eskalavimą, pranešimą, informavimą, taisomuosius veiksmus ir įgytos patirties panaudojimą. Articles 28–30 reikalauja IRT trečiųjų šalių riziką valdyti per registrus, deramą patikrinimą, sutartines apsaugos priemones, audito teises, pasitraukimo planavimą ir priežiūrą.

Finansų subjektams, kuriems taikoma DORA, DORA paprastai pakeičia lygiaverčius NIS2 rizikos valdymo ir pranešimų teikimo įpareigojimus. Tačiau NIS2 išlieka svarbi ekosistemos koordinavimui ir subjektams, nepatenkantiems į DORA taikymo sritį. SaaS, MSP ir MSSP teikėjams, aptarnaujantiems finansų sektoriaus klientus, praktinė realybė tiesioginė: klientai gali reikalauti jūsų pažeidžiamumų įrodymų, kad įvykdytų savo DORA įpareigojimus.

GDPR prideda dar vieną sluoksnį. Articles 2 ir 3 gali būti taikomi ES įsteigtoms organizacijoms ir ne ES organizacijoms, siūlančioms prekes ar paslaugas žmonėms ES arba stebinčioms jų elgseną. Article 5 reikalauja asmens duomenų apsaugos ir atskaitomybės už atitiktį. Article 4 asmens duomenų saugumo pažeidimą apibrėžia kaip saugumo incidentą, dėl kurio atsitiktinai ar neteisėtai prarandami, sunaikinami, pakeičiami, neautorizuotai atskleidžiami asmens duomenys arba prie jų suteikiama prieiga. Atidėta duomenų bazės, tapatybės platformos ar klientų portalo pataisa gali tapti privatumo atskaitomybės klausimu.

Nuo politikos iki įrodymo

Pirmasis žingsnis – apibrėžti taisykles. Stipri pažeidžiamumų ir pataisų valdymo politika nėra vien audito dokumentas. Tai kontrolės priemonės veikimo konstitucija.

Įmonių aplinkoms Pažeidžiamumų ir pataisų valdymo politika aiškiai susieja techninį pataisų diegimą su kelių atitikties sistemų reikalavimais:

Ši politika palaiko atitiktį ISO/IEC 27001 A priedo kontrolės priemonei 8.8 ir ISO/IEC 27002 gairėms bei apima reglamentavimo reikalavimus pagal DORA Article 8, NIS2 Article 21, GDPR Article 32 ir COBIT 2019 DSS bei APO sritis.

Iš skyriaus „Tikslas“.

Ta pati politika nustato valdysenos lūkestį pagrindiniam įrodymų artefaktui:

Centralizuotą pažeidžiamumų valdymo registrą turi prižiūrėti Saugumo operacijų komanda, o CISO arba įgaliotas asmuo turi jį peržiūrėti kas mėnesį.

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.1.

Ji taip pat apibrėžia skenavimo periodiškumą:

Visos sistemos turi būti skenuojamos bent kartą per mėnesį; didelės rizikos arba iš išorės pasiekiamas turtas turi būti skenuojamas kas savaitę.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.

Ir neleidžia skubiam pataisų diegimui tapti nekontroliuojama technine veikla:

Visos taisomųjų veiksmų veiklos turi būti koordinuojamos per pakeitimų valdymo procesą pagal P5 – Pakeitimų valdymo politiką, siekiant užtikrinti stabilumą ir išsaugoti audito pėdsaką.

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.5.

MVĮ tuos pačius įrodymų principus galima įgyvendinti paprasčiau. Pažeidžiamumų ir pataisų valdymo politika MVĮ nurodo:

Tvarkyti tikslius įrašus apie pritaikytas pataisas, neišspręstas problemas ir išimtis, kad būtų užtikrintas pasirengimas auditui

Iš skyriaus „Tikslai“, politikos punktas 3.4.

Tada ji apibrėžia pataisų žurnalą kaip audito įrodymą:

Pataisų žurnalas turi būti prižiūrimas ir peržiūrimas audito bei reagavimo į incidentus veiklų metu

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.1.

Ir nustato minimalų turinį:

Žurnaluose turi būti nurodytas įrenginio pavadinimas, pritaikytas atnaujinimas, pataisos diegimo data ir bet kokio vėlavimo priežastis

Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.2.

Skubiam iš interneto pasiekiamam turtui MVĮ politika nustato išmatuojamą reikalavimą:

Kritinės pataisos turi būti pritaikytos per 3 dienas nuo išleidimo, ypač iš interneto pasiekiamoms sistemoms

Iš Pažeidžiamumų ir pataisų valdymo politika MVĮ, skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.

Šie punktai techninį darbą paverčia įrodymais. Politika apibrėžia lūkesčius. Registras fiksuoja išvadas. Užduotis priskiria darbą. Pakeitimo įrašas kontroliuoja diegimą. Pataisų žurnalas įrodo veiksmą. Rizikų registras fiksuoja išimtis. Peržiūros protokolai įrodo priežiūrą.

Clarysec į įrodymus orientuotas modelis

Clarysec į įrodymus orientuotas modelis prasideda nuo vieno principo: kiekviena pažeidžiamumo išvada turi būti atsekama nuo aptikimo iki sprendimo.

Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas etape „Kontrolės priemonės veiksme“, 19 žingsnyje „Technologinės kontrolės priemonės I“, pažeidžiamumų valdymas vertinamas kaip kartotinė kontrolės priemonė, o ne teorinis reikalavimas:

Pažeidžiamumų valdymas yra viena kritiškiausių šiuolaikinės kibernetinės higienos sričių. Nors ugniasienės ir antivirusinės programinės įrangos priemonės suteikia apsaugą, ji gali būti susilpninta, jei nepataisytos sistemos arba neteisingai sukonfigūruotos paslaugos lieka pasiekiamos.

Tas pats žingsnis paaiškina, kad organizacijos turėtų naudoti reguliarius pataisų diegimo grafikus, pažeidžiamumų skenavimo priemones, pirminį įvertinimą, priskyrimą, taisomųjų veiksmų vykdymo sekimą, kompensuojančias kontrolės priemones ir liekamosios rizikos priėmimą. Svarbiausia – jis teisingai suformuluoja audito mąstyseną:

Kontrolės priemonės esmė nėra tobulybė; esmė – organizuotas, skaidrus ir atskaitingas procesas.

Auditoriams šis skirtumas svarbus. Brandžioje organizacijoje gali būti atvirų pažeidžiamumų ir ji vis tiek gali įrodyti kontrolę, jei taiko rizika grindžiamą prioritetizavimą, dokumentuotą savininkystę, patvirtintas išimtis, kompensuojančias kontrolės priemones ir patikrintus taisomuosius veiksmus.

Zenith Blueprint taip pat įspėja, kad auditoriai šią sritį tikrins atidžiai:

Tai yra aukšto prioriteto kontrolės priemonė auditoriams, ir jie paprastai ją nagrinėja išsamiai. Tikėkitės klausimų, kaip dažnai diegiate pataisas sistemose, kokio proceso laikotės paskelbus nulinės dienos pažeidžiamumą ir kurias sistemas sunkiausia pataisyti.

Todėl CISO neturėtų eiti į auditą turėdamas vien skenavimo priemonės valdymo skydą. Įrodymų paketas turi parodyti valdyseną, procesą, vykdymą, patikrinimą ir tobulinimą.

ISO 27002 kontrolės priemonių susiejimas su audito įrodymais

Zenith Controls: kelių atitikties sistemų vadovas veikia kaip kelių atitikties sistemų kompasas: jis susieja ISO/IEC 27002:2022 kontrolės priemones ir parodo, kaip jos siejasi su audito lūkesčiais. Pažeidžiamumų ir pataisų valdymui trys ISO/IEC 27002:2022 kontrolės priemonės sudaro veikimo trikampį.

ISO/IEC 27002:2022 kontrolės priemonė 8.8 „Techninių pažeidžiamumų valdymas“ yra centrinė kontrolės priemonė. Ji yra prevencinė, palaiko konfidencialumą, vientisumą ir prieinamumą, dera su kibernetinio saugumo sąvokomis Identify ir Protect bei siejasi su grėsmių ir pažeidžiamumų valdymu.

ISO/IEC 27002:2022 kontrolės priemonė 8.32 „Pakeitimų valdymas“ taip pat yra prevencinė. Ji susieja pataisų diegimą su kontroliuojamu diegimu, testavimu, patvirtinimu, grąžinimu į ankstesnę būseną ir audituojamumu.

ISO/IEC 27002:2022 kontrolės priemonė 5.36 „Atitiktis informacijos saugumo politikoms, taisyklėms ir standartams“ užtikrina, kad procesas nebūtų pasirenkamas arba priklausomas nuo pavienių asmenų pastangų. Ji susieja pažeidžiamumų valdymą su politikos laikymusi, patikinimu ir priežiūra.

Šis susiejimas padeda išvengti dažnos audito nesėkmės. Saugumo komanda sako: „Pataisėme.“ Operacijų komanda sako: „Įdiegėme.“ Atitikties komanda sako: „Negalime įrodyti sekos.“ Susieta įrodymų grandinė suteikia visoms trims komandoms tą pačią istoriją.

Įrodymų grandinė, kurios tikisi auditoriai

Pagrįsta pažeidžiamumų valdymo įrodymų grandinė turi septynis etapus.

Praktinis skirtumas tarp „vykdome skenavimus“ ir „esame pasirengę auditui“ yra tęstinumas. Jei pažeidžiamumo negalima atsekti nuo aptikimo iki uždarymo, kontrolės priemonė silpna. Jei išimtys egzistuoja, bet niekas jų nepatvirtino, procesas silpnas. Jei pataisos apeina pakeitimų valdymą, audito pėdsakas silpnas. Jei kritiniai pažeidžiamumai lieka atviri be kompensuojančių kontrolės priemonių, valdysena silpna.

Audito ir atitikties stebėsenos politika palaiko automatizavimą kaip šio modelio dalį:

Automatizuotos priemonės turi būti diegiamos konfigūracijos atitikčiai, pažeidžiamumų valdymui, pataisų būsenai ir privilegijuotajai prieigai stebėti.

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.4.1.

MVĮ atveju Audito ir atitikties stebėsenos politika MVĮ techninių kontrolės priemonių patikrinimą apibrėžia praktiniais terminais:

Techninių kontrolės priemonių patikrinimas (pvz., atsarginių kopijų būsena, prieigos kontrolės konfigūracija, pataisų įrašai)

Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.2.

Mažoms organizacijoms nereikia įmonių klasės įrankių, kad jos būtų pasirengusios auditui. Joms reikia nuoseklių įrodymų. Lengvas registras, užduočių lenta, pataisų žurnalas ir mėnesinė peržiūra gali būti pakankami, jei jie yra išsamūs, aktualūs ir susieti su rizika.

Pavyzdys: viena kritinė išvada, visiškai tinkama auditui

Marijos savaitinis išorinis skenavimas nustato CVE-2026-12345 iš interneto pasiekiamame mokėjimų API šliuze. Skenavimo priemonė jį įvertina kaip kritinį. Paslauga tvarko klientų tapatybės ir operacijų metaduomenis, todėl galimos GDPR ir DORA pasekmės. Šliuzo savininkė yra Platform Engineering komanda, tačiau pataisai reikia trumpos prastovos.

Toliau pateikiama auditui tinkama darbo eiga.

1. Sukurti įrašą pažeidžiamumų registre

Saugumo komanda užregistruoja išvadą centriniame registre:

• Išvados ID: VULN-2026-0142
• Šaltinis: savaitinis išorinis skenavimas
• Aptikimo data ir laikas
• Turtas: api-gw-prod-01
• Savininkas: Platform Engineering
• Pasiekiamumas: iš interneto pasiekiamas
• Duomenų kontekstas: klientų tapatybės ir operacijų metaduomenys
• Sunkumas: kritinis
• SLA: 72 valandos arba griežčiau pagal politiką
• Užduotis: SEC-4821
• Pakeitimo įrašas: CHG-10988
• Būsena: taisomieji veiksmai suplanuoti

2. Atlikti pirminį įvertinimą pagal verslo ir reglamentavimo kontekstą

Komanda patikrina išnaudojimo prieinamumą, atakos paviršių, autentifikavimo reikalavimus, verslo poveikį ir duomenų jautrumą. Kadangi sistema yra pasiekiama iš interneto ir palaiko klientų darbo eigas, pažeidžiamumas lieka kritinis. Rizikos savininkas yra platformos vadovas, o CISO informuojamas dėl galimų NIS2, DORA ir GDPR pasekmių.

ISO/IEC 27005:2022 7.1–7.4 punktai palaiko rizikų identifikavimą, savininkystę, pasekmes, tikėtinumą ir prioritetizavimą. 8.2–8.6 punktai palaiko rizikos tvarkymo pasirinkimą, kontrolės priemonių nustatymą, SoA sąsają, tvarkymo planavimą ir liekamosios rizikos patvirtinimą.

3. Atidaryti kontroliuojamą neatidėliotiną pakeitimą

Pataisa suplanuojama tą patį vakarą. Pakeitimo įraše pateikiama tiekėjo nuoroda, paveiktos paslaugos, testavimo planas, grąžinimo į ankstesnę būseną planas, priežiūros langas, sprendimas dėl klientų informavimo, patvirtinimai ir patikrinimo po diegimo reikalavimas.

Tai tiesiogiai palaiko ISO/IEC 27002:2022 kontrolės priemonę 8.32 ir įmonės politikos reikalavimą koordinuoti taisomuosius veiksmus per pakeitimų valdymą.

4. Pritaikyti pataisą ir atnaujinti pataisų žurnalą

Pataisų žurnale įrašomas įrenginio pavadinimas, pritaikytas atnaujinimas, pataisos diegimo data ir, jei buvo, vėlavimo priežastis. Jei pataisos diegimas būtų buvęs atidėtas, komanda dokumentuotų kompensuojančias kontrolės priemones, tokias kaip žiniatinklio taikomųjų programų ugniasienės taisyklės, laikini prieigos apribojimai, išplėstinis žurnalavimas, izoliavimas arba sustiprinta stebėsena.

5. Patikrinti ir uždaryti

Saugumo komanda pakartotinai skenuoja API šliuzą. Pažeidžiamumas nebepasirodo. Užduotis atnaujinama švaraus skenavimo įrodymais, pataisos versija, diegimo laiko žyma ir pakeitimo įrašo nuoroda. Pažeidžiamumų registro būsena pakeičiama į „Uždaryta, patikrinta“.

6. Peržiūrėti pranešimų teikimo poveikį

Jei išnaudojimo ir paslaugos sutrikimo nebuvo, NIS2 arba DORA incidentų pranešimai gali būti nesuaktyvinti. Jei randama kompromitavimo indikatorių, incidentų procesas turi klasifikuoti poveikį ir eskalavimą. Pagal NIS2 reikšmingam incidentui gali reikėti ankstyvojo įspėjimo ir etapinio pranešimų teikimo. Pagal DORA reikšmingas su IRT susijęs incidentas turi būti klasifikuojamas ir apie jį pranešama per taikomą kompetentingos institucijos procesą.

7. Įtraukti pamokas į vadovybės peržiūrą

Mėnesio pabaigoje CISO peržiūros pastabose nurodoma, kad pažeidžiamumas buvo aptiktas savaitiniu išoriniu skenavimu, pašalintas per SLA, patikrintas pakartotiniu skenavimu ir uždarytas be incidento. Jei panašios problemos kartojasi, rizikos tvarkymo plane gali būti numatytos saugios konfigūracijos bazinės nuostatos, automatizuotas pataisų diegimas, tiekėjo eskalavimas arba taikomosios programos modernizavimas.

Kai auditorius paklausia apie CVE-2026-12345, Marija gali pateikti sutvarkytą paketą, o ne el. laiškus ir ekrano kopijas.

Tai yra pasirengimas auditui. Ne todėl, kad organizacija neturėjo pažeidžiamumų, o todėl, kad ji turėjo kontrolę.

Vienas įrodymų rinkinys, keli įpareigojimai

Tinkamai sukurta pažeidžiamumų ir pataisų valdymo programa gali tenkinti kelių atitikties sistemų reikalavimus nedubliuojant darbo.

ISO 27001:2022 atveju įrodymai palaiko rizika grindžiamą ISVS, A priedo kontrolės priemonių įgyvendinimą, Taikytinumo pareiškimą, rizikos tvarkymo planus, vidaus auditą ir nuolatinį tobulinimą. Jei ISO/IEC 27002:2022 kontrolės priemonė 8.8 taikoma SoA, organizacija turi galėti parodyti teisinį, reglamentavimo, rizikos arba verslo pagrindimą. Toks pagrindimas dažnai apima NIS2 Article 21, DORA IRT rizikos įpareigojimus, GDPR atskaitomybę, klientų sutartis ir operacinio atsparumo poreikius.

NIS2 atveju tie patys įrodymai padeda pagrįsti Article 21 priemones, įskaitant rizikos analizę, pažeidžiamumų tvarkymą, incidentų tvarkymą, veiklos tęstinumą, tiekimo grandinės saugumą, kibernetinę higieną, prieigos kontrolę ir veiksmingumo vertinimą. Article 20 įrodomas per CISO peržiūrą, valdybos ataskaitas, vadovybės patvirtinimą ir kibernetinio saugumo mokymus. Article 23 tampa aktualus, jei išnaudojimas sukelia arba galėtų sukelti didelį veiklos sutrikimą, finansinius nuostolius arba žalą kitiems.

DORA atveju pažeidžiamumų ir pataisų įrodymai palaiko IRT rizikos valdymo sistemą, valdymo organo priežiūrą, atsparumo strategiją, incidentų aptikimą ir klasifikavimą, atsparumo testavimą ir IRT trečiųjų šalių priežiūrą. Kai IRT teikėjas talpina arba valdo paveiktą sistemą, Articles 28–30 reikalauja deramo patikrinimo, sutartinių apsaugos priemonių, audito teisių, pagalbos incidentų metu ir pasitraukimo svarstymų.

GDPR atveju tie patys įrodymai palaiko Article 5 atskaitomybę ir saugumo lygį, kurio tikimasi pagal Article 32. Jei pažeidžiamumas lemia neautorizuotą prieigą prie asmens duomenų, jų pakeitimą, praradimą arba atskleidimą, pažeidžiamumo laiko juosta, pataisų įrašai, stebėsenos žurnalai ir pažeidimo vertinimo pastabos tampa esminiai.

COBIT 2019 ir ISACA tipo patikinimui pažeidžiamumų valdymas vertinamas per operacinį saugumą, kontrolės stebėseną, pakeitimų įgalinimą ir valdysenos atskaitomybę. Zenith Blueprint kelių atitikties sistemų nuorodos išskiria COBIT 2019 DSS05.04 ir BAI09.02, taip pat ITAF patikinimo lūkesčius dėl pažeidžiamumų valdymo, pataisų diegimo ir saugaus pakeitimų valdymo.

Pagalbiniai ISO standartai sustiprina veikimo modelį. ISO/IEC 27005:2022 palaiko rizikos vertinimą ir tvarkymą. ISO/IEC 27035:2023 palaiko reagavimą į incidentus, kai pažeidžiamumai išnaudojami. ISO/IEC 30111 palaiko pažeidžiamumų tvarkymo procesus. ISO/IEC 29147 palaiko pažeidžiamumų atskleidimą ir saugumo pranešimus. ISO/IEC 27017 palaiko pažeidžiamumų valdymą debesijoje. ISO 22301 palaiko tęstinumo planavimą, kai techniniai pažeidžiamumai gali sutrikdyti verslo paslaugas.

Kaip skirtingi auditoriai tikrina tą patį procesą

Skirtingi vertintojai taiko skirtingas perspektyvas. Įrodymai gali būti tie patys, tačiau klausimai keičiasi.

Politika nurodo, kas turi vykti. Operaciniai įrodymai parodo, kas įvyko. Peržiūros įrašai parodo, kad vadovybė žinojo, kėlė klausimus ir veikė.

Dažnos priežastys, kodėl pataisų valdymas neišlaiko audito

Dauguma išvadų kyla ne dėl skenavimo priemonės nebuvimo. Jas lemia nutrūkęs atsekamumas.

Turto registras neišsamus.
Jei skenavimo priemonė randa turto, kurio nėra CMDB arba turto registre, savininkystės ir verslo poveikio neįmanoma patikimai įvertinti. Tai silpnina ISO 27001:2022 taikymo sritį, rizikos vertinimą ir tvarkymą.

Pažeidžiamumai sekami tik skenavimo priemonėje.
Skenavimo priemonių valdymo skydai nėra valdysenos registrai. Juose dažnai trūksta rizikos savininko patvirtinimo, išimties pagrindimo, pakeitimų nuorodų ir verslo konteksto.

Kritinėms išvadoms nėra SLA įrodymų.
Politika gali nurodyti, kad kritiniai pažeidžiamumai ištaisomi per tris dienas. Audito klausimas – ar įrašai įrodo, kad taip įvyko.

Išimtys neformalios.
Senosios sistemos, prastovų apribojimai ir tiekėjų vėlavimai pasitaiko. Tačiau „negalėjome įdiegti pataisos“ turi tapti dokumentuota išimtimi su kompensuojančiomis kontrolės priemonėmis, galiojimo pabaigos data ir liekamosios rizikos patvirtinimu.

Neatidėliotinas pataisų diegimas apeina pakeitimų valdymą.
Neatidėliotini pakeitimai vis tiek yra pakeitimai. Jei nėra patvirtinimo, testavimo ar grąžinimo į ankstesnę būseną įrodymų, auditoriai gali daryti išvadą, kad taisomieji veiksmai sukūrė operacinę riziką.

Trečiųjų šalių sistemos nematomos.
Pagal NIS2 ir DORA tiekėjų ir IRT trečiųjų šalių rizika yra centrinė. Jei teikėjas diegia pataisas platformoje, jums vis tiek reikia įrodymų, sutartinių teisių, paslaugų ataskaitų ir eskalavimo kelių.

Niekas neperžiūri tendencijų.
Pasikartojantys pažeidžiamumai gali rodyti silpną konfigūracijų valdymą, prastas saugaus kūrimo praktikas, nebepalaikomą turtą arba tiekėjo nesėkmę. Mėnesinė peržiūra techninius duomenis paverčia valdysenos veiksmais.

Clarysec pažeidžiamumų audito paketas

Būsimai ISO 27001:2022, NIS2 arba DORA pasirengimo peržiūrai Clarysec padeda organizacijoms parengti pažeidžiamumų ir pataisų valdymo audito paketą, apimantį:

• Pažeidžiamumų ir pataisų valdymo politiką, įskaitant taikymo sritį, vaidmenis, skenavimo periodiškumą, pataisų SLA ir išimčių taisykles
• Turto registro išrašą, kuriame matomos taikymo srityje esančios sistemos, savininkai, kritiškumas ir pasiekiamumas
• Naujausias vidinių ir išorinių pažeidžiamumų skenavimo ataskaitas
• Centrinį pažeidžiamumų valdymo registrą su atvirais, uždarytais ir išimties elementais
• Pataisų žurnalus, rodančius įrenginį, atnaujinimą, pataisos datą ir vėlavimo priežastis
• Pakeitimų įrašus atrinktiems kritiniams ir didelio sunkumo pažeidžiamumams
• Pakartotinių skenavimų arba patikrinimo po taisomųjų veiksmų įrodymus
• Išimčių ir liekamosios rizikos patvirtinimus atidėtoms arba nepataisomoms sistemoms
• Tiekėjų, bibliotekų ir debesijos paslaugų saugumo pranešimų stebėsenos procesą
• Mėnesinius CISO arba vadovybės peržiūros protokolus
• Susiejimą su ISO 27001:2022, NIS2, DORA, GDPR ir COBIT 2019 įpareigojimais
• Vidaus audito arba techninės kontrolės priemonių patikrinimo rezultatus

Zenith Blueprint audito, peržiūros ir tobulinimo etape, 24 žingsnyje, Clarysec pabrėžia atsekamumą tarp Taikytinumo pareiškimo, rizikų registro ir rizikos tvarkymo plano:

Jūsų SoA turi derėti su rizikų registru ir rizikos tvarkymo planu. Dar kartą patikrinkite, kad kiekviena kontrolės priemonė, kurią pasirinkote kaip rizikos tvarkymo priemonę, SoA būtų pažymėta kaip „Taikoma“.

Tai ypač svarbu pažeidžiamumų valdymui. Jei kontrolės priemonė 8.8 yra taikoma, audito paketas turi įrodyti ne tik tai, kad skenavimas vyksta, bet ir tai, kad išvados valdomos per rizikos tvarkymą ir nuolatinį tobulinimą.

30 dienų pasirengimo sprintas

Jei auditas arti, nepradėkite nuo visko perrašymo. Pradėkite nuo greito įrodymų sukūrimo.

Šis sprintas nepašalins visos techninės skolos. Jis pakeis audito pokalbį. Užuot gynę netvarkingą skenavimo eksportą, galite parodyti valdomą procesą su savininkais, terminais, veiksmais, sprendimais ir priežiūra.

Pereikite nuo skenavimų prie pagrįstų įrodymų

Pažeidžiamumų ir pataisų valdymo pasirengimas auditui nėra apie įrodymą, kad neturite pažeidžiamumų. Jis yra apie įrodymą, kad galite juos rasti, suprasti, prioritetizuoti, ištaisyti, kontroliuoti išimtis ir parodyti priežiūrą.

Clarysec Zenith Blueprint, Zenith Controls, Pažeidžiamumų ir pataisų valdymo politika, Pažeidžiamumų ir pataisų valdymo politika MVĮ, Audito ir atitikties stebėsenos politika ir Audito ir atitikties stebėsenos politika MVĮ suteikia struktūrą tokiai įrodymų darbo eigai sukurti.

Jei jūsų organizacija rengiasi ISO 27001:2022 sertifikavimui, NIS2 pasirengimui, DORA skaitmeniniam operaciniam atsparumui, klientų deramo patikrinimo peržiūrai arba vidaus auditui, pradėkite nuo vieno klausimo:

Ar kiekvieną kritinį pažeidžiamumą galima atsekti nuo skenavimo iki uždarymo?

Jei atsakymas neigiamas, Clarysec gali padėti jums sukurti registrą, politikų rinkinį, kelių atitikties sistemų susiejimą, vadovybės peržiūros paketą ir auditui tinkamą įrodymų darbo eigą, kuri techninį skenavimą paverčia pagrįsta valdysena.