No skenējumiem līdz pierādījumiem: ISO 27001:2022, NIS2 un DORA

Ir pirmdienas 08:16. Internetam pieejama lietojumprogrammu servera informācijas panelī tikko parādījusies kritiska attālinātas koda izpildes ievainojamība. Infrastruktūras komanda norāda, ka piegādātāja ielāps ir pieejams. Lietojumprogrammas īpašnieks brīdina, ka serveris nodrošina ieņēmumiem kritisku klientu darbplūsmu. Juridiskais dienests jautā, vai ievainojamības izmantošana varētu radīt ziņošanas pienākumus saskaņā ar NIS2, DORA vai GDPR. Informācijas drošības vadītāja Marija atver audita kalendāru un ierauga patieso problēmu: ISO 27001:2022 uzraudzības audits sākas nākamnedēļ, NIS2 gatavības pārskatīšana jau notiek, un nozīmīgs fintech klients ir pieprasījis DORA pierādījumus.

Skeneris rāda sarkanu statusu. Pieteikumu panelis rāda aktivitāti. Izklājlapa rāda ieguldīto darbu. Taču neviens no šiem elementiem automātiski nepierāda kontroles pasākuma darbību.

Tā ir plaisa, ko daudzas organizācijas atklāj pārāk vēlu. Ievainojamību skenēšana nav tas pats, kas auditgatava ievainojamību pārvaldība. Skenējums norāda, ka kaut kas varētu būt nepareizi. Audita pierādījumi apliecina, ka organizācija zināja, kādi aktīvi tai ir, izvērtēja risku, piešķīra īpašumtiesības, rīkojās atbilstoši politikai, kontrolēja izmaiņas, dokumentēja izņēmumus, pārbaudīja rezultātus un pārskatīja iznākumu.

ISO/IEC 27001:2022, NIS2 un DORA kontekstā šī pierādījumu ķēde ir tikpat svarīga kā tehniskais labojums. Skeneris sāk stāstu. Aktīvu uzskaite, ievainojamību reģistrs, pieteikums, riska lēmums, izmaiņu ieraksts, ielāpu žurnāls, validācijas pierādījumi, izņēmuma apstiprinājums un vadības pārskatīšana to pabeidz.

Clarysec pieeja ir vienkārša: neuztveriet ievainojamību pārvaldību kā ikmēneša tehnisku rituālu. Uztveriet to kā pārvaldītu pierādījumu darbplūsmu.

Kāpēc skenēšanas pārskati nav pietiekami audita pierādījumi

Ievainojamību skenēšana ir konkrēta laika brīža tehnisks novērojums. Tā var identificēt CVE, trūkstošu ielāpu, neatbalstītu bibliotēku, eksponētu pakalpojumu vai vāju konfigurāciju. Tas ir noderīgi, bet nepilnīgi.

Auditors uzdos citus jautājumus:

• Vai skartais aktīvs bija piemērošanas jomā?
• Kam pieder aktīvs un biznesa pakalpojums?
• Vai ievainojamība tika izvērtēta, ņemot vērā ekspozīciju, izmantojamību, biznesa ietekmi un datu sensitivitāti?
• Vai ievainojamības novēršana tika pabeigta noteiktajā termiņā?
• Ja novēršana kavējās, kurš pieņēma atlikušo risku?
• Vai ielāps tika ieviests kontrolētā izmaiņu pārvaldības procesā?
• Vai labojums tika pārbaudīts ar atkārtotu skenēšanu vai tehnisko validāciju?
• Vai pierādījumi tika saglabāti un pārskatīti vadības līmenī?

Mape ar skenera eksportiem reti atbild uz šiem jautājumiem. ISO 27001:2022 auditā auditors pārbauda, vai ISMS darbojas tā, kā paredzēts. Saskaņā ar NIS2 vadības institūcijām jāapstiprina un jāpārrauga kiberdrošības risku pārvaldības pasākumi. Saskaņā ar DORA finanšu iestādēm nepieciešams dokumentēts IKT risku pārvaldības ietvars, incidentu dzīves cikls, noturības testēšana un IKT trešo pušu riska kontroles pasākumi. Saskaņā ar GDPR jautājums ir par to, vai piemēroti tehniskie un organizatoriskie pasākumi aizsargāja personas datus un vai organizācija var pierādīt pārskatatbildību.

ISO/IEC 27001:2022 punkti 4.1 līdz 4.4 prasa organizācijai izprast savu kontekstu, ieinteresētās puses, prasības un ISMS darbības jomu. Ievainojamību un ielāpu pārvaldību nevar projektēt izolēti. Tai jāatspoguļo klientu līgumi, regulatori, mākoņpakalpojumu atkarības, ārpakalpojumā nodrošināti IKT pakalpojumi, datu aizsardzības pienākumi un kritiski pakalpojumi.

ISO/IEC 27001:2022 punkti 6.1.1 līdz 6.1.3 prasa risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi, Paziņojumu par piemērojamību un riska īpašnieka apstiprinājumu atlikušajam riskam. Tas nozīmē, ka ievainojamību pierādījumiem jābūt sasaistītiem ar riska reģistru, riska apstrādes plānu un SoA.

ISO/IEC 27005:2022 nostiprina šo modeli, mudinot organizācijas riska novērtējuma bāzē apvienot prasības no Annex A, nozares pienākumiem, regulējuma, līgumiem, iekšējiem noteikumiem un esošajiem kontroles pasākumiem. Tas arī uzsver kritērijus, kas attiecas uz varbūtību, sekām, juridiskajiem pienākumiem, piegādātāju attiecībām, privātuma ietekmi un trešo pušu ietekmi. Praktiski ievainojamība nav tikai CVSS skaitlis. Tā ir riska notikums, kas saistīts ar aktīviem, pienākumiem, iesaistītajām pusēm un biznesa sekām.

Regulatīvais spiediens aiz ielāpu pierādījumiem

Mūsdienu kiberdrošības regulējums arvien mazāk pieļauj neformālu ielāpošanu.

NIS2 attiecas uz daudzām vidējām un lielām vienībām augstas kritiskuma un kritiskās nozarēs, kā arī var attiekties uz noteiktām vienībām neatkarīgi no to lieluma. Tās darbības joma ietver digitālās infrastruktūras nodrošinātājus, piemēram, mākoņpakalpojumus, datu centru pakalpojumus, satura piegādes tīklus, publisko elektronisko sakaru nodrošinātājus, uzticamības pakalpojumus, DNS un TLD pakalpojumus, kā arī IKT pakalpojumu pārvaldības sniedzējus, tostarp pārvaldīto pakalpojumu sniedzējus un pārvaldīto drošības pakalpojumu sniedzējus. Tā aptver arī nozīmīgus digitālos pakalpojumu sniedzējus, piemēram, tiešsaistes tirdzniecības vietas, tiešsaistes meklētājprogrammas un sociālo tīklu platformas.

NIS2 Article 20 nosaka kiberdrošību kā vadības institūcijas atbildību. Article 21 prasa piemērotus un samērīgus tehniskos, darbības un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi, drošu izstrādi, drošu uzturēšanu, ievainojamību apstrādi un izpaušanu, efektivitātes izvērtēšanu, kiberdrošības higiēnu, piekļuves kontroli, aktīvu pārvaldību un autentifikāciju. Article 23 izveido pakāpenisku būtisku incidentu paziņošanas procesu, tostarp agrīnu brīdinājumu 24 stundu laikā, paziņojumu 72 stundu laikā un, ja piemērojams, galīgo ziņojumu viena mēneša laikā.

DORA no 2025. gada 17. janvāra izveido tieši piemērojamu digitālās darbības noturības noteikumu kopumu finanšu iestādēm. Tā aptver IKT risku pārvaldību, ziņošanu par būtiskiem IKT incidentiem, darbības noturības testēšanu, kiberdraudu izlūkošanas apmaiņu, IKT trešo pušu riska pārvaldību un kritisku IKT trešo pušu pakalpojumu sniedzēju pārraudzību. Articles 5 un 6 nosaka IKT risku pārvaldību vadības institūcijas pārziņā un prasa dokumentētu, integrētu un regulāri pārskatītu IKT risku pārvaldības ietvaru. Article 8 pastiprina nepieciešamību identificēt IKT atbalstītās biznesa funkcijas, informācijas aktīvus, IKT aktīvus un atkarības. Articles 17 līdz 20 prasa IKT saistītu incidentu atklāšanu, reģistrēšanu, klasifikāciju, eskalāciju, ziņošanu, komunikāciju, trūkumu novēršanu un mācīšanos. Articles 28 līdz 30 prasa kontrolēt IKT trešo pušu risku, izmantojot reģistrus, sākotnējo izpēti, līgumiskos drošības pasākumus, audita tiesības, izstāšanās plānošanu un pārraudzību.

Finanšu iestādēm, uz kurām attiecas DORA, DORA kopumā aizstāj līdzvērtīgus NIS2 riska pārvaldības un ziņošanas pienākumus. Tomēr NIS2 joprojām ir būtiska ekosistēmas koordinācijai un vienībām ārpus DORA darbības jomas. SaaS, MSP un MSSP pakalpojumu sniedzējiem, kas apkalpo finanšu klientus, praktiskā realitāte ir tieša: klienti var pieprasīt jūsu ievainojamību pierādījumus, lai izpildītu savus DORA pienākumus.

GDPR pievieno vēl vienu slāni. Articles 2 un 3 var attiekties uz ES reģistrētām organizācijām un ārpus ES esošām organizācijām, kas piedāvā preces vai pakalpojumus cilvēkiem ES vai uzrauga viņu uzvedību. Article 5 prasa personas datu aizsardzību un pārskatatbildību par atbilstību. Article 4 definē personas datu aizsardzības pārkāpumu kā drošības incidentu, kas izraisa nejaušu vai nelikumīgu personas datu zudumu, iznīcināšanu, izmainīšanu, nesankcionētu izpaušanu vai piekļuvi tiem. Kavēts datubāzes, identitātes platformas vai klientu portāla ielāps var kļūt par privātuma pārskatatbildības jautājumu.

No politikas līdz pierādījumam

Pirmais solis ir noteikumu definēšana. Spēcīga ievainojamību un ielāpu pārvaldības politika nav tikai audita dokuments. Tā ir kontroles pasākuma darbības konstitūcija.

Uzņēmuma vidēs Ievainojamību un ielāpu pārvaldības politika skaidri sasaista tehnisko ielāpošanu ar atbilstību vairākos standartos un regulējumos:

Šī politika atbalsta atbilstību ISO/IEC 27001 Annex A Control 8.8 un ISO/IEC 27002 vadlīnijām un aptver regulatīvās prasības saskaņā ar DORA Article 8, NIS2 Article 21, GDPR Article 32 un COBIT 2019 DSS un APO domēniem.

No sadaļas “Mērķis”.

Tā pati politika nosaka pārvaldības prasības galvenajam pierādījumu artefaktam:

Drošības operāciju komandai jāuztur centralizēts ievainojamību pārvaldības reģistrs, un informācijas drošības vadītājs vai deleģēta pilnvarotā persona to pārskata reizi mēnesī.

No sadaļas “Pārvaldības prasības”, politikas punkts 5.1.

Tā arī definē skenēšanas periodiskumu:

Visas sistēmas jāskenē vismaz reizi mēnesī; augsta riska vai ārēji eksponēti aktīvi jāskenē reizi nedēļā.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

Un tā novērš situāciju, kad steidzama ielāpošana kļūst par nekontrolētu tehnisku darbību:

Visas ievainojamību novēršanas darbības jākoordinē, izmantojot izmaiņu pārvaldības procesu (saskaņā ar P5 — Izmaiņu pārvaldības politika), lai nodrošinātu stabilitāti un audita pēdas saglabāšanu.

No sadaļas “Pārvaldības prasības”, politikas punkts 5.5.

MVU gadījumā tos pašus pierādījumu principus var ieviest vienkāršāk. Ievainojamību un ielāpu pārvaldības politika MVU nosaka:

Uzturēt precīzus ierakstus par piemērotajiem ielāpiem, neatrisinātajām problēmām un izņēmumiem, lai nodrošinātu gatavību auditam

No sadaļas “Mērķi”, politikas punkts 3.4.

Pēc tam tā definē ielāpu žurnālu kā audita pierādījumu:

Ielāpu žurnāls ir jāuztur un jāpārskata auditu un incidentu reaģēšanas darbību laikā

No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.1.

Un tā nosaka minimālo saturu:

Žurnālos jāiekļauj ierīces nosaukums, piemērotais atjauninājums, ielāpošanas datums un jebkuras kavēšanās iemesls

No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.2.

Steidzamai internetam pieejamai ekspozīcijai MVU politika nosaka izmērāmu prasību:

Kritiskie ielāpi jāpiemēro 3 dienu laikā pēc laidiena, īpaši internetam pieejamām sistēmām

No Ievainojamību un ielāpu pārvaldības politika MVU, sadaļa “Politikas ieviešanas prasības”, politikas punkts 6.1.1.

Šie punkti pārvērš tehnisko darbu pierādījumos. Politika nosaka prasības. Reģistrs fiksē konstatējumus. Pieteikums piešķir darbu. Izmaiņu ieraksts kontrolē ieviešanu. Ielāpu žurnāls pierāda darbību. Riska reģistrs fiksē izņēmumus. Pārskatīšanas protokoli pierāda pārraudzību.

Clarysec modelis ar pierādījumiem pirmajā vietā

Clarysec modelis ar pierādījumiem pirmajā vietā sākas ar vienu principu: katram ievainojamības konstatējumam jābūt izsekojamam no atklāšanas līdz lēmumam.

Zenith Blueprint: auditora 30 soļu ceļvedī posmā “Kontroles pasākumi darbībā”, 19. solis: Tehnoloģiskie kontroles pasākumi I, ievainojamību pārvaldība tiek uztverta kā atkārtojams kontroles pasākums, nevis teorētiska prasība:

Ievainojamību pārvaldība ir viena no kritiskākajām mūsdienu kiberdrošības higiēnas jomām. Lai gan ugunsmūri un antivīrusu programmatūra nodrošina aizsardzību, to var vājināt, ja neielāpītas sistēmas vai nepareizi konfigurēti pakalpojumi paliek eksponēti.

Tas pats solis skaidro, ka organizācijām jāizmanto regulāri ielāpu grafiki, ievainojamību skeneri, sākotnējā izvērtēšana, piešķiršana, novēršanas izsekošana, kompensējošie kontroles pasākumi un atlikušā riska pieņemšana. Vissvarīgākais — tas pareizi formulē audita domāšanu:

Kontroles pasākums nav par pilnību; tas ir par organizētu, pārredzamu un pārskatatbildīgu procesu.

Auditoriem šī atšķirība ir būtiska. Nobriedušai organizācijai var būt atvērtas ievainojamības, un tā joprojām var pierādīt kontroli, ja tai ir uz risku balstīta prioritizācija, dokumentētas īpašumtiesības, apstiprināti izņēmumi, kompensējošie kontroles pasākumi un verificēta novēršana.

Zenith Blueprint arī brīdina, ka auditori šo jomu pārbaudīs padziļināti:

Šis ir augstas prioritātes kontroles pasākums auditoriem, un viņi parasti tajā iedziļinās. Sagaidiet jautājumus par to, cik bieži sistēmas tiek ielāpītas, kāds process tiek ievērots, kad tiek paziņota nulltās dienas ievainojamība, un kuras sistēmas ir visgrūtāk ielāpīt.

Tāpēc informācijas drošības vadītājs nedrīkst ierasties auditā tikai ar skenera informācijas paneli. Pierādījumu paketei jāparāda pārvaldība, process, izpilde, verifikācija un uzlabojumi.

ISO 27002 kontroles pasākumu kartēšana ar audita pierādījumiem

Zenith Controls: starpstandartu atbilstības ceļvedis darbojas kā starpstandartu atbilstības kompass, kartējot ISO/IEC 27002:2022 kontroles pasākumus un parādot, kā tie saistīti ar audita gaidām. Ievainojamību un ielāpu pārvaldībā trīs ISO/IEC 27002:2022 kontroles pasākumi veido darbības trijstūri.

ISO/IEC 27002:2022 kontroles pasākums 8.8, tehnisko ievainojamību pārvaldība, ir centrālais kontroles pasākums. Tas ir preventīvs, atbalsta konfidencialitāti, integritāti un pieejamību, ir saskaņots ar kiberdrošības konceptiem Identify un Protect un ir saistīts ar draudu un ievainojamību pārvaldību.

ISO/IEC 27002:2022 kontroles pasākums 8.32, izmaiņu pārvaldība, arī ir preventīvs. Tas sasaista ielāpošanu ar kontrolētu ieviešanu, testēšanu, apstiprināšanu, atcelšanu un auditējamību.

ISO/IEC 27002:2022 kontroles pasākums 5.36, atbilstība informācijas drošības politikām, noteikumiem un standartiem, nodrošina, ka process nav neobligāts un nav atkarīgs no individuālas varonības. Tas sasaista ievainojamību pārvaldību ar politikas atbilstību, apliecinājumu un pārraudzību.

Šis kartējums novērš biežu audita neveiksmi. Drošības komanda saka: “Mēs to ielāpījām.” Operāciju komanda saka: “Mēs to ieviesām.” Atbilstības funkcija saka: “Mēs nevaram pierādīt secību.” Kartēta pierādījumu ķēde visām trim komandām sniedz vienu un to pašu stāstu.

Pierādījumu ķēde, ko sagaida auditori

Aizstāvamai ievainojamību pārvaldības pierādījumu ķēdei ir septiņi posmi.

Praktiskā atšķirība starp “mēs veicam skenējumus” un “mēs esam gatavi auditam” ir nepārtrauktība. Ja ievainojamību nevar izsekot no atklāšanas līdz slēgšanai, kontroles pasākums ir vājš. Ja izņēmumi pastāv, bet neviens tos nav apstiprinājis, process ir vājš. Ja ielāpi apiet izmaiņu pārvaldības procesu, audita pēda ir vāja. Ja kritiskas ievainojamības paliek atvērtas bez kompensējošiem kontroles pasākumiem, pārvaldība ir vāja.

Audita un atbilstības uzraudzības politika atbalsta automatizāciju kā daļu no šī modeļa:

Jāievieš automatizēti rīki, lai uzraudzītu konfigurācijas atbilstību, ievainojamību pārvaldību, ielāpu statusu un privileģētās piekļuves pārvaldību.

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

MVU gadījumā Audita un atbilstības uzraudzības politika MVU definē tehnisko kontroles pasākumu verifikāciju praktiskā veidā:

Tehnisko kontroles pasākumu verifikācija (piemēram, rezerves kopiju statuss, piekļuves kontroles konfigurācija, ielāpu ieraksti)

No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.2.

Mazām organizācijām nav nepieciešami uzņēmuma līmeņa rīki, lai kļūtu gatavas auditam. Tām nepieciešami konsekventi pierādījumi. Vienkāršots reģistrs, pieteikumu panelis, ielāpu žurnāls un ikmēneša pārskatīšana var būt pietiekami, ja tie ir pilnīgi, aktuāli un sasaistīti ar risku.

Piemērs: viens kritisks konstatējums, pilnībā gatavs auditam

Marijas iknedēļas ārējais skenējums identificē CVE-2026-12345 internetam pieejamā maksājumu API vārtejā. Skeneris to novērtē kā kritisku. Pakalpojums apstrādā klientu identitātes un darījumu metadatus, tāpēc iespējamas GDPR un DORA sekas. Vārtejas īpašnieks ir Platformas inženierijas komanda, bet ielāps prasa īsu pārtraukumu.

Tālāk aprakstīta auditam gatava darbplūsma.

1. Izveidot ierakstu ievainojamību reģistrā

Drošības komanda reģistrē konstatējumu centrālajā reģistrā:

• Konstatējuma ID: VULN-2026-0142
• Avots: iknedēļas ārējais skenējums
• Atklāšanas datums un laiks
• Aktīvs: api-gw-prod-01
• Īpašnieks: Platformas inženierija
• Ekspozīcija: internetam pieejams
• Datu konteksts: klientu identitātes un darījumu metadati
• Smaguma pakāpe: kritiska
• SLA: 72 stundas vai stingrāk saskaņā ar politiku
• Pieteikums: SEC-4821
• Izmaiņu ieraksts: CHG-10988
• Statuss: novēršana plānota

2. Veikt sākotnējo izvērtēšanu, izmantojot biznesa un regulatīvo kontekstu

Komanda pārbauda izmantošanas paņēmiena pieejamību, uzbrukuma virsmu, autentifikācijas prasības, biznesa ietekmi un datu sensitivitāti. Tā kā sistēma ir internetam pieejama un atbalsta klientu darbplūsmas, ievainojamība paliek kritiska. Riska īpašnieks ir platformas vadītājs, un informācijas drošības vadītājs tiek informēts iespējamo NIS2, DORA un GDPR seku dēļ.

ISO/IEC 27005:2022 punkti 7.1 līdz 7.4 atbalsta risku identificēšanu, īpašumtiesības, sekas, varbūtību un prioritizāciju. Punkti 8.2 līdz 8.6 atbalsta apstrādes izvēli, kontroles pasākumu noteikšanu, SoA sasaisti, apstrādes plānošanu un atlikušā riska apstiprināšanu.

3. Atvērt kontrolētu ārkārtas izmaiņu

Ielāps tiek ieplānots tajā pašā vakarā. Izmaiņu ierakstā iekļauta piegādātāja atsauce, skartie pakalpojumi, testēšanas plāns, atcelšanas plāns, apkopes logs, klientu komunikācijas lēmums, apstiprinājumi un prasība par validēšanu pēc ieviešanas.

Tas tieši atbalsta ISO/IEC 27002:2022 kontroles pasākumu 8.32 un uzņēmuma politikas prasību koordinēt novēršanu ar izmaiņu pārvaldības procesu.

4. Piemērot ielāpu un atjaunināt ielāpu žurnālu

Ielāpu žurnālā tiek reģistrēts ierīces nosaukums, piemērotais atjauninājums, ielāpošanas datums un kavēšanās iemesls, ja tāds ir. Ja ielāpošana būtu kavējusies, komanda dokumentētu kompensējošos kontroles pasākumus, piemēram, tīmekļa lietojumprogrammu ugunsmūra noteikumus, pagaidu piekļuves ierobežojumus, pastiprinātu žurnālfiksēšanu, izolāciju vai pastiprinātu uzraudzību.

5. Verificēt un slēgt

Drošības komanda atkārtoti skenē API vārteju. Ievainojamība vairs neparādās. Pieteikums tiek atjaunināts ar tīra skenējuma pierādījumiem, ielāpa versiju, ieviešanas laikspiedolu un saiti uz izmaiņu ierakstu. Ievainojamību reģistra statuss tiek mainīts uz “Slēgts, verificēts”.

6. Izvērtēt ziņošanas ietekmi

Ja izmantošana nav notikusi un pakalpojuma darbības traucējumu nav bijis, NIS2 vai DORA incidentu ziņošana var nebūt jāaktivizē. Ja tiek atrasti kompromitācijas indikatori, incidentu procesam jāklasificē ietekme un eskalācija. Saskaņā ar NIS2 būtisks incidents var prasīt agrīnu brīdinājumu un pakāpenisku ziņošanu. Saskaņā ar DORA būtisks ar IKT saistīts incidents prasa klasifikāciju un ziņošanu, izmantojot piemērojamo kompetentās iestādes procesu.

7. Iekļaut gūtās mācības vadības pārskatīšanā

Mēneša beigās informācijas drošības vadītājs pārskatīšanas piezīmēs norāda, ka ievainojamība tika atklāta ar iknedēļas ārējo skenēšanu, novērsta SLA ietvaros, verificēta ar atkārtotu skenēšanu un slēgta bez incidenta. Ja līdzīgas problēmas atkārtojas, riska apstrādes plānā var iekļaut drošas pamatkonfigurācijas, automatizētu ielāpu ieviešanu, piegādātāju eskalāciju vai lietojumprogrammas modernizāciju.

Kad auditors jautā par CVE-2026-12345, Marija var iesniegt sakārtotu paketi, nevis e-pastus un ekrānuzņēmumus.

Tas ir gatavs auditam. Ne tāpēc, ka organizācijai nebija ievainojamību, bet tāpēc, ka tai bija kontrole.

Viens pierādījumu kopums, vairāki pienākumi

Labi izstrādāta ievainojamību un ielāpu pārvaldības programma var izpildīt vairāku ietvaru prasības, nedublējot darbu.

ISO 27001:2022 vajadzībām pierādījumi atbalsta uz risku balstītu ISMS, Annex A kontroles pasākumu ieviešanu, Paziņojumu par piemērojamību, riska apstrādes plānus, iekšējo auditu un nepārtrauktu uzlabošanu. Ja ISO/IEC 27002:2022 kontroles pasākums 8.8 ir piemērojams SoA, organizācijai jāspēj parādīt juridisko, regulatīvo, riska vai biznesa pamatojumu. Šis pamatojums bieži ietver NIS2 Article 21, DORA IKT riska pienākumus, GDPR pārskatatbildību, klientu līgumus un darbības noturības vajadzības.

NIS2 vajadzībām tie paši pierādījumi palīdz pierādīt Article 21 pasākumus, tostarp riska analīzi, ievainojamību apstrādi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, kiberdrošības higiēnu, piekļuves kontroli un efektivitātes izvērtēšanu. Article 20 tiek pierādīts ar informācijas drošības vadītāja pārskatīšanu, ziņošanu valdei, vadības apstiprinājumu un kiberdrošības apmācību. Article 23 kļūst būtisks, ja izmantošana izraisa vai varētu izraisīt būtiskus darbības traucējumus, finansiālus zaudējumus vai kaitējumu citām personām.

DORA vajadzībām ievainojamību un ielāpu pierādījumi atbalsta IKT risku pārvaldības ietvaru, vadības institūcijas pārraudzību, noturības stratēģiju, incidentu atklāšanu un klasifikāciju, noturības testēšanu un IKT trešo pušu pārraudzību. Ja IKT pakalpojumu sniedzējs mitina vai pārvalda skarto sistēmu, Articles 28 līdz 30 prasa sākotnējo izpēti, līgumiskos aizsardzības pasākumus, audita tiesības, palīdzību incidentu gadījumā un izstāšanās apsvērumus.

GDPR vajadzībām tie paši pierādījumi atbalsta Article 5 pārskatatbildību un drošības stāvokli, kas sagaidāms saskaņā ar Article 32. Ja ievainojamība izraisa nesankcionētu piekļuvi personas datiem, to izmaiņas, zudumu vai izpaušanu, ievainojamības laika skala, ielāpu ieraksti, uzraudzības žurnāli un pārkāpuma izvērtēšanas piezīmes kļūst būtiskas.

COBIT 2019 un ISACA tipa apliecinājuma vajadzībām ievainojamību pārvaldība tiek vērtēta caur operacionālo drošību, kontroles uzraudzību, izmaiņu ieviešanu un pārvaldības pārskatatbildību. Zenith Blueprint starpstandartu atbilstības atsaucēs ir izcelti COBIT 2019 DSS05.04 un BAI09.02, kā arī ITAF apliecinājuma gaidas attiecībā uz ievainojamību pārvaldību, ielāpošanu un drošu izmaiņu pārvaldību.

Atbalstošie ISO standarti stiprina darbības modeli. ISO/IEC 27005:2022 atbalsta risku izvērtēšanu un apstrādi. ISO/IEC 27035:2023 atbalsta reaģēšanu uz incidentiem, kad ievainojamības tiek izmantotas. ISO/IEC 30111 atbalsta ievainojamību apstrādes procesus. ISO/IEC 29147 atbalsta ievainojamību izpaušanu un paziņojumus. ISO/IEC 27017 atbalsta ievainojamību pārvaldību mākoņpakalpojumos. ISO 22301 atbalsta nepārtrauktības plānošanu gadījumos, kad tehniskās ievainojamības var traucēt biznesa pakalpojumus.

Kā dažādi auditori pārbauda vienu un to pašu procesu

Dažādi vērtētāji izmanto atšķirīgus skatpunktus. Pierādījumi var būt vieni un tie paši, bet jautājumi mainās.

Politika nosaka, kam jānotiek. Operacionālie pierādījumi parāda, kas faktiski notika. Pārskatīšanas ieraksti parāda, ka vadība zināja, apstrīdēja un rīkojās.

Biežākie iemesli, kāpēc ielāpu pārvaldība neiztur auditu

Lielākā daļa konstatējumu nerodas tāpēc, ka nav skenera. Tie rodas pārrautas izsekojamības dēļ.

Aktīvu uzskaite ir nepilnīga.
Ja skeneris atrod aktīvus, kuru nav CMDB vai aktīvu reģistrā, īpašumtiesības un biznesa ietekmi nevar uzticami izvērtēt. Tas vājina ISO 27001:2022 darbības jomu, risku izvērtēšanu un apstrādi.

Ievainojamības tiek izsekotas tikai skenerī.
Skeneru informācijas paneļi nav pārvaldības reģistri. Tiem bieži trūkst riska īpašnieka apstiprinājuma, izņēmuma pamatojuma, izmaiņu atsauču un biznesa konteksta.

Kritiskiem konstatējumiem nav SLA pierādījumu.
Politikā var būt noteikts, ka kritiskas ievainojamības tiek novērstas trīs dienu laikā. Audita jautājums ir, vai ieraksti pierāda, ka tas notika.

Izņēmumi ir neformāli.
Mantotās sistēmas, dīkstāves ierobežojumi un piegādātāju kavēšanās notiek. Taču “mēs nevarējām to ielāpīt” jāpārvērš par dokumentētu izņēmumu ar kompensējošiem kontroles pasākumiem, derīguma termiņu un atlikušā riska apstiprinājumu.

Ārkārtas ielāpošana apiet izmaiņu pārvaldības procesu.
Ārkārtas izmaiņas joprojām ir izmaiņas. Ja nav apstiprinājuma, testēšanas vai atcelšanas pierādījumu, auditori var secināt, ka novēršana radīja darbības risku.

Trešo pušu sistēmas nav redzamas.
Saskaņā ar NIS2 un DORA piegādātāju un IKT trešo pušu risks ir centrāls. Ja pakalpojumu sniedzējs ielāpo platformu, jums joprojām nepieciešami pierādījumi, līgumiskās tiesības, pakalpojumu ziņošana un eskalācijas ceļi.

Neviens nepārskata tendences.
Atkārtotas ievainojamības var liecināt par vāju konfigurāciju pārvaldību, nepietiekamām drošas izstrādes praksēm, neatbalstītiem aktīviem vai piegādātāja neveiksmi. Ikmēneša pārskatīšana pārvērš tehniskos datus pārvaldības darbībā.

Clarysec ievainojamību audita pakete

Gatavojoties ISO 27001:2022, NIS2 vai DORA gatavības pārskatīšanai, Clarysec palīdz organizācijām sagatavot ievainojamību un ielāpu pārvaldības audita paketi, kas ietver:

• Ievainojamību un ielāpu pārvaldības politiku, tostarp darbības jomu, lomas, skenēšanas periodiskumu, ielāpu SLA un izņēmumu noteikumus
• Aktīvu uzskaites izvilkumu, kas parāda piemērošanas jomā esošās sistēmas, īpašniekus, kritiskumu un ekspozīciju
• Jaunākos iekšējo un ārējo ievainojamību skenēšanas pārskatus
• Centrālo ievainojamību pārvaldības reģistru ar atvērtajiem, slēgtajiem un izņēmumu ierakstiem
• Ielāpu žurnālus, kas parāda ierīci, atjauninājumu, ielāpa datumu un kavēšanās iemeslus
• Izmaiņu ierakstus atlasītām kritiskām un augsta riska ievainojamībām
• Pierādījumus par atkārtotu skenēšanu vai validāciju pēc ievainojamību novēršanas
• Izņēmumu un atlikušā riska apstiprinājumus kavētām vai neielāpojamām sistēmām
• Drošības paziņojumu uzraudzības procesu piegādātājiem, bibliotēkām un mākoņpakalpojumiem
• Ikmēneša informācijas drošības vadītāja vai vadības pārskatīšanas protokolus
• Kartējumu uz ISO 27001:2022, NIS2, DORA, GDPR un COBIT 2019 pienākumiem
• Iekšējā audita vai tehnisko kontroles pasākumu verifikācijas rezultātus

Zenith Blueprint posmā “Audits, pārskatīšana un uzlabošana”, 24. solī, Clarysec uzsver izsekojamību starp Paziņojumu par piemērojamību, riska reģistru un riska apstrādes plānu:

Jūsu SoA jābūt saskaņotam ar jūsu Riska reģistru un Risku apstrādes plānu. Vēlreiz pārbaudiet, vai katrs kontroles pasākums, ko izvēlējāties kā riska apstrādi, SoA ir atzīmēts kā “Piemērojams”.

Tas ir īpaši svarīgi ievainojamību pārvaldībā. Ja kontroles pasākums 8.8 ir piemērojams, audita paketei jāpierāda ne tikai tas, ka skenēšana notiek, bet arī tas, ka konstatējumi tiek pārvaldīti, izmantojot riska apstrādi un nepārtrauktu uzlabošanu.

30 dienu gatavības sprints

Ja audits ir tuvu, nesāciet ar visa pārrakstīšanu. Sāciet ar ātru pierādījumu izveidi.

Šis sprints nenovērsīs visu tehnisko parādu. Tas mainīs audita sarunu. Tā vietā, lai aizstāvētu nekārtīgu skenera eksportu, jūs varat parādīt pārvaldītu procesu ar īpašniekiem, termiņiem, darbībām, lēmumiem un pārraudzību.

Pārejiet no skenējumiem uz aizstāvamiem pierādījumiem

Gatavība auditam ievainojamību un ielāpu pārvaldībā nav par to, lai pierādītu, ka jums nav ievainojamību. Tā ir par to, lai pierādītu, ka jūs varat tās atrast, izprast, prioritizēt, novērst, kontrolēt izņēmumus un pierādīt pārraudzību.

Clarysec Zenith Blueprint, Zenith Controls, Ievainojamību un ielāpu pārvaldības politika, Ievainojamību un ielāpu pārvaldības politika MVU, Audita un atbilstības uzraudzības politika un Audita un atbilstības uzraudzības politika MVU nodrošina struktūru šādas pierādījumu darbplūsmas izveidei.

Ja jūsu organizācija gatavojas ISO 27001:2022 sertifikācijai, NIS2 gatavībai, DORA digitālajai darbības noturībai, klientu sākotnējai izpētei vai iekšējam auditam, sāciet ar vienu jautājumu:

Vai katru kritisku ievainojamību var izsekot no skenējuma līdz slēgšanai?

Ja atbilde ir nē, Clarysec var palīdzēt izveidot reģistru, politiku kopumu, starpstandartu atbilstības kartējumu, vadības pārskatīšanas paketi un auditam gatavu pierādījumu darbplūsmu, kas tehnisko skenēšanu pārvērš aizstāvamā pārvaldībā.