CVD pre NIS2 a DORA: dôkazová mapa ISO 27001

V utorok o 08:17 prijme bezpečnostná schránka správu od nezávislého výskumníka. Predmet správy je pokojný, takmer zdvorilý: „Možné prevzatie účtu vo vašom zákazníckom portáli.“ Samotný obsah je už menej príjemný. Výskumník tvrdí, že reťazená zraniteľnosť vo vašej SaaS aplikácii umožňuje jednému tenantovi prístup k fakturačným záznamom iného tenanta. Priložený je dôkaz konceptu, zašifrovaný vaším zverejneným PGP kľúčom.

Pre Máriu, novú riaditeľku informačnej bezpečnosti (CISO) vo FinanTechSaaS, nemohlo byť načasovanie horšie. Spoločnosť práve podpísala významnú zmluvu s poprednou bankou v EÚ. Klientsky tím pre due diligence si už vyžiadal „Politiku koordinovaného zverejňovania zraniteľností“ a dôkazy o jej implementácii s výslovným odkazom na NIS2 a DORA. Spoločnosť má e-mailovú adresu security@, ale monitoruje ju jeden vývojár. Neexistuje formálny register príjmu hlásení, definované SLA na overenie, eskalačný postup pre vedenie ani auditná stopa.

Naraz sa spustia tri hodiny.

Prvé hodiny sú prevádzkové. Je zraniteľnosť skutočná? Dá sa zneužiť v produkčnom prostredí? Zneužíva ju už niekto aktívne?

Druhé hodiny sú regulačné. Ak boli sprístupnené údaje zákazníkov, začína sa posúdenie porušenia ochrany osobných údajov podľa GDPR. Ak je ovplyvnené poskytovanie služby základnému alebo dôležitému subjektu podľa NIS2, môžu sa aktivovať prahy nahlasovania incidentov. Ak je spoločnosť finančným subjektom alebo poskytovateľom IKT podporujúcim finančné služby, môžu byť relevantné pravidlá DORA pre riadenie incidentov, klasifikáciu, eskaláciu a komunikáciu s klientmi.

Tretie hodiny sú dôkazové. O šesť mesiacov sa audítor ISO/IEC 27001:2022, orgán dohľadu finančného sektora, tím zákazníckeho uistenia alebo výbor pre vnútorný audit môže opýtať: „Ukážte nám, ako bola táto zraniteľnosť riešená.“

Práve pri tejto otázke mnohé organizácie zistia, že koordinované zverejňovanie zraniteľností nie je len bezpečnostná schránka. Je to systém správy a riadenia. Vyžaduje vlastníctvo politiky, verejný kanál na hlásenie, pracovný tok triáže, SLA pre nápravu, eskaláciu dodávateľom, rozhodovaciu logiku pre incidenty, preskúmanie z pohľadu ochrany súkromia, reportovanie vedeniu a obhájiteľné dôkazy.

Clarysec vníma CVD ako integrovaný vzor kontrol, nie ako samostatný inbox. V Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint sa spracovanie zraniteľností objavuje vo fáze Kontroly v praxi, krok 19: Technologické kontrolné opatrenia I, kde je odporúčanie jasné: organizácie nemajú zistenia o zraniteľnostiach pasívne archivovať, ale triážovať ich, priraďovať vlastníkom a sledovať až do uzavretia. Rovnaký štandard platí pre externé zverejnenia. Ak vám niekto oznámi, ako môže vaša služba zlyhať, skutočná otázka znie: viete preukázať, že ste hlásenie prijali, posúdili, prioritizovali, napravili, odkomunikovali a poučili sa z neho?

Prečo je CVD podľa NIS2 a DORA témou pre predstavenstvo

Organizácie s vysokou úrovňou bezpečnostného povedomia roky vyzývali etických hackerov, aby hlásili zraniteľnosti, pretože išlo o osvedčenú prax. Podľa NIS2 a DORA sa táto prax stala súčasťou regulovanej digitálnej odolnosti.

NIS2 sa vzťahuje na mnohé stredne veľké a väčšie subjekty v sektoroch s vysokou kritickosťou a v iných kritických sektoroch vrátane poskytovateľov digitálnej infraštruktúry, poskytovateľov cloudových výpočtových služieb, poskytovateľov služieb dátových centier, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb a určitých digitálnych poskytovateľov, ako sú online trhoviská, vyhľadávače a platformy sociálnych sietí. Môže sa uplatniť aj bez ohľadu na veľkosť na kategórie, ako sú poskytovatelia dôveryhodných služieb, poskytovatelia služieb DNS, registre TLD a poskytovatelia verejných elektronických komunikačných sietí alebo služieb.

NIS2 článok 21 vyžaduje, aby základné a dôležité subjekty zaviedli primerané a proporcionálne technické, prevádzkové a organizačné opatrenia na riadenie kybernetických rizík s použitím prístupu založeného na všetkých hrozbách. Jednou z minimálnych oblastí je bezpečnosť pri nadobúdaní, vývoji a údržbe sietí a informačných systémov vrátane spracovania a zverejňovania zraniteľností. Rovnaký základ pokrýva aj riešenie incidentov, bezpečnosť dodávateľského reťazca, kontinuitu činností, riadenie prístupu, správu aktív, školenia, kryptografiu a postupy na posúdenie účinnosti kontrol.

NIS2 článok 20 zároveň výslovne stanovuje zodpovednosť vedenia za konanie. Riadiace orgány musia schvaľovať opatrenia na riadenie kybernetických rizík, dohliadať na ich implementáciu a absolvovať školenia. Pre program CVD to znamená, že predstavenstvo alebo vrcholový manažment musí rozumieť kanálu na hlásenie, tímu reakcie na zraniteľnosti, lehotám overenia, očakávaniam nápravy, závislostiam od dodávateľov a spúšťačom nahlasovania incidentov.

DORA od 17. januára 2025 vytvára sektorovo špecifický režim pre finančné subjekty. Pokrýva riadenie rizík IKT, nahlasovanie incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, zdieľanie informácií, riziká IKT tretích strán, zmluvné požiadavky, dohľad nad kritickými externými poskytovateľmi IKT a spoluprácu s orgánmi dohľadu. Pri finančných subjektoch, na ktoré sa vzťahuje DORA, má DORA pri riadení rizík IKT a nahlasovaní incidentov spravidla prednosť pred NIS2, pretože ide o sektorovo špecifický právny akt Únie. Praktická požiadavka však zostáva rovnaká: finančné subjekty a poskytovatelia IKT, ktorí ich obsluhujú, musia prevádzkovať štruktúrovaný, zdokumentovaný a testovateľný proces na identifikáciu, analýzu, klasifikáciu, eskaláciu, nápravu a poučenie sa zo slabín IKT.

Hlásenie zraniteľnosti môže začať ako technické zistenie, stať sa bezpečnostnou udalosťou, eskalovať na incident, spustiť posúdenie porušenia ochrany osobných údajov podľa GDPR, vyžadovať zásah dodávateľa a neskôr sa objaviť vo vyhlásení o uplatniteľnosti (SoA) podľa ISO/IEC 27001:2022. Preto má byť CVD navrhnuté ako jednotný prevádzkový model naprieč bezpečnosťou, súladom, vývojom, právnym oddelením, ochranou súkromia, obstarávaním a vedením.

Základ ISO 27001: od zverejnenia k dôkazom ISMS

ISO/IEC 27001:2022 poskytuje CISO a lídrom v oblasti súladu systém manažérstva, vďaka ktorému je CVD auditovateľné.

Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela interným a externým otázkam, požiadavkám zainteresovaných strán, hraniciam ISMS a závislostiam od iných organizácií. Práve tu vstupujú do ISMS NIS2, DORA, GDPR, zákaznícke zmluvy, povinnosti dodávateľov a záväzky týkajúce sa zverejňovania zraniteľností.

Kapitoly 5.1 až 5.3 vytvárajú zodpovednosť vedenia. Vrcholový manažment musí zosúladiť informačnú bezpečnosť so strategickým smerovaním, poskytnúť zdroje, prideliť zodpovednosti a zabezpečiť, aby ISMS dosahoval zamýšľané výsledky. Pri CVD to znamená vymenovať tím reakcie na zraniteľnosti, definovať právomoc akceptovať zostatkové riziko a eskalovať zraniteľnosti s vysokým dopadom vedeniu.

Kapitoly 6.1.1 až 6.1.3 poskytujú rizikový mechanizmus. Organizácia musí definovať kritériá rizík, posudzovať riziká informačnej bezpečnosti, priraďovať vlastníkov rizík, vyberať možnosti ošetrenia rizík, porovnať kontroly s prílohou A, vypracovať vyhlásenie o uplatniteľnosti a získať schválenie zostatkového rizika. Kapitoly 8.1 až 8.3 následne vyžadujú prevádzkové riadenie, plánované zmeny, riadenie externe poskytovaných procesov, posudzovanie rizík v plánovaných intervaloch alebo po významných zmenách a dôkazy o výsledkoch ošetrenia rizík.

V Zenith Blueprint, fáza Riadenie rizík, krok 13, je vyhlásenie o uplatniteľnosti opísané ako viac než tabuľkový prehľad súladu:

„SoA je v skutočnosti prepájací dokument: spája vaše posúdenie/ošetrenie rizík so skutočnými kontrolami, ktoré máte.“
Zdroj: Zenith Blueprint: 30-kroková cestovná mapa audítora, fáza Riadenie rizík, krok 13: Plánovanie ošetrenia rizík a vyhlásenie o uplatniteľnosti (SoA) Zenith Blueprint

Pri koordinovanom zverejňovaní zraniteľností má SoA prepájať regulačné povinnosti, riziká organizácie, kontroly prílohy A, ustanovenia politík a prevádzkové dôkazy.

Cieľom nie je vytvárať paralelné silá súladu. Politika CVD má byť riadeným procesom ISMS, ktorý súčasne podporuje certifikáciu ISO/IEC 27001:2022, súlad s NIS2, pripravenosť na DORA, uistenie zákazníkov a bezpečnostnú prevádzku.

Základ politiky: čo musí vaša politika CVD obsahovať

Prvou viditeľnou kontrolou je verejný kanál na zverejňovanie. Výskumníci, zákazníci, dodávatelia a partneri musia vedieť, kam majú zraniteľnosti hlásiť a ako majú chrániť citlivé dôkazy.

Clarysec Politika koordinovaného zverejňovania zraniteľností Politika koordinovaného zverejňovania zraniteľností poskytuje podnikový základ:

„Verejné kanály na zverejňovanie: Organizácia musí udržiavať jasný kanál na hlásenie zraniteľností, napríklad vyhradenú bezpečnostnú kontaktnú e-mailovú adresu (napríklad security@company.com) alebo webový formulár. Tieto informácie musia byť zverejnené na bezpečnostnej stránke webového sídla spoločnosti spolu s verejným PGP kľúčom organizácie, aby bolo možné posielať šifrované podania.“
Zdroj: Politika koordinovaného zverejňovania zraniteľností, Požiadavky na implementáciu, bod 6.1

Toto ustanovenie rieši časté auditné zlyhanie. Mnohé organizácie tvrdia, že prijímajú hlásenia, ale trasa hlásenia je skrytá, nešifrovaná alebo ju vlastní nesprávny tím. Zrelý kanál je verejný, bezpečný, monitorovaný a priradený zodpovednej funkcii.

Ďalšou kontrolou je disciplína reakcie. Kritické hlásenie nasledované mlčaním vytvára riziko zverejnenia, reputačné riziko a riziko zneužitia. Politika koordinovaného zverejňovania zraniteľností stanovuje konkrétne očakávanie potvrdenia prijatia a overenia:

„Triáž a potvrdenie prijatia: Po prijatí hlásenia ho tím reakcie na zraniteľnosti (VRT) musí zaznamenať a do 2 pracovných dní zaslať oznamovateľovi potvrdenie prijatia s prideleným referenčným číslom. VRT musí vykonať predbežné posúdenie závažnosti, napríklad s použitím skórovania CVSS, a overiť problém vrátane podpory tímov IT a vývoja, ak je to potrebné, v cieľovej lehote 5 pracovných dní. Kritické zraniteľnosti, napríklad také, ktoré umožňujú vzdialené spustenie kódu alebo závažné porušenie ochrany údajov, musia byť riešené zrýchlene.“
Zdroj: Politika koordinovaného zverejňovania zraniteľností, Požiadavky na implementáciu, bod 6.4

Toto znenie vytvára okamžité dôkazové body: čas prijatia, čas potvrdenia prijatia, referenčné číslo, predbežnú závažnosť, výsledok overenia a rozhodnutie o zrýchlenom postupe.

Pre MSP používa Clarysec rovnakú logiku s proporcionálnou implementáciou. Politika požiadaviek na bezpečnosť aplikácií pre MSP Politika požiadaviek na bezpečnosť aplikácií - SME vyžaduje, aby organizácie:

„špecifikovali povinnosti pre zverejňovanie zraniteľností, reakčné časy a záplatovanie.“
Zdroj: Politika požiadaviek na bezpečnosť aplikácií pre MSP, Požiadavky na správu a riadenie, bod 5.3.2

Na zodpovednosť nepotrebujete veľký tím produktovej bezpečnosti. Potrebujete výslovné povinnosti, realistické lehoty, pomenovaných vlastníkov a dôkazy, že proces funguje.

Pracovný tok príjmu CVD: od e-mailu výskumníka po záznam o rozhodnutí

Dobrý pracovný tok príjmu hlásení je dostatočne jednoduchý na použitie pod tlakom a dostatočne úplný na uspokojenie audítora. Mal by začínať vyhradeným kanálom, napríklad security@[company], webovým formulárom alebo zverejneným súborom security.txt. Trasa podania má umožniť šifrované dôkazy, identifikáciu dotknutého produktu alebo koncového bodu, kroky reprodukcie, kontaktné údaje oznamovateľa, preferované načasovanie zverejnenia a akúkoľvek indikáciu sprístupnenia údajov alebo aktívneho zneužitia.

Po prijatí má tím reakcie na zraniteľnosti vytvoriť záznam v GRC nástroji, tiketovacej platforme, systéme riadenia zraniteľností alebo riadenom registri. Samotný nástroj je menej dôležitý než konzistentnosť a kvalita dôkazov.

Pracovný tok má následne prejsť siedmimi prevádzkovými krokmi.

1. Príjem hlásenia: hlásenie sa prijme cez verejný kanál a automaticky alebo manuálne sa zaznamená.
2. Potvrdenie prijatia: VRT odpovie do 2 pracovných dní a pridelí referenčné číslo.
3. Overenie: technický tím reprodukuje problém, potvrdí dotknuté systémy a vykoná predbežné skórovanie závažnosti.
4. Posúdenie udalosti: VRT určí, či je zraniteľnosť iba slabinou, udalosťou informačnej bezpečnosti alebo incidentom.
5. Eskalácia: vysoké alebo kritické problémy sa podľa potreby postúpia vlastníkom systémov, CISO, funkcii ochrany súkromia, právnemu oddeleniu, dodávateľom a vedeniu.
6. Náprava: zodpovedný tím aplikuje opravu, zmierňujúce opatrenie, kompenzačnú kontrolu alebo dočasné obmedzenie.
7. Uzavretie: VRT overí opravu, komunikuje s oznamovateľom, aktualizuje dôkazový spis a zaznamená ponaučenia.

Clarysec mapuje tento prevádzkový krok na ISO/IEC 27002:2022 kontrolu A.5.25, Posúdenie a rozhodnutie o udalostiach informačnej bezpečnosti, a kontrolu A.8.8, Riadenie technických zraniteľností, prostredníctvom Zenith Controls: Sprievodca krížovým súladom Zenith Controls. Pri A.5.25 Zenith Controls vysvetľuje, že posúdenie udalosti je funkcia triáže medzi surovými monitorovacími upozorneniami a formálnym riešením incidentov, ktorá používa logy, prahové hodnoty a rozhodovacie kritériá na určenie eskalácie. Pri A.8.8 Zenith Controls prepája riadenie technických zraniteľností s ochranou pred škodlivým kódom, riadením konfigurácie, riadením zmien, zabezpečením koncových bodov, spravodajstvom o hrozbách, monitorovaním, bezpečným vývojom, posúdením udalostí a reakciou na incidenty.

Jedna pasáž zo Zenith Controls je obzvlášť užitočná pri podozrení na aktívne zneužitie:

„Spravodajstvo o hrozbách informuje o tom, ktoré zraniteľnosti sa aktívne zneužívajú, a tým usmerňuje prioritizáciu záplatovania.“
Zdroj: Zenith Controls: Sprievodca krížovým súladom, ISO/IEC 27002:2022 kontrola 8.8, väzba na kontrolu 5.7 Spravodajstvo o hrozbách Zenith Controls

Ide o dôležitý bod správy a riadenia. Závažnosť nie je len CVSS. Zraniteľnosť so stredným skóre, ktorá sa aktívne zneužíva proti vášmu sektoru, môže mať vyššiu prioritu než teoreticky kritický problém v testovacom systéme, ktorý nie je vystavený externe.

Kedy sa zraniteľnosť stáva incidentom

Nie každé hlásenie zraniteľnosti je incidentom. Chýbajúca bezpečnostná hlavička v predprodukčnom prostredí nie je to isté ako zneužitý obchvat autorizácie, ktorý sprístupňuje zákaznícke faktúry. Každé dôveryhodné hlásenie zraniteľnosti však musí prejsť rozhodovacou bránou pre incidenty.

NIS2 článok 23 vyžaduje, aby základné a dôležité subjekty bez zbytočného odkladu oznamovali svojmu CSIRT alebo príslušnému orgánu incidenty, ktoré významne ovplyvňujú poskytovanie služieb. Významný incident je taký, ktorý spôsobil alebo môže spôsobiť závažné narušenie prevádzky alebo finančnú stratu, alebo ktorý ovplyvnil alebo môže ovplyvniť iné osoby spôsobením značnej majetkovej alebo nemajetkovej ujmy. Postup oznamovania zahŕňa včasné varovanie do 24 hodín od zistenia, oznámenie incidentu do 72 hodín, priebežné správy na vyžiadanie a záverečnú správu do jedného mesiaca od oznámenia do 72 hodín.

DORA články 17 až 20 vyžadujú, aby finančné subjekty detegovali, riadili, zaznamenávali, klasifikovali, eskalovali, oznamovali a komunikovali incidenty súvisiace s IKT a významné kybernetické hrozby. Závažné incidenty súvisiace s IKT musia byť eskalované vrcholovému manažmentu a riadiacemu orgánu. Komunikácia s klientmi môže byť vyžadovaná, keď sú dotknuté finančné záujmy.

Pre MSP musí byť kultúra hlásenia rovnako jasná. Clarysec Politika reakcie na incidenty pre MSP Politika reakcie na incidenty - SME uvádza:

„Personál musí nahlásiť akúkoľvek podozrivú aktivitu alebo potvrdený incident na incident@[company] alebo ústne generálnemu manažérovi či poskytovateľovi IT služieb.“
Zdroj: Politika reakcie na incidenty pre MSP, Požiadavky na implementáciu politiky, bod 6.2.1

V Zenith Blueprint, fáza Kontroly v praxi, krok 16: Personálne opatrenia II, je princíp ešte jednoduchší:

„Ak máte pochybnosti, nahláste to.“
Zdroj: Zenith Blueprint: 30-kroková cestovná mapa audítora, fáza Kontroly v praxi, krok 16: Personálne opatrenia II (A.6.5 až A.6.8)

Táto veta sa má vzťahovať na vývojárov, tímy podpory, manažérov dodávateľov, vedúcich ochrany súkromia, vrcholový manažment aj outsourcovaných poskytovateľov. Zraniteľnosť, ktorá môže ovplyvniť dôvernosť, integritu, dostupnosť, dôveru zákazníkov, regulačné oznamovanie alebo finančné operácie, má byť zaznamenaná a posúdená, nie neformálne riešená v chate.

Náprava, záplatovanie a kompenzačné kontroly

Po overení zraniteľnosti sa musí zraniteľnosť ošetriť. Ošetrenie má byť založené na riziku, podložené dôkazmi a časovo ohraničené.

Politika koordinovaného zverejňovania zraniteľností stanovuje podnikové očakávanie:

„Plán nápravy: Pre všetky potvrdené zraniteľnosti musí byť vypracovaný plán nápravy alebo zmiernenia. Implementácia opravy musí byť prioritizovaná podľa závažnosti. Napríklad kritické zraniteľnosti musia byť opravené alebo zmiernené do 14 dní, ak je to uskutočniteľné, alebo skôr, ak sa zistí aktívne zneužitie, zatiaľ čo problémy s nižšou závažnosťou musia byť riešené v primeranej lehote. Ak sa úplná oprava oneskorí, musia byť implementované kompenzačné kontroly alebo dočasné zmierňujúce opatrenia, napríklad deaktivácia zraniteľnej funkcionality alebo zvýšenie monitorovania.“
Zdroj: Politika koordinovaného zverejňovania zraniteľností, Požiadavky na implementáciu, bod 6.6

Pre disciplínu záplatovania v MSP Politika riadenia zraniteľností a záplat pre MSP Politika riadenia zraniteľností a záplat - SME uvádza:

„Kritické záplaty musia byť aplikované do 3 dní od vydania, najmä pri systémoch dostupných z internetu“
Zdroj: Politika riadenia zraniteľností a záplat pre MSP, Požiadavky na implementáciu politiky, bod 6.1.1

Tieto lehoty si neodporujú. Záplata dodávateľa pre systém dostupný z internetu môže vyžadovať veľmi rýchle nasadenie. Produktová zraniteľnosť vyžadujúca zmeny kódu, regresné testovanie, koordináciu so zákazníkmi a postupné vydanie môže vyžadovať plán nápravy s dočasnými zmierňujúcimi opatreniami. Kľúčové je, aby bolo rozhodnutie zdokumentované, vlastnené vlastníkom rizika a schválené tam, kde zostáva zostatkové riziko.

Praktický tok prípadu vyzerá takto:

1. Výskumník nahlási obchvat autorizácie v zákazníckom fakturačnom API.
2. VRT zaznamená CVD-2026-014 s časovou pečiatkou a do 2 pracovných dní potvrdí prijatie.
3. Produktová bezpečnosť overí chybu do 24 hodín a pridelí vysokú závažnosť z dôvodu prístupu k údajom medzi tenantmi.
4. Ochrana súkromia vykoná posúdenie porušenia podľa GDPR, pretože fakturačné záznamy môžu obsahovať osobné údaje.
5. Manažér incidentov otvorí posúdenie udalosti podľa ISO/IEC 27002:2022 kontroly A.5.25.
6. Vlastník systému deaktivuje zraniteľný koncový bod prostredníctvom dočasného prepínača funkcionality.
7. Vývoj vytvorí urgentnú opravu podľa ISO/IEC 27002:2022 kontroly A.8.32, Riadenie zmien.
8. Pridajú sa monitorovacie pravidlá pre indikátory zneužitia s väzbou na A.8.15, Logovanie, a A.8.16, Monitorovacie aktivity.
9. CISO informuje vrcholový manažment, pretože ide o vysoko rizikový problém.
10. VRT koordinuje s výskumníkom opätovné testovanie a načasovanie zverejnenia.
11. Vlastník rizika schváli uzavretie až po overovacom testovaní a preskúmaní dopadu na zákazníkov.
12. Aktualizuje sa SoA, register rizík, tiket, logy, oznámenie vedeniu a ponaučenia.

To je rozdiel medzi „záplatu sme aplikovali“ a „vieme preukázať, že sme to riadili“.

Závislosti od dodávateľov a cloudu: skryté miesto zlyhania

Mnohé zlyhania CVD sú v skutočnosti skryté zlyhania dodávateľov. Zraniteľnosť sa môže týkať SaaS komponentu, cloudovej služby, poskytovateľa riadených bezpečnostných služieb, platobnej brány, sprostredkovateľa autentifikácie, open-source knižnice, outsourcovaného vývojového tímu alebo subdodávateľa.

NIS2 článok 21 vyžaduje bezpečnosť dodávateľského reťazca vrátane vzťahov s priamymi dodávateľmi a poskytovateľmi služieb. Opatrenia dodávateľského reťazca majú zohľadňovať zraniteľnosti dodávateľov, kvalitu produktov, praktiky kybernetickej bezpečnosti a postupy bezpečného vývoja.

DORA články 28 až 30 idú pri finančných subjektoch hlbšie. Vyžadujú, aby sa riziko IKT tretích strán riadilo ako súčasť rámca rizík IKT vrátane registrov zmlúv o IKT službách, rozlíšenia kritických alebo dôležitých funkcií, due diligence pred uzatvorením zmluvy, zmluvných bezpečnostných požiadaviek, pomoci pri incidentoch, spolupráce s orgánmi, práv na audit, práv na ukončenie a exit stratégií. Finančné subjekty zostávajú plne zodpovedné za súlad s DORA aj pri využívaní externých poskytovateľov IKT.

Clarysec Politika bezpečnosti tretích strán a dodávateľov pre MSP Politika bezpečnosti tretích strán a dodávateľov - SME obsahuje jednoduché pravidlo eskalácie:

„Musí okamžite informovať generálneho manažéra o akomkoľvek porušení bezpečnosti, zmene alebo incidente“
Zdroj: Politika bezpečnosti tretích strán a dodávateľov pre MSP, Úlohy a zodpovednosti, bod 4.4.3

Pre podnikové zmluvy s dodávateľmi Zenith Blueprint, fáza Kontroly v praxi, krok 23, odporúča zahrnúť povinnosti zachovávať dôvernosť, zodpovednosti za riadenie prístupu, technické a organizačné opatrenia, lehoty nahlasovania incidentov, právo na audit, kontroly subdodávateľov a ustanovenia pri ukončení zmluvy. Uvádza:

„Dôležité je, že existujú a že im obe strany rozumejú a akceptujú ich.“
Zdroj: Zenith Blueprint: 30-kroková cestovná mapa audítora, fáza Kontroly v praxi, krok 23: Organizačné opatrenia (5.19 až 5.37)

Pripravenosť dodávateľov na CVD má odpovedať na tieto otázky:

• Zverejňuje dodávateľ kanál na hlásenie zraniteľností?
• Sú v zmluve definované lehoty oznamovania zraniteľností?
• Sú kritické zraniteľnosti dodávateľa nahlasované bez zbytočného odkladu?
• Sú slabiny s dopadom na zákazníkov prepojené s povinnosťami pomoci pri incidentoch?
• Vie dodávateľ poskytnúť dôkazy o náprave alebo bezpečnostné upozornenia?
• Sú povinnosti týkajúce sa zraniteľností prenesené aj na subdodávateľov?
• Existuje exit stratégia, ak je náprava nedostatočná?

Práve tu sa NIS2, DORA a ISO/IEC 27001:2022 stretávajú. Riadenie zraniteľností dodávateľov nie je zaškrtávacie políčko obstarávania. Je súčasťou prevádzkovej odolnosti.

Mapovanie dôkazov pre ISO 27001, NIS2, DORA, GDPR a COBIT

Najsilnejšie programy CVD sú navrhnuté od dôkazov. Predpokladajú, že každé významné hlásenie môže neskôr preskúmať vnútorný audit, certifikační audítori, regulátori, zákazníci, poisťovatelia alebo rizikový výbor predstavenstva.

Clarysec Politika monitorovania auditov a súladu pre MSP Politika monitorovania auditov a súladu - SME zachytáva detail, ktorý mnohým tímom uniká:

„Metadáta (napr. kto ich zhromaždil, kedy a z ktorého systému) musia byť zdokumentované.“
Zdroj: Politika monitorovania auditov a súladu pre MSP, Požiadavky na implementáciu politiky, bod 6.2.3

Snímka obrazovky zo zaplátaného servera je slabým dôkazom, ak nikto nevie, kto ju zachytil, kedy, z akého systému a ako sa mapuje na zraniteľnosť. Tiket s časovými pečiatkami, výstupom skenera, pull requestom, schválením zmeny, logmi nasadenia, monitorovacím dotazom, potvrdením opätovného testovania a metadátami je omnoho silnejší.

Podrobnejšia matica sledovateľnosti pomáha pri due diligence klienta a vnútornom audite.

Rôzni audítori budú testovať ten istý proces rôznymi optikami.

Audítor ISO/IEC 27001:2022 začne pri ISMS. Bude sa pýtať, či sú povinnosti zverejňovania zraniteľností zahrnuté medzi požiadavky zainteresovaných strán, či sa riziká posudzujú konzistentne, či sa kontroly objavujú v SoA, či existujú prevádzkové dôkazy a či manažment preskúmava trendy a omeškané položky.

Posudzovateľ podľa DORA alebo z prostredia finančných služieb sa zameria na prevádzkovú odolnosť. Preskúma integráciu rizík IKT, klasifikáciu incidentov, eskaláciu vrcholovému manažmentu, komunikáciu s klientmi, závislosti od tretích strán, testovanie a ponaučenia. Ak zraniteľnosť ovplyvňuje kritickú alebo dôležitú funkciu, bude očakávať úzku väzbu medzi technickým tiketom, dopadom na činnosť organizácie, implikáciami pre kontinuitu a povinnosťami dodávateľov.

Posudzovateľ podľa GDPR sa zameria na osobné údaje. Boli zapojené osobné údaje? Došlo k neoprávnenému prístupu, strate, zmene alebo zverejneniu? Boli jasné roly prevádzkovateľa a sprostredkovateľa? Bol posúdený prah porušenia? Boli relevantné ochranné opatrenia ako šifrovanie, riadenie prístupu, logovanie a minimalizácia?

Audítor podľa COBIT 2019 alebo ISACA sa zameria na správu a riadenie, zodpovednosť, výkonnosť a uistenie. Bude hľadať definované vlastníctvo, metriky, eskaláciu, ciele kontrol, dohľad manažmentu a sledovanie výnimiek. Omeškaná kritická zraniteľnosť nie je len technický problém. Je to problém správy a riadenia, pokiaľ nie je formálne eskalovaná a riziko nie je akceptované.

Posudzovateľ orientovaný na NIST bude uvažovať v kategóriách Identify, Protect, Detect, Respond a Recover. Bude požadovať vlastníctvo aktív, identifikáciu zraniteľností, prioritizáciu, ochrannú zmenu, detekciu zneužitia, koordináciu reakcie a validáciu obnovy.

Výhodou integrovaného modelu CVD je, že rovnaká dôkazová línia môže podporiť všetky tieto preskúmania.

Mesačný kontrolný cyklus: metriky použiteľné manažmentom

CVD sa nekončí uzavretím tiketu. Politika koordinovaného zverejňovania zraniteľností vyžaduje priebežné preskúmanie registra:

„VRT musí viesť register zverejňovania zraniteľností, ktorý sleduje každé hlásenie od prijatia po uzavretie. Register sa musí mesačne preskúmavať, aby sa zabezpečil včasný postup otvorených položiek. Omeškané položky musia byť eskalované.“
Zdroj: Politika koordinovaného zverejňovania zraniteľností, Monitorovanie a audit, bod 9.1

Toto mesačné preskúmanie mení zverejňovanie zraniteľností na správu pripravenú pre predstavenstvo. Manažment nepotrebuje každý technický detail. Potrebuje trend, expozíciu, zodpovednosť a omeškané riziko.

V zrelej implementácii Clarysec toto mesačné preskúmanie registra napája register rizík, vyhlásenie o uplatniteľnosti, backlog bezpečného vývoja, preskúmania dodávateľov, ponaučenia z incidentov, plán vnútorného auditu a balík reportovania vedeniu.

Vybudujte proces skôr, než príde závažné hlásenie

Najhorší čas na návrh koordinovaného zverejňovania zraniteľností je po tom, ako výskumník verejne zverejní vašu slabinu alebo kritický bankový klient pozastaví onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, očakávania odolnosti podľa prístupu NIST a správa a riadenie podľa COBIT 2019 smerujú rovnakým smerom: zverejňovanie zraniteľností musí byť plánované, vlastnené, testované, podložené dôkazmi a zlepšované.

Začnite týmito piatimi krokmi:

1. Prijmite alebo prispôsobte Politiku koordinovaného zverejňovania zraniteľností.
2. Vybudujte pracovný tok príjmu a triáže pomocou Zenith Blueprint, najmä krok 13 pre sledovateľnosť SoA, krok 16 pre kultúru hlásenia, krok 19 pre riadenie technických zraniteľností a krok 23 pre dohody s dodávateľmi.
3. Namapujte pracovný tok cez Zenith Controls so zameraním na ISO/IEC 27002:2022 kontroly 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 a A.8.32.
4. Doplňte ustanovenia pripravené pre MSP z Politiky reakcie na incidenty pre MSP, Politiky riadenia zraniteľností a záplat pre MSP, Politiky bezpečnosti tretích strán a dodávateľov pre MSP, Politiky požiadaviek na bezpečnosť aplikácií pre MSP a Politiky monitorovania auditov a súladu pre MSP tam, kde je dôležitá proporcionalita.
5. Vykonajte stolové cvičenie simulujúce hlásenie výskumníka s dopadom na osobné údaje a komponent prevádzkovaný dodávateľom, potom otestujte potvrdenie prijatia, triáž, klasifikáciu incidentu, záplatovanie, komunikáciu so zákazníkom, zaistenie dôkazov a eskaláciu vedeniu.

Clarysec vám môže pomôcť premeniť to na funkčnú politiku CVD, register príjmu hlásení, dôkazovú mapu ISO/IEC 27001:2022, rozhodovací strom NIS2 a DORA, model eskalácie dodávateľom a balík kontrol pripravený na audit. Cieľ je jednoduchý: keď príde ďalšie hlásenie zraniteľnosti, váš tím nemá improvizovať. Má konať s istotou, dôkazmi a riadením.