CVD NIS2 ja DORA kontekstis: ISO 27001 tõendusmaterjali kaart

Teisipäeval kell 08.17 saabub turbe postkasti sõltumatu uurija sõnum. Teemarida on rahulik, peaaegu viisakas: „Võimalik konto ülevõtmine teie kliendiportaalis.“ Sisu on märksa ebamugavam. Uurija väidab, et teie SaaS-rakenduse aheldatud haavatavus võimaldab ühel rentnikul pääseda ligi teise rentniku arvekirjetele. Lisatud on kontseptsioonitõendus, mis on krüpteeritud teie avaldatud PGP-võtmega.

Maria, FinanTechSaaS-i uue infoturbejuhi jaoks ei saaks ajastus olla halvem. Tema ettevõte on äsja sõlminud suure lepingu juhtiva ELi pangaga. Kliendi hoolsuskontrolli meeskond on juba küsinud „koordineeritud haavatavuste avalikustamise poliitikat“ ja tõendusmaterjali selle rakendamise kohta, viidates sõnaselgelt NIS2-le ja DORA-le. Ettevõttel on security@ e-posti aadress, kuid seda jälgib üks arendaja. Puudub ametlik vastuvõturegister, määratletud valideerimise SLA, juhtkonna eskaleerimistee ja auditijälg.

Korraga käivitub kolm kella.

Esimene kell on operatiivne. Kas haavatavus on tegelik? Kas seda saab tootmiskeskkonnas ära kasutada? Kas keegi kuritarvitab seda aktiivselt?

Teine kell on regulatiivne. Kui kliendiandmed on avalikustunud, algab GDPR-i rikkumise hindamine. Kui NIS2 alusel olulise või tähtsa üksuse teenuse osutamine on mõjutatud, võivad rakenduda intsidendist teavitamise künnised. Kui ettevõte on finantsüksus või finantsteenuseid toetav IKT-teenuseosutaja, võivad asjakohaseks muutuda DORA intsidendihalduse, klassifitseerimise, eskaleerimise ja kliendisuhtluse nõuded.

Kolmas kell on tõenduslik. Kuus kuud hiljem võib ISO/IEC 27001:2022 audiitor, finantssektori järelevalveasutus, kliendi kindlustandmise meeskond või siseauditi komitee küsida: „Näidake, kuidas seda haavatavust käsitleti.“

Just selle küsimuse juures avastavad paljud organisatsioonid, et koordineeritud haavatavuste avalikustamine ei ole pelgalt turbe postkast. See on juhtimissüsteemi protsess. See vajab poliitika omanikku, avalikku teavituskanalit, triaaži töövoogu, parandusmeetmete SLA-sid, tarnijate eskaleerimist, intsidendi otsustusloogikat, andmekaitsealast ülevaatust, juhtkonna aruandlust ja kaitstavat tõendusmaterjali.

Clarysec käsitleb CVD-d integreeritud kontrollimustrina, mitte eraldiseisva postkastina. Materjalis Zenith Blueprint: audiitori 30-sammuline teekaart Zenith Blueprint paikneb haavatavuste käsitlemine etapis „Kontrollimeetmed praktikas“, samm 19: „Tehnilised kontrollimeetmed I“, kus suunis on selge: organisatsioonid ei tohi haavatavuste leide passiivselt arhiveerida, vaid peavad neid triaažima, määrama vastutajale ja jälgima kuni sulgemiseni. Sama standard kehtib väliste avalikustamiste kohta. Kui keegi ütleb teile, kuidas teie teenus võib ebaõnnestuda, on tegelik küsimus: kas suudate tõendada, et võtsite teate vastu, hindasite seda, prioriseerisite, kõrvaldasite puuduse, suhtlesite asjaosalistega ja õppisite juhtumist?

Miks CVD on NIS2 ja DORA alusel nüüd juhatuse tasandi küsimus

Aastaid kutsusid turbeteadlikud organisatsioonid eetilisi häkkereid haavatavustest teatama, sest see oli hea tava. NIS2 ja DORA alusel on see tava muutunud reguleeritud digitaalse vastupidavuse osaks.

NIS2 kohaldub paljudele keskmise suurusega ja suurematele üksustele kõrgkriitilistes ja muudes kriitilistes sektorites, sealhulgas digitaristu pakkujatele, pilveteenuse osutajatele, andmekeskusteenuse osutajatele, hallatud teenuse osutajatele, hallatud turbeteenuse osutajatele ning teatud digiteenuse osutajatele, nagu veebiturud, otsingumootorid ja sotsiaalvõrgustiku platvormid. Samuti võib see kohalduda suurusest sõltumata sellistele kategooriatele nagu usaldusteenuse osutajad, DNS-teenuse osutajad, TLD-registrid ning avalike elektrooniliste sidevõrkude või -teenuste osutajad.

NIS2 Article 21 nõuab, et olulised ja tähtsad üksused rakendaksid kõiki ohte hõlmava lähenemisviisi alusel asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi küberturvalisuse riskijuhtimise meetmeid. Üks miinimumvaldkondi on võrgu- ja infosüsteemide hankimise, arendamise ja hoolduse turvalisus, sealhulgas haavatavuste käsitlemine ja avalikustamine. Sama baastase hõlmab ka intsidentide käsitlemist, tarneahela turvet, talitluspidevust, juurdepääsukontrolli, varahaldust, koolitust, krüptograafiat ning protseduure kontrollimeetmete tõhususe hindamiseks.

NIS2 Article 20 muudab selgesõnaliseks ka juhtkonna vastutuse. Juhtorganid peavad küberturvalisuse riskijuhtimise meetmed heaks kiitma, jälgima nende rakendamist ja läbima koolituse. CVD programmi puhul tähendab see, et juhatus või kõrgem juhtkond peab mõistma teavituskanalit, haavatavustele reageerimise meeskonda, valideerimistähtaegu, parandusmeetmete ootusi, tarnijasõltuvusi ja intsidendist teavitamise päästikuid.

DORA loob alates 17. jaanuarist 2025 finantsüksustele sektoripõhise korra. See hõlmab IKT-riski juhtimist, IKT-ga seotud intsidentidest teavitamist, digitaalse operatsioonilise toimepidevuse testimist, teabe jagamist, IKT kolmanda osapoole riski, lepingulisi nõudeid, kriitiliste IKT kolmandatest osapooltest teenuseosutajate järelevalvet ja järelevalvealast koostööd. DORA-ga hõlmatud finantsüksuste puhul on DORA-l IKT-riski juhtimise ja intsidentidest teavitamise osas üldjuhul NIS2 ees eelis, sest tegemist on sektoripõhise liidu õigusaktiga. Praktiline nõue jääb siiski samaks: finantsüksused ja neid teenindavad IKT-teenuseosutajad peavad kasutama struktureeritud, dokumenteeritud ja testitavat protsessi IKT nõrkuste tuvastamiseks, analüüsimiseks, klassifitseerimiseks, eskaleerimiseks, parandamiseks ja neist õppimiseks.

Haavatavuse teade võib alata tehnilise leiuna, muutuda turbesündmuseks, eskaleeruda intsidendiks, käivitada GDPR-i isikuandmetega seotud rikkumise hindamise, nõuda tarnija tegevust ning hiljem kajastuda ISO/IEC 27001:2022 kohaldatavusdeklaratsioonis. Seetõttu tuleb CVD kujundada ühtse toimemudelina, mis hõlmab turvet, vastavust, arendust, õigust, andmekaitset, hankeid ja juhtimist.

ISO 27001 alus: avalikustamisest ISMS-i tõendusmaterjalini

ISO/IEC 27001:2022 annab infoturbejuhtidele ja vastavusjuhtidele juhtimissüsteemi, mis muudab CVD auditeeritavaks.

Punktid 4.1 kuni 4.4 nõuavad, et organisatsioon mõistaks sisemisi ja väliseid teemasid, huvitatud poolte nõudeid, ISMS-i piire ning sõltuvusi teistest organisatsioonidest. Siin jõuavad ISMS-i NIS2, DORA, GDPR, kliendilepingud, tarnijate kohustused ja haavatavuste avalikustamise lubadused.

Punktid 5.1 kuni 5.3 loovad juhtkonna vastutuse. Tippjuhtkond peab viima infoturbe kooskõlla strateegilise suunaga, tagama ressursid, määrama vastutused ja tagama, et ISMS saavutab kavandatud tulemused. CVD puhul tähendab see haavatavustele reageerimise meeskonna määramist, jääkriski aktsepteerimise volituse määratlemist ja suure mõjuga haavatavuste eskaleerimist juhtkonnale.

Punktid 6.1.1 kuni 6.1.3 annavad riskimootori. Organisatsioon peab määratlema riskikriteeriumid, hindama infoturberiske, määrama riskiomanikud, valima riskikäsitluse võimalused, võrdlema kontrollimeetmeid lisaga A, koostama kohaldatavusdeklaratsiooni ja saama jääkriskile heakskiidu. Seejärel nõuavad punktid 8.1 kuni 8.3 tegevuse ohjet, kavandatud muudatusi, väljastpoolt pakutavate protsesside ohjet, riskihindamisi kavandatud ajavahemike järel või pärast olulisi muudatusi ning tõendusmaterjali riskikäsitluse tulemuste kohta.

Materjalis Zenith Blueprint, riskijuhtimise etapis, sammus 13 kirjeldatakse kohaldatavusdeklaratsiooni enamana kui vastavustabelit:

„SoA on tegelikult silladokument: see seob teie riskihindamise/-käsitluse tegelike kontrollimeetmetega, mis teil olemas on.“
Allikas: Zenith Blueprint: audiitori 30-sammuline teekaart, riskijuhtimise etapp, samm 13: riskikäsitluse planeerimine ja kohaldatavusdeklaratsioon (SoA) Zenith Blueprint

Koordineeritud haavatavuste avalikustamise puhul peab SoA ühendama regulatiivsed kohustused, äririski, lisa A kontrollimeetmed, poliitikaklauslid ja operatiivse tõendusmaterjali.

Eesmärk ei ole luua paralleelseid vastavussilosid. CVD-poliitika peab olema ohjatud ISMS-i protsess, mis toetab samaaegselt ISO/IEC 27001:2022 sertifitseerimist, NIS2 vastavust, DORA valmisolekut, klientidele kindlustunde andmist ja turbeoperatsioone.

Poliitika baastase: mida teie CVD-poliitika peab ütlema

Esimene nähtav kontrollimeede on avalik avalikustamiskanal. Uurijad, kliendid, tarnijad ja partnerid peavad teadma, kuhu haavatavustest teatada ja kuidas kaitsta tundlikku tõendusmaterjali.

Claryseci Koordineeritud haavatavuste avalikustamise poliitika Koordineeritud haavatavuste avalikustamise poliitika annab ettevõtte baastaseme:

„Avalikud avalikustamiskanalid: organisatsioon peab hoidma selget kanalit haavatavustest teatamiseks, näiteks spetsiaalset turbekontakti e-posti aadressi (näiteks security@company.com) või veebivormi. See teave tuleb avaldada ettevõtte veebilehe turbelehel koos organisatsiooni PGP avaliku võtmega, et võimaldada krüpteeritud esitamist.“
Allikas: Koordineeritud haavatavuste avalikustamise poliitika, rakendusnõuded, punkt 6.1

See punkt lahendab levinud auditileiu. Paljud organisatsioonid väidavad, et nad võtavad teateid vastu, kuid teavitustee on varjatud, krüpteerimata või vale meeskonna vastutusalas. Küps kanal on avalik, turvaline, seiratud ja määratud vastutavale funktsioonile.

Järgmine kontrollimeede on reageerimisdistsipliin. Kriitiline teade, millele järgneb vaikus, loob avalikustamisriski, mainekahju ja ärakasutamisriski. Koordineeritud haavatavuste avalikustamise poliitika seab konkreetse kinnitamise ja valideerimise ootuse:

„Triaaž ja kinnitus: teate saamisel peab VRT selle registreerima ja saatma teatajatele kinnituse 2 tööpäeva jooksul, määrates jälgimisviite. VRT peab tegema esialgse tõsiduse hindamise, näiteks kasutades CVSS-skoorimist, ning valideerima probleemi, vajaduse korral IT- ja arendusmeeskondade toel, sihttähtajaga 5 tööpäeva. Kriitilisi haavatavusi, näiteks neid, mis võimaldavad kaugkoodi käivitamist või olulist andmekaitserikkumist, tuleb käsitleda kiirendatud korras.“
Allikas: Koordineeritud haavatavuste avalikustamise poliitika, rakendusnõuded, punkt 6.4

See sõnastus loob kohesed tõenduspunktid: kättesaamise aeg, kinnitamise aeg, jälgimisviide, esialgne tõsidus, valideerimise tulemus ja kiirendatud käsitlemise otsus.

VKE-de puhul kasutab Clarysec sama loogikat proportsionaalse rakendamisega. Rakendusturbe nõuete poliitika VKE-dele Rakendusturbe nõuete poliitika - VKE nõuab organisatsioonidelt järgmist:

„määrata haavatavuste avalikustamise, reageerimisaegade ja paikamise kohustused.“
Allikas: Rakendusturbe nõuete poliitika VKE-dele, juhtimisnõuded, punkt 5.3.2

Vastutuse kandmiseks ei ole vaja suurt tooteturbe meeskonda. Vaja on selgesõnalisi kohustusi, realistlikke tähtaegu, nimetatud omanikke ja tõendusmaterjali, et protsess toimib.

CVD vastuvõtu töövoog: uurija e-kirjast otsustuskirjeni

Hea vastuvõtu töövoog on piisavalt lihtne, et töötada surve all, ja piisavalt täielik, et rahuldada audiitorit. See peab algama spetsiaalse kanaliga, nagu security@[company], veebivorm või avaldatud security.txt fail. Esitamistee peab võimaldama krüpteeritud tõendusmaterjali, mõjutatud toodet või lõpp-punkti, taasesitamise samme, teataja kontaktandmeid, eelistatud avalikustamise ajastust ning viiteid andmete avalikustumisele või aktiivsele ärakasutamisele.

Pärast teate saamist peab haavatavustele reageerimise meeskond looma kirje GRC-tööriistas, piletihaldussüsteemis, haavatavuste halduse süsteemis või ohjatud registris. Tööriist on vähem oluline kui järjepidevus ja tõendusmaterjali kvaliteet.

Seejärel peab töövoog läbima seitse operatiivset sammu.

1. Vastuvõtt: teade saadakse avaliku kanali kaudu ja logitakse automaatselt või käsitsi.
2. Kinnitus: VRT vastab 2 tööpäeva jooksul ja määrab jälgimisviite.
3. Valideerimine: tehniline meeskond taasesitab probleemi, kinnitab mõjutatud süsteemid ja teeb esialgse tõsiduse skoorimise.
4. Sündmuse hindamine: VRT otsustab, kas haavatavus on üksnes nõrkus, infoturbe sündmus või intsident.
5. Eskaleerimine: kõrge või kriitilise tõsidusega probleemid edastatakse vajaduse korral süsteemiomanikele, infoturbejuhile, andmekaitse-, õigus- ja tarnijafunktsioonidele ning juhtkonnale.
6. Parandus: vastutav meeskond rakendab paranduse, leevenduse, kompenseeriva kontrollimeetme või ajutise piirangu.
7. Sulgemine: VRT kontrollib parandust, suhtleb teatajaga, ajakohastab tõendusfaili ja registreerib õppetunnid.

Clarysec kaardistab selle operatiivse sammu ISO/IEC 27002:2022 kontrollimeetmega A.5.25, infoturbe sündmuste hindamine ja otsustamine, ning kontrollimeetmega A.8.8, tehniliste haavatavuste haldus, materjali Zenith Controls: vastavusteülene juhend Zenith Controls kaudu. A.5.25 puhul selgitab Zenith Controls, et sündmuse hindamine on triaažifunktsioon töötlemata seireteavituste ja formaalse intsidendikäsitluse vahel, kasutades logisid, lävendeid ja otsustuskriteeriume eskaleerimise määramiseks. A.8.8 puhul seob Zenith Controls tehniliste haavatavuste halduse pahavaratõrje, konfiguratsioonihalduse, muudatuste juhtimise, lõppseadmete turbe, ohuteabe, seire, turvalise arenduse, sündmuste hindamise ja intsidentidele reageerimisega.

Üks Zenith Controls lõik on eriti kasulik aktiivse ärakasutamise kahtluse korral:

„Ohuteave näitab, milliseid haavatavusi aktiivselt ära kasutatakse, suunates paikamise prioriseerimist.“
Allikas: Zenith Controls: vastavusteülene juhend, ISO/IEC 27002:2022 kontrollimeede 8.8, seos kontrollimeetmega 5.7 Ohuteave Zenith Controls

See on oluline juhtimispunkt. Tõsidus ei ole ainult CVSS. Teie sektori vastu aktiivselt ära kasutatav keskmise skooriga haavatavus võib olla olulisem kui teoreetiline kriitiline probleem mitteavalikus testisüsteemis.

Millal haavatavusest saab intsident

Mitte iga haavatavuse teade ei ole intsident. Puuduv turvapäis vahekeskkonnas ei ole sama mis ära kasutatud autoriseerimisest möödahiilimine, mis avalikustab klientide arveid. Kuid iga usaldusväärne haavatavuse teade peab läbima intsidendi otsustusvärava.

NIS2 Article 23 nõuab, et olulised ja tähtsad üksused teavitaksid oma CSIRT-i või pädevat asutust põhjendamatu viivituseta intsidentidest, mis mõjutavad oluliselt teenuse osutamist. Oluline intsident on selline, mis on põhjustanud või võib põhjustada tõsise tegevushäire või rahalise kahju või mis on mõjutanud või võib mõjutada teisi, põhjustades märkimisväärset materiaalset või mittemateriaalset kahju. Teavitamise järjestus hõlmab varajast hoiatust 24 tunni jooksul teadlikuks saamisest, intsidenditeavitust 72 tunni jooksul, vahearuandeid nõudmisel ja lõpparuannet ühe kuu jooksul pärast 72-tunnist teavitust.

DORA Articles 17 to 20 nõuavad, et finantsüksused tuvastaksid, haldaksid, registreeriksid, klassifitseeriksid, eskaleeriksid, teavitaksid ja suhtleksid IKT-ga seotud intsidentide ja oluliste küberohtude kohta. Olulised IKT-ga seotud intsidendid tuleb eskaleerida kõrgemale juhtkonnale ja juhtorganile. Kliendisuhtlus võib olla nõutav, kui mõjutatud on finantshuvid.

VKE-de puhul peab teavituskultuur olema sama selge. Claryseci Intsidentidele reageerimise poliitika VKE-dele Intsidentidele reageerimise poliitika - VKE sätestab:

„Personal peab teatama igast kahtlasest tegevusest või kinnitatud intsidendist aadressile incident@[company] või suuliselt tegevjuhile või IT-teenuseosutajale.“
Allikas: Intsidentidele reageerimise poliitika VKE-dele, poliitika rakendusnõuded, punkt 6.2.1

Materjalis Zenith Blueprint, etapis „Kontrollimeetmed praktikas“, samm 16: inimressursside kontrollid II, on põhimõte veel lihtsam:

„Kahtluse korral teata.“
Allikas: Zenith Blueprint: audiitori 30-sammuline teekaart, etapp „Kontrollimeetmed praktikas“, samm 16: inimressursside kontrollid II (A.6.5 kuni A.6.8)

See fraas peab kehtima arendajatele, tugimeeskondadele, tarnijajuhtidele, andmekaitse eest vastutajatele, tippjuhtidele ja allhanketeenuse osutajatele. Haavatavus, mis võib mõjutada konfidentsiaalsust, terviklust, käideldavust, kliendi usaldust, regulatiivset teavitamist või finantstegevust, tuleb registreerida ja hinnata, mitte käsitleda mitteametlikult vestluses.

Parandusmeetmed, paikamine ja kompenseerivad kontrollimeetmed

Kui haavatavus on valideeritud, tuleb seda käsitleda. Käsitlus peab olema riskipõhine, tõendusmaterjaliga toetatud ja ajaliselt piiritletud.

Koordineeritud haavatavuste avalikustamise poliitika seab ettevõtte ootuse:

„Parandusmeetmete plaan: kõigi kinnitatud haavatavuste kohta tuleb koostada parandamise või leevendamise plaan. Paranduse rakendamine tuleb prioriseerida tõsiduse alusel. Näiteks kriitilised haavatavused tuleb võimaluse korral parandada või leevendada 14 päeva jooksul või aktiivse ärakasutamise tuvastamisel kiiremini, samas kui madalama tõsidusega probleemid tuleb lahendada mõistliku aja jooksul. Kui täielik parandus viibib, tuleb rakendada kompenseerivad kontrollimeetmed või ajutised leevendusmeetmed, näiteks haavatava funktsionaalsuse keelamine või seire suurendamine.“
Allikas: Koordineeritud haavatavuste avalikustamise poliitika, rakendusnõuded, punkt 6.6

VKE-de paikamisdistsipliini kohta sätestab Haavatavuste ja paikade halduse poliitika VKE-dele Haavatavuste ja paikade halduse poliitika - VKE:

„Kriitilised paigad tuleb rakendada 3 päeva jooksul pärast väljalaskmist, eriti internetile avatud süsteemide puhul“
Allikas: Haavatavuste ja paikade halduse poliitika VKE-dele, poliitika rakendusnõuded, punkt 6.1.1

Need tähtajad ei ole vastuolus. Tarnija paik internetile avatud süsteemi jaoks võib vajada väga kiiret juurutamist. Tootehaavatavus, mis nõuab koodimuudatusi, regressioonitestimist, kliendikoordineerimist ja etapiviisilist väljalaset, võib vajada parandusmeetmete plaani koos vahepealsete leevendustega. Oluline on, et otsus oleks dokumenteeritud, riskiomaniku vastutusalas ja jääkriski korral heaks kiidetud.

Praktiline juhtumivoog näeb välja järgmine:

1. Uurija teatab autoriseerimisest möödahiilimisest kliendi arvelduse API-s.
2. VRT logib CVD-2026-014 koos ajatempliga ja saadab kinnituse 2 tööpäeva jooksul.
3. Tooteturbe meeskond valideerib vea 24 tunni jooksul ja määrab tõsiduseks kõrge, sest võimalik on rentnikevaheline juurdepääs andmetele.
4. Andmekaitsefunktsioon teeb GDPR-i rikkumise hindamise, sest arvekirjed võivad sisaldada isikuandmeid.
5. Intsidendihaldur avab sündmuse hindamise ISO/IEC 27002:2022 kontrollimeetme A.5.25 alusel.
6. Süsteemiomanik keelab haavatava lõpp-punkti ajutise funktsioonilipuga.
7. Arendus loob kuumparanduse ISO/IEC 27002:2022 kontrollimeetme A.8.32, muudatuste juhtimine, alusel.
8. Lisatakse seirereeglid ärakasutamise indikaatorite jaoks, mis seotakse A.8.15, logimine, ja A.8.16, seiretegevused, kontrollimeetmetega.
9. Infoturbejuht teavitab kõrgemat juhtkonda, sest probleem on kõrge riskiga.
10. VRT koordineerib uurijaga kordustestimist ja avalikustamise ajastust.
11. Riskiomanik kiidab sulgemise heaks alles pärast verifitseerimistestimist ja kliendimõju ülevaatust.
12. SoA, riskiregister, pilet, logid, juhtkonna teavitus ja õppetunnid ajakohastatakse.

See on erinevus väidete „me paikasime selle“ ja „me suudame tõendada, et juhtisime seda“ vahel.

Tarnija- ja pilvesõltuvused: varjatud tõrkepunkt

Paljud CVD tõrked on tegelikult varjatud tarnijatõrked. Haavatavus võib mõjutada SaaS-komponenti, pilveteenust, hallatud turbeteenuse osutajat, makselüüsi, autentimisvahendajat, avatud lähtekoodiga teeki, allhankearenduse meeskonda või alltöövõtjat.

NIS2 Article 21 nõuab tarneahela turvet, sealhulgas suhteid otseste tarnijate ja teenuseosutajatega. Tarneahela meetmed peavad arvestama tarnijate haavatavusi, tootekvaliteeti, küberturvalisuse praktikaid ja turvalise arenduse protseduure.

DORA Articles 28 to 30 lähevad finantsüksuste puhul sügavamale. Need nõuavad, et IKT kolmanda osapoole riski juhitaks IKT-riskiraamistiku osana, koos IKT-teenuslepingute registritega, kriitiliste või oluliste funktsioonide eristustega, lepingueelse hoolsuskontrolliga, lepinguliste turvanõuetega, intsidendiabiga, koostööga asutustega, auditeerimisõigustega, lõpetamisõigustega ja väljumisstrateegiatega. Finantsüksused jäävad DORA vastavuse eest täielikult vastutavaks ka IKT kolmandatest osapooltest teenuseosutajate kasutamisel.

Claryseci Kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele Kolmandate osapoolte ja tarnijate turbepoliitika - VKE sisaldab lihtsat eskaleerimisreeglit:

„Peab viivitamata teavitama tegevjuhti igast turberikkumisest, muudatusest või intsidendist“
Allikas: Kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele, rollid ja vastutused, punkt 4.4.3

Ettevõtte tarnijalepingute puhul soovitab Zenith Blueprint, etapis „Kontrollimeetmed praktikas“, samm 23, lisada konfidentsiaalsuskohustused, juurdepääsukontrolli vastutused, tehnilised ja korralduslikud meetmed, intsidentidest teavitamise tähtajad, auditeerimisõigus, alltöövõtjate kontrollimeetmed ja lepingu lõppemise sätted. See ütleb:

„Oluline on, et need oleksid olemas ning mõlemad pooled mõistaksid ja aktsepteeriksid neid.“
Allikas: Zenith Blueprint: audiitori 30-sammuline teekaart, etapp „Kontrollimeetmed praktikas“, samm 23: organisatsioonilised kontrollimeetmed (5.19 kuni 5.37)

CVD tarnijavalmidus peab vastama järgmistele küsimustele:

• Kas tarnija avaldab haavatavustest teatamise kanali?
• Kas haavatavustest teavitamise tähtajad on lepingus määratletud?
• Kas kriitilistest tarnijahaavatavustest teatatakse põhjendamatu viivituseta?
• Kas kliendimõjuga nõrkused on seotud intsidendiabi kohustustega?
• Kas tarnija saab esitada parandusmeetmete tõendusmaterjali või turvateateid?
• Kas alltöövõtjate haavatavustega seotud kohustused kantakse edasi?
• Kas ebapiisava paranduse korral on olemas väljumisstrateegia?

Siin koonduvad NIS2, DORA ja ISO/IEC 27001:2022. Tarnija haavatavuste haldus ei ole hanke kontrollkast. See on osa talitluspidevusest.

Tõendusmaterjali kaardistamine ISO 27001, NIS2, DORA, GDPR ja COBIT jaoks

Tugevaimad CVD programmid on tõendusmaterjalist lähtuvad. Need eeldavad, et iga olulist teadet võivad hiljem läbi vaadata siseaudit, sertifitseerimisaudiitorid, regulaatorid, kliendid, kindlustusandjad või juhatuse riskikomitee.

Claryseci Auditi ja vastavuse seire poliitika VKE-dele Auditi ja vastavuse seire poliitika - VKE tabab detaili, mille paljud meeskonnad tähelepanuta jätavad:

„Metaandmed (nt kes selle kogus, millal ja millisest süsteemist) tuleb dokumenteerida.“
Allikas: Auditi ja vastavuse seire poliitika VKE-dele, poliitika rakendusnõuded, punkt 6.2.3

Paigatud serveri ekraanitõmmis on nõrk tõendusmaterjal, kui keegi ei tea, kes selle jäädvustas, millal, millisest süsteemist ja kuidas see haavatavusega seostub. Pilet koos ajatemplite, skanneri väljundi, pull request’i, muudatuse heakskiidu, juurutuslogide, seirepäringu, kordustestimise kinnituse ja metaandmetega on palju tugevam.

Üksikasjalikum jälgitavusmaatriks aitab kliendi hoolsuskontrolli ja siseauditi ajal.

Erinevad audiitorid testivad sama protsessi eri vaatenurkadest.

ISO/IEC 27001:2022 audiitor alustab ISMS-ist. Ta küsib, kas haavatavuste avalikustamise kohustused sisalduvad huvitatud poolte nõuetes, kas riske hinnatakse järjepidevalt, kas kontrollimeetmed kajastuvad SoA-s, kas tegevust tõendav materjal on olemas ja kas juhtkond vaatab läbi trendid ning tähtaja ületanud tegevused.

DORA või finantsteenuste ülevaataja keskendub operatsioonilisele toimepidevusele. Ta uurib IKT-riski integreerimist, intsidendi klassifitseerimist, kõrgemale juhtkonnale eskaleerimist, kliendisuhtlust, kolmandate osapoolte sõltuvusi, testimist ja õppetunde. Kui haavatavus mõjutab kriitilist või olulist funktsiooni, eeldatakse tihedat seost tehnilise pileti, ärimõju, talitluspidevuse mõjude ja tarnijakohustuste vahel.

GDPR-i ülevaataja keskendub isikuandmetele. Kas isikuandmed olid kaasatud? Kas esines loata juurdepääs, kaotsiminek, muutmine või avalikustamine? Kas vastutava töötleja ja volitatud töötleja rollid olid selged? Kas rikkumise künnist hinnati? Kas kaitsemeetmed, nagu krüptimine, juurdepääsukontroll, logimine ja andmete minimaalsus, olid asjakohased?

COBIT 2019 või ISACA audiitor keskendub valitsemisele, vastutusele, toimivusele ja kindlusele. Ta otsib määratletud omanikku, mõõdikuid, eskaleerimist, kontrollieesmärke, juhtkonna järelevalvet ja erandite jälgimist. Tähtaja ületanud kriitiline haavatavus ei ole ainult tehniline probleem. See on juhtimisprobleem, kui seda ei ole formaalselt eskaleeritud ja riskina aktsepteeritud.

NIST-põhise hindaja mõtleb kategooriates Identify, Protect, Detect, Respond ja Recover. Ta soovib näha vara omanikku, haavatavuse tuvastamist, prioriseerimist, kaitsvat muudatust, ärakasutamise tuvastust, reageerimise koordineerimist ja taastamise valideerimist.

Integreeritud CVD mudeli eelis on see, et sama tõendusmaterjali selgroog saab toetada kõiki neid ülevaatusi.

Igakuine kontrollitsükkel: mõõdikud juhtkonnale

CVD ei lõpe pileti sulgemisega. Koordineeritud haavatavuste avalikustamise poliitika nõuab pidevat logide läbivaatamist:

„VRT peab pidama haavatavuste avalikustamise logi, mis jälgib iga teadet alates kättesaamisest kuni sulgemiseni. Logi tuleb iga kuu läbi vaadata, et tagada avatud tegevuste õigeaegne edenemine. Tähtaja ületanud tegevused tuleb eskaleerida.“
Allikas: Koordineeritud haavatavuste avalikustamise poliitika, seire ja audit, punkt 9.1

See igakuine läbivaatamine muudab haavatavuste avalikustamise juhatuse jaoks kasutatavaks juhtimisteabeks. Juhtkond ei vaja kõiki tehnilisi detaile. Ta vajab trendi, kokkupuudet, vastutust ja tähtaja ületanud riski.

Küpses Claryseci rakenduses toidab see igakuine logide läbivaatamine riskiregistrit, kohaldatavusdeklaratsiooni, turvalise arenduse tööjärge, tarnijate ülevaatusi, intsidendi õppetunde, siseauditi plaani ja juhtkonna aruandluspaketti.

Ehita protsess enne tõsise teate saabumist

Halvim aeg koordineeritud haavatavuste avalikustamise kujundamiseks on pärast seda, kui uurija on teie nõrkuse avalikult postitanud või kriitiline pangaklient on kasutuselevõtu peatanud. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST-laadsed vastupidavusootused ja COBIT 2019 juhtimine osutavad kõik samas suunas: haavatavuste avalikustamine peab olema kavandatud, omaniku vastutusalas, testitud, tõendatud ja täiustatud.

Alusta nende viie tegevusega:

1. Võta kasutusele või kohanda Koordineeritud haavatavuste avalikustamise poliitika.
2. Loo vastuvõtu ja triaaži töövoog, kasutades Zenith Blueprinti, eriti sammu 13 SoA jälgitavuse jaoks, sammu 16 teavituskultuuri jaoks, sammu 19 tehniliste haavatavuste halduse jaoks ja sammu 23 tarnijalepingute jaoks.
3. Kaardista töövoog läbi Zenith Controlsi, keskendudes ISO/IEC 27002:2022 kontrollimeetmetele 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 ja A.8.32.
4. Lisa proportsionaalsuse vajaduse korral VKE-dele sobivad klauslid dokumentidest Intsidentidele reageerimise poliitika VKE-dele, Haavatavuste ja paikade halduse poliitika VKE-dele, Kolmandate osapoolte ja tarnijate turbepoliitika VKE-dele, Rakendusturbe nõuete poliitika VKE-dele ning Auditi ja vastavuse seire poliitika VKE-dele.
5. Vii läbi lauaõppus, mis simuleerib uurija teadet isikuandmeid ja tarnija majutatud komponenti mõjutava probleemi kohta, ning testi kinnitamist, triaaži, intsidendi klassifitseerimist, paikamist, kliendisuhtlust, tõendusmaterjali kogumist ja juhtkonna eskaleerimist.

Clarysec saab aidata muuta selle toimivaks CVD-poliitikaks, vastuvõturegistriks, ISO/IEC 27001:2022 tõendusmaterjali kaardiks, NIS2 ja DORA otsustuspuuks, tarnijate eskaleerimismudeliks ning auditiks valmis kontrollipaketiks. Eesmärk on lihtne: kui järgmine haavatavuse teade saabub, ei peaks teie meeskond improviseerima. Ta peab tegutsema kindlalt, tõendusmaterjalile tuginedes ja kontrollitult.