Od skeniranja do dokaza: ISO 27001:2022, NIS2, DORA

Ponedjeljak je, 08:16. Kritična ranjivost za udaljeno izvršavanje koda upravo se pojavila na nadzornoj ploči za aplikacijski poslužitelj izložen internetu. Infrastrukturni tim potvrđuje da je zakrpa dobavljača dostupna. Vlasnik aplikacije upozorava da poslužitelj podržava korisnički tijek rada kritičan za prihod. Pravna služba pita bi li iskorištavanje moglo pokrenuti obveze izvješćivanja prema NIS2, DORA ili GDPR. CISO Maria otvara revizijski kalendar i vidi stvarni problem: nadzorna revizija ISO 27001:2022 počinje sljedeći tjedan, pregled spremnosti za NIS2 već je u tijeku, a važan fintech klijent zatražio je dokaze za DORA.

Skener prikazuje crveno. Sustav za upravljanje zahtjevima pokazuje aktivnost. Proračunska tablica pokazuje uloženi trud. No ništa od toga samo po sebi ne dokazuje da kontrola djeluje.

To je praznina koju mnoge organizacije otkriju prekasno. Skeniranje ranjivosti nije isto što i revizijska spremnost upravljanja ranjivostima. Skeniranje pokazuje da nešto možda nije u redu. Revizijski dokazi dokazuju da je organizacija znala čime raspolaže, procijenila rizik, dodijelila vlasništvo, postupila u skladu s politikom, kontrolirala promjenu, dokumentirala iznimke, provjerila rezultate i pregledala ishod.

Za ISO/IEC 27001:2022, NIS2 i DORA taj lanac dokaza jednako je važan kao i tehnički ispravak. Skener započinje priču. Dovršavaju je popis imovine, registar ranjivosti, radni nalog, odluka o riziku, zapis o promjeni, zapisnik zakrpa, dokazi provjere, odobrenje iznimke i preispitivanje uprave.

Clarysecov pristup je jednostavan: upravljanje ranjivostima nemojte tretirati kao mjesečni tehnički ritual. Tretirajte ga kao upravljani tijek rada za dokaze.

Zašto izvješća o skeniranju nisu dovoljna kao revizijski dokazi

Skeniranje ranjivosti tehničko je opažanje u određenom trenutku. Može identificirati CVE, nedostajuću zakrpu, nepodržanu biblioteku, izloženu uslugu ili slabu konfiguraciju. To je korisno, ali nije cjelovito.

Revizor će postaviti drukčija pitanja:

• Je li zahvaćena imovina bila u opsegu?
• Tko je vlasnik imovine i poslovne usluge?
• Je li ranjivost procijenjena prema izloženosti, mogućnosti iskorištavanja, utjecaju na poslovanje i osjetljivosti podataka?
• Je li otklanjanje ranjivosti dovršeno u definiranom roku?
• Ako je otklanjanje ranjivosti odgođeno, tko je prihvatio preostali rizik?
• Je li zakrpa uvedena kroz kontrolirano upravljanje promjenama?
• Je li ispravak provjeren ponovnim skeniranjem ili tehničkom provjerom?
• Jesu li dokazi zadržani i pregledani od strane uprave?

Mapa s izvozima iz skenera rijetko odgovara na ta pitanja. U reviziji ISO 27001:2022 revizor provjerava radi li ISMS kako je projektiran. Prema NIS2, upravljačka tijela moraju odobriti i nadzirati mjere upravljanja rizicima kibernetičke sigurnosti. Prema DORA, financijski subjekti trebaju dokumentiran okvir za upravljanje IKT rizicima, životni ciklus incidenta, testiranje otpornosti i kontrole IKT rizika trećih strana. Prema GDPR, pitanje postaje jesu li odgovarajuće tehničke i organizacijske mjere zaštitile osobne podatke te može li se dokazati odgovornost.

ISO/IEC 27001:2022 točke 4.1 do 4.4 zahtijevaju da organizacija razumije svoj kontekst, zainteresirane strane, zahtjeve i opseg ISMS-a. Upravljanje ranjivostima i zakrpama ne može se projektirati izolirano. Mora odražavati ugovore s klijentima, regulatore, ovisnosti o oblaku, vanjsko ugovorene IKT usluge, obveze zaštite podataka i kritične usluge.

ISO/IEC 27001:2022 točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, odabir kontrola, Izjavu o primjenjivosti i odobrenje vlasnika rizika za preostali rizik. To znači da dokazi o ranjivostima trebaju biti povezani s registrom rizika, planom obrade rizika i SoA.

ISO/IEC 27005:2022 dodatno učvršćuje ovaj model potičući organizacije da objedine zahtjeve iz Priloga A, sektorske obveze, propise, ugovore, interna pravila i postojeće kontrole u polaznu osnovu procjene rizika. Također naglašava kriterije za vjerojatnost, posljedicu, pravne obveze, odnose s dobavljačima, utjecaj na privatnost i utjecaj trećih strana. U praksi ranjivost nije samo CVSS broj. Ona je događaj rizika povezan s imovinom, obvezama, dionicima i poslovnim posljedicama.

Regulatorni pritisak iza dokaza o zakrpavanju

Suvremena regulativa kibernetičke sigurnosti sve manje tolerira neformalno zakrpavanje.

NIS2 primjenjuje se na mnoge srednje i velike subjekte u visokokritičnim i kritičnim sektorima, a može obuhvatiti i određene subjekte neovisno o veličini. Njegov opseg uključuje pružatelje digitalne infrastrukture kao što su usluge računalstva u oblaku, usluge podatkovnih centara, mreže za isporuku sadržaja, pružatelji javnih elektroničkih komunikacija, usluge povjerenja, DNS i TLD usluge, kao i pružatelje upravljanja IKT uslugama poput pružatelja upravljanih usluga i pružatelja upravljanih sigurnosnih usluga. Također obuhvaća važne digitalne pružatelje kao što su internetska tržišta, internetske tražilice i platforme društvenih mreža.

Article 20 NIS2 postavlja kibernetičku sigurnost kao odgovornost upravljačkog tijela. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, siguran razvoj, sigurno održavanje, postupanje s ranjivostima i objavu ranjivosti, procjenu učinkovitosti, kibernetičku higijenu, kontrolu pristupa, upravljanje imovinom i autentifikaciju. Article 23 uspostavlja postupni proces obavješćivanja o značajnom incidentu, uključujući rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i završno izvješće u roku od jednog mjeseca kada je primjenjivo.

DORA od 17. siječnja 2025. uspostavlja izravno primjenjiv režim digitalne operativne otpornosti za financijske subjekte. Obuhvaća upravljanje IKT rizikom, izvješćivanje o većim IKT incidentima, testiranje operativne otpornosti, razmjenu obavještajnih podataka o kibernetičkim prijetnjama, upravljanje IKT rizikom trećih strana i nadzor nad kritičnim pružateljima IKT usluga trećih strana. Articles 5 and 6 stavljaju upravljanje IKT rizikom pod odgovornost upravljačkog tijela i zahtijevaju dokumentiran, integriran i redovito preispitivan okvir za upravljanje IKT rizicima. Article 8 dodatno naglašava potrebu identificiranja poslovnih funkcija podržanih IKT-om, informacijskih resursa, IKT imovine i ovisnosti. Articles 17 to 20 zahtijevaju otkrivanje, evidentiranje, klasifikaciju, eskalaciju, izvješćivanje, komunikaciju, otklanjanje i učenje iz IKT incidenata. Articles 28 to 30 zahtijevaju da se IKT rizik trećih strana kontrolira kroz registre, dubinsku analizu dobavljača, ugovorne zaštitne mjere, prava na reviziju, planiranje izlaska i nadzor.

Za financijske subjekte obuhvaćene DORA, DORA općenito nadomješta ekvivalentne NIS2 obveze upravljanja rizicima i izvješćivanja. No NIS2 je i dalje važan za koordinaciju ekosustava i subjekte izvan opsega DORA. Za pružatelje SaaS-a, pružatelje upravljanih usluga i pružatelje upravljanih sigurnosnih usluga koji opslužuju financijske klijente praktična je stvarnost izravna: klijenti mogu zahtijevati vaše dokaze o ranjivostima kako bi ispunili vlastite DORA obveze.

GDPR dodaje još jedan sloj. Articles 2 and 3 mogu se primjenjivati na organizacije osnovane u EU i organizacije izvan EU koje nude robu ili usluge osobama u EU ili prate njihovo ponašanje. Article 5 zahtijeva zaštitu osobnih podataka i odgovornost za usklađenost. Article 4 definira povredu osobnih podataka kao sigurnosni incident koji dovodi do slučajnog ili nezakonitog gubitka, uništenja, izmjene, neovlaštenog otkrivanja osobnih podataka ili pristupa osobnim podacima. Odgođena zakrpa na bazi podataka, platformi identiteta ili korisničkom portalu može postati pitanje odgovornosti u području privatnosti.

Od politike do dokaza

Prvi je korak definiranje pravila. Snažna politika upravljanja ranjivostima i zakrpama nije samo revizijski dokument. Ona je operativni temelj kontrole.

Za poslovna okruženja, Politika upravljanja ranjivostima i zakrpama izričito povezuje tehničko zakrpavanje s međusobnom usklađenošću više okvira:

Ova politika podupire usklađenost s ISO/IEC 27001 Prilog A kontrolom 8.8 i smjernicama ISO/IEC 27002 te obuhvaća regulatorne zahtjeve prema DORA Article 8, NIS2 Article 21, GDPR Article 32 i domenama DSS i APO COBIT 2019.

Iz odjeljka „Svrha”.

Ista politika postavlja očekivanje upravljanja za ključni artefakt dokaza:

Centralizirani Registar ranjivosti mora održavati tim centra sigurnosnih operacija, a CISO ili delegirano ovlašteno tijelo mora ga pregledavati mjesečno.

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.1.

Također definira učestalost skeniranja:

Svi sustavi moraju se skenirati najmanje jednom mjesečno; imovina visokog rizika ili imovina izložena prema van mora se skenirati tjedno.

Iz odjeljka „Zahtjevi provedbe politike”, točka politike 6.1.1.

I sprječava da hitno zakrpavanje postane nekontrolirana tehnička aktivnost:

Sve aktivnosti otklanjanja ranjivosti moraju se koordinirati kroz proces upravljanja promjenama (prema P5 - Politika upravljanja promjenama) radi osiguravanja stabilnosti i očuvanja revizijskog traga.

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.5.

Za mala i srednja poduzeća ista načela dokaza mogu se provesti jednostavnije. Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća navodi:

Održavati točne zapise o primijenjenim zakrpama, otvorenim pitanjima i iznimkama radi osiguravanja spremnosti za reviziju

Iz odjeljka „Ciljevi”, točka politike 3.4.

Zatim definira zapisnik zakrpa kao revizijski dokaz:

Zapisnik zakrpa mora se održavati i pregledavati tijekom revizija i aktivnosti odgovora na incidente

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.4.1.

I određuje minimalni sadržaj:

Zapisi dnevnika moraju sadržavati naziv uređaja, primijenjeno ažuriranje, datum zakrpavanja i razlog svakog kašnjenja

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.4.2.

Za hitnu izloženost prema internetu politika za mala i srednja poduzeća postavlja mjerljiv zahtjev:

Kritične zakrpe moraju se primijeniti u roku od 3 dana od objave, osobito za sustave izložene internetu

Iz Politike upravljanja ranjivostima i zakrpama za mala i srednja poduzeća, odjeljak „Zahtjevi provedbe politike”, točka politike 6.1.1.

Ove točke pretvaraju tehnički rad u dokaze. Politika definira očekivanja. Registar evidentira nalaze. Radni nalog dodjeljuje posao. Zapis o promjeni kontrolira implementaciju. Zapisnik zakrpa dokazuje radnju. Registar rizika obuhvaća iznimke. Zapisnik pregleda dokazuje nadzor.

Clarysecov model usmjeren na dokaze

Clarysecov model usmjeren na dokaze počinje jednim načelom: svaki nalaz ranjivosti mora biti sljediv od otkrivanja do odluke.

U Zenith Blueprint: revizijski plan u 30 koraka, faza Kontrole u praksi, korak 19: Tehnološke kontrole I, tretira upravljanje ranjivostima kao ponovljivu kontrolu, a ne kao teorijski zahtjev:

Upravljanje ranjivostima jedno je od najkritičnijih područja moderne kibernetičke higijene. Iako vatrozidi i antivirusni softver pružaju zaštitu, ona se može narušiti ako nezakrpani sustavi ili pogrešno konfigurirane usluge ostanu izloženi.

Isti korak objašnjava da organizacije trebaju koristiti redovite rasporede zakrpavanja, skenere ranjivosti, trijažu, dodjelu odgovornosti, praćenje otklanjanja ranjivosti, kompenzacijske kontrole i prihvaćanje preostalog rizika. Najvažnije, ispravno postavlja revizijski način razmišljanja:

Kontrola nije usmjerena na savršenstvo, nego na organiziran, transparentan i odgovoran proces.

Za revizore je ta razlika važna. Zrela organizacija može imati otvorene ranjivosti i ipak dokazati kontrolu, pod uvjetom da ima prioritizaciju temeljenu na riziku, dokumentirano vlasništvo, odobrene iznimke, kompenzacijske kontrole i provjereno otklanjanje ranjivosti.

Zenith Blueprint također upozorava da će revizori ovo područje detaljno pregledati:

Ovo je kontrola visokog prioriteta za revizore i obično će ulaziti vrlo duboko. Očekujte pitanja o tome koliko često se sustavi zakrpavaju, koji proces slijedite kada se objavi zero-day ranjivost i koje je sustave najteže zakrpati.

Zato CISO ne bi trebao ući u reviziju samo s nadzornom pločom skenera. Paket dokaza mora pokazati upravljanje, proces, provedbu, provjeru i poboljšanje.

Mapiranje kontrola ISO 27002 na revizijske dokaze

Zenith Controls: Vodič za međusobnu usklađenost djeluje kao kompas za međusobnu usklađenost mapiranjem kontrola ISO/IEC 27002:2022 i prikazom njihova odnosa prema revizijskim očekivanjima. Za upravljanje ranjivostima i zakrpama tri kontrole ISO/IEC 27002:2022 čine operativni trokut.

ISO/IEC 27002:2022 kontrola 8.8, Upravljanje tehničkim ranjivostima, središnja je kontrola. Ona je preventivna, podupire povjerljivost, cjelovitost i dostupnost, usklađena je s konceptima kibernetičke sigurnosti Identify i Protect te se povezuje s upravljanjem prijetnjama i ranjivostima.

ISO/IEC 27002:2022 kontrola 8.32, Upravljanje promjenama, također je preventivna. Povezuje zakrpavanje s kontroliranom implementacijom, testiranjem, odobrenjem, povratom i revizijskom provjerljivošću.

ISO/IEC 27002:2022 kontrola 5.36, Usklađenost s politikama, pravilima i standardima informacijske sigurnosti, osigurava da proces nije opcionalan niti ovisan o pojedinačnim iznimnim naporima. Povezuje upravljanje ranjivostima s poštivanjem politike, osiguranjem i nadzorom.

Ovo mapiranje izbjegava čest revizijski neuspjeh. Sigurnost kaže: „Zakrpali smo.” Operacije kažu: „Implementirali smo.” Usklađenost kaže: „Ne možemo dokazati redoslijed.” Mapirani lanac dokaza daje svim trima timovima istu priču.

Lanac dokaza koji revizori očekuju

Dokaziv lanac dokaza upravljanja ranjivostima ima sedam faza.

Praktična razlika između „provodimo skeniranja” i „spremni smo za reviziju” jest kontinuitet. Ako se ranjivost ne može pratiti od otkrivanja do zatvaranja, kontrola je slaba. Ako iznimke postoje, ali ih nitko nije odobrio, proces je slab. Ako zakrpe zaobilaze upravljanje promjenama, revizijski trag je slab. Ako kritične ranjivosti ostaju otvorene bez kompenzacijskih kontrola, upravljanje je slabo.

Politika praćenja revizije i usklađenosti podupire automatizaciju kao dio ovog modela:

Automatizirani alati moraju se uvesti za praćenje usklađenosti konfiguracije, upravljanja ranjivostima, statusa zakrpa i privilegiranog pristupa.

Iz odjeljka „Zahtjevi provedbe politike”, točka politike 6.4.1.

Za mala i srednja poduzeća, Politika praćenja revizije i usklađenosti za mala i srednja poduzeća definira provjeru tehničkih kontrola praktičnim pojmovima:

Provjera tehničkih kontrola (npr. status sigurnosnih kopija, konfiguracija kontrole pristupa, zapisi o zakrpama)

Iz odjeljka „Zahtjevi provedbe politike”, točka politike 6.1.1.2.

Male organizacije ne trebaju alate razine velikog poduzeća da bi postale spremne za reviziju. Trebaju dosljedne dokaze. Jednostavan registar, ploča za evidentiranje zahtjeva, zapisnik zakrpa i mjesečni pregled mogu biti dovoljni ako su potpuni, ažurni i povezani s rizikom.

Primjer: jedan kritični nalaz, potpuno spreman za reviziju

Marijino tjedno vanjsko skeniranje identificira CVE-2026-12345 na API pristupniku za plaćanja izloženom internetu. Skener ga ocjenjuje kritičnim. Usluga obrađuje identitet korisnika i metapodatke transakcija, stoga su moguće implikacije prema GDPR i DORA. Vlasnik pristupnika je Platform Engineering, ali zakrpa zahtijeva kratak prekid rada.

Ovo je tijek rada spreman za reviziju.

1. Izradite zapis u registru ranjivosti

Sigurnosni tim bilježi nalaz u središnjem registru:

• ID nalaza: VULN-2026-0142
• Izvor: tjedno vanjsko skeniranje
• Datum i vrijeme otkrivanja
• Imovina: api-gw-prod-01
• Vlasnik: Platform Engineering
• Izloženost: izloženo internetu
• Kontekst podataka: identitet korisnika i metapodaci transakcija
• Ozbiljnost: kritično
• SLA: 72 sata ili strože prema politici
• Radni nalog: SEC-4821
• Zapis o promjeni: CHG-10988
• Status: otklanjanje ranjivosti planirano

2. Provedite trijažu koristeći poslovni i regulatorni kontekst

Tim provjerava dostupnost exploita, napadnu površinu, zahtjeve autentifikacije, utjecaj na poslovanje i osjetljivost podataka. Budući da je sustav izložen internetu i podržava korisničke tijekove rada, ranjivost ostaje kritična. Vlasnik rizika je voditelj platforme, a CISO je obaviješten zbog mogućih implikacija prema NIS2, DORA i GDPR.

ISO/IEC 27005:2022 točke 7.1 do 7.4 podupiru identifikaciju rizika, vlasništvo, posljedicu, vjerojatnost i prioritizaciju. Točke 8.2 do 8.6 podupiru odabir obrade, određivanje kontrola, povezivanje sa SoA, planiranje obrade i odobrenje preostalog rizika.

3. Otvorite kontroliranu hitnu promjenu

Zakrpa je zakazana za istu večer. Zapis o promjeni uključuje referencu dobavljača, zahvaćene usluge, plan testiranja, plan povrata, termin održavanja, odluku o komunikaciji prema korisnicima, odobrenja i zahtjev za provjeru nakon uvođenja.

To izravno podupire ISO/IEC 27002:2022 kontrolu 8.32 i zahtjev poslovne politike da se otklanjanje ranjivosti koordinira kroz upravljanje promjenama.

4. Primijenite zakrpu i ažurirajte zapisnik zakrpa

Zapisnik zakrpa evidentira naziv uređaja, primijenjeno ažuriranje, datum zakrpavanja i razlog kašnjenja, ako postoji. Da je zakrpavanje bilo odgođeno, tim bi dokumentirao kompenzacijske kontrole kao što su pravila vatrozida za web aplikacije, privremena ograničenja pristupa, povećano zapisivanje događaja, izolacija ili pojačano praćenje.

5. Provjerite i zatvorite

Sigurnost ponovno skenira API pristupnik. Ranjivost se više ne pojavljuje. Radni nalog se ažurira dokazom čistog skeniranja, verzijom zakrpe, vremenskom oznakom implementacije i poveznicom na zapis o promjeni. Status u registru ranjivosti mijenja se u „Zatvoreno, provjereno”.

6. Pregledajte utjecaj na izvješćivanje

Ako nije bilo iskorištavanja ni prekida usluge, izvješćivanje o incidentu prema NIS2 ili DORA možda se neće pokrenuti. Ako se pronađu pokazatelji kompromitacije, proces incidenta mora klasificirati utjecaj i eskalaciju. Prema NIS2, značajan incident može zahtijevati rano upozorenje i postupno izvješćivanje. Prema DORA, veći IKT incident zahtijeva klasifikaciju i izvješćivanje kroz primjenjivi postupak nadležnog tijela.

7. Uključite naučene lekcije u preispitivanje uprave

Na kraju mjeseca CISO pregled bilježi da je ranjivost otkrivena tjednim vanjskim skeniranjem, otklonjena unutar SLA, provjerena ponovnim skeniranjem i zatvorena bez incidenta. Ako se slični problemi ponavljaju, plan obrade rizika može uključivati polazne osnove sigurne konfiguracije, automatiziranu implementaciju zakrpa, eskalaciju prema dobavljaču ili modernizaciju aplikacije.

Kada revizor pita za CVE-2026-12345, Maria može predstaviti uređen paket umjesto e-pošte i snimki zaslona.

To je spremno za reviziju. Ne zato što organizacija nije imala ranjivosti, nego zato što je imala kontrolu.

Jedan skup dokaza, više obveza

Dobro osmišljen program upravljanja ranjivostima i zakrpama može zadovoljiti više okvira bez dupliciranja posla.

Za ISO 27001:2022, dokazi podupiru ISMS temeljen na riziku, implementaciju kontrola Priloga A, Izjavu o primjenjivosti, planove obrade rizika, internu reviziju i kontinuirano poboljšanje. Ako je ISO/IEC 27002:2022 kontrola 8.8 primjenjiva u SoA, organizacija bi trebala moći pokazati pravno, regulatorno, rizikom uvjetovano ili poslovno obrazloženje. To obrazloženje često uključuje NIS2 Article 21, DORA obveze u području IKT rizika, odgovornost prema GDPR, ugovore s klijentima i potrebe operativne otpornosti.

Za NIS2, isti dokazi pomažu dokazati mjere iz Article 21, uključujući analizu rizika, postupanje s ranjivostima, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, kibernetičku higijenu, kontrolu pristupa i procjenu učinkovitosti. Article 20 dokazuje se kroz CISO pregled, izvješćivanje upravnom odboru, odobrenje uprave i osposobljavanje o kibernetičkoj sigurnosti. Article 23 postaje relevantan ako iskorištavanje uzrokuje ili bi moglo uzrokovati ozbiljan operativni poremećaj, financijski gubitak ili štetu drugima.

Za DORA, dokazi o ranjivostima i zakrpama podupiru okvir za upravljanje IKT rizicima, nadzor upravljačkog tijela, strategiju otpornosti, otkrivanje i klasifikaciju incidenata, testiranje otpornosti i nadzor IKT trećih strana. Kada IKT pružatelj hostira ili upravlja zahvaćenim sustavom, Articles 28 to 30 zahtijevaju dubinsku analizu dobavljača, ugovorne zaštitne mjere, prava na reviziju, pomoć u slučaju incidenta i razmatranja izlaska.

Za GDPR, isti dokazi podupiru odgovornost iz Article 5 i sigurnosni profil očekivan prema Article 32. Ako ranjivost dovede do neovlaštenog pristupa, izmjene, gubitka ili otkrivanja osobnih podataka, vremenski slijed ranjivosti, zapisi o zakrpama, zapisi dnevnika praćenja i bilješke procjene povrede postaju ključni.

Za COBIT 2019 i osiguranje u ISACA stilu, upravljanje ranjivostima procjenjuje se kroz operativnu sigurnost, praćenje kontrola, omogućavanje promjena i odgovornost upravljanja. Reference na međusobnu usklađenost u Zenith Blueprint ističu COBIT 2019 DSS05.04 i BAI09.02, kao i ITAF očekivanja osiguranja nad upravljanjem ranjivostima, zakrpavanjem i sigurnim upravljanjem promjenama.

Podržavajući ISO standardi jačaju operativni model. ISO/IEC 27005:2022 podupire procjenu rizika i obradu rizika. ISO/IEC 27035:2023 podupire odgovor na incidente kada se ranjivosti iskorištavaju. ISO/IEC 30111 podupire procese postupanja s ranjivostima. ISO/IEC 29147 podupire objavu ranjivosti i sigurnosne obavijesti. ISO/IEC 27017 podupire upravljanje ranjivostima u oblaku. ISO 22301 podupire planiranje kontinuiteta gdje bi tehničke ranjivosti mogle poremetiti poslovne usluge.

Kako različiti revizori testiraju isti proces

Različiti procjenitelji koriste različite perspektive. Dokazi mogu biti isti, ali se pitanja mijenjaju.

Politika kaže što se mora dogoditi. Operativni dokazi pokazuju što se dogodilo. Zapisi pregleda pokazuju da je uprava znala, preispitivala i postupala.

Česti razlozi zbog kojih upravljanje zakrpama pada na reviziji

Većina nalaza nije uzrokovana nepostojanjem skenera. Uzrokovana je prekinutom sljedivošću.

Popis imovine je nepotpun.
Ako skener pronađe imovinu koja nedostaje u CMDB-u ili registru imovine, vlasništvo i utjecaj na poslovanje ne mogu se pouzdano procijeniti. To narušava opseg ISO 27001:2022, procjenu rizika i obradu rizika.

Ranjivosti se prate samo u skeneru.
Nadzorne ploče skenera nisu registri upravljanja. Često im nedostaju odobrenje vlasnika rizika, obrazloženje iznimke, reference na promjene i poslovni kontekst.

Kritični nalazi nemaju dokaze o SLA.
Politika može navoditi da se kritične ranjivosti popravljaju u roku od tri dana. Revizijsko pitanje jest dokazuju li zapisi da se to dogodilo.

Iznimke su neformalne.
Naslijeđeni sustavi, ograničenja zbog prekida rada i kašnjenja dobavljača događaju se. No „nismo mogli zakrpati” mora postati dokumentirana iznimka s kompenzacijskim kontrolama, datumom isteka i odobrenjem preostalog rizika.

Hitno zakrpavanje zaobilazi upravljanje promjenama.
Hitne promjene i dalje su promjene. Ako nema dokaza o odobrenju, testiranju ili povratu, revizori mogu zaključiti da je otklanjanje ranjivosti stvorilo operativni rizik.

Sustavi trećih strana su nevidljivi.
Prema NIS2 i DORA, rizik dobavljača i IKT trećih strana središnji su elementi. Ako pružatelj zakrpava platformu, i dalje su vam potrebni dokazi, ugovorna prava, izvješćivanje o usluzi i putovi eskalacije.

Nitko ne pregledava trendove.
Ponavljajuće ranjivosti mogu upućivati na slabo upravljanje konfiguracijom, loše prakse sigurnog razvoja, nepodržanu imovinu ili neuspjeh dobavljača. Mjesečni pregled pretvara tehničke podatke u upravljačku radnju.

Clarysecov revizijski paket za ranjivosti

Za nadolazeći pregled spremnosti za ISO 27001:2022, NIS2 ili DORA, Clarysec pomaže organizacijama sastaviti revizijski paket za upravljanje ranjivostima i zakrpama koji uključuje sljedeće:

• Politiku upravljanja ranjivostima i zakrpama, uključujući opseg, uloge, učestalost skeniranja, SLA za zakrpe i pravila iznimaka
• Izvod iz popisa imovine koji prikazuje sustave u opsegu, vlasnike, kritičnost i izloženost
• Najnovija interna i vanjska izvješća o skeniranju ranjivosti
• Središnji Registar ranjivosti s otvorenim, zatvorenim i iznimnim stavkama
• Zapisnike zakrpa koji prikazuju uređaj, ažuriranje, datum zakrpe i razloge kašnjenja
• Zapise promjena za uzorkovane kritične i visoke ranjivosti
• Dokaze o ponovnim skeniranjima ili provjeri nakon otklanjanja ranjivosti
• Odobrenja iznimaka i preostalog rizika za odgođene ili nezakrpljive sustave
• Proces praćenja sigurnosnih obavijesti za dobavljače, biblioteke i usluge u oblaku
• Mjesečne zapisnike pregleda CISO-a ili uprave
• Mapiranje na obveze ISO 27001:2022, NIS2, DORA, GDPR i COBIT 2019
• Rezultate interne revizije ili provjere tehničkih kontrola

U Zenith Blueprint, faza Revizija, pregled i poboljšanje, korak 24, Clarysec naglašava sljedivost između Izjave o primjenjivosti, registra rizika i plana obrade rizika:

Vaša SoA treba biti usklađena s vašim registrom rizika i planom obrade rizika. Još jednom provjerite da je svaka kontrola koju ste odabrali kao obradu rizika označena kao „Primjenjiva” u SoA.

To je osobito važno za upravljanje ranjivostima. Ako je kontrola 8.8 primjenjiva, revizijski paket treba dokazati ne samo da se skeniranje provodi, nego i da se nalazima upravlja kroz obradu rizika i kontinuirano poboljšanje.

Sprint spremnosti od 30 dana

Ako je revizija blizu, nemojte početi prepisivanjem svega. Počnite brzom izgradnjom dokaza.

Ovaj sprint neće ukloniti sav tehnički dug. Promijenit će razgovor na reviziji. Umjesto obrane neurednog izvoza iz skenera, možete pokazati upravljani proces s vlasnicima, rokovima, radnjama, odlukama i nadzorom.

Prijeđite sa skeniranja na dokazive dokaze

Revizijska spremnost upravljanja ranjivostima i zakrpama ne znači dokazivati da nemate ranjivosti. Znači dokazati da ih možete pronaći, razumjeti, prioritizirati, popraviti, kontrolirati iznimke i dokazati nadzor.

Clarysecovi Zenith Blueprint, Zenith Controls, Politika upravljanja ranjivostima i zakrpama, Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća, Politika praćenja revizije i usklađenosti i Politika praćenja revizije i usklađenosti za mala i srednja poduzeća pružaju strukturu za izgradnju tog tijeka rada za dokaze.

Ako se vaša organizacija priprema za certifikaciju ISO 27001:2022, spremnost za NIS2, digitalnu operativnu otpornost prema DORA, dubinsku analizu dobavljača prema zahtjevu klijenta ili internu reviziju, počnite jednim pitanjem:

Može li se svaka kritična ranjivost pratiti od skeniranja do zatvaranja?

Ako je odgovor ne, Clarysec vam može pomoći izgraditi registar, skup politika, mapiranje međusobne usklađenosti, paket za preispitivanje uprave i revizijski spreman tijek rada za dokaze koji tehničko skeniranje pretvara u dokazivo upravljanje.