Pažeidžiamumų šalinimo SLA pagal NIS2 ir DORA

Antradienio rytą, 08:17, 2026 m. pradžioje, sparčiai augančios fintech bendrovės CISO Anna gauna pirmąją žinutę dar nespėjusi pabaigti kavos.

SOC pažymėjo aktyvias diskusijas apie klientams skirto API šliuzo pažeidžiamumo išnaudojimą. Inžinerijos komanda teigia, kad pataisa yra prieinama, tačiau rizikinga, nes šliuzas yra prieš mokėjimų darbo eigas. Atitikties vadovas persiunčia oficialų nacionalinės kompetentingos institucijos prašymą pateikti „pažeidžiamumų tvarkymo ir atskleidimo“ įrodymus ir pagrindimą, kad procesas buvo veiksmingas per pastaruosius 12 mėnesių. Pirkimų komanda prideda trečią problemą: šliuzą valdo MSP, o sutartyje tik nurodyta, kad paslaugų teikėjas „laiku taikys saugumo atnaujinimus“.

Iki 09:00 tai nebėra vien pataisų diegimo klausimas. Tai ISO/IEC 27001:2022 įrodymų klausimas, NIS2 kibernetinės higienos klausimas, DORA IRT rizikos valdymo klausimas, tiekėjų valdysenos klausimas ir galimas pranešimo apie incidentą klausimas, jei išnaudojimas paveikia paslaugų tęstinumą arba asmens duomenis.

Tai praktinė atitikties spraga, su kuria 2026 m. susidurs daugelis organizacijų. Jos turi skenerius, valdymo skydus, užduotis ir pataisų diegimo priemones, tačiau negali aiškiai atsakyti į audito klausimus:

• Kas patvirtino šalinimo SLA?
• Kaip SLA pagrįstas rizika?
• Kas vyksta, kai kritinė pataisa neįdiegiama per nustatytą terminą?
• Kaip prioritetizuojamas viešai iš interneto pasiekiamas turtas?
• Kaip užtikrinama, kad tiekėjams būtų taikomi tie patys terminai?
• Kur yra rizikos priėmimo įrašas nepataisytai sistemai?
• Kokie įrodymai patvirtina, kad kontrolės priemonė veikė, o ne tik egzistavo?

Atsakymas nėra dar viena terminų skaičiuoklė. Pažeidžiamumų šalinimo SLA turi būti valdomi kaip gyva kontrolės priemonių sistema, jungianti turto savininkystę, pažeidžiamumų vertinimą balais, grėsmių žvalgybą, pakeitimų valdymą, tiekėjų SLA, išimčių tvarkymą, stebėseną, reagavimą į incidentus ir vadovybinę vertinamąją analizę.

Čia tampa naudingi Clarysec Enterprise Pažeidžiamumų ir pataisų valdymo politika (VPMP), MVĮ Pažeidžiamumų ir pataisų valdymo politika MVĮ (VPMP-SME), Trečiųjų šalių ir tiekėjų saugumo politika MVĮ (TPSSP-SME), Zenith Blueprint (ZB) ir Zenith Controls (ZC). Kartu jie „diegti pataisas greičiau“ paverčia pagrindžiamu valdysenos procesu, galinčiu atlaikyti ISO, NIS2, DORA, GDPR, NIST ir ISACA tipo audito patikrą.

Kodėl pažeidžiamumų šalinimo SLA tapo valdybos lygmens įrodymais

Pažeidžiamumų šalinimas anksčiau buvo vertinamas kaip IT higienos rodiklis. 2026 m. jis labiau panašus į reglamentuojamą veiklos atsparumo įsipareigojimą.

NIS2 kibernetinį saugumą paverčia vadovybės atskaitomybės klausimu. Esminiai ir svarbūs subjektai turi užtikrinti, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų mokymuose, kad suprastų rizikas ir saugumo praktikų poveikį paslaugoms. NIS2 Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir priežiūrą, pažeidžiamumų tvarkymą ir atskleidimą, kibernetinę higieną, mokymus, prieigos kontrolę, turto valdymą ir autentifikavimą.

Finansų sektoriaus subjektams DORA yra specializuotas veiklos atsparumo režimas. Jis reikalauja IRT rizikos valdysenos ir kontrolės priemonių, kai valdymo organas apibrėžia, patvirtina, prižiūri ir išlieka atsakingas už IRT rizikos valdymą. Taip pat reikalaujama identifikuoti IRT turtą ir priklausomybes, taikyti apsaugos ir prevencijos kontrolės priemones, tokias kaip pataisų diegimas ir pakeitimų valdymas, valdyti su IRT susijusius incidentus, vykdyti skaitmeninio veiklos atsparumo testavimą ir IRT trečiųjų šalių rizikos valdymą.

Praktinis poveikis reikšmingas. Praleistas pataisos terminas gali rodyti nesėkmę šiose srityse:

• Valdysena, jei vadovybė nepatvirtino rizika grindžiamų SLA
• Turto valdymas, jei nežinomas paveiktos sistemos savininkas
• Pakeitimų valdymas, jei neatidėliotinas pataisų diegimas nėra kontroliuojamas
• Tiekėjų valdymas, jei paslaugų teikėjo terminai yra neapibrėžti
• Reagavimas į incidentus, jei išnaudojimo požymiai nėra preliminariai įvertinami
• Įrodymų valdymas, jei užduotys ir žurnalai negali pagrįsti uždarymo
• Rizikos tvarkymas, jei išimtys nėra patvirtinamos ir peržiūrimos

ISO/IEC 27001:2022 suteikia valdymo sistemos pagrindą. 4.1–4.3 punktai reikalauja, kad organizacijos suprastų vidinius ir išorinius klausimus, suinteresuotųjų šalių reikalavimus, teisines ir sutartines prievoles bei sąsajas su kitomis organizacijomis. 6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, Taikytinumo pareiškimo ir rizikos savininko patvirtinimo dėl likutinės rizikos. 9.1, 9.2, 9.3, 10.1 ir 10.2 punktai reikalauja stebėsenos, vidaus audito, vadovybinės vertinamosios analizės, nuolatinio tobulinimo, korekcinių veiksmų ir dokumentuotos informacijos.

Paprastai tariant, jei norite, kad pažeidžiamumų šalinimo SLA būtų tinkami auditui, jie turi būti ISVS dalis, o ne vien DevOps rodiklis.

SLA modelis, kurio tikisi auditoriai

Pažeidžiamumų šalinimo SLA turi atsakyti į tris klausimus:

1. Kaip greitai turime veikti?
2. Kas yra atskaitingas?
3. Kokie įrodymai pagrindžia rezultatą?

Pažeidžiamumų ir pataisų valdymo politika apibrėžia praktišką pradinį tašką rizika grindžiamiems šalinimo terminams:

Organizacija privalo klasifikuoti visus aptiktus pažeidžiamumus pagal standartizuotą metodiką (pvz., CVSS v3.x) ir taikyti šalinimo terminus, suderintus su verslo kritiškumu: 5.2.1 Kritinis (CVSS 9.0-10.0): nedelsiant atliekama peržiūra; pataisos įdiegimo terminas – ne daugiau kaip 72 valandos. 5.2.2 Aukštas (7.0-8.9): reagavimas per 48 valandas; pataisos įdiegimo terminas – 7 kalendorinės dienos. 5.2.3 Vidutinis (4.0-6.9): reagavimas per 5 dienas; pataisos įdiegimo terminas – 30 kalendorinių dienų. 5.2.4 Žemas (<4.0): reagavimas per 10 dienų; pataisos įdiegimo terminas – 60 kalendorinių dienų.

Ši nuostata veiksminga, nes atskiria reagavimo laiką nuo pataisos įdiegimo termino. Aukšto lygio pažeidžiamumas neturi likti nepastebėtas šešias dienas ir būti ištaisytas tik septintą dieną. Reagavimo laikmatis patvirtina preliminarų vertinimą, savininkystę, poveikio vertinimą ir šalinimo planavimą. Pataisos įdiegimo terminas patvirtina techninį uždarymą arba patvirtintą išimtį.

Mažesnėms organizacijoms Pažeidžiamumų ir pataisų valdymo politika MVĮ naudoja paprastesnę, bet vis tiek audituojamą kalbą:

Kritinės pataisos turi būti įdiegtos per 3 dienas nuo išleidimo, ypač viešai iš interneto pasiekiamose sistemose

O platesnei pataisų aplinkai:

Visos kitos pataisos turi būti įdiegtos per 30 dienų, nebent dokumentuota galiojanti išimtis

Esmė nėra ta, kad kiekviena organizacija turi taikyti identiškus terminus. ISO/IEC 27001:2022, NIS2 ir DORA remia proporcingumo principą. Esmė ta, kad šalinimo SLA turi būti apibrėžti, patvirtinti, grindžiami rizika, stebimi ir pagrindžiami įrodymais.

Čia daugelis įmonių suklysta. Jos apibrėžia SLA, bet neapibrėžia įrodymų. Auditoriaus požiūriu politika be operacinių įrašų yra pažadas, o ne kontrolės priemonė.

Turto savininkystė yra paslėpta priklausomybė

Skeneris gali pasakyti, kad serveryje egzistuoja CVE. Jis negali pasakyti, ar serveris palaiko kritinį mokėjimų procesą, saugo specialių kategorijų asmens duomenis, jungiasi prie atsiskaitymų paslaugų teikėjo arba yra suplanuotas eksploatacijos nutraukimui.

Šis kontekstas gaunamas iš turto valdymo, duomenų klasifikavimo, tiekėjų apskaitos ir rizikos vertinimo.

ISO/IEC 27001:2022 Annex A kontrolė 8.8, Techninių pažeidžiamumų valdymas, yra centrinė, tačiau ji neveikia atskirai. Ji labai priklauso nuo konfigūracijų valdymo, pakeitimų valdymo, tiekėjų stebėsenos, debesijos valdysenos, žurnalavimo, stebėsenos ir rizikos tvarkymo.

NIST CSF 2.0 tą pačią problemą išreiškia rezultatų kalba. GOVERN funkcija numato, kad teisiniai, reglamentavimo ir sutartiniai kibernetinio saugumo reikalavimai turi būti suprasti ir valdomi, rizikos apetitas ir tolerancija dokumentuoti, vaidmenys ir ištekliai priskirti, o kibernetinio saugumo politikos nustatytos, taikomos, peržiūrimos ir atnaujinamos. IDENTIFY rezultatai apima aparatinės įrangos, programinės įrangos, paslaugų, sistemų, duomenų ir gyvavimo ciklo apskaitą, taip pat pažeidžiamumų identifikavimą, rizikos analizę, išimčių valdymą ir pažeidžiamumų atskleidimo procesus.

Annos antradienio ryto scenarijuje pirmasis techninis klausimas yra „kur yra pažeidžiamas komponentas?“ Pirmasis valdysenos klausimas yra „kokią paslaugą ir kokią riziką jis paveikia?“

Zenith Blueprint, Rizikos valdymo etapas, 13 žingsnis: Rizikos tvarkymo planavimas ir Taikytinumo pareiškimas, tai sprendžia susiedamas rizikas su kontrolės priemonėmis, savininkais ir terminais:

Taip pat kiekvienam veiksmui priskirkite savininką ir terminą (galbūt atskirame stulpelyje arba komentaruose). Pvz., „Savininkas: IT vadovas, terminas: iki 2025 m. III ketv.“ Tai paverčia dokumentą tikru planu.

Būtent to reikia pažeidžiamumų šalinimui. Išvada be savininko tampa darbų sąrašo triukšmu. Išvada su savininku, terminu, rizikos tvarkymo sprendimu ir įrodymų pėdsaku tampa audituojama kontrolės priemone.

Kaip Zenith Controls susieja kontrolės priemonių ryšius

Zenith Controls ISO/IEC 27002:2022 kontrolę 8.8, Techninių pažeidžiamumų valdymas, traktuoja kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą. Ji siejama su kibernetinio saugumo sąvokomis Identify ir Protect, grėsmių ir pažeidžiamumų valdymo operaciniu pajėgumu ir saugumo sritimis: valdysena, ekosistema, apsauga ir gynyba.

Tai svarbu, nes šalinimo SLA nėra vien apsaugos mechanizmas. Jie taip pat yra valdysenos mechanizmas ir ekosistemos mechanizmas. Jūsų rizikos ekspoziciją lemia tiekėjai, debesijos platformos, valdomos paslaugos, atvirojo kodo komponentai ir viešai iš interneto pasiekiamos priklausomybės.

Zenith Controls susieja 8.8 su keliomis palaikančiomis kontrolės priemonėmis:

Zenith Controls taip pat susieja pažeidžiamumų valdymą su ISO/IEC 27005:2024, ypač su pažeidžiamumų identifikavimu ir rizikos scenarijais, susijusiais su nepataisytomis sistemomis. Tai sustiprina argumentą, kad pataisų diegimo terminai turi būti grindžiami rizika, o ne savavališki. Taip pat tiekėjų stebėsena susiejama su ISO/IEC 27036-4:2016 debesijos paslaugų susitarimų saugumo lygiais ir ISO/IEC 20000-1:2018 paslaugos teikimo planavimu bei pakeitimų valdymu.

Tokia kelių standartų struktūra svarbi audito metu. Jei organizacija teigia, kad „kritiniai pažeidžiamumai pataisomi per 72 valandas“, auditorius tikrins, ar šį teiginį pagrindžia rizikos vertinimas, turto klasifikavimas, tiekėjų įsipareigojimai, pakeitimų įrašai ir stebėsenos įrodymai.

NIS2 kibernetinė higiena: nuo pažeidžiamumų tvarkymo iki korekcinių veiksmų

NIS2 Article 21 reikalauja visų pavojų požiūrio į tinklų ir informacines sistemas. Pažeidžiamumų šalinimo SLA tiesiogiai aktualūs keli Article 21 elementai:

• Rizikos analizė ir informacinių sistemų saugumo politikos
• Incidentų valdymas
• Veiklos tęstinumas ir krizių valdymas
• Tiekimo grandinės saugumas
• Saugus įsigijimas, kūrimas ir priežiūra, įskaitant pažeidžiamumų tvarkymą ir atskleidimą
• Procedūros kibernetinio saugumo veiksmingumui vertinti
• Bazinė kibernetinė higiena ir mokymai
• Prieigos kontrolė ir turto valdymas
• Kelių veiksnių autentifikavimas arba tęstinis autentifikavimas, kai tinkama

NIS2 Article 20 nustato valdymo organų atskaitomybę už kibernetinio saugumo rizikos valdymo priemonių patvirtinimą ir priežiūrą. Tai reiškia, kad pažeidžiamumų šalinimo rodikliai negali likti vien inžinerijos valdymo skyde. Jie turi būti įtraukti į vadovybės ataskaitas, rizikos komiteto medžiagą arba ISVS vadovybinės vertinamosios analizės įrašus.

Article 21 taip pat tikisi, kad subjektai, nustatę neatitiktį reikalaujamoms priemonėms, imtųsi korekcinių veiksmų nepagrįstai nedelsdami. Ši formuluotė svarbi. Jei jūsų valdymo skydas rodo vėluojamus kritinius pažeidžiamumus, atitikties įrodymai neturi baigtis fraze „mes žinome“. Jie turi parodyti eskalavimą, rizikos peržiūrą, vadovybės matomumą, korekcinius veiksmus ir pakartotinį vertinimą.

NIS2 Article 23 prideda dar vieną dimensiją. Jei nepataisyto pažeidžiamumo išnaudojimas sukelia arba gali sukelti didelį veiklos sutrikimą, finansinius nuostolius ar žalą kitiems asmenims, tai gali tapti reikšmingu incidentu. Ataskaitų teikimo gyvavimo ciklas apima ankstyvąjį įspėjimą per 24 valandas nuo sužinojimo apie reikšmingą incidentą, pranešimą apie incidentą per 72 valandas, tarpines ataskaitas pagal prašymą ir galutinę ataskaitą per vieną mėnesį po pranešimo apie incidentą. Galutinėje ataskaitoje turi būti nurodytas sunkumas, poveikis, tikėtina pagrindinė priežastis, švelninimo priemonės ir tarpvalstybinis poveikis, kai taikoma.

Todėl SLA procesas turi būti susietas su reagavimu į incidentus. Kritinis pažeidžiamumas su aktyvaus išnaudojimo įrodymais turi inicijuoti saugumo triažą, stebėseną, įrodymų išsaugojimą ir pranešimo vertinimą, o ne tik įprastą pataisos užduotį.

DORA IRT rizika: šalinimo terminai kaip atsparumo įrodymai

Finansų sektoriaus subjektams DORA taikomas nuo 2025 m. sausio 17 d. ir nustato vienodus reikalavimus IRT rizikos valdymui, pranešimams apie reikšmingus su IRT susijusius incidentus, skaitmeninio veiklos atsparumo testavimui, informacijos dalijimuisi ir IRT trečiųjų šalių rizikos valdymui. Jis laikomas sektoriui skirtu ES teisės aktu taikomiems finansų subjektams, identifikuotiems pagal nacionalines NIS2 taisykles.

DORA veikimo modelis artimas integruotai ISVS. Articles 5 ir 6 reikalauja valdysenos, politikų, procedūrų, priemonių, metinės arba periodinės peržiūros, audito, kritinių audito išvadų šalinimo ir skaitmeninio veiklos atsparumo strategijos. Article 8 reikalauja identifikuoti ir apskaityti IRT palaikomas verslo funkcijas, informacijos išteklius, IRT turtą, priklausomybes, trečiųjų šalių procesus ir senosios IRT rizikas. Article 9 reikalauja apsaugos ir prevencijos kontrolės priemonių, įskaitant pataisų diegimą ir pakeitimų valdymą. Articles 11 ir 12 reikalauja tęstinumo, reagavimo, atkūrimo, atsarginių kopijų, atkūrimo iš atsarginių kopijų ir atkūrimo tikslų.

DORA Articles 17–19 reikalauja su IRT susijusių incidentų valdymo proceso, kuris aptinka, valdo, registruoja, klasifikuoja, eskaluoja, teikia pranešimus, komunikuoja, analizuoja pagrindinę priežastį ir atkuria saugias operacijas. Articles 24–26 reikalauja skaitmeninio veiklos atsparumo testavimo, įskaitant tinkamą IRT priemonių ir sistemų testavimą, pažeidžiamumų vertinimus, tinklo saugumo vertinimus, spragų analizes, pirminio kodo peržiūras, kai įmanoma, įsiskverbimo testavimą ir grėsmėmis grindžiamą įsiskverbimo testavimą tam tikriems finansų subjektams. Articles 28 ir 30 reikalauja valdyti IRT trečiųjų šalių riziką, tvarkyti IRT paslaugų sutarčių registrus, atlikti deramą patikrinimą, nustatyti audito ir patikrinimo teises, paslaugų lygius, paslaugų teikėjo pagalbą incidentų metu, nutraukimo teises ir pasitraukimo priemones.

Šalinimo SLA atžvilgiu DORA keičia įrodymų lūkesčius trimis būdais.

Pirma, testavimo metu nustatytos pažeidžiamumų išvados turi patekti į prioritetizuotą šalinimo procesą. Vien skenavimo ataskaitos nepakanka.

Antra, kritinių išvadų šalinimas turi būti sekamas per valdyseną ir auditą. DORA tikisi formalaus kritinių audito išvadų šalinimo ne mikroįmonėms.

Trečia, IRT trečiųjų šalių paslaugų teikėjams turi būti taikomi išmatuojami įsipareigojimai. Jei jūsų debesijos, SaaS arba MSP paslaugų teikėjas kontroliuoja pataisų diegimo langą, sutartis ir registras turi parodyti, kaip jų šalinimo terminai palaiko jūsų atsparumo įsipareigojimus.

Pažeidžiamumų ir pataisų valdymo politika tai aptaria tiesiogiai:

Trečiųjų šalių pataisų diegimo ir SaaS rizikos priežiūra 6.6.1 Visos trečiųjų šalių sistemos (SaaS, PaaS, MSP valdomos) turi įrodyti tinkamas pažeidžiamumų ir pataisų valdymo kontrolės priemones. 6.6.2 Tiekėjų SLA turi apimti šalinimo terminus, lygiaverčius viduje apibrėžtiems, kritiškumu grindžiamiems slenksčiams.

Ši nuostata dažnai yra trūkstama jungtis tarp vidinių ISO įrodymų ir DORA tiekėjų priežiūros.

GDPR: kai pataisų vėlavimas tampa asmens duomenų atskaitomybės nesėkme

GDPR nėra pažeidžiamumų valdymo standartas, tačiau jis keičia pataisų nesėkmės pasekmes.

GDPR Article 5 reikalauja, kad asmens duomenys būtų tvarkomi saugiai, ir reikalauja, kad duomenų valdytojas galėtų įrodyti atitiktį. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių, užtikrinančių riziką atitinkantį saugumo lygį. Kai nepataisytos sistemos tvarko asmens duomenis, ypač tapatybės duomenis, finansinius duomenis, biometrinius duomenis, sveikatos duomenis, darbo santykių duomenis arba KYC informaciją, šalinimo SLA tampa tvarkymo saugumo atskaitomybės dalimi.

Vėluojama pataisa gali būti pagrindžiama, jei rizika buvo įvertinta, pritaikytos kompensuojančios kontrolės priemonės, o likutinę riziką priėmė tinkamas asmuo. Ją daug sunkiau apginti, jei pažeidžiamumas buvo vėluojamas, viešai iš interneto pasiekiamas ir neturėjo savininko.

Zenith Controls susieja pažeidžiamumų valdymą su GDPR Articles 32 ir 5(1)(f), nes savalaikis pataisų diegimas mažina rizikas asmens duomenų konfidencialumui ir vientisumui. Jis taip pat susieja pakeitimų valdymą su GDPR Article 24 ir Article 32, nes sistemų, tvarkančių asmens duomenis, pakeitimai turi būti įvertinti pagal riziką, patvirtinti, dokumentuoti ir peržiūrėti.

Atitikties pamoka paprasta: jei dalyvauja asmens duomenys, pataisų įrodymai turi apimti duomenų kontekstą. Auditoriai ir priežiūros institucijos klaus ne tik „ar buvo pataisyta?“, bet ir „kokiems duomenims kilo rizika, kiek laiko ir kokios kontrolės priemonės šią riziką sumažino?“

Praktinė Clarysec darbo eiga auditui tinkamiems SLA įrodymams

Brandus pažeidžiamumų šalinimo procesas neprasideda tada, kai auditorius paprašo įrašų. Jis projektuojamas taip, kad įrašai būtų generuojami kiekvieną mėnesį.

1 žingsnis: patvirtinkite SLA politiką

Pradėkite nuo Pažeidžiamumų ir pataisų valdymo politikos arba Pažeidžiamumų ir pataisų valdymo politikos MVĮ, priklausomai nuo jūsų veikimo modelio. Pritaikykite SLA slenksčius pagal rizikos apetitą, reglamentavimo taikymo sritį, paslaugų kritiškumą, duomenų jautrumą ir techninius apribojimus. Užtikrinkite CISO, rizikos komiteto arba valdymo organo patvirtinimą.

Įmonių aplinkose naudokite CVSS, turto kritiškumą, išnaudojamumą, interneto pasiekiamumą, duomenų jautrumą ir poveikį verslui. MVĮ atveju modelį išlaikykite paprastą, bet aiškų: kritinės pataisos per tris dienas, kitos pataisos per 30 dienų, nebent yra galiojanti išimtis.

2 žingsnis: susiekite turtą su savininkais ir kritinėmis paslaugomis

Kiekviena pažeidžiamumo išvada turi būti susiejama su:

• Turto pavadinimu ir unikaliu identifikatoriumi
• Verslo paslauga arba taikomąja programa
• Sistemos savininku
• Techniniu savininku
• Duomenų klasifikavimu
• Interneto pasiekiamumu
• Tiekėjo priklausomybe, jei taikoma
• Palaikomos funkcijos kritiškumu

Tai palaiko ISO/IEC 27001:2022 rizikos savininkystę, NIS2 turto valdymą, DORA IRT turto ir priklausomybių apskaitą ir NIST CSF IDENTIFY rezultatus.

3 žingsnis: atlikite preliminarų pažeidžiamumo vertinimą

Sukurkite užduotį kiekvienai išvadai arba sugrupuotam išvadų rinkiniui. Įtraukite CVSS balą, skenerio šaltinį, paveiktą turtą, išnaudojimo būseną, grėsmių žvalgybą, verslo kritiškumą ir reikalingą SLA. Jei įtariamas išnaudojimas, susiekite užduotį su incidento vertinimu.

4 žingsnis: vykdykite per pakeitimų valdymą

Pataisų diegimas yra pakeitimas. Įprastiems atnaujinimams naudokite standartinį pakeitimą, o kritiniams išnaudojamiems pažeidžiamumams – neatidėliotiną pakeitimą. Įtraukite testavimo įrodymus, patvirtinimą, įgyvendinimo laiko žymą, grąžinimo į ankstesnę būseną planą ir validavimą po pakeitimo.

Tai atitinka Zenith Controls ryšį tarp 8.8 ir 8.32, kai pataisų taikymas valdomas per pakeitimų valdymą, siekiant suderinti skubumą ir veiklos stabilumą.

5 žingsnis: validuokite uždarymą

Neuždarykite užduočių vien remdamiesi teiginiu „pataisa įdiegta“. Reikalaukite validavimo per pakartotinį skenavimą, versijos patvirtinimą, konfigūracijos patikrinimą arba kompensuojančios kontrolės priemonės patvirtinimą. Jei pataisos pritaikyti negalima, atidarykite išimtį.

6 žingsnis: registruokite išimtis ir likutinę riziką

Pažeidžiamumų ir pataisų valdymo politika apibrėžia privalomą išimties turinį:

Išimties prašymuose turi būti nurodyta: 7.2.1 Verslo pagrindimas dėl vėlavimo arba nešalinimo 7.2.2 Rizikos vertinimas (grindžiamas CVSS, turto kritiškumu, grėsmių žvalgyba) 7.2.3 Siūlomos kompensuojančios kontrolės priemonės 7.2.4 Šalinimo arba pakartotinio vertinimo terminas

Ji taip pat apibrėžia patvirtinimą ir peržiūrą:

Išimtis turi patvirtinti CISO arba deleguotas Rizikos komitetas, jos turi būti registruojamos ISVS išimčių registre, o peržiūros intervalas neturi viršyti 90 dienų.

Šis išimčių registras tampa esminiu įrodymu ISO/IEC 27001:2022 Clause 6.1.3 rizikos tvarkymui ir likutinės rizikos priėmimui, taip pat vadovybinei vertinamajai analizei.

Šis įrašas parodo, kad organizacija neignoravo pažeidžiamumo. Ji įvertino riziką, pritaikė kompensuojančias kontrolės priemones, patvirtino likutinę riziką ir nustatė peržiūros datą.

7 žingsnis: parenkite mėnesinį įrodymų paketą

Jūsų mėnesinis pažeidžiamumų šalinimo įrodymų paketas turėtų apimti:

MVĮ įrodymai gali būti paprastesni, tačiau jie vis tiek turi būti nuoseklūs. Pažeidžiamumų ir pataisų valdymo politika MVĮ reikalauja pataisų žurnalų su atsekamumu:

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

Ši viena nuostata yra audito auksas. Ji pataisų diegimą paverčia ne teiginiu, o įrašu.

Tiekėjų pataisų diegimas: sutartis turi atitikti jūsų SLA

Jei MSP, SaaS teikėjas, PaaS teikėjas arba debesijos paslaugų teikėjas kontroliuoja pataisų diegimą, vidiniai SLA neturi vertės, jei tiekėjų įsipareigojimai jų neatitinka.

Trečiųjų šalių ir tiekėjų saugumo politika MVĮ apima informacijos saugumo įsipareigojimus kaip valdysenos reikalavimą. Pažeidžiamumų šalinimui šie įsipareigojimai turi tapti išmatuojama sutartine kalba:

• Kritinių pažeidžiamumų pranešimo langai
• Kritinių, aukštų, vidutinių ir žemų pažeidžiamumų šalinimo terminai
• Neatidėliotinų pakeitimų procesas
• Kliento patvirtinimo reikalavimai prastovoms
• Pataisos užbaigimo įrodymų formatas
• Pažeidžiamumų atskleidimo procesas
• Pagalbos įsipareigojimai incidentų metu
• Teisė atlikti auditą arba gauti patikinimo ataskaitas
• Subtvarkytojų arba subtiekėjų pataisų diegimo įsipareigojimai
• Pasitraukimo ir perėjimo pagalba kritinėms paslaugoms

Zenith Blueprint, Kontrolės priemonės praktikoje etapas, 20 žingsnis, kontrolė 8.21 Tinklo paslaugų saugumas, aiškiai suformuluoja principą:

Kai paslaugos teikiamos išorėje, įskaitant ISP, SD-WAN tiekėjus arba privačios debesijos paslaugų teikėjus, saugumo reikalavimai turi būti įtraukti į sutartis ir SLA. Tai apima veikimo nepertraukiamumo garantijas, reagavimo į incidentus laikus, įsipareigojimus diegti pataisas arba mažinti pažeidžiamumus ir aiškias duomenų tvarkymo ribas. Niekada neturėtumėte manyti, kad paslaugų teikėjas atitinka jūsų lūkesčius, nebent tai yra užrašyta, išmatuojama ir audituojama.

DORA tai daro ypač svarbu finansų sektoriaus subjektams. IRT trečiųjų šalių susitarimai turi apimti paslaugų lygius, paslaugų teikėjo pagalbą IRT incidentų metu, prieigą prie duomenų ir jų atkūrimą, bendradarbiavimą su institucijomis, nutraukimo teises ir stipresnes nuostatas kritinėms ar svarbioms funkcijoms, įskaitant stebėseną, audito teises, nenumatytų atvejų planus ir saugumo priemones.

NIST CSF 2.0 tą patį nurodo per tiekimo grandinės rizikos rezultatus: tiekėjai turi būti žinomi, prioritetizuojami pagal kritiškumą, įvertinami prieš pasitelkimą, valdomi sutartiniais reikalavimais, stebimi viso santykio metu, įtraukiami į incidentų planavimą ir valdomi nutraukimo metu.

Ko auditoriai iš tikrųjų klaus

Audito pokalbis keičiasi priklausomai nuo auditoriaus patirties.

ISO/IEC 27001:2022 auditorius pradės nuo ISVS. Jis tikrins, ar pažeidžiamumų valdymas įtrauktas į Taikytinumo pareiškimą, ar rizikos vertinime nepataisytos sistemos identifikuojamos kaip rizika, ar rizikos tvarkymo planuose yra savininkai ir terminai, ar įgyvendinta Annex A kontrolė 8.8, ar saugoma dokumentuota informacija ir ar vidaus auditas bei vadovybinė vertinamoji analizė vertina veiksmingumą.

Zenith Blueprint, Kontrolės priemonės praktikoje etapas, 19 žingsnis, aiškiai apibrėžia audito lūkestį:

Tai yra aukšto prioriteto kontrolės priemonė auditoriams, ir jie paprastai gilinsis išsamiai. Tikėkitės klausimų, kaip dažnai sistemos pataisomos, kokį procesą taikote paskelbus nulinės dienos pažeidžiamumą ir kurias sistemas pataisyti sunkiausia.

Toliau pateikiami praktiniai įrodymų lūkesčiai:

Auditoriai tikriausiai paprašys pažeidžiamumų skenavimo rezultatų. Jei naudojate tokias priemones kaip Nessus, OpenVAS arba Qualys, eksportuokite ataskaitą, rodančią neseniai aptiktus pažeidžiamumus ir kaip jie buvo pašalinti. Idealiu atveju ji turėtų apimti rizikos lygius (CVSS) ir šalinimo terminus.

Į NIS2 orientuotas auditorius arba kompetentinga institucija ieškos valdybos patvirtinimo, proporcingumo, kibernetinės higienos, pažeidžiamumų tvarkymo, tiekėjų saugumo, incidentų valdymo, veiksmingumo vertinimo, korekcinių veiksmų be nepagrįsto delsimo ir pranešimo sprendimų įrašų, jei išnaudojimas sukėlė reikšmingą poveikį.

DORA priežiūros institucija tikrins, ar pažeidžiamumų išvados integruotos į IRT rizikos valdymą, skaitmeninio veiklos atsparumo testavimą, incidentų klasifikavimą, pagrindinės priežasties analizę, trečiųjų šalių registrus, sutartinius įsipareigojimus, audito teises ir kritinių išvadų šalinimą.

NIST CSF vertintojas tikriausiai organizuos peržiūrą pagal GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER. Jis klaus, ar suprasti teisiniai ir sutartiniai reikalavimai, ar dokumentuota rizikos tolerancija, ar pažeidžiamumai identifikuojami ir prioritetizuojami, ar valdomos išimtys, ar stebėsena aptinka išnaudojimą ir ar koordinuojami reagavimo bei atkūrimo veiksmai.

COBIT 2019 arba ISACA tipo auditorius sutelks dėmesį į valdysenos tikslus, proceso pajėgumą, valdymo praktikas, rodiklius, savininkystę, kontrolės priemonių projektavimą, kontrolės priemonių veikimą ir įrodymų pakankamumą. Jis klaus, ar pažeidžiamumų šalinimas yra pakartojamas, matuojamas, eskaluojamas, tobulinamas ir suderintas su įmonės tikslais bei rizikos apetitu.

Eskalavimas ir rodikliai: kaip įrodyti, kad SLA valdomas

SLA be eskalavimo yra tik tikslas. Pagrindžiama pažeidžiamumų šalinimo programa turi numatyti eskalavimą prieš pažeidžiant terminą, pažeidus terminą ir po pasikartojančių nesėkmių.

Clarysec rekomenduoja keturių lygių eskalavimo modelį:

1. Operacinis eskalavimas – užduoties savininkas ir techninis vadovas informuojami prieš termino pažeidimą.
2. Rizikos eskalavimas – turto savininkas ir rizikos savininkas peržiūri poveikį, kai termino pažeidimas tikėtinas.
3. Saugumo valdysenos eskalavimas – CISO arba rizikos komitetas patvirtina išimtį arba neatidėliotiną veiksmą.
4. Vadovybės eskalavimas – pasikartojantys arba kritiniai SLA pažeidimai teikiami vadovybinei vertinamajai analizei kartu su korekciniais veiksmais.

Pažeidžiamumų ir pataisų valdymo politika sustiprina šį audito lūkestį:

Vidaus auditas arba nepriklausoma trečioji šalis turi periodiškai atlikti auditus, kad patikrintų: 5.6.1 Atitiktį SLA 5.6.2 Rizika grindžiamo prioritetizavimo įrodymus 5.6.3 Įdiegtų pataisų veiksmingumą 5.6.4 Nepataisytų sistemų kontrolės priemones

Rodikliai turi padėti priimti sprendimus, o ne dekoruoti valdymo skydus. Stipriausi 2026 m. rodikliai apima:

• Kritinių SLA laikymosi procentą
• Aukštų SLA laikymosi procentą
• Vidutinį preliminaraus vertinimo laiką
• Vidutinį šalinimo laiką pagal turto klasę
• Vėluojamų kritinių pažeidžiamumų skaičių
• Priimtų išimčių skaičių pagal amžių
• Išimtis, viršijančias 90 dienų
• Viešai iš interneto pasiekiamų kritinių rizikos ekspozicijų skaičių
• Tiekėjų SLA pažeidimus
• Po validavimo pakartotinai atidarytus pažeidžiamumus
• Neatidėliotinus pakeitimus, kuriuos sukėlė išnaudojami pažeidžiamumai
• Pataisų nesėkmes pagal platformą arba verslo padalinį

Susiekite šiuos rodiklius su ISO/IEC 27001:2022 Clause 9.3 vadovybine vertinamąja analize, DORA valdysenos ataskaitų teikimu ir NIS2 vadovybės priežiūra. NIST CSF 2.0 atveju naudokite juos esamiems ir siektiniems profiliams, spragų analizei ir veiksmų planams atnaujinti.

Clarysec šalinimo SLA kontrolinis sąrašas

Naudokite šį kontrolinį sąrašą savo dabartinei programai įvertinti:

• Ar yra patvirtinta pažeidžiamumų ir pataisų valdymo politika?
• Ar šalinimo SLA apibrėžti pagal sunkumą ir verslo kritiškumą?
• Ar viešai iš interneto pasiekiamiems ir išnaudojamiems pažeidžiamumams taikomas pagreitintas procesas?
• Ar turtas susietas su savininkais, paslaugomis, duomenimis ir tiekėjais?
• Ar skenerio išvados paverčiamos priskirtomis užduotimis?
• Ar pataisos vykdomos per pakeitimų valdymą?
• Ar neatidėliotini pakeitimai dokumentuojami ir peržiūrimi?
• Ar šalinimo rezultatai validuojami pakartotiniais skenavimais arba versijų patikromis?
• Ar išimtys įvertinamos pagal riziką, patvirtinamos ir peržiūrimos bent kas 90 dienų?
• Ar dokumentuotos kompensuojančios kontrolės priemonės nepataisomoms sistemoms?
• Ar tiekėjų sutartys suderintos su vidiniais šalinimo slenksčiais?
• Ar pataisų žurnalai pakankamai išsamūs, kad įrodytų, kas ir kada įvyko?
• Ar SLA pažeidimai eskaluojami ir koreguojami?
• Ar rodiklius peržiūri vadovybė?
• Ar incidentų ir pažeidimų vertinimai inicijuojami, kai įtariamas išnaudojimas?

Jei keli atsakymai yra „ne“, problema nėra įrankiai. Tai kontrolės priemonių projektavimas.

Tolesni veiksmai: paverskite pataisų terminus auditui tinkamu atsparumu

2026 m. pažeidžiamumų šalinimo SLA turi padaryti daugiau nei patenkinti skenerio valdymo skydą. Jie turi įrodyti, kad jūsų organizacija gali identifikuoti rizikos ekspoziciją, prioritetizuoti riziką, veikti per patvirtintus terminus, valdyti išimtis, užtikrinti tiekėjų valdyseną ir pagrįsti sprendimus įrodymais pagal ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019 audito lūkesčius.

Clarysec gali padėti pereiti nuo fragmentuotų pataisų užduočių prie integruotos, įrodymais grindžiamos pažeidžiamumų šalinimo programos naudojant:

• Pažeidžiamumų ir pataisų valdymo politika
• Pažeidžiamumų ir pataisų valdymo politika MVĮ
• Trečiųjų šalių ir tiekėjų saugumo politika MVĮ
• Zenith Blueprint: 30 žingsnių auditoriaus veiksmų planas
• Zenith Controls: kryžminės atitikties vadovas

Pradėkite nuo vienos didelės rizikos paslaugos. Susiekite jos turtą, tiekėjus, pažeidžiamumus, užduotis, pakeitimus, išimtis ir įrodymus. Tada pritaikykite jai audito klausimus. Jei negalite pagrįsti SLA nuo aptikimo iki uždarymo, tai yra jūsų pirmasis šalinimo projektas.

Tikslas nėra tobulas pataisų diegimas. Tikslas yra valdoma, rizika grindžiama, išmatuojama ir audituojama pažeidžiamumų šalinimo veikla. Atsisiųskite Clarysec politikų šablonus, atlikite tikslinį spragų vertinimą arba užsisakykite Clarysec demonstraciją, kad pažeidžiamumų šalinimą iš audito spaudimo paverstumėte veiklos atsparumu.