CVD NIS2 un DORA kontekstā: ISO 27001 pierādījumu karte

Otrdien plkst. 08.17 drošības e-pasta kastītē pienāk ziņojums no neatkarīga pētnieka. Temata rinda ir mierīga, gandrīz pieklājīga: “Iespējama konta pārņemšana jūsu klientu portālā.” Ziņojuma saturs ir satraucošāks. Pētnieks apgalvo, ka savstarpēji saistīta ievainojamība jūsu SaaS lietotnē ļauj vienam nomniekam piekļūt cita nomnieka rēķinu ierakstiem. Pievienots koncepcijas pierādījums, kas šifrēts ar jūsu publicēto PGP atslēgu.

Marijai, jaunajai CISO uzņēmumā FinanTechSaaS, laiks nevarētu būt sliktāks. Viņas uzņēmums tikko ir parakstījis būtisku līgumu ar augstākā līmeņa ES banku. Klienta sākotnējās izpētes komanda jau ir pieprasījusi “Koordinētas ievainojamību atklāšanas politiku” un ieviešanas pierādījumus, tieši atsaucoties uz NIS2 un DORA. Uzņēmumam ir security@ e-pasta adrese, taču to uzrauga viens izstrādātājs. Nav formāla pieņemšanas reģistra, nav definēta validācijas SLA, nav vadības eskalācijas ceļa un nav audita pēdas.

Vienlaikus sāk ritēt trīs pulksteņi.

Pirmais pulkstenis ir darbības pulkstenis. Vai ievainojamība ir reāla? Vai to var izmantot produkcijas vidē? Vai kāds to jau aktīvi ļaunprātīgi izmanto?

Otrais pulkstenis ir regulatīvais pulkstenis. Ja klientu dati ir eksponēti, sākas GDPR pārkāpuma izvērtēšana. Ja tiek ietekmēta pakalpojuma sniegšana būtiskai vai svarīgai vienībai NIS2 izpratnē, var tikt sasniegti incidentu ziņošanas sliekšņi. Ja uzņēmums ir finanšu sabiedrība vai IKT pakalpojumu sniedzējs, kas atbalsta finanšu pakalpojumus, var kļūt piemērojami DORA incidentu pārvaldības, klasifikācijas, eskalācijas un klientu komunikācijas noteikumi.

Trešais pulkstenis ir pierādījumu pulkstenis. Pēc sešiem mēnešiem ISO/IEC 27001:2022 auditors, finanšu sektora uzraugs, klienta apliecinājuma komanda vai iekšējā audita komiteja var jautāt: “Parādiet, kā šī ievainojamība tika apstrādāta.”

Tieši šajā jautājumā daudzas organizācijas atklāj, ka koordinēta ievainojamību atklāšana nav tikai drošības e-pasta kastīte. Tā ir pārvaldības sistēma. Tai ir vajadzīgas politikas īpašumtiesības, publisks ziņošanas kanāls, sākotnējās izvērtēšanas darbplūsma, ievainojamību novēršanas SLA, piegādātāju eskalācija, incidenta lēmuma loģika, privātuma pārskatīšana, vadības ziņošana un pamatoti pierādījumi.

Clarysec CVD aplūko kā integrētu kontroles pasākumu modeli, nevis atsevišķu iesūtni. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ievainojamību apstrāde ir iekļauta fāzē “Controls in Action”, 19. solī: “Technological Controls I”, kur norādījums ir skaidrs: organizācijām nevajadzētu ievainojamību konstatējumus pasīvi arhivēt, bet gan veikt to sākotnējo izvērtēšanu, piešķirt atbildīgajiem un izsekot līdz slēgšanai. Tas pats standarts attiecas uz ārēju atklāšanu. Ja kāds jums parāda, kā jūsu pakalpojums var pārstāt droši darboties, īstais jautājums kļūst šāds: vai varat pierādīt, ka ziņojumu saņēmāt, izvērtējāt, prioritizējāt, novērsāt, par to sazinājāties un no tā mācījāties?

Kāpēc CVD NIS2 un DORA kontekstā tagad ir valdes līmeņa jautājums

Gadiem ilgi drošības ziņā apzinīgas organizācijas aicināja ētiskos hakerus ziņot par ievainojamībām, jo tā bija laba prakse. NIS2 un DORA kontekstā šī prakse ir kļuvusi par daļu no regulētas digitālās noturības.

NIS2 attiecas uz daudzām vidēja lieluma un lielākām vienībām augstas kritiskuma un citās kritiskās nozarēs, tostarp digitālās infrastruktūras pakalpojumu sniedzējiem, mākoņdatošanas pakalpojumu sniedzējiem, datu centru pakalpojumu sniedzējiem, pārvaldīto pakalpojumu sniedzējiem, pārvaldīto drošības pakalpojumu sniedzējiem un noteiktiem digitālajiem pakalpojumu sniedzējiem, piemēram, tiešsaistes tirdzniecības vietām, meklētājprogrammām un sociālo tīklu platformām. Tā var būt piemērojama neatkarīgi no lieluma arī tādām kategorijām kā uzticamības pakalpojumu sniedzēji, DNS pakalpojumu sniedzēji, TLD reģistri un publisko elektronisko sakaru tīklu vai pakalpojumu sniedzēji.

NIS2 Article 21 pieprasa būtiskām un svarīgām vienībām ieviest atbilstošus un samērīgus tehniskus, darbības un organizatoriskus kiberdrošības risku pārvaldības pasākumus, izmantojot visu apdraudējumu pieeju. Viena no minimālajām jomām ir tīklu un informācijas sistēmu iegādes, izstrādes un uzturēšanas drošība, tostarp ievainojamību apstrāde un atklāšana. Tas pats pamatlīmenis aptver arī incidentu apstrādi, piegādes ķēdes drošību, darbības nepārtrauktību, piekļuves kontroli, aktīvu pārvaldību, apmācību, kriptogrāfiju un procedūras kontroles efektivitātes izvērtēšanai.

NIS2 Article 20 arī skaidri nosaka vadības pārskatatbildību. Vadības struktūrām ir jāapstiprina kiberdrošības risku pārvaldības pasākumi, jāuzrauga ieviešana un jāapgūst apmācība. CVD programmai tas nozīmē, ka valdei vai augstākajai vadībai ir jāizprot ziņošanas kanāls, ievainojamību reaģēšanas komanda, validācijas termiņi, ievainojamību novēršanas prasības, piegādātāju atkarības un incidentu ziņošanas ierosinātāji.

DORA no 2025. gada 17. janvāra izveido nozarei specifisku režīmu finanšu sabiedrībām. Tas aptver IKT risku pārvaldību, ar IKT saistītu incidentu ziņošanu, digitālās darbības noturības testēšanu, informācijas apmaiņu, IKT trešo pušu risku, līgumiskās prasības, kritisko IKT trešo pušu pakalpojumu sniedzēju pārraudzību un sadarbību ar uzraudzības iestādēm. Finanšu sabiedrībām, uz kurām attiecas DORA, IKT risku pārvaldības un incidentu ziņošanas jautājumos DORA parasti ir prioritāra attiecībā pret NIS2, jo tas ir nozarei specifisks Savienības tiesību akts. Taču praktiskā prasība paliek tā pati: finanšu sabiedrībām un IKT pakalpojumu sniedzējiem, kas tās apkalpo, ir jāuztur strukturēts, dokumentēts un testējams process IKT vājo vietu identificēšanai, analīzei, klasificēšanai, eskalēšanai, novēršanai un no tām gūto mācību izmantošanai.

Ievainojamības ziņojums var sākties kā tehnisks konstatējums, kļūt par drošības notikumu, eskalēties par incidentu, ierosināt GDPR personas datu aizsardzības pārkāpuma izvērtēšanu, prasīt piegādātāja rīcību un vēlāk parādīties ISO/IEC 27001:2022 Piemērojamības deklarācijā. Tāpēc CVD ir jāprojektē kā vienots darbības modelis drošībai, atbilstībai, inženierijai, juridiskajai funkcijai, privātumam, iepirkumam un vadībai.

ISO 27001 pamats: no atklāšanas līdz ISMS pierādījumiem

ISO/IEC 27001:2022 CISO un atbilstības vadītājiem nodrošina pārvaldības sistēmu, kas padara CVD auditējamu.

4.1.–4.4. punkts pieprasa organizācijai izprast iekšējos un ārējos jautājumus, ieinteresēto pušu prasības, ISMS robežas un atkarības no citām organizācijām. Šeit ISMS tvērumā ienāk NIS2, DORA, GDPR, klientu līgumi, piegādātāju pienākumi un ievainojamību atklāšanas saistības.

5.1.–5.3. punkts nosaka vadības pārskatatbildību. Augstākajai vadībai ir jāsaskaņo informācijas drošība ar stratēģisko virzienu, jānodrošina resursi, jāpiešķir atbildība un jānodrošina, ka ISMS sasniedz paredzētos rezultātus. CVD gadījumā tas nozīmē ievainojamību reaģēšanas komandas iecelšanu, pilnvaru definēšanu atlikušā riska pieņemšanai un augstas ietekmes ievainojamību eskalēšanu vadībai.

6.1.1.–6.1.3. punkts nodrošina riska mehānismu. Organizācijai ir jādefinē riska kritēriji, jāizvērtē informācijas drošības riski, jāpiešķir riska īpašnieki, jāizvēlas riska apstrādes iespējas, jāsalīdzina kontroles pasākumi ar A pielikumu, jāsagatavo Piemērojamības deklarācija un jāsaņem atlikušā riska apstiprinājums. 8.1.–8.3. punkts pēc tam pieprasa darbības kontroles pasākumus, plānotās izmaiņas, ārēji nodrošināto procesu kontroli, risku izvērtēšanu plānotos intervālos vai pēc būtiskām izmaiņām un apstrādes rezultātu pierādījumus.

Zenith Blueprint risku pārvaldības fāzes 13. solī Piemērojamības deklarācija ir aprakstīta kā vairāk nekā atbilstības izklājlapa:

“SoA faktiski ir savienojošs dokuments: tas sasaista jūsu risku izvērtēšanu/apstrādi ar faktiskajiem kontroles pasākumiem, kas jums ir.”
Avots: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Koordinētas ievainojamību atklāšanas gadījumā SoA jāsaista regulatīvie pienākumi, darbības risks, A pielikuma kontroles pasākumi, politikas punkti un operacionālie pierādījumi.

Mērķis nav radīt paralēlus atbilstības silosus. CVD politikai jābūt kontrolētam ISMS procesam, kas vienlaikus atbalsta ISO/IEC 27001:2022 sertifikāciju, NIS2 atbilstību, DORA gatavību, klientu apliecinājumu un drošības operācijas.

Politikas pamatlīmenis: kas jānosaka jūsu CVD politikā

Pirmais redzamais kontroles pasākums ir publiskais atklāšanas kanāls. Pētniekiem, klientiem, piegādātājiem un partneriem jāzina, kur ziņot par ievainojamībām un kā aizsargāt sensitīvus pierādījumus.

Clarysec Koordinētas ievainojamību atklāšanas politika Koordinētas ievainojamību atklāšanas politika nodrošina uzņēmuma pamatlīmeni:

“Publiskie atklāšanas kanāli: organizācijai jāuztur skaidrs kanāls ievainojamību ziņošanai, piemēram, īpaša drošības kontaktpersonas e-pasta adrese (piemēram, security@company.com) vai tīmekļa veidlapa. Šī informācija jāpublicē uzņēmuma tīmekļvietnes drošības lapā kopā ar organizācijas PGP publisko atslēgu, lai nodrošinātu šifrētu iesniegšanu.”
Avots: Koordinētas ievainojamību atklāšanas politika, ieviešanas prasības, 6.1. punkts

Šis punkts novērš biežu audita nepilnību. Daudzas organizācijas apgalvo, ka pieņem ziņojumus, taču ziņošanas ceļš ir grūti atrodams, nešifrēts vai pieder nepareizai komandai. Nobriedis kanāls ir publisks, drošs, uzraudzīts un piešķirts atbildīgai funkcijai.

Nākamais kontroles pasākums ir reaģēšanas disciplīna. Kritiskam ziņojumam sekojošs klusums rada atklāšanas risku, reputācijas risku un ekspluatācijas risku. Koordinētas ievainojamību atklāšanas politika nosaka konkrētu saņemšanas apstiprinājuma un validācijas prasību:

“Sākotnējā izvērtēšana un saņemšanas apstiprinājums: saņemot ziņojumu, VRT to reģistrē un 2 darbdienu laikā nosūta ziņotājam saņemšanas apstiprinājumu, piešķirot izsekošanas atsauci. VRT veic sākotnējo smaguma pakāpes izvērtējumu, piemēram, izmantojot CVSS vērtējumu, un validē problēmu, vajadzības gadījumā piesaistot IT un izstrādes komandas, mērķa termiņā 5 darbdienu laikā. Kritiskās ievainojamības, piemēram, tādas, kas ļauj attālināti izpildīt kodu vai izraisa būtisku datu aizsardzības pārkāpumu, jāapstrādā paātrināti.”
Avots: Koordinētas ievainojamību atklāšanas politika, ieviešanas prasības, 6.4. punkts

Šis formulējums rada tūlītējus pierādījumu punktus: saņemšanas laiku, saņemšanas apstiprinājuma laiku, izsekošanas atsauci, sākotnējo smaguma pakāpi, validācijas rezultātu un lēmumu par paātrinātu apstrādi.

MVU gadījumā Clarysec izmanto to pašu loģiku ar samērīgu ieviešanu. Lietojumprogrammu drošības prasību politika MVU Lietojumprogrammu drošības prasību politika - MVU pieprasa organizācijām:

“noteikt pienākumus attiecībā uz ievainojamību atklāšanu, reaģēšanas termiņiem un ielāpu uzstādīšanu.”
Avots: Lietojumprogrammu drošības prasību politika MVU, pārvaldības prasības, 5.3.2. punkts

Lai būtu pārskatatbildīgi, nav vajadzīga liela produktu drošības komanda. Ir vajadzīgi skaidri pienākumi, reālistiski termiņi, noteikti īpašnieki un pierādījumi, ka process darbojas.

CVD pieņemšanas darbplūsma: no pētnieka e-pasta līdz lēmuma ierakstam

Laba pieņemšanas darbplūsma ir pietiekami vienkārša, lai to izmantotu spriedzes apstākļos, un pietiekami pilnīga, lai apmierinātu auditoru. Tai jāsākas ar īpašu kanālu, piemēram, security@[company], tīmekļa veidlapu vai publicētu security.txt datni. Iesniegšanas ceļam jāļauj iesniegt šifrētus pierādījumus, norādīt skarto produktu vai galapunktu, reproducēšanas soļus, ziņotāja kontaktinformāciju, vēlamo atklāšanas laiku un jebkādas norādes par datu ekspozīciju vai aktīvu izmantošanu.

Pēc saņemšanas ievainojamību reaģēšanas komandai jāizveido ieraksts GRC rīkā, pieteikumu platformā, ievainojamību pārvaldības sistēmā vai kontrolētā reģistrā. Rīkam ir mazāka nozīme nekā konsekvencei un pierādījumu kvalitātei.

Pēc tam darbplūsmai jāvirzās caur septiņiem operacionāliem soļiem.

1. Pieņemšana: ziņojums tiek saņemts publiskajā kanālā un automātiski vai manuāli reģistrēts žurnālā.
2. Saņemšanas apstiprinājums: VRT atbild 2 darbdienu laikā un piešķir izsekošanas atsauci.
3. Validācija: tehniskā komanda reproducē problēmu, apstiprina skartās sistēmas un veic sākotnējo smaguma pakāpes vērtējumu.
4. Notikuma izvērtēšana: VRT nosaka, vai ievainojamība ir tikai vājā vieta, informācijas drošības notikums vai incidents.
5. Eskalācija: augstas vai kritiskas problēmas pēc vajadzības tiek nodotas sistēmu īpašniekiem, CISO, privātuma funkcijai, juridiskajai funkcijai, piegādātājiem un vadībai.
6. Ievainojamības novēršana: atbildīgā komanda piemēro labojumu, riska mazināšanas pasākumu, kompensējošo kontroles pasākumu vai pagaidu ierobežojumu.
7. Slēgšana: VRT pārbauda labojumu, sazinās ar ziņotāju, atjaunina pierādījumu lietu un reģistrē gūtās mācības.

Clarysec šo darbības soli kartē uz ISO/IEC 27002:2022 kontroles pasākumu A.5.25 “Informācijas drošības notikumu izvērtēšana un lēmums” un kontroles pasākumu A.8.8 “Tehnisko ievainojamību pārvaldība”, izmantojot Zenith Controls: The Cross-Compliance Guide Zenith Controls. Attiecībā uz A.5.25 Zenith Controls skaidro, ka notikumu izvērtēšana ir sākotnējās izvērtēšanas funkcija starp neapstrādātiem uzraudzības brīdinājumiem un formālu incidentu apstrādi, izmantojot žurnālus, sliekšņus un lēmumu kritērijus, lai noteiktu eskalāciju. Attiecībā uz A.8.8 Zenith Controls sasaista tehnisko ievainojamību pārvaldību ar aizsardzību pret ļaunprogrammatūru, konfigurāciju pārvaldību, izmaiņu pārvaldību, galiekārtu drošību, draudu izlūkošanu, uzraudzību, drošu izstrādi, notikumu izvērtēšanu un reaģēšanu uz incidentiem.

Viens Zenith Controls fragments ir īpaši noderīgs, ja pastāv aizdomas par aktīvu izmantošanu:

“Draudu izlūkošana informē, kuras ievainojamības tiek aktīvi izmantotas, vadot ielāpu prioritizēšanu.”
Avots: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 kontroles pasākums 8.8, sasaiste ar kontroles pasākumu 5.7 Threat Intelligence Zenith Controls

Tas ir būtisks pārvaldības punkts. Smaguma pakāpe nav tikai CVSS. Vidējas smaguma pakāpes ievainojamība, kas aktīvi tiek izmantota pret jūsu nozari, var būt prioritārāka par teorētisku kritisku problēmu neeksponētā testa sistēmā.

Kad ievainojamība kļūst par incidentu

Ne katrs ievainojamības ziņojums ir incidents. Trūkstoša drošības galvene pirmsprodukcijas vidē nav tas pats, kas izmantota autorizācijas apiešana, kas eksponē klientu rēķinus. Taču katram ticamam ievainojamības ziņojumam jāiziet caur incidenta lēmuma vārtiem.

NIS2 Article 23 pieprasa būtiskām un svarīgām vienībām bez nepamatotas kavēšanās paziņot savam CSIRT vai kompetentajai iestādei par incidentiem, kas būtiski ietekmē pakalpojumu sniegšanu. Būtisks incidents ir tāds, kas ir izraisījis vai spēj izraisīt nopietnus darbības traucējumus vai finansiālus zaudējumus, vai kas ir ietekmējis vai spēj ietekmēt citus, radot ievērojamu materiālu vai nemateriālu kaitējumu. Ziņošanas secība ietver agrīnu brīdinājumu 24 stundu laikā pēc informētības iegūšanas, incidenta paziņojumu 72 stundu laikā, starpposma ziņojumus pēc pieprasījuma un gala ziņojumu viena mēneša laikā pēc 72 stundu paziņojuma.

DORA Articles 17 to 20 pieprasa finanšu sabiedrībām atklāt, pārvaldīt, reģistrēt, klasificēt, eskalēt, paziņot un komunicēt ar IKT saistītus incidentus un nozīmīgus kiberdraudus. Būtiski ar IKT saistīti incidenti jāeskalē augstākajai vadībai un vadības struktūrai. Klientu komunikācija var būt nepieciešama, ja tiek ietekmētas finanšu intereses.

MVU gadījumā ziņošanas kultūrai jābūt tikpat skaidrai. Clarysec Reaģēšanas uz incidentiem politika MVU Reaģēšanas uz incidentiem politika - MVU nosaka:

“Personālam par jebkādu aizdomīgu darbību vai apstiprinātu incidentu jāziņo uz incident@[company] vai mutiski ģenerāldirektoram vai IT pakalpojumu sniedzējam.”
Avots: Reaģēšanas uz incidentiem politika MVU, politikas ieviešanas prasības, 6.2.1. punkts

Zenith Blueprint fāzē “Controls in Action”, 16. solī: “People Controls II”, princips ir vēl vienkāršāks:

“Ja ir šaubas, ziņo.”
Avots: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 16: People Controls II (A.6.5 to A.6.8)

Šai frāzei jāattiecas uz izstrādātājiem, atbalsta komandām, piegādātāju pārvaldniekiem, privātuma vadītājiem, vadošajiem darbiniekiem un ārpakalpojumu sniedzējiem. Ievainojamība, kas var ietekmēt konfidencialitāti, integritāti, pieejamību, klientu uzticēšanos, regulatīvo ziņošanu vai finanšu operācijas, ir jāreģistrē un jāizvērtē, nevis neformāli jāapstrādā tērzēšanā.

Ievainojamību novēršana, ielāpu uzstādīšana un kompensējošie kontroles pasākumi

Kad ievainojamība ir validēta, tā ir jāapstrādā. Apstrādei jābūt balstītai uz risku, pamatotai ar pierādījumiem un ierobežotai laikā.

Koordinētas ievainojamību atklāšanas politika nosaka uzņēmuma prasību:

“Ievainojamības novēršanas plāns: visām apstiprinātajām ievainojamībām jāizstrādā novēršanas vai mazināšanas plāns. Labojuma ieviešana jāprioritizē, pamatojoties uz smaguma pakāpi. Piemēram, kritiskās ievainojamības, ja iespējams, jānovērš vai jāmazina 14 dienu laikā vai ātrāk, ja tiek konstatēta aktīva izmantošana, savukārt zemākas smaguma pakāpes problēmas jārisina saprātīgā termiņā. Ja pilns labojums kavējas, jāievieš kompensējošie kontroles pasākumi vai pagaidu mazināšanas pasākumi, piemēram, ievainojamās funkcionalitātes atspējošana vai uzraudzības pastiprināšana.”
Avots: Koordinētas ievainojamību atklāšanas politika, ieviešanas prasības, 6.6. punkts

MVU ielāpu disciplīnai Ievainojamību un ielāpu pārvaldības politika MVU Ievainojamību un ielāpu pārvaldības politika - MVU nosaka:

“Kritiskie ielāpi jāuzstāda 3 dienu laikā pēc izlaišanas, īpaši internetam pieejamām sistēmām”
Avots: Ievainojamību un ielāpu pārvaldības politika MVU, politikas ieviešanas prasības, 6.1.1. punkts

Šie termiņi nav pretrunīgi. Piegādātāja ielāps internetam pieejamai sistēmai var prasīt ļoti ātru ieviešanu. Produkta ievainojamībai, kurai nepieciešamas koda izmaiņas, regresijas testēšana, klientu koordinācija un pakāpeniska izlaišana, var būt vajadzīgs ievainojamības novēršanas plāns ar pagaidu mazināšanas pasākumiem. Svarīgākais ir tas, ka lēmums ir dokumentēts, tam ir riska īpašnieks un tas ir apstiprināts, ja saglabājas atlikušais risks.

Praktiskais gadījuma plūsmas piemērs izskatās šādi:

1. Pētnieks ziņo par autorizācijas apiešanu klientu norēķinu API.
2. VRT reģistrē CVD-2026-014 ar laikspiedolu un 2 darbdienu laikā nosūta saņemšanas apstiprinājumu.
3. Produktu drošības komanda 24 stundu laikā validē trūkumu un piešķir augstu smaguma pakāpi, jo pastāv starpnomnieku datu piekļuve.
4. Privātuma funkcija veic GDPR pārkāpuma izvērtēšanu, jo rēķinu ierakstos var būt personas dati.
5. Incidentu pārvaldnieks atver notikuma izvērtēšanu saskaņā ar ISO/IEC 27002:2022 kontroles pasākumu A.5.25.
6. Sistēmas īpašnieks ar pagaidu funkcionalitātes slēdzi atspējo ievainojamo galapunktu.
7. Inženierija izveido ārkārtas labojumu saskaņā ar ISO/IEC 27002:2022 kontroles pasākumu A.8.32, izmaiņu pārvaldība.
8. Uzraudzības noteikumi tiek papildināti ar izmantošanas indikatoriem, sasaistot tos ar A.8.15, žurnālfiksēšanu, un A.8.16, uzraudzības darbībām.
9. CISO informē augstāko vadību, jo problēma ir augsta riska.
10. VRT koordinē atkārtotu testēšanu un atklāšanas laiku ar pētnieku.
11. Riska īpašnieks apstiprina slēgšanu tikai pēc verifikācijas testēšanas un klientu ietekmes pārskatīšanas.
12. SoA, riska reģistrs, pieteikums, žurnāli, vadības paziņojums un gūtās mācības tiek atjaunināti.

Tā ir atšķirība starp “mēs to ielāpojām” un “mēs varam pierādīt, ka to pārvaldījām”.

Piegādātāju un mākoņpakalpojumu atkarības: slēptais atteices punkts

Daudzas CVD neveiksmes patiesībā ir piegādātāju neveiksmes. Ievainojamība var ietekmēt SaaS komponentu, mākoņpakalpojumu, pārvaldīto drošības pakalpojumu sniedzēju, maksājumu vārteju, autentifikācijas starpnieku, atvērtā pirmkoda bibliotēku, ārpakalpojuma izstrādes komandu vai apakšuzņēmēju.

NIS2 Article 21 pieprasa piegādes ķēdes drošību, tostarp attiecības ar tiešajiem piegādātājiem un pakalpojumu sniedzējiem. Piegādes ķēdes pasākumiem jāņem vērā piegādātāju ievainojamības, produktu kvalitāte, kiberdrošības prakses un drošas izstrādes procedūras.

DORA Articles 28 to 30 finanšu sabiedrībām nosaka padziļinātākas prasības. Tie pieprasa pārvaldīt IKT trešo pušu risku kā daļu no IKT risku ietvara, uzturēt IKT pakalpojumu līgumu reģistrus, nošķirt kritiskas vai svarīgas funkcijas, veikt pirmslīguma sākotnējo izpēti, noteikt līgumiskās drošības prasības, incidentu atbalstu, sadarbību ar iestādēm, audita tiesības, izbeigšanas tiesības un izstāšanās stratēģijas. Finanšu sabiedrības saglabā pilnu atbildību par DORA atbilstību arī tad, ja tās izmanto IKT trešo pušu pakalpojumu sniedzējus.

Clarysec Trešo pušu un piegādātāju drošības politika MVU Trešo pušu un piegādātāju drošības politika - MVU ietver vienkāršu eskalācijas noteikumu:

“Ģenerāldirektors nekavējoties jāinformē par jebkādu drošības pārkāpumu, izmaiņu vai incidentu”
Avots: Trešo pušu un piegādātāju drošības politika MVU, lomas un pienākumi, 4.4.3. punkts

Uzņēmuma piegādātāju līgumiem Zenith Blueprint fāzes “Controls in Action” 23. solis iesaka iekļaut konfidencialitātes pienākumus, piekļuves kontroles atbildību, tehniskos un organizatoriskos pasākumus, incidentu ziņošanas termiņus, audita tiesības, apakšuzņēmēju kontroles pasākumus un līguma izbeigšanas noteikumus. Tajā ir teikts:

“Svarīgi ir tas, ka tie pastāv un ka abas puses tos saprot un pieņem.”
Avots: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action phase, Step 23: Organizational controls (5.19 to 5.37)

CVD piegādātāju gatavībai jāatbild uz šiem jautājumiem:

• Vai piegādātājs publicē ievainojamību ziņošanas kanālu?
• Vai ievainojamību paziņošanas termiņi ir definēti līgumā?
• Vai par kritiskām piegādātāja ievainojamībām tiek ziņots bez nepamatotas kavēšanās?
• Vai klientus ietekmējošas vājās vietas ir sasaistītas ar incidentu atbalsta pienākumiem?
• Vai piegādātājs var sniegt ievainojamības novēršanas pierādījumus vai drošības paziņojumus?
• Vai apakšuzņēmēju ievainojamību pienākumi tiek pārnesti tālāk?
• Vai pastāv izstāšanās stratēģija, ja ievainojamības novēršana ir nepietiekama?

Šeit NIS2, DORA un ISO/IEC 27001:2022 saplūst. Piegādātāju ievainojamību pārvaldība nav iepirkuma izvēles rūtiņa. Tā ir daļa no darbības noturības.

Pierādījumu kartējums ISO 27001, NIS2, DORA, GDPR un COBIT vajadzībām

Spēcīgākās CVD programmas sākas ar pierādījumiem. Tās pieņem, ka jebkuru nozīmīgu ziņojumu vēlāk var pārskatīt iekšējais audits, sertifikācijas auditori, regulatori, klienti, apdrošinātāji vai valdes riska komiteja.

Clarysec Audita un atbilstības uzraudzības politika MVU Audita un atbilstības uzraudzības politika - MVU fiksē detaļu, ko daudzas komandas palaiž garām:

“Metadati (piemēram, kas tos savāca, kad un no kuras sistēmas) ir jādokumentē.”
Avots: Audita un atbilstības uzraudzības politika MVU, politikas ieviešanas prasības, 6.2.3. punkts

Ekrānuzņēmums ar ielāpītu serveri ir vājš pierādījums, ja neviens nezina, kas to fiksēja, kad, no kādas sistēmas un kā tas kartējas uz ievainojamību. Pieteikums ar laikspiedoliem, skenera izvadi, pull request, izmaiņu apstiprinājumu, izvietošanas žurnāliem, uzraudzības vaicājumu, atkārtotas testēšanas apstiprinājumu un metadatiem ir daudz spēcīgāks.

Detalizētāka izsekojamības matrica palīdz klientu sākotnējās izpētes un iekšējā audita laikā.

Dažādi auditori to pašu procesu testēs no dažādām perspektīvām.

ISO/IEC 27001:2022 auditors sāks ar ISMS. Viņš jautās, vai ievainojamību atklāšanas pienākumi ir iekļauti ieinteresēto pušu prasībās, vai riski tiek konsekventi izvērtēti, vai kontroles pasākumi parādās SoA, vai pastāv darbības pierādījumi un vai vadība pārskata tendences un kavētos vienumus.

DORA vai finanšu pakalpojumu pārskatītājs koncentrēsies uz darbības noturību. Viņš pārbaudīs IKT risku integrāciju, incidentu klasifikāciju, eskalāciju augstākajai vadībai, klientu komunikāciju, trešo pušu atkarības, testēšanu un gūtās mācības. Ja ievainojamība ietekmē kritisku vai svarīgu funkciju, būs sagaidāma cieša sasaiste starp tehnisko pieteikumu, biznesa ietekmi, nepārtrauktības sekām un piegādātāju pienākumiem.

GDPR pārskatītājs koncentrēsies uz personas datiem. Vai tika iesaistīti personas dati? Vai notika nesankcionēta piekļuve, zudums, izmaiņas vai izpaušana? Vai pārziņa un apstrādātāja lomas bija skaidras? Vai tika izvērtēts pārkāpuma slieksnis? Vai bija būtiski tādi drošības pasākumi kā šifrēšana, piekļuves kontrole, žurnālfiksēšana un minimizēšana?

COBIT 2019 vai ISACA auditors koncentrēsies uz pārvaldību, pārskatatbildību, veiktspēju un apliecinājumu. Viņš meklēs definētas īpašumtiesības, metriku, eskalāciju, kontroles mērķus, vadības pārraudzību un izņēmumu izsekošanu. Kavēta kritiska ievainojamība nav tikai tehniska problēma. Tā ir pārvaldības problēma, ja vien tā nav formāli eskalēta un risks nav pieņemts.

Uz NIST orientēts izvērtētājs domās kategorijās Identify, Protect, Detect, Respond un Recover. Viņš sagaidīs aktīvu īpašumtiesības, ievainojamību identificēšanu, prioritizēšanu, aizsargājošas izmaiņas, izmantošanas detekciju, reaģēšanas koordināciju un atjaunošanas validāciju.

Integrēta CVD modeļa priekšrocība ir tā, ka viena un tā pati pierādījumu ass var atbalstīt visas šīs pārskatīšanas.

Ikmēneša kontroles cikls: metrika, ko vadība var izmantot

CVD nebeidzas, kad pieteikums tiek slēgts. Koordinētas ievainojamību atklāšanas politika pieprasa pastāvīgu žurnāla pārskatīšanu:

“VRT uztur ievainojamību atklāšanas žurnālu, kurā katrs ziņojums tiek izsekots no saņemšanas līdz slēgšanai. Žurnāls tiek pārskatīts katru mēnesi, lai nodrošinātu atvērto vienumu savlaicīgu virzību. Kavētie vienumi jāeskalē.”
Avots: Koordinētas ievainojamību atklāšanas politika, uzraudzība un audits, 9.1. punkts

Šī ikmēneša pārskatīšana pārvērš ievainojamību atklāšanu par valdei piemērotu pārvaldības procesu. Vadībai nav vajadzīga katra tehniskā detaļa. Tai vajadzīgas tendences, pakļautība riskam, pārskatatbildība un kavēts risks.

Nobriedušā Clarysec ieviešanā šī ikmēneša žurnāla pārskatīšana nodrošina ievadi riska reģistram, Piemērojamības deklarācijai, drošas izstrādes uzkrājumam, piegādātāju pārskatīšanai, incidentos gūtajām mācībām, iekšējā audita plānam un vadības ziņošanas paketei.

Izveidojiet procesu pirms nopietna ziņojuma saņemšanas

Sliktākais brīdis koordinētas ievainojamību atklāšanas projektēšanai ir pēc tam, kad pētnieks jau ir publiski publicējis jūsu vājo vietu vai kritisks bankas klients ir apturējis uzņemšanu. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST tipa noturības prasības un COBIT 2019 pārvaldība norāda vienā virzienā: ievainojamību atklāšanai jābūt plānotai, ar noteiktām īpašumtiesībām, testētai, pamatotai ar pierādījumiem un uzlabotai.

Sāciet ar šīm piecām darbībām:

1. Pieņemiet vai pielāgojiet Koordinētas ievainojamību atklāšanas politiku.
2. Izveidojiet pieņemšanas un sākotnējās izvērtēšanas darbplūsmu, izmantojot Zenith Blueprint, īpaši 13. soli SoA izsekojamībai, 16. soli ziņošanas kultūrai, 19. soli tehnisko ievainojamību pārvaldībai un 23. soli piegādātāju vienošanām.
3. Kartējiet darbplūsmu, izmantojot Zenith Controls, koncentrējoties uz ISO/IEC 27002:2022 kontroles pasākumiem 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 un A.8.32.
4. Pievienojiet MVU vajadzībām piemērotus punktus no Reaģēšanas uz incidentiem politika MVU, Ievainojamību un ielāpu pārvaldības politika MVU, Trešo pušu un piegādātāju drošības politika MVU, Lietojumprogrammu drošības prasību politika MVU un Audita un atbilstības uzraudzības politika MVU, ja nozīme ir samērīgumam.
5. Veiciet galda vingrinājumu, kas simulē pētnieka ziņojumu, kurš ietekmē personas datus un piegādātāja mitinātu komponentu, un pēc tam pārbaudiet saņemšanas apstiprinājumu, sākotnējo izvērtēšanu, incidenta klasifikāciju, ielāpu uzstādīšanu, klientu komunikāciju, pierādījumu fiksēšanu un vadības eskalāciju.

Clarysec var palīdzēt jums to pārvērst par funkcionējošu CVD politiku, pieņemšanas reģistru, ISO/IEC 27001:2022 pierādījumu karti, NIS2 un DORA lēmumu koku, piegādātāju eskalācijas modeli un auditam gatavu kontroles pasākumu paketi. Mērķis ir vienkāršs: kad pienāk nākamais ievainojamības ziņojums, jūsu komandai nevajadzētu improvizēt. Tai jārīkojas pārliecinoši, ar pierādījumiem un kontroli.