CVD za NIS2 i DORA: mapa dokaza prema ISO 27001

U utorak u 08:17 sigurnosni poštanski sandučić zaprima poruku neovisnog istraživača. Predmet poruke miran je, gotovo uljudan: „Moguće preuzimanje računa na vašem korisničkom portalu.” Sadržaj poruke znatno je neugodniji. Istraživač tvrdi da ulančana ranjivost u vašoj SaaS aplikaciji omogućuje jednom korisniku pristup zapisima računa drugog korisnika. Dokaz koncepta priložen je i šifriran vašim objavljenim PGP ključem.

Za Mariju, novu CISO u FinanTechSaaS-u, trenutak ne može biti lošiji. Njezina je tvrtka upravo potpisala veliki ugovor s vodećom bankom iz EU-a. Tim klijenta za dubinsku provjeru dobavljača već je zatražio „Politiku koordiniranog otkrivanja ranjivosti” i dokaze o provedbi, izričito se pozivajući na NIS2 i DORA. Tvrtka ima adresu e-pošte security@, ali nadzire je jedan razvojni inženjer. Ne postoji formalna evidencija zaprimljenih prijava, definirani SLA za provjeru, put eskalacije prema upravi ni revizijski trag.

Istodobno počinju teći tri sata.

Prvi je operativni. Je li ranjivost stvarna? Može li se iskoristiti u produkciji? Iskorištava li je netko aktivno?

Drugi je regulatorni. Ako su izloženi podaci klijenata, započinje procjena povrede prema GDPR-u. Ako je pružanje usluge pogođeno za ključni ili važni subjekt prema NIS2, mogu se aktivirati pragovi za prijavu incidenta. Ako je tvrtka financijski subjekt ili IKT pružatelj usluga koji podržava financijske usluge, mogu postati relevantna pravila DORA o upravljanju incidentima, klasifikaciji, eskalaciji i komunikaciji s klijentima.

Treći je dokazni. Šest mjeseci poslije, revizor ISO/IEC 27001:2022, nadzorno tijelo financijskog sektora, klijentov tim za sigurnosnu provjeru ili odbor za internu reviziju može pitati: „Pokažite nam kako ste postupili s ovom ranjivošću.”

Upravo na tom pitanju mnoge organizacije otkrivaju da koordinirano otkrivanje ranjivosti nije samo sigurnosni poštanski sandučić. To je sustav upravljanja. Potrebni su vlasništvo nad politikom, javni kanal za prijavu, tijek trijaže, SLA-ovi za otklanjanje nedostataka, eskalacija prema dobavljačima, logika odlučivanja o incidentima, pregled utjecaja na privatnost, izvješćivanje uprave i provjerljivi dokazi.

Clarysec CVD tretira kao integrirani obrazac kontrola, a ne kao samostalni poštanski sandučić. U Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, postupanje s ranjivostima pojavljuje se u fazi Controls in Action, korak 19: Technological Controls I, gdje su smjernice jasne: organizacije ne bi trebale pasivno arhivirati nalaze ranjivosti, nego ih trijažirati, dodjeljivati odgovornima i pratiti do zatvaranja. Isti standard vrijedi za vanjska otkrivanja. Ako vam netko kaže kako vaša usluga može zakazati, stvarno pitanje postaje: možete li dokazati da ste prijavu zaprimili, procijenili, prioritizirali, otklonili, komunicirali i iz nje naučili?

Zašto je CVD sada pitanje na razini upravnog odbora prema NIS2 i DORA

Godinama su sigurnosno osviještene organizacije pozivale etičke hakere da prijavljuju ranjivosti jer je to bila dobra praksa. Prema NIS2 i DORA, ta je praksa postala dio regulirane digitalne otpornosti.

NIS2 se primjenjuje na mnoge srednje i velike subjekte u visokokritičnim i drugim kritičnim sektorima, uključujući pružatelje digitalne infrastrukture, pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga i određene digitalne pružatelje kao što su internetska tržišta, tražilice i platforme društvenih mreža. Može se primjenjivati i neovisno o veličini na kategorije kao što su pružatelji usluga povjerenja, pružatelji DNS usluga, registri TLD-a te pružatelji javnih elektroničkih komunikacijskih mreža ili usluga.

NIS2 Article 21 zahtijeva da ključni i važni subjekti provedu odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere upravljanja rizicima kibernetičke sigurnosti primjenom pristupa koji obuhvaća sve opasnosti. Jedno od minimalnih područja jest sigurnost pri nabavi, razvoju i održavanju mrežnih i informacijskih sustava, uključujući postupanje s ranjivostima i njihovo otkrivanje. Ista polazna osnova obuhvaća i postupanje s incidentima, sigurnost opskrbnog lanca, kontinuitet poslovanja, kontrolu pristupa, upravljanje imovinom, osposobljavanje, kriptografiju i postupke za procjenu djelotvornosti kontrola.

NIS2 Article 20 također izričito utvrđuje odgovornost uprave. Upravljačka tijela moraju odobriti mjere upravljanja rizicima kibernetičke sigurnosti, nadzirati njihovu provedbu i pohađati osposobljavanje. Za CVD program to znači da upravni odbor ili više rukovodstvo trebaju razumjeti kanal za prijavu, tim za odgovor na ranjivosti, rokove za provjeru, očekivanja u pogledu otklanjanja nedostataka, ovisnosti o dobavljačima i okidače za prijavu incidenta.

DORA od 17. siječnja 2025. uspostavlja sektorski poseban režim za financijske subjekte. Obuhvaća upravljanje IKT rizicima, prijavljivanje incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti, razmjenu informacija, rizik trećih strana u području IKT-a, ugovorne zahtjeve, nadzor nad kritičnim IKT pružateljima usluga trećih strana i suradnju nadzornih tijela. Za financijske subjekte obuhvaćene DORA, DORA u pravilu ima prednost pred NIS2 za upravljanje IKT rizicima i prijavljivanje incidenata jer je sektorski poseban pravni akt Unije. No praktični zahtjev ostaje isti: financijski subjekti i IKT pružatelji koji ih opslužuju moraju provoditi strukturiran, dokumentiran i provjerljiv proces za identifikaciju, analizu, klasifikaciju, eskalaciju, otklanjanje i učenje iz IKT slabosti.

Prijava ranjivosti može započeti kao tehnički nalaz, postati sigurnosni događaj, eskalirati u incident, pokrenuti procjenu povrede osobnih podataka prema GDPR-u, zahtijevati postupanje dobavljača i kasnije se pojaviti u ISO/IEC 27001:2022 Izjavi o primjenjivosti. Zato CVD treba oblikovati kao jedinstveni operativni model za sigurnost, usklađenost, inženjering, pravne poslove, privatnost, nabavu i upravu.

Temelj ISO 27001: od otkrivanja do dokaza ISMS-a

ISO/IEC 27001:2022 daje CISO-ima i voditeljima usklađenosti sustav upravljanja koji CVD čini provjerljivim u reviziji.

Točke 4.1 do 4.4 zahtijevaju da organizacija razumije interna i vanjska pitanja, zahtjeve zainteresiranih strana, granice ISMS-a i ovisnosti o drugim organizacijama. Tu NIS2, DORA, GDPR, ugovori s klijentima, obveze dobavljača i obveze povezane s otkrivanjem ranjivosti ulaze u ISMS.

Točke 5.1 do 5.3 stvaraju odgovornost vodstva. Najviše rukovodstvo mora uskladiti informacijsku sigurnost sa strateškim usmjerenjem, osigurati resurse, dodijeliti odgovornosti i osigurati da ISMS ostvaruje predviđene ishode. Za CVD to znači imenovanje tima za odgovor na ranjivosti, definiranje ovlasti za prihvaćanje preostalog rizika i eskalaciju ranjivosti visokog utjecaja prema upravi.

Točke 6.1.1 do 6.1.3 daju mehanizam upravljanja rizicima. Organizacija mora definirati kriterije rizika, procijeniti rizike informacijske sigurnosti, dodijeliti vlasnike rizika, odabrati opcije obrade rizika, usporediti kontrole s Prilogom A, izraditi Izjavu o primjenjivosti i pribaviti odobrenje za preostali rizik. Točke 8.1 do 8.3 zatim zahtijevaju operativno upravljanje, planirane promjene, kontrolu eksterno pruženih procesa, procjene rizika u planiranim intervalima ili nakon značajnih promjena te dokaze o rezultatima obrade rizika.

U Zenith Blueprint, faza Risk Management, korak 13, Izjava o primjenjivosti opisana je kao više od proračunske tablice za usklađenost:

„SoA je zapravo povezni dokument: povezuje vašu procjenu/obradu rizika sa stvarnim kontrolama koje imate.”
Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Risk Management, korak 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Za koordinirano otkrivanje ranjivosti, SoA treba povezati regulatorne obveze, poslovni rizik, kontrole iz Priloga A, odredbe politike i operativne dokaze.

Cilj nije stvarati paralelne silose usklađenosti. CVD politika treba biti kontrolirani ISMS proces koji istodobno podržava certifikaciju ISO/IEC 27001:2022, usklađenost s NIS2, spremnost za DORA, dokazivanje sigurnosti prema zahtjevima klijenata i sigurnosne operacije.

Polazna osnova politike: što vaša CVD politika mora sadržavati

Prva vidljiva kontrola jest javni kanal za prijavu. Istraživači, klijenti, dobavljači i partneri moraju znati gdje prijaviti ranjivosti i kako zaštititi osjetljive dokaze.

Clarysecova Politika koordiniranog otkrivanja ranjivosti Politika koordiniranog otkrivanja ranjivosti daje korporativnu polaznu osnovu:

„Javni kanali za otkrivanje: Organizacija mora održavati jasan kanal za prijavu ranjivosti, kao što je namjenska sigurnosna kontakt adresa e-pošte (na primjer, security@company.com) ili web obrazac. Ta se informacija mora objaviti na sigurnosnoj stranici internetske stranice društva zajedno s javnim PGP ključem organizacije kako bi se omogućilo šifrirano podnošenje prijava.”
Izvor: Politika koordiniranog otkrivanja ranjivosti, Zahtjevi za provedbu, točka 6.1

Ova točka rješava čest neuspjeh u reviziji. Mnoge organizacije tvrde da prihvaćaju prijave, ali je put prijave skriven, nešifriran ili u vlasništvu pogrešnog tima. Zreo kanal je javan, siguran, nadziran i dodijeljen odgovornoj funkciji.

Sljedeća kontrola jest disciplina odgovora. Kritična prijava nakon koje slijedi šutnja stvara rizik objave, reputacijski rizik i rizik iskorištavanja. Politika koordiniranog otkrivanja ranjivosti postavlja konkretno očekivanje za potvrdu zaprimanja i provjeru:

„Trijaža i potvrda zaprimanja: Po zaprimanju prijave, VRT je mora evidentirati i poslati potvrdu zaprimanja prijavitelju u roku od 2 radna dana, uz dodjelu referentne oznake za praćenje. VRT mora provesti preliminarnu procjenu ozbiljnosti, primjerice primjenom CVSS bodovanja, i provjeriti problem, uključujući podršku IT i razvojnih timova gdje je to potrebno, u ciljnom roku od 5 radnih dana. Kritične ranjivosti, primjerice one koje omogućuju udaljeno izvršavanje koda ili veću povredu podataka, moraju se rješavati ubrzano.”
Izvor: Politika koordiniranog otkrivanja ranjivosti, Zahtjevi za provedbu, točka 6.4

Ova formulacija odmah stvara dokazne točke: vrijeme zaprimanja, vrijeme potvrde zaprimanja, referentnu oznaku za praćenje, preliminarnu ozbiljnost, ishod provjere i odluku o ubrzanom postupanju.

Za mala i srednja poduzeća Clarysec primjenjuje istu logiku razmjernom provedbom. Politika zahtjeva za sigurnost aplikacija - SME Politika zahtjeva za sigurnost aplikacija - SME zahtijeva od organizacija da:

„navedu obveze za otkrivanje ranjivosti, rokove odgovora i zakrpavanje.”
Izvor: Politika zahtjeva za sigurnost aplikacija - SME, Zahtjevi upravljanja, točka 5.3.2

Ne trebate veliki tim za sigurnost proizvoda da biste postupali odgovorno. Trebate izričite obveze, realne rokove, imenovane vlasnike i dokaze da proces funkcionira.

Tijek zaprimanja CVD prijava: od e-pošte istraživača do zapisa odluke

Dobar tijek zaprimanja prijava dovoljno je jednostavan da se može provesti pod pritiskom i dovoljno potpun da zadovolji revizora. Treba započeti namjenskim kanalom kao što je security@[company], web obrazac ili objavljena datoteka security.txt. Put podnošenja prijave treba omogućiti šifrirane dokaze, pogođeni proizvod ili krajnju točku, korake za reprodukciju, kontakt podatke prijavitelja, željeno vrijeme objave i svaku naznaku izloženosti podataka ili aktivnog iskorištavanja.

Nakon zaprimanja, tim za odgovor na ranjivosti treba izraditi zapis u GRC alatu, platformi za evidentiranje zahtjeva, sustavu za upravljanje ranjivostima ili kontroliranoj evidenciji. Alat je manje važan od dosljednosti i kvalitete dokaza.

Tijek rada zatim treba proći kroz sedam operativnih koraka.

1. Zaprimanje, prijava se prima putem javnog kanala i automatski ili ručno evidentira.
2. Potvrda zaprimanja, VRT odgovara u roku od 2 radna dana i dodjeljuje referentnu oznaku za praćenje.
3. Provjera, tehnički tim reproducira problem, potvrđuje pogođene sustave i provodi preliminarno bodovanje ozbiljnosti.
4. Procjena događaja, VRT utvrđuje je li ranjivost samo slabost, događaj informacijske sigurnosti ili incident.
5. Eskalacija, visoki ili kritični problemi šalju se vlasnicima sustava, CISO-u, funkciji privatnosti, pravnim poslovima, dobavljačima i upravi prema potrebi.
6. Otklanjanje nedostatka, odgovorni tim primjenjuje ispravak, ublažavanje, kompenzacijsku kontrolu ili privremeno ograničenje.
7. Zatvaranje, VRT provjerava ispravak, komunicira s prijaviteljem, ažurira dokaznu dokumentaciju i evidentira naučene lekcije.

Clarysec mapira ovaj operativni korak na kontrolu ISO/IEC 27002:2022 A.5.25, Assessment and decision on information security events, i kontrolu A.8.8, Management of technical vulnerabilities, kroz Zenith Controls: The Cross-Compliance Guide Zenith Controls. Za A.5.25, Zenith Controls objašnjava da je procjena događaja funkcija trijaže između sirovih upozorenja nadzora i formalnog postupanja s incidentima, uz korištenje zapisa dnevnika, pragova i kriterija odlučivanja za određivanje eskalacije. Za A.8.8, Zenith Controls povezuje upravljanje tehničkim ranjivostima sa zaštitom od zlonamjernog softvera, upravljanjem konfiguracijom, upravljanjem promjenama, sigurnošću krajnjih točaka, obavještajnim podacima o prijetnjama, nadzorom, sigurnim razvojem, procjenom događaja i odgovorom na incidente.

Jedan odlomak iz Zenith Controls posebno je koristan kada se sumnja na aktivno iskorištavanje:

„Obavještajni podaci o prijetnjama pokazuju koje se ranjivosti aktivno iskorištavaju i tako usmjeravaju prioritizaciju zakrpa.”
Izvor: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 kontrola 8.8, poveznica s kontrolom 5.7 Threat Intelligence Zenith Controls

To je važna točka upravljanja. Ozbiljnost nije samo CVSS. Ranjivost srednje ocjene koja se aktivno iskorištava protiv vašeg sektora može imati prednost pred teorijski kritičnim problemom na neizloženom testnom sustavu.

Kada ranjivost postaje incident

Nije svaka prijava ranjivosti incident. Nedostajuće sigurnosno zaglavlje u pripremnom okruženju nije isto što i iskorišteno zaobilaženje autorizacije koje izlaže račune klijenata. No svaka vjerodostojna prijava ranjivosti treba proći kroz kontrolnu točku odlučivanja o incidentu.

NIS2 Article 23 zahtijeva od ključnih i važnih subjekata da bez nepotrebnog odgađanja obavijeste svoj CSIRT ili nadležno tijelo o incidentima koji znatno utječu na pružanje usluga. Značajan incident jest onaj koji je prouzročio ili može prouzročiti ozbiljan operativni poremećaj ili financijski gubitak, ili koji je utjecao ili može utjecati na druge prouzročenjem znatne materijalne ili nematerijalne štete. Redoslijed izvješćivanja uključuje rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata, međuizvješća kada se zatraže i završno izvješće u roku od mjesec dana od obavijesti u roku od 72 sata.

DORA Articles 17 to 20 zahtijevaju od financijskih subjekata da otkrivaju, upravljaju, evidentiraju, klasificiraju, eskaliraju, prijavljuju i komuniciraju incidente povezane s IKT-om i značajne kibernetičke prijetnje. Veći incidenti povezani s IKT-om moraju se eskalirati višem rukovodstvu i upravljačkom tijelu. Komunikacija s klijentima može biti potrebna kada su pogođeni financijski interesi.

Za mala i srednja poduzeća kultura prijavljivanja mora biti jednako jasna. Clarysecova Politika odgovora na incidente - SME Politika odgovora na incidente - SME navodi:

„Osoblje mora prijaviti svaku sumnjivu aktivnost ili potvrđeni incident na incident@[company] ili usmeno glavnom direktoru ili pružatelju IT podrške.”
Izvor: Politika odgovora na incidente - SME, Zahtjevi za provedbu politike, točka 6.2.1

U Zenith Blueprint, faza Controls in Action, korak 16: People Controls II, načelo je još jednostavnije:

„Kada ste u dvojbi, prijavite.”
Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controls in Action, korak 16: People Controls II (A.6.5 to A.6.8)

Ta se rečenica treba primjenjivati na razvojne inženjere, timove podrške, voditelje dobavljača, voditelje privatnosti, izvršne rukovoditelje i vanjske pružatelje usluga. Ranjivost koja može utjecati na povjerljivost, cjelovitost, dostupnost, povjerenje klijenata, regulatorno izvješćivanje ili financijske operacije treba evidentirati i procijeniti, a ne neformalno rješavati u chatu.

Otklanjanje nedostataka, zakrpavanje i kompenzacijske kontrole

Nakon što se ranjivost provjeri, mora se obraditi. Obrada rizika treba biti utemeljena na riziku, potkrijepljena dokazima i vremenski ograničena.

Politika koordiniranog otkrivanja ranjivosti postavlja korporativno očekivanje:

„Plan otklanjanja nedostataka: Za sve potvrđene ranjivosti mora se izraditi plan otklanjanja ili ublažavanja. Provedba ispravka mora se prioritizirati prema ozbiljnosti. Primjerice, kritične ranjivosti moraju se ispraviti ili ublažiti u roku od 14 dana kada je to izvedivo, ili ranije kada se otkrije aktivno iskorištavanje, dok se problemi niže ozbiljnosti moraju riješiti u razumnom roku. Kada je potpuni ispravak odgođen, moraju se provesti kompenzacijske kontrole ili privremene mjere ublažavanja, kao što su onemogućavanje ranjive funkcionalnosti ili pojačani nadzor.”
Izvor: Politika koordiniranog otkrivanja ranjivosti, Zahtjevi za provedbu, točka 6.6

Za disciplinu zakrpavanja u malim i srednjim poduzećima, Politika upravljanja ranjivostima i zakrpama - SME Politika upravljanja ranjivostima i zakrpama - SME navodi:

„Kritične zakrpe moraju se primijeniti u roku od 3 dana od objave, osobito za sustave izložene internetu”
Izvor: Politika upravljanja ranjivostima i zakrpama - SME, Zahtjevi za provedbu politike, točka 6.1.1

Ti rokovi nisu proturječni. Zakrpa dobavljača za sustav izložen internetu može zahtijevati vrlo brzo uvođenje. Ranjivost proizvoda koja zahtijeva izmjene koda, regresijsko testiranje, koordinaciju s klijentima i fazno izdanje može zahtijevati plan otklanjanja nedostataka s privremenim mjerama ublažavanja. Ključno je da odluka bude dokumentirana, dodijeljena vlasniku rizika i odobrena kada preostali rizik ostaje.

Praktični tijek slučaja izgleda ovako:

1. Istraživač prijavljuje zaobilaženje autorizacije u API-ju za naplatu klijentima.
2. VRT evidentira CVD-2026-014 s vremenskom oznakom i potvrđuje zaprimanje u roku od 2 radna dana.
3. Sigurnost proizvoda provjerava nedostatak u roku od 24 sata i dodjeljuje visoku ozbiljnost zbog pristupa podacima između korisnika.
4. Funkcija privatnosti provodi procjenu povrede prema GDPR-u jer zapisi računa mogu sadržavati osobne podatke.
5. Voditelj incidenta otvara procjenu događaja prema kontroli ISO/IEC 27002:2022 A.5.25.
6. Vlasnik sustava onemogućava ranjivu krajnju točku privremenom feature flag kontrolom.
7. Inženjering izrađuje hitni ispravak prema kontroli ISO/IEC 27002:2022 A.8.32, Change management.
8. Dodaju se pravila nadzora za pokazatelje iskorištavanja, povezana s A.8.15, Logging, i A.8.16, Monitoring activities.
9. CISO obavješćuje više rukovodstvo jer je problem visokog rizika.
10. VRT koordinira s istraživačem ponovno testiranje i vrijeme objave.
11. Vlasnik rizika odobrava zatvaranje tek nakon provjere ispravka testiranjem i pregleda utjecaja na klijente.
12. Ažuriraju se SoA, registar rizika, tiket, zapisi dnevnika, obavijest upravi i naučene lekcije.

To je razlika između „zakrpali smo” i „možemo dokazati da smo time upravljali”.

Ovisnosti o dobavljačima i oblaku: skrivena točka neuspjeha

Mnogi neuspjesi CVD-a zapravo su prikriveni neuspjesi dobavljača. Ranjivost može utjecati na SaaS komponentu, uslugu u oblaku, pružatelja upravljanih sigurnosnih usluga, pristupnik za plaćanja, posrednika za autentifikaciju, biblioteku otvorenog koda, razvojni tim kojem je rad povjeren vanjskim izvođačima ili podizvršitelja obrade.

NIS2 Article 21 zahtijeva sigurnost opskrbnog lanca, uključujući odnose s izravnim dobavljačima i pružateljima usluga. Mjere opskrbnog lanca trebaju uzeti u obzir ranjivosti dobavljača, kvalitetu proizvoda, prakse kibernetičke sigurnosti i postupke sigurnog razvoja.

DORA Articles 28 to 30 idu dublje za financijske subjekte. Zahtijevaju da se rizikom trećih strana u području IKT-a upravlja kao dijelom okvira upravljanja IKT rizicima, uz registre ugovora o IKT uslugama, razlikovanje kritičnih ili važnih funkcija, dubinsku provjeru dobavljača prije sklapanja ugovora, ugovorne sigurnosne zahtjeve, pomoć pri incidentima, suradnju s nadležnim tijelima, prava na reviziju, prava raskida i izlazne strategije. Financijski subjekti ostaju u potpunosti odgovorni za usklađenost s DORA čak i kada koriste IKT pružatelje usluga trećih strana.

Clarysecova Politika sigurnosti trećih strana i dobavljača - SME Politika sigurnosti trećih strana i dobavljača - SME uključuje jednostavno pravilo eskalacije:

„Mora odmah obavijestiti GM-a o svakoj sigurnosnoj povredi, promjeni ili incidentu”
Izvor: Politika sigurnosti trećih strana i dobavljača - SME, Uloge i odgovornosti, točka 4.4.3

Za korporativne ugovore s dobavljačima, Zenith Blueprint, faza Controls in Action, korak 23, preporučuje uključivanje obveza povjerljivosti, odgovornosti za kontrolu pristupa, tehničkih i organizacijskih mjera, rokova za prijavljivanje incidenata, prava na reviziju, kontrola podizvršitelja i odredbi o prestanku ugovora. Navodi:

„Važno je da postoje i da ih obje strane razumiju i prihvaćaju.”
Izvor: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controls in Action, korak 23: Organizational controls (5.19 to 5.37)

Spremnost dobavljača za CVD treba odgovoriti na ova pitanja:

• Objavljuje li dobavljač kanal za prijavu ranjivosti?
• Jesu li rokovi za obavješćivanje o ranjivostima definirani u ugovoru?
• Prijavljuju li se kritične ranjivosti dobavljača bez nepotrebnog odgađanja?
• Jesu li slabosti koje utječu na klijente povezane s obvezama pomoći pri incidentima?
• Može li dobavljač dostaviti dokaze otklanjanja nedostataka ili sigurnosne obavijesti?
• Prenose li se obveze u vezi s ranjivostima na podizvršitelje?
• Postoji li izlazna strategija ako je otklanjanje nedostataka neadekvatno?

Ovdje se NIS2, DORA i ISO/IEC 27001:2022 susreću. Upravljanje ranjivostima dobavljača nije kvačica u nabavi. Ono je dio operativne otpornosti.

Mapiranje dokaza za ISO 27001, NIS2, DORA, GDPR i COBIT

Najjači CVD programi počinju od dokaza. Pretpostavljaju da svaku značajnu prijavu kasnije mogu pregledati interna revizija, certifikacijski revizori, regulatorna tijela, klijenti, osiguratelji ili odbor za rizike na razini upravnog odbora.

Clarysecova Politika praćenja revizije i usklađenosti - SME Politika praćenja revizije i usklađenosti - SME ističe detalj koji mnogi timovi propuštaju:

„Metapodaci (npr. tko ih je prikupio, kada i iz kojeg sustava) moraju se dokumentirati.”
Izvor: Politika praćenja revizije i usklađenosti - SME, Zahtjevi za provedbu politike, točka 6.2.3

Snimka zaslona zakrpanog poslužitelja slab je dokaz ako nitko ne zna tko ju je zabilježio, kada, iz kojeg sustava i kako se mapira na ranjivost. Tiket s vremenskim oznakama, izlazom skenera, pull requestom, odobrenjem promjene, dnevničkim zapisima uvođenja, upitom nadzora, potvrdom ponovnog testiranja i metapodacima znatno je snažniji.

Detaljnija matrica sljedivosti pomaže tijekom dubinske provjere klijenata i interne revizije.

Različiti revizori testirat će isti proces iz različitih perspektiva.

Revizor ISO/IEC 27001:2022 započet će od ISMS-a. Pitat će jesu li obveze otkrivanja ranjivosti uključene u zahtjeve zainteresiranih strana, procjenjuju li se rizici dosljedno, pojavljuju li se kontrole u SoA, postoje li operativni dokazi i pregledava li uprava trendove i stavke s prekoračenim rokovima.

DORA ili pregledavatelj financijskih usluga usredotočit će se na operativnu otpornost. Ispitat će integraciju IKT rizika, klasifikaciju incidenata, eskalaciju prema višem rukovodstvu, komunikaciju s klijentima, ovisnosti o trećim stranama, testiranje i naučene lekcije. Ako ranjivost utječe na kritičnu ili važnu funkciju, očekivat će čvrstu vezu između tehničkog tiketa, poslovnog utjecaja, implikacija za kontinuitet poslovanja i obveza dobavljača.

Pregledavatelj GDPR-a usredotočit će se na osobne podatke. Jesu li osobni podaci bili uključeni? Je li došlo do neovlaštenog pristupa, gubitka, izmjene ili otkrivanja? Jesu li uloge voditelja obrade i izvršitelja obrade bile jasne? Je li procijenjen prag povrede? Jesu li zaštitne mjere kao što su šifriranje, kontrola pristupa, zapisivanje događaja i minimizacija bile relevantne?

Revizor COBIT 2019 ili ISACA usredotočit će se na upravljanje, odgovornost, učinkovitost i uvjerenje. Tražit će definirano vlasništvo, metrike, eskalaciju, ciljeve kontrola, nadzor uprave i praćenje iznimaka. Kritična ranjivost s prekoračenim rokom nije samo tehnički problem. To je problem upravljanja ako nije formalno eskalirana i prihvaćena kao rizik.

Procjenitelj usmjeren na NIST razmišljat će u kategorijama Identify, Protect, Detect, Respond i Recover. Očekivat će vlasništvo nad imovinom, identifikaciju ranjivosti, prioritizaciju, zaštitnu promjenu, otkrivanje iskorištavanja, koordinaciju odgovora i provjeru oporavka.

Prednost integriranog CVD modela jest u tome što ista dokazna okosnica može podržati sve te preglede.

Mjesečna kontrolna petlja: metrike koje uprava može koristiti

CVD ne završava zatvaranjem tiketa. Politika koordiniranog otkrivanja ranjivosti zahtijeva stalni pregled evidencije:

„VRT mora održavati evidenciju otkrivanja ranjivosti koja prati svaku prijavu od zaprimanja do zatvaranja. Evidencija se mora pregledavati mjesečno kako bi se osiguralo pravodobno napredovanje otvorenih stavki. Stavke s prekoračenim rokom moraju se eskalirati.”
Izvor: Politika koordiniranog otkrivanja ranjivosti, Praćenje i revizija, točka 9.1

Ovaj mjesečni pregled pretvara otkrivanje ranjivosti u upravljanje spremno za upravni odbor. Upravi nije potreban svaki tehnički detalj. Potrebni su joj trend, izloženost, odgovornost i rizik prekoračenih rokova.

U zreloj Clarysec implementaciji, ovaj mjesečni pregled evidencije hrani registar rizika, Izjavu o primjenjivosti, zaostatak poslova sigurnog razvoja, preglede dobavljača, naučene lekcije iz incidenata, plan interne revizije i paket izvješća za upravu.

Izgradite proces prije nego što stigne ozbiljna prijava

Najgore vrijeme za oblikovanje koordiniranog otkrivanja ranjivosti jest nakon što je istraživač javno objavio vašu slabost ili nakon što je kritični bankovni klijent zaustavio uvođenje. NIS2, DORA, GDPR, ISO/IEC 27001:2022, očekivanja otpornosti u stilu NIST-a i upravljanje prema COBIT 2019 upućuju u istom smjeru: otkrivanje ranjivosti mora biti planirano, imati vlasnika, biti testirano, potkrijepljeno dokazima i poboljšavano.

Započnite s ovih pet radnji:

1. Usvojite ili prilagodite Politiku koordiniranog otkrivanja ranjivosti.
2. Izgradite tijek zaprimanja i trijaže koristeći Zenith Blueprint, osobito korak 13 za sljedivost SoA, korak 16 za kulturu prijavljivanja, korak 19 za upravljanje tehničkim ranjivostima i korak 23 za ugovore s dobavljačima.
3. Mapirajte tijek rada kroz Zenith Controls, s naglaskom na kontrole ISO/IEC 27002:2022 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 i A.8.32.
4. Dodajte odredbe prikladne za SME iz Politike odgovora na incidente - SME, Politike upravljanja ranjivostima i zakrpama - SME, Politike sigurnosti trećih strana i dobavljača - SME, Politike zahtjeva za sigurnost aplikacija - SME i Politike praćenja revizije i usklađenosti - SME gdje je razmjernost važna.
5. Provedite stolnu vježbu koja simulira prijavu istraživača koja utječe na osobne podatke i komponentu hostiranu kod dobavljača, zatim testirajte potvrdu zaprimanja, trijažu, klasifikaciju incidenta, zakrpavanje, komunikaciju s klijentima, prikupljanje dokaza i eskalaciju prema upravi.

Clarysec vam može pomoći pretvoriti to u funkcionalnu CVD politiku, evidenciju zaprimanja prijava, mapu dokaza ISO/IEC 27001:2022, stablo odlučivanja za NIS2 i DORA, model eskalacije prema dobavljačima i paket kontrola spreman za reviziju. Cilj je jednostavan: kada stigne sljedeća prijava ranjivosti, vaš tim ne bi trebao improvizirati. Trebao bi postupati sigurno, uz dokaze i kontrolu.