CVD pagal NIS2 ir DORA: ISO 27001 įrodymų susiejimo žemėlapis

Antradienį 08:17 saugumo el. pašto dėžutė gauna žinutę iš nepriklausomo tyrėjo. Temos eilutė skamba ramiai, beveik mandagiai: „Galimas paskyros perėmimas jūsų klientų portale“. Turinys kelia daugiau nerimo. Tyrėjas teigia, kad jūsų SaaS taikomojoje programoje esanti pažeidžiamumų grandinė leidžia vienos kliento aplinkos naudotojui pasiekti kitos kliento aplinkos sąskaitų įrašus. Pridėtas PoC, užšifruotas jūsų paskelbtu PGP raktu.

Marijai, naujajai FinanTechSaaS CISO, laikas negalėjo būti blogesnis. Įmonė ką tik pasirašė didelę sutartį su aukščiausio lygio ES banku. Kliento deramo patikrinimo komanda jau paprašė „Koordinuoto pažeidžiamumų atskleidimo politikos“ ir įgyvendinimo įrodymų, aiškiai nurodydama NIS2 ir DORA. Įmonė turi security@ el. pašto adresą, tačiau jį stebi vienas kūrėjas. Nėra formalaus priėmimo registro, apibrėžto techninės patikros SLA, vadovybės eskalavimo kelio ir audito pėdsako.

Vienu metu pradeda tiksėti trys laikrodžiai.

Pirmasis yra operacinis. Ar pažeidžiamumas tikras? Ar jį galima išnaudoti produkcinėje aplinkoje? Ar kas nors aktyviai juo piktnaudžiauja?

Antrasis yra reguliacinis. Jei klientų duomenys atskleisti, pradedamas GDPR pažeidimo vertinimas. Jei paveikiamas paslaugos teikimas esminiam arba svarbiam subjektui pagal NIS2, gali būti pasiekti incidentų pranešimo slenksčiai. Jei įmonė yra finansų subjektas arba IRT paslaugų teikėjas, palaikantis finansines paslaugas, gali tapti aktualios DORA incidentų valdymo, klasifikavimo, eskalavimo ir komunikacijos su klientais taisyklės.

Trečiasis yra įrodymų. Po šešių mėnesių ISO/IEC 27001:2022 auditorius, finansų sektoriaus priežiūros institucija, klientų saugumo užtikrinimo komanda arba vidaus audito komitetas gali paklausti: „Parodykite, kaip buvo suvaldytas šis pažeidžiamumas.“

Būtent tada daugelis organizacijų supranta, kad koordinuotas pažeidžiamumų atskleidimas nėra tik saugumo el. pašto dėžutė. Tai valdysenos sistema. Jai reikia politikos savininko, viešo pranešimo kanalo, pirminio vertinimo darbo eigos, taisomųjų veiksmų SLA, tiekėjų eskalavimo, sprendimų dėl incidentų logikos, privatumo peržiūros, vadovybės ataskaitų ir dokumentuotų įrodymų.

Clarysec CVD vertina kaip integruotą kontrolės modelį, o ne kaip atskirą pašto dėžutę. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pažeidžiamumų valdymas įtrauktas į „Controls in Action“ etapą, 19 žingsnį: „Technological Controls I“, kur rekomendacija aiški: organizacijos neturi pasyviai archyvuoti pažeidžiamumų išvadų; jos privalo jas įvertinti, priskirti atsakingiems asmenims ir sekti iki uždarymo. Tas pats standartas taikomas išoriniams atskleidimams. Jei kas nors praneša, kaip jūsų paslauga gali sugesti, tikrasis klausimas yra toks: ar galite įrodyti, kad pranešimą gavote, įvertinote, prioritetizavote, pašalinote, apie jį komunikavote ir iš jo pasimokėte?

Kodėl CVD pagal NIS2 ir DORA tapo valdybos lygmens klausimu

Daugelį metų saugumui brandžios organizacijos kvietė etiškus įsilaužėlius pranešti apie pažeidžiamumus, nes tai buvo geroji praktika. Pagal NIS2 ir DORA ši praktika tapo reglamentuoto skaitmeninio atsparumo dalimi.

NIS2 taikoma daugeliui vidutinio dydžio ir didesnių subjektų itin kritiniuose ir kituose kritiniuose sektoriuose, įskaitant skaitmeninės infrastruktūros teikėjus, debesijos paslaugų teikėjus, duomenų centrų paslaugų teikėjus, valdomų paslaugų teikėjus, valdomo saugumo paslaugų teikėjus ir tam tikrus skaitmeninių paslaugų teikėjus, tokius kaip internetinės prekyvietės, paieškos sistemos ir socialinių tinklų platformos. Ji taip pat gali būti taikoma nepriklausomai nuo dydžio tokioms kategorijoms kaip patikimumo užtikrinimo paslaugų teikėjai, DNS paslaugų teikėjai, TLD registrai ir viešųjų elektroninių ryšių tinklų ar paslaugų teikėjai.

NIS2 Article 21 reikalauja, kad esminiai ir svarbūs subjektai taikytų tinkamas ir proporcingas technines, operacines ir organizacines kibernetinio saugumo rizikos valdymo priemones, vadovaudamiesi visų grėsmių požiūriu. Viena iš minimalių sričių yra tinklų ir informacinių sistemų įsigijimo, kūrimo ir priežiūros saugumas, įskaitant pažeidžiamumų valdymą ir atskleidimą. Tas pats bazinis rinkinys taip pat apima incidentų valdymą, tiekimo grandinės saugumą, veiklos tęstinumą, prieigos kontrolę, turto valdymą, mokymus, kriptografiją ir procedūras kontrolės veiksmingumui vertinti.

NIS2 Article 20 taip pat aiškiai įtvirtina vadovybės atskaitomybę. Valdymo organai privalo patvirtinti kibernetinio saugumo rizikos valdymo priemones, prižiūrėti jų įgyvendinimą ir dalyvauti mokymuose. CVD programai tai reiškia, kad valdyba arba vyresnioji vadovybė turi suprasti pranešimo kanalą, pažeidžiamumų reagavimo komandą, techninės patikros terminus, taisomųjų veiksmų lūkesčius, tiekėjų priklausomybes ir incidentų pranešimo inicijavimo kriterijus.

DORA nuo 2025 m. sausio 17 d. sukuria sektoriui būdingą režimą finansų subjektams. Ji apima IRT rizikos valdymą, su IRT susijusių incidentų pranešimą, skaitmeninio operacinio atsparumo testavimą, dalijimąsi informacija, IRT trečiųjų šalių riziką, sutartinius reikalavimus, kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrą ir priežiūros institucijų bendradarbiavimą. DORA taikomiems finansų subjektams DORA paprastai turi viršenybę prieš NIS2 IRT rizikos valdymo ir incidentų pranešimo srityse, nes tai yra sektoriui būdingas Sąjungos teisės aktas. Tačiau praktinis reikalavimas išlieka tas pats: finansų subjektai ir juos aptarnaujantys IRT paslaugų teikėjai privalo turėti struktūrizuotą, dokumentuotą ir testuojamą procesą IRT silpnosioms vietoms identifikuoti, analizuoti, klasifikuoti, eskaluoti, šalinti ir iš jų mokytis.

Pažeidžiamumo pranešimas gali prasidėti kaip techninė išvada, tapti saugumo įvykiu, eskaluotis į incidentą, inicijuoti GDPR asmens duomenų saugumo pažeidimo vertinimą, pareikalauti tiekėjo veiksmų ir vėliau atsirasti ISO/IEC 27001:2022 Taikytinumo pareiškime. Todėl CVD turi būti kuriamas kaip vienas veiklos modelis, apimantis saugumą, atitiktį, inžineriją, teisę, privatumą, pirkimus ir vadovybę.

ISO 27001 pagrindas: nuo atskleidimo iki ISVS įrodymų

ISO/IEC 27001:2022 suteikia CISO ir atitikties vadovams valdymo sistemą, kuri CVD padaro audituojamą.

4.1–4.4 punktai reikalauja, kad organizacija suprastų vidaus ir išorės aplinkybes, suinteresuotųjų šalių reikalavimus, ISVS ribas ir priklausomybes nuo kitų organizacijų. Būtent čia NIS2, DORA, GDPR, klientų sutartys, tiekėjų įsipareigojimai ir pažeidžiamumų atskleidimo įsipareigojimai patenka į ISVS.

5.1–5.3 punktai sukuria vadovybės atskaitomybę. Aukščiausioji vadovybė turi suderinti informacijos saugumą su strategine kryptimi, skirti išteklius, priskirti atsakomybes ir užtikrinti, kad ISVS pasiektų numatytus rezultatus. CVD atveju tai reiškia pažeidžiamumų reagavimo komandos paskyrimą, įgaliojimų priimti liekamąją riziką apibrėžimą ir didelio poveikio pažeidžiamumų eskalavimą vadovybei.

6.1.1–6.1.3 punktai suteikia rizikos valdymo pagrindą. Organizacija turi apibrėžti rizikos kriterijus, įvertinti informacijos saugumo rizikas, priskirti rizikos savininkus, pasirinkti rizikos tvarkymo parinktis, palyginti kontrolės priemones su A priedu, parengti Taikytinumo pareiškimą ir gauti liekamosios rizikos patvirtinimą. 8.1–8.3 punktai tada reikalauja operacinės kontrolės, planuojamų pakeitimų, išorėje teikiamų procesų kontrolės, rizikos vertinimų planuotais intervalais arba po reikšmingų pokyčių ir rizikos tvarkymo rezultatų įrodymų.

Zenith Blueprint rizikos valdymo etapo 13 žingsnyje Taikytinumo pareiškimas apibūdinamas kaip daugiau nei atitikties skaičiuoklė:

„SoA iš esmės yra jungiamasis dokumentas: jis susieja jūsų rizikos vertinimą / tvarkymą su faktinėmis kontrolės priemonėmis, kurias turite.“
Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, rizikos valdymo etapas, 13 žingsnis: rizikos tvarkymo planavimas ir Taikytinumo pareiškimas (SoA) Zenith Blueprint

Koordinuoto pažeidžiamumų atskleidimo atveju SoA turi susieti reguliacinius įpareigojimus, verslo riziką, A priedo kontrolės priemones, politikos nuostatas ir operacinius įrodymus.

Tikslas nėra kurti lygiagrečius atitikties silosus. CVD politika turi būti kontroliuojamas ISVS procesas, kuris vienu metu palaiko ISO/IEC 27001:2022 sertifikavimą, NIS2 atitiktį, pasirengimą DORA, klientų užtikrinimą ir saugumo operacijas.

Politikos bazinis rinkinys: ką turi nustatyti jūsų CVD politika

Pirmoji matoma kontrolės priemonė yra viešas atskleidimo kanalas. Tyrėjai, klientai, tiekėjai ir partneriai turi žinoti, kur pranešti apie pažeidžiamumus ir kaip apsaugoti jautrius įrodymus.

Clarysec Koordinuoto pažeidžiamumų atskleidimo politika Koordinuoto pažeidžiamumų atskleidimo politika pateikia įmonės bazinį reikalavimą:

„Viešieji atskleidimo kanalai: organizacija privalo palaikyti aiškų pažeidžiamumų pranešimo kanalą, pvz., specialų saugumo kontaktinį el. pašto adresą (pavyzdžiui, security@company.com) arba žiniatinklio formą. Ši informacija turi būti paskelbta įmonės interneto svetainės saugumo puslapyje kartu su organizacijos PGP viešuoju raktu, kad būtų galima teikti šifruotus pranešimus.“
Šaltinis: Koordinuoto pažeidžiamumų atskleidimo politika, įgyvendinimo reikalavimai, 6.1 punktas

Ši nuostata išsprendžia dažną audito neatitiktį. Daugelis organizacijų teigia priimančios pranešimus, tačiau pranešimo kelias yra paslėptas, nešifruotas arba priskirtas netinkamai komandai. Brandus kanalas yra viešas, saugus, stebimas ir priskirtas atsakingai funkcijai.

Kita kontrolės priemonė yra reagavimo disciplina. Kritinis pranešimas, po kurio seka tyla, sukuria atskleidimo riziką, reputacijos riziką ir išnaudojimo riziką. Koordinuoto pažeidžiamumų atskleidimo politika nustato konkretų gavimo patvirtinimo ir techninės patikros lūkestį:

„Pirminis vertinimas ir gavimo patvirtinimas: gavusi pranešimą, VRT privalo jį užregistruoti ir per 2 darbo dienas išsiųsti pranešėjui gavimo patvirtinimą, priskirdama sekimo identifikatorių. VRT turi atlikti preliminarų sunkumo vertinimą, pavyzdžiui, naudodama CVSS balų sistemą, ir patikrinti problemą, prireikus pasitelkdama IT ir kūrimo komandas, per tikslinį 5 darbo dienų terminą. Kritiniai pažeidžiamumai, pavyzdžiui, leidžiantys nuotolinį kodo vykdymą arba galintys sukelti didelį duomenų saugumo pažeidimą, turi būti nagrinėjami pagreitinta tvarka.“
Šaltinis: Koordinuoto pažeidžiamumų atskleidimo politika, įgyvendinimo reikalavimai, 6.4 punktas

Ši formuluotė sukuria tiesioginius įrodymų taškus: gavimo laiką, gavimo patvirtinimo laiką, sekimo identifikatorių, preliminarų sunkumą, techninės patikros rezultatą ir sprendimą dėl pagreitinto tvarkymo.

MVĮ atveju Clarysec taiko tą pačią logiką proporcingai. Taikomųjų programų saugumo reikalavimų politika MVĮ Taikomųjų programų saugumo reikalavimų politika - SME reikalauja, kad organizacijos:

„nurodytų pažeidžiamumų atskleidimo, reagavimo terminų ir pataisų diegimo įsipareigojimus.“
Šaltinis: Taikomųjų programų saugumo reikalavimų politika MVĮ, valdysenos reikalavimai, 5.3.2 punktas

Atskaitomybei nereikia didelės produktų saugumo komandos. Reikia aiškių įsipareigojimų, realistiškų terminų, įvardytų savininkų ir įrodymų, kad procesas veikia.

CVD priėmimo darbo eiga: nuo tyrėjo el. laiško iki sprendimo įrašo

Gera priėmimo darbo eiga turi būti pakankamai paprasta, kad veiktų spaudimo sąlygomis, ir pakankamai išsami, kad patenkintų auditorių. Ji turėtų prasidėti specialiu kanalu, pvz., security@[company], žiniatinklio forma arba paskelbtu security.txt failu. Pateikimo kelias turi leisti pateikti šifruotus įrodymus, paveiktą produktą ar galinį tašką, atkūrimo veiksmus, pranešėjo kontaktinius duomenis, pageidaujamą atskleidimo laiką ir bet kokią informaciją apie duomenų atskleidimą ar aktyvų išnaudojimą.

Gavusi pranešimą, pažeidžiamumų reagavimo komanda turi sukurti įrašą GRC priemonėje, užklausų valdymo platformoje, pažeidžiamumų valdymo sistemoje arba kontroliuojamame registre. Priemonė yra mažiau svarbi nei nuoseklumas ir įrodymų kokybė.

Tada darbo eiga turėtų pereiti septynis operacinius veiksmus.

1. Priėmimas: pranešimas gaunamas per viešą kanalą ir automatiškai arba rankiniu būdu užregistruojamas.
2. Gavimo patvirtinimas: VRT atsako per 2 darbo dienas ir priskiria sekimo identifikatorių.
3. Techninė patikra: techninė komanda atkuria problemą, patvirtina paveiktas sistemas ir atlieka preliminarų sunkumo vertinimą balais.
4. Įvykio vertinimas: VRT nustato, ar pažeidžiamumas yra tik silpnoji vieta, informacijos saugumo įvykis ar incidentas.
5. Eskalavimas: didelio arba kritinio sunkumo klausimai pagal poreikį perduodami sistemų savininkams, CISO, privatumo, teisės, tiekėjų valdymo funkcijoms ir vadovybei.
6. Taisomieji veiksmai: atsakinga komanda pritaiko pataisą, švelninimo priemonę, kompensuojančią kontrolės priemonę arba laikiną apribojimą.
7. Uždarymas: VRT patikrina pataisą, komunikuoja su pranešėju, atnaujina įrodymų bylą ir užregistruoja įgytą patirtį.

Clarysec susieja šį operacinį žingsnį su ISO/IEC 27002:2022 kontrolės priemone A.5.25, informacijos saugumo įvykių vertinimu ir sprendimu, ir kontrolės priemone A.8.8, techninių pažeidžiamumų valdymu, per Zenith Controls: The Cross-Compliance Guide Zenith Controls. A.5.25 atveju Zenith Controls paaiškina, kad įvykių vertinimas yra pirminio vertinimo funkcija tarp neapdorotų stebėsenos perspėjimų ir formalaus incidentų valdymo, naudojanti žurnalus, slenksčius ir sprendimo kriterijus eskalavimui nustatyti. A.8.8 atveju Zenith Controls susieja techninių pažeidžiamumų valdymą su apsauga nuo kenkėjiškos programinės įrangos, konfigūracijų valdymu, pakeitimų valdymu, galinių įrenginių saugumu, grėsmių žvalgyba, stebėsena, saugiu kūrimu, įvykių vertinimu ir reagavimu į incidentus.

Viena Zenith Controls ištrauka ypač naudinga, kai įtariamas aktyvus išnaudojimas:

„Grėsmių žvalgyba informuoja, kurie pažeidžiamumai yra aktyviai išnaudojami, ir padeda prioritetizuoti pataisų diegimą.“
Šaltinis: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 kontrolės priemonė 8.8, sąsaja su kontrolės priemone 5.7 Grėsmių žvalgyba Zenith Controls

Tai svarbus valdysenos aspektas. Sunkumas nėra vien CVSS. Vidutinį balą turintis pažeidžiamumas, aktyviai išnaudojamas prieš jūsų sektorių, gali būti svarbesnis už teorinę kritinę problemą nepasiekiamoje testavimo sistemoje.

Kada pažeidžiamumas tampa incidentu

Ne kiekvienas pažeidžiamumo pranešimas yra incidentas. Trūkstama saugumo antraštė parengiamojoje aplinkoje nėra tas pats, kas išnaudotas autorizavimo apėjimas, atskleidžiantis klientų sąskaitas. Tačiau kiekvienas patikimas pažeidžiamumo pranešimas turi pereiti sprendimo dėl incidento vartus.

NIS2 Article 23 reikalauja, kad esminiai ir svarbūs subjektai nepagrįstai nedelsdami praneštų savo CSIRT arba kompetentingai institucijai apie incidentus, kurie reikšmingai paveikia paslaugų teikimą. Reikšmingas incidentas yra toks, kuris sukėlė arba gali sukelti didelį veiklos sutrikimą ar finansinius nuostolius arba paveikė ar gali paveikti kitus, sukeldamas didelę turtinę arba neturtinę žalą. Pranešimų seka apima ankstyvąjį įspėjimą per 24 valandas nuo sužinojimo, incidento pranešimą per 72 valandas, tarpines ataskaitas pagal prašymą ir galutinę ataskaitą per vieną mėnesį nuo 72 valandų pranešimo.

DORA Articles 17 to 20 reikalauja, kad finansų subjektai aptiktų, valdytų, registruotų, klasifikuotų, eskaluotų, praneštų ir komunikuotų su IRT susijusius incidentus ir reikšmingas kibernetines grėsmes. Reikšmingi su IRT susiję incidentai turi būti eskaluojami vyresniajai vadovybei ir valdymo organui. Kai paveikiami finansiniai interesai, gali būti reikalaujama komunikacijos su klientais.

MVĮ pranešimo kultūra turi būti tokia pat aiški. Clarysec Reagavimo į incidentus politika MVĮ Reagavimo į incidentus politika - SME nurodo:

„Darbuotojai privalo pranešti apie bet kokią įtartiną veiklą arba patvirtintą incidentą adresu incident@[company] arba žodžiu generaliniam direktoriui ar IT paslaugų teikėjui.“
Šaltinis: Reagavimo į incidentus politika MVĮ, politikos įgyvendinimo reikalavimai, 6.2.1 punktas

Zenith Blueprint „Controls in Action“ etapo 16 žingsnyje: „People Controls II“, principas dar paprastesnis:

„Jei abejojate, praneškite.“
Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, „Controls in Action“ etapas, 16 žingsnis: „People Controls II“ (A.6.5 to A.6.8)

Ši frazė turi būti taikoma kūrėjams, pagalbos komandoms, tiekėjų valdytojams, privatumo vadovams, vykdomiesiems vadovams ir išorės paslaugų teikėjams. Pažeidžiamumas, galintis paveikti konfidencialumą, vientisumą, prieinamumą, klientų pasitikėjimą, reguliacinius pranešimus arba finansines operacijas, turi būti užregistruotas ir įvertintas, o ne neformaliai tvarkomas pokalbių kanale.

Taisomieji veiksmai, pataisų diegimas ir kompensuojančios kontrolės priemonės

Kai pažeidžiamumas patikrinamas, jis turi būti suvaldytas. Rizikos tvarkymas turi būti pagrįstas rizika, paremtas įrodymais ir ribotas laike.

Koordinuoto pažeidžiamumų atskleidimo politika nustato įmonės lūkestį:

„Taisomųjų veiksmų planas: visiems patvirtintiems pažeidžiamumams turi būti parengtas taisomųjų veiksmų arba švelninimo planas. Pataisos įgyvendinimas turi būti prioritetizuojamas pagal sunkumą. Pavyzdžiui, kritiniai pažeidžiamumai, kai įmanoma, turi būti pašalinti arba sušvelninti per 14 dienų arba greičiau, kai aptinkamas aktyvus išnaudojimas, o mažesnio sunkumo problemos turi būti sprendžiamos per pagrįstą terminą. Kai visavertė pataisa vėluoja, turi būti įgyvendintos kompensuojančios kontrolės priemonės arba laikinos švelninimo priemonės, pvz., pažeidžiamos funkcijos išjungimas arba stebėsenos sustiprinimas.“
Šaltinis: Koordinuoto pažeidžiamumų atskleidimo politika, įgyvendinimo reikalavimai, 6.6 punktas

MVĮ pataisų diegimo disciplinai Pažeidžiamumų ir pataisų valdymo politika MVĮ Pažeidžiamumų ir pataisų valdymo politika - SME nurodo:

„Kritinės pataisos turi būti įdiegtos per 3 dienas nuo išleidimo, ypač į internetą nukreiptoms sistemoms“
Šaltinis: Pažeidžiamumų ir pataisų valdymo politika MVĮ, politikos įgyvendinimo reikalavimai, 6.1.1 punktas

Šie terminai neprieštarauja vienas kitam. Tiekėjo pataisai, skirtai į internetą nukreiptai sistemai, gali reikėti labai greito diegimo. Produkto pažeidžiamumui, kuriam reikia kodo pakeitimų, regresinio testavimo, klientų koordinavimo ir etapinio išleidimo, gali reikėti taisomųjų veiksmų plano su tarpinėmis švelninimo priemonėmis. Svarbiausia, kad sprendimas būtų dokumentuotas, priskirtas rizikos savininkui ir patvirtintas, kai lieka liekamoji rizika.

Praktinis atvejis gali atrodyti taip:

1. Tyrėjas praneša apie autorizavimo apėjimą klientų atsiskaitymų API.
2. VRT užregistruoja CVD-2026-014 su laiko žyma ir patvirtina gavimą per 2 darbo dienas.
3. Produktų saugumo komanda per 24 valandas patikrina trūkumą ir priskiria didelį sunkumą dėl prieigos prie skirtingų klientų aplinkų duomenų.
4. Privatumo funkcija atlieka GDPR pažeidimo vertinimą, nes sąskaitų įrašuose gali būti asmens duomenų.
5. Incidentų valdytojas pradeda įvykio vertinimą pagal ISO/IEC 27002:2022 kontrolės priemonę A.5.25.
6. Sistemos savininkas išjungia pažeidžiamą galinį tašką naudodamas laikiną funkcijos vėliavėlę.
7. Inžinerijos komanda sukuria skubią pataisą pagal ISO/IEC 27002:2022 kontrolės priemonę A.8.32, pakeitimų valdymą.
8. Pridedamos stebėsenos taisyklės išnaudojimo indikatoriams, susietos su A.8.15, žurnalų registravimu, ir A.8.16, stebėsenos veikla.
9. CISO informuoja vyresniąją vadovybę, nes klausimas yra didelės rizikos.
10. VRT koordinuoja su tyrėju pakartotinį testavimą ir atskleidimo laiką.
11. Rizikos savininkas patvirtina uždarymą tik po patikrinamojo testavimo ir poveikio klientams peržiūros.
12. Atnaujinami SoA, rizikų registras, užklausa, žurnalai, vadovybės pranešimas ir įgyta patirtis.

Tai yra skirtumas tarp „mes pataisėme“ ir „galime įrodyti, kad tai valdėme“.

Tiekėjų ir debesijos priklausomybės: paslėptas nesėkmės taškas

Daugelis CVD nesėkmių iš tikrųjų yra tiekėjų nesėkmės. Pažeidžiamumas gali paveikti SaaS komponentą, debesijos paslaugą, valdomo saugumo paslaugų teikėją, mokėjimų šliuzą, autentifikavimo tarpininką, atvirojo kodo biblioteką, išorės kūrimo komandą arba subtiekėją.

NIS2 Article 21 reikalauja tiekimo grandinės saugumo, įskaitant santykius su tiesioginiais tiekėjais ir paslaugų teikėjais. Tiekimo grandinės priemonės turi atsižvelgti į tiekėjų pažeidžiamumus, produktų kokybę, kibernetinio saugumo praktikas ir saugaus kūrimo procedūras.

DORA Articles 28 to 30 finansų subjektams nustato dar gilesnius reikalavimus. Jos reikalauja, kad IRT trečiųjų šalių rizika būtų valdoma kaip IRT rizikos sistemos dalis, įskaitant IRT paslaugų sutarčių registrus, kritinių ar svarbių funkcijų atskyrimą, deramą patikrinimą prieš sudarant sutartį, sutartinius saugumo reikalavimus, pagalbą incidentų atveju, bendradarbiavimą su institucijomis, audito teises, nutraukimo teises ir pasitraukimo strategijas. Finansų subjektai išlieka visiškai atsakingi už DORA atitiktį net naudodamiesi IRT trečiųjų šalių paslaugų teikėjais.

Clarysec Trečiųjų šalių ir tiekėjų saugumo politika MVĮ Trečiųjų šalių ir tiekėjų saugumo politika - SME apima paprastą eskalavimo taisyklę:

„Privalo nedelsiant informuoti generalinį direktorių apie bet kokį saugumo pažeidimą, pakeitimą ar incidentą“
Šaltinis: Trečiųjų šalių ir tiekėjų saugumo politika MVĮ, vaidmenys ir atsakomybės, 4.4.3 punktas

Įmonių tiekėjų sutartims Zenith Blueprint, „Controls in Action“ etapas, 23 žingsnis, rekomenduoja įtraukti konfidencialumo įsipareigojimus, prieigos kontrolės atsakomybes, technines ir organizacines priemones, incidentų pranešimo terminus, audito teisę, subtiekėjų kontrolės priemones ir sutarties pabaigos nuostatas. Jame teigiama:

„Svarbiausia, kad jos egzistuotų ir būtų suprastos bei priimtos abiejų šalių.“
Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, „Controls in Action“ etapas, 23 žingsnis: organizacinės kontrolės priemonės (5.19 to 5.37)

CVD tiekėjų pasirengimas turi atsakyti į šiuos klausimus:

• Ar tiekėjas skelbia pažeidžiamumų pranešimo kanalą?
• Ar sutartyje apibrėžti pažeidžiamumų pranešimo terminai?
• Ar kritiniai tiekėjų pažeidžiamumai pranešami nepagrįstai nedelsiant?
• Ar klientus paveikiančios silpnosios vietos susietos su pagalbos incidentų atveju įsipareigojimais?
• Ar tiekėjas gali pateikti taisomųjų veiksmų įrodymus arba saugumo pranešimus?
• Ar subtiekėjams perduodami pažeidžiamumų įsipareigojimai?
• Ar yra pasitraukimo strategija, jei taisomieji veiksmai nepakankami?

Čia NIS2, DORA ir ISO/IEC 27001:2022 susilieja. Tiekėjų pažeidžiamumų valdymas nėra pirkimų kontrolinis langelis. Tai operacinio atsparumo dalis.

Įrodymų susiejimas ISO 27001, NIS2, DORA, GDPR ir COBIT kontekste

Stipriausios CVD programos pirmiausia orientuojasi į įrodymus. Jos daro prielaidą, kad bet kuris reikšmingas pranešimas vėliau gali būti peržiūrimas vidaus audito, sertifikavimo auditorių, reguliuotojų, klientų, draudikų arba valdybos rizikos komiteto.

Clarysec Audito ir atitikties stebėsenos politika MVĮ Audito ir atitikties stebėsenos politika - SME užfiksuoja detalę, kurią daugelis komandų praleidžia:

„Metaduomenys (pvz., kas juos surinko, kada ir iš kurios sistemos) turi būti dokumentuoti.“
Šaltinis: Audito ir atitikties stebėsenos politika MVĮ, politikos įgyvendinimo reikalavimai, 6.2.3 punktas

Pataisyto serverio ekrano kopija yra silpnas įrodymas, jei niekas nežino, kas ją užfiksavo, kada, iš kurios sistemos ir kaip ji susieta su pažeidžiamumu. Užklausa su laiko žymomis, skenerio išvestimi, pull request, pakeitimo patvirtinimu, diegimo žurnalais, stebėsenos užklausa, pakartotinio testavimo patvirtinimu ir metaduomenimis yra gerokai stipresnė.

Išsamesnė atsekamumo matrica padeda klientų deramo patikrinimo ir vidaus audito metu.

Skirtingi auditoriai tą patį procesą tikrins per skirtingas prizmes.

ISO/IEC 27001:2022 auditorius pradės nuo ISVS. Jis klaus, ar pažeidžiamumų atskleidimo įsipareigojimai įtraukti į suinteresuotųjų šalių reikalavimus, ar rizikos vertinamos nuosekliai, ar kontrolės priemonės atsispindi SoA, ar yra veiklos įrodymų ir ar vadovybė peržiūri tendencijas bei vėluojančius elementus.

DORA arba finansinių paslaugų peržiūrą atliekantis asmuo daugiausia dėmesio skirs operaciniam atsparumui. Jis nagrinės IRT rizikos integraciją, incidentų klasifikavimą, eskalavimą vyresniajai vadovybei, klientų komunikaciją, priklausomybes nuo trečiųjų šalių, testavimą ir įgytą patirtį. Jei pažeidžiamumas paveikia kritinę arba svarbią funkciją, bus tikimasi glaudaus ryšio tarp techninės užklausos, verslo poveikio, tęstinumo pasekmių ir tiekėjo įsipareigojimų.

GDPR peržiūrą atliekantis asmuo daugiausia dėmesio skirs asmens duomenims. Ar buvo susiję asmens duomenys? Ar buvo neteisėta prieiga, praradimas, pakeitimas arba atskleidimas? Ar buvo aiškūs valdytojo ir tvarkytojo vaidmenys? Ar buvo įvertintas pažeidimo slenkstis? Ar buvo aktualios tokios apsaugos priemonės kaip šifravimas, prieigos kontrolė, žurnalavimas ir minimizavimas?

COBIT 2019 arba ISACA auditorius daugiausia dėmesio skirs valdysenai, atskaitomybei, veiklos rezultatams ir užtikrinimui. Jis ieškos apibrėžtos savininkystės, rodiklių, eskalavimo, kontrolės tikslų, vadovybės priežiūros ir išimčių sekimo. Vėluojantis kritinis pažeidžiamumas nėra tik techninė problema. Tai valdysenos problema, nebent ji formaliai eskaluota ir rizika priimta.

NIST orientuotas vertintojas mąstys pagal Identify, Protect, Detect, Respond ir Recover funkcijas. Jam reikės turto savininkystės, pažeidžiamumų identifikavimo, prioritetizavimo, apsauginio pakeitimo, išnaudojimo aptikimo, reagavimo koordinavimo ir atkūrimo patikros.

Integruoto CVD modelio pranašumas yra tas, kad ta pati įrodymų struktūra gali palaikyti visas šias peržiūras.

Mėnesinis kontrolės ciklas: vadovybei naudingi rodikliai

CVD nesibaigia uždarius užklausą. Koordinuoto pažeidžiamumų atskleidimo politika reikalauja nuolatinės žurnalų peržiūros:

„VRT privalo palaikyti pažeidžiamumų atskleidimo žurnalą, kuriame kiekvienas pranešimas sekamas nuo gavimo iki uždarymo. Žurnalas turi būti peržiūrimas kas mėnesį, siekiant užtikrinti savalaikę atvirų elementų eigą. Vėluojantys elementai turi būti eskaluojami.“
Šaltinis: Koordinuoto pažeidžiamumų atskleidimo politika, stebėsena ir auditas, 9.1 punktas

Ši mėnesinė peržiūra pažeidžiamumų atskleidimą paverčia valdybai tinkama valdysena. Vadovybei nereikia kiekvienos techninės detalės. Jai reikia tendencijos, ekspozicijos, atskaitomybės ir vėluojančios rizikos.

Brandžioje Clarysec įgyvendinimo aplinkoje ši mėnesinė žurnalo peržiūra papildo rizikų registrą, Taikytinumo pareiškimą, saugaus kūrimo darbų sąrašą, tiekėjų peržiūras, incidentų metu įgytą patirtį, vidaus audito planą ir vadovybės ataskaitų paketą.

Sukurkite procesą prieš gaudami rimtą pranešimą

Blogiausias laikas projektuoti koordinuotą pažeidžiamumų atskleidimą yra tada, kai tyrėjas jau viešai paskelbė jūsų silpnąją vietą arba kritinis banko klientas sustabdė įdiegimą. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST tipo atsparumo lūkesčiai ir COBIT 2019 valdysena rodo tą pačią kryptį: pažeidžiamumų atskleidimas turi būti suplanuotas, turėti savininką, būti testuojamas, pagrįstas įrodymais ir tobulinamas.

Pradėkite nuo šių penkių veiksmų:

1. Priimkite arba pritaikykite Koordinuoto pažeidžiamumų atskleidimo politiką.
2. Sukurkite priėmimo ir pirminio vertinimo darbo eigą naudodami Zenith Blueprint, ypač 13 žingsnį SoA atsekamumui, 16 žingsnį pranešimo kultūrai, 19 žingsnį techninių pažeidžiamumų valdymui ir 23 žingsnį tiekėjų susitarimams.
3. Susiekite darbo eigą per Zenith Controls, sutelkdami dėmesį į ISO/IEC 27002:2022 kontrolės priemones A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 ir A.8.32.
4. Kai svarbus proporcingumas, pridėkite MVĮ pritaikytas nuostatas iš Reagavimo į incidentus politika MVĮ, Pažeidžiamumų ir pataisų valdymo politika MVĮ, Trečiųjų šalių ir tiekėjų saugumo politika MVĮ, Taikomųjų programų saugumo reikalavimų politika MVĮ ir Audito ir atitikties stebėsenos politika MVĮ.
5. Surenkite stalo pratybas, imituojančias tyrėjo pranešimą, paveikiantį asmens duomenis ir tiekėjo talpinamą komponentą, tada patikrinkite gavimo patvirtinimą, pirminį vertinimą, incidento klasifikavimą, pataisų diegimą, klientų komunikaciją, įrodymų surinkimą ir vadovybės eskalavimą.

Clarysec gali padėti tai paversti veikiančia CVD politika, priėmimo registru, ISO/IEC 27001:2022 įrodymų žemėlapiu, NIS2 ir DORA sprendimų medžiu, tiekėjų eskalavimo modeliu ir auditui tinkamu kontrolės priemonių paketu. Tikslas paprastas: kai ateis kitas pažeidžiamumo pranešimas, jūsų komanda neturi improvizuoti. Ji turi veikti užtikrintai, remdamasi įrodymais ir kontrole.