CVD pro NIS2 a DORA: mapa důkazů pro ISO 27001

V úterý v 08:17 obdrží bezpečnostní schránka zprávu od nezávislého výzkumníka. Předmět je klidný, téměř zdvořilý: „Možné převzetí účtu ve vašem zákaznickém portálu.“ Text zprávy už tak uklidňující není. Výzkumník tvrdí, že zřetězená zranitelnost ve vaší SaaS aplikaci umožňuje jednomu tenantovi přístup k fakturačním záznamům jiného tenanta. Přiložen je proof of concept zašifrovaný vaším zveřejněným PGP klíčem.

Pro Marii, novou CISO ve společnosti FinanTechSaaS, nemohlo načasování přijít hůř. Její společnost právě podepsala významnou smlouvu s přední bankou v EU. Tým klienta pro prověření dodavatele si již vyžádal „Politiku koordinovaného zveřejňování zranitelností“ a důkazy o její implementaci s výslovným odkazem na NIS2 a DORA. Společnost má e-mailovou adresu security@, ale monitoruje ji jeden vývojář. Neexistuje formální evidence příjmu hlášení, definovaná SLA pro ověření, eskalační cesta na vedení ani auditní stopa.

Najednou běží troje hodiny.

První jsou provozní. Je zranitelnost skutečná? Je zneužitelná v produkčním prostředí? Zneužívá ji někdo aktivně?

Druhé jsou regulační. Pokud došlo k expozici zákaznických dat, začíná posouzení porušení zabezpečení podle GDPR. Pokud je ovlivněno poskytování služeb pro základní nebo důležitý subjekt podle NIS2, mohou být spuštěny prahové hodnoty pro hlášení incidentů. Pokud je společnost finančním subjektem nebo poskytovatelem ICT podporujícím finanční služby, mohou být relevantní pravidla DORA pro řízení incidentů, klasifikaci, eskalaci a komunikaci s klienty.

Třetí jsou důkazní. O šest měsíců později se auditor ISO/IEC 27001:2022, orgán dohledu nad finančním trhem, tým zákaznického ujištění nebo výbor interního auditu může zeptat: „Ukažte nám, jak jste tuto zranitelnost řešili.“

Právě u této otázky mnoho organizací zjistí, že koordinované zveřejňování zranitelností není jen bezpečnostní schránka. Je to systém správy a řízení. Potřebuje vlastnictví politiky, veřejný kanál pro hlášení, proces triáže, SLA nápravy, eskalaci na dodavatele, rozhodovací logiku pro incidenty, přezkum ochrany soukromí, reporty pro vedení a obhajitelné důkazy.

Clarysec chápe CVD jako integrovaný vzorec opatření, nikoli jako samostatnou schránku. V Zenith Blueprint: 30kroková mapa auditora Zenith Blueprint se řízení zranitelností objevuje ve fázi Opatření v praxi, krok 19: Technologická opatření I, kde je doporučení jasné: organizace nesmí zjištění zranitelností pasivně archivovat, ale musí je triážovat, přiřazovat a sledovat až do uzavření. Stejný standard platí pro externí oznámení. Pokud vám někdo sdělí, jak může vaše služba selhat, skutečná otázka zní: dokážete prokázat, že jste hlášení přijali, posoudili, prioritizovali, napravili, komunikovali a poučili se z něj?

Proč je CVD podle NIS2 a DORA tématem pro vedoucí orgány

Organizace s vyspělým bezpečnostním přístupem po léta vybízely etické hackery k hlášení zranitelností, protože šlo o dobrou praxi. Podle NIS2 a DORA se tato praxe stala součástí regulované digitální odolnosti.

NIS2 se vztahuje na mnoho středních a větších subjektů v odvětvích s vysokou kritičností a v dalších kritických odvětvích, včetně poskytovatelů digitální infrastruktury, poskytovatelů služeb cloud computingu, poskytovatelů služeb datových center, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb a některých digitálních poskytovatelů, například online tržišť, internetových vyhledávačů a platforem sociálních sítí. Bez ohledu na velikost se může vztahovat také na kategorie, jako jsou poskytovatelé služeb vytvářejících důvěru, poskytovatelé služeb DNS, registry TLD a poskytovatelé veřejných sítí nebo služeb elektronických komunikací.

NIS2 Article 21 vyžaduje, aby základní a důležité subjekty zavedly vhodná a přiměřená technická, provozní a organizační opatření řízení rizik v oblasti kybernetické bezpečnosti s využitím přístupu zahrnujícího všechna rizika. Jednou z minimálních oblastí je bezpečnost při pořizování, vývoji a údržbě sítí a informačních systémů, včetně řízení zranitelností a jejich zveřejňování. Stejný základní rámec pokrývá také zvládání incidentů, zabezpečení dodavatelského řetězce, kontinuitu činností, řízení přístupu, správu aktiv, školení, kryptografii a postupy posuzování účinnosti opatření.

NIS2 Article 20 rovněž výslovně stanoví odpovědnost vedení. Vedoucí orgány musí schvalovat opatření řízení rizik v oblasti kybernetické bezpečnosti, dohlížet na jejich implementaci a absolvovat školení. U programu CVD to znamená, že vedoucí orgán nebo vrcholové vedení musí rozumět kanálu pro hlášení, týmu pro reakci na zranitelnosti, lhůtám ověření, očekáváním ohledně nápravy, závislostem na dodavatelích a spouštěčům hlášení incidentů.

DORA vytváří od 17. ledna 2025 sektorový režim pro finanční subjekty. Zahrnuje řízení rizik v oblasti ICT, hlášení incidentů souvisejících s ICT, testování digitální provozní odolnosti, sdílení informací, riziko třetích stran v oblasti ICT, smluvní požadavky, dohled nad kritickými poskytovateli ICT služeb z řad třetích stran a spolupráci orgánů dohledu. U finančních subjektů spadajících pod DORA má DORA obecně přednost před NIS2 pro řízení rizik v oblasti ICT a hlášení incidentů, protože jde o sektorový právní akt Unie. Praktický požadavek však zůstává stejný: finanční subjekty a poskytovatelé ICT, kteří jim poskytují služby, musí provozovat strukturovaný, dokumentovaný a testovatelný proces pro identifikaci, analýzu, klasifikaci, eskalaci, nápravu a učení se ze slabin v oblasti ICT.

Hlášení zranitelnosti může začít jako technické zjištění, stát se bezpečnostní událostí, eskalovat do incidentu, spustit posouzení porušení zabezpečení osobních údajů podle GDPR, vyžadovat opatření dodavatele a později se objevit v Prohlášení o použitelnosti podle ISO/IEC 27001:2022. Proto má být CVD navrženo jako jednotný provozní model napříč bezpečností, compliance, engineeringem, právní oblastí, ochranou soukromí, nákupem a vedením.

Základ ISO 27001: od oznámení k důkazům ISMS

ISO/IEC 27001:2022 poskytuje CISO a manažerům compliance systém řízení, díky němuž je CVD auditovatelné.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace rozuměla interním a externím otázkám, požadavkům zainteresovaných stran, hranicím ISMS a závislostem na jiných organizacích. Právě zde do ISMS vstupují NIS2, DORA, GDPR, zákaznické smlouvy, povinnosti dodavatelů a závazky v oblasti zveřejňování zranitelností.

Kapitoly 5.1 až 5.3 vytvářejí odpovědnost vedení. Vrcholové vedení musí sladit bezpečnost informací se strategickým směřováním, poskytovat zdroje, přiřazovat odpovědnosti a zajistit, že ISMS dosahuje zamýšlených výsledků. U CVD to znamená jmenovat tým pro reakci na zranitelnosti, definovat pravomoc přijímat zbytkové riziko a eskalovat zranitelnosti s vysokým dopadem na vedení.

Kapitoly 6.1.1 až 6.1.3 poskytují rizikový mechanismus. Organizace musí definovat kritéria rizik, posuzovat rizika bezpečnosti informací, přiřazovat vlastníky rizik, vybírat možnosti ošetření rizik, porovnávat opatření s přílohou A, vytvořit Prohlášení o použitelnosti a získat schválení zbytkového rizika. Kapitoly 8.1 až 8.3 poté vyžadují provozní plánování a řízení, řízení plánovaných změn, řízení externě poskytovaných procesů, posouzení rizik v plánovaných intervalech nebo po významných změnách a důkazy o výsledcích ošetření.

V Zenith Blueprint, fáze řízení rizik, krok 13, je Prohlášení o použitelnosti popsáno jako více než tabulka souladu:

„SoA je ve skutečnosti propojovací dokument: propojuje vaše posouzení/ošetření rizik se skutečnými opatřeními, která máte.“
Zdroj: Zenith Blueprint: 30kroková mapa auditora, fáze řízení rizik, krok 13: plánování ošetření rizik a Prohlášení o použitelnosti (SoA) Zenith Blueprint

U koordinovaného zveřejňování zranitelností má SoA propojit regulační povinnosti, obchodní riziko, opatření přílohy A, ustanovení politik a provozní důkazy.

Cílem není vytvářet paralelní compliance sila. Politika CVD má být řízeným procesem ISMS, který současně podporuje certifikaci ISO/IEC 27001:2022, soulad s NIS2, připravenost na DORA, zákaznické ujištění a bezpečnostní provoz.

Základ politiky: co musí vaše politika CVD obsahovat

Prvním viditelným opatřením je veřejný kanál pro hlášení. Výzkumníci, zákazníci, dodavatelé a partneři musí vědět, kam zranitelnosti hlásit a jak chránit citlivé důkazy.

Clarysec Politika koordinovaného zveřejňování zranitelností Politika koordinovaného zveřejňování zranitelností poskytuje základ pro podnikové prostředí:

„Veřejné kanály pro hlášení: Organizace musí udržovat jasný kanál pro hlášení zranitelností, například vyhrazenou bezpečnostní kontaktní e-mailovou adresu (například security@company.com) nebo webový formulář. Tyto informace musí být zveřejněny na bezpečnostní stránce webu společnosti společně s veřejným PGP klíčem organizace, aby bylo možné zasílat šifrovaná podání.“
Zdroj: Politika koordinovaného zveřejňování zranitelností, požadavky na implementaci, ustanovení 6.1

Toto ustanovení řeší časté selhání při auditu. Mnoho organizací tvrdí, že přijímá hlášení, ale cesta pro hlášení je skrytá, nešifrovaná nebo ve vlastnictví nesprávného týmu. Vyspělý kanál je veřejný, bezpečný, monitorovaný a přiřazený odpovědné funkci.

Dalším opatřením je disciplína reakce. Kritické hlášení následované mlčením vytváří riziko zveřejnění, reputační riziko a riziko zneužití. Politika koordinovaného zveřejňování zranitelností stanoví konkrétní očekávání pro potvrzení přijetí a ověření:

„Triáž a potvrzení přijetí: Po obdržení hlášení jej VRT zaznamená a do 2 pracovních dnů zašle oznamovateli potvrzení přijetí včetně přiřazení referenčního čísla. VRT provede předběžné posouzení závažnosti, například pomocí skórování CVSS, a ověří problém, včetně podpory IT a vývojových týmů, je-li to nezbytné, v cílové lhůtě 5 pracovních dnů. Kritické zranitelnosti, například ty, které umožňují vzdálené spuštění kódu nebo závažné porušení zabezpečení dat, musí být řešeny zrychleně.“
Zdroj: Politika koordinovaného zveřejňování zranitelností, požadavky na implementaci, ustanovení 6.4

Toto znění vytváří okamžité důkazní body: čas přijetí, čas potvrzení, referenční číslo, předběžnou závažnost, výsledek ověření a rozhodnutí o zrychleném postupu.

Pro malé a střední podniky používá Clarysec stejnou logiku s přiměřenou implementací. Politika požadavků na zabezpečení aplikací pro malé a střední podniky Politika požadavků na zabezpečení aplikací - SME vyžaduje, aby organizace:

„stanovily povinnosti týkající se hlášení zranitelností, reakčních dob a záplatování.“
Zdroj: Politika požadavků na zabezpečení aplikací pro malé a střední podniky, požadavky na správu a řízení, ustanovení 5.3.2

K odpovědnosti nepotřebujete velký tým produktové bezpečnosti. Potřebujete výslovné povinnosti, realistické lhůty, jmenované vlastníky a důkazy, že proces funguje.

Proces příjmu CVD: od e-mailu výzkumníka k rozhodovacímu záznamu

Dobrý proces příjmu hlášení je dostatečně jednoduchý, aby fungoval pod tlakem, a zároveň dostatečně úplný, aby obstál u auditora. Měl by začínat vyhrazeným kanálem, například security@[company], webovým formulářem nebo zveřejněným souborem security.txt. Cesta pro podání musí umožnit šifrované důkazy, uvedení dotčeného produktu nebo endpointu, kroky k reprodukci, kontaktní údaje oznamovatele, preferované načasování zveřejnění a jakoukoli informaci o expozici dat nebo aktivním zneužití.

Po přijetí má tým pro reakci na zranitelnosti vytvořit záznam v nástroji GRC, ticketovací platformě, systému řízení zranitelností nebo řízeném registru. Na konkrétním nástroji záleží méně než na konzistenci a kvalitě důkazů.

Proces má následně projít sedmi provozními kroky.

1. Příjem: hlášení je přijato veřejným kanálem a automaticky nebo ručně zaevidováno.
2. Potvrzení přijetí: VRT odpoví do 2 pracovních dnů a přiřadí referenční číslo.
3. Ověření: technický tým reprodukuje problém, potvrdí dotčené systémy a provede předběžné skórování závažnosti.
4. Posouzení události: VRT určí, zda je zranitelnost pouze slabinou, událostí bezpečnosti informací nebo incidentem.
5. Eskalace: vysoké nebo kritické problémy jsou podle potřeby předány vlastníkům systémů, CISO, funkci ochrany soukromí, právní funkci, dodavatelům a vedení.
6. Náprava: odpovědný tým aplikuje opravu, zmírnění, kompenzační opatření nebo dočasné omezení.
7. Uzavření: VRT ověří opravu, komunikuje s oznamovatelem, aktualizuje důkazní spis a zaznamená získané poznatky.

Clarysec mapuje tento provozní krok na opatření ISO/IEC 27002:2022 A.5.25, Posouzení a rozhodnutí o událostech bezpečnosti informací, a opatření A.8.8, Řízení technických zranitelností, prostřednictvím Zenith Controls: průvodce napříč compliance Zenith Controls. U A.5.25 Zenith Controls vysvětluje, že posouzení události je triážní funkcí mezi nezpracovanými upozorněními z monitorování a formálním zvládáním incidentů, která využívá logy, prahové hodnoty a rozhodovací kritéria pro určení eskalace. U A.8.8 Zenith Controls propojuje řízení technických zranitelností s ochranou před škodlivým kódem, řízením konfigurace, řízením změn, zabezpečením koncových bodů, informacemi o hrozbách, monitorováním, bezpečným vývojem, posouzením událostí a reakcí na incidenty.

Jedna pasáž ze Zenith Controls je obzvlášť užitečná při podezření na aktivní zneužití:

„Informace o hrozbách ukazují, které zranitelnosti jsou aktivně zneužívány, a vedou prioritizaci záplat.“
Zdroj: Zenith Controls: průvodce napříč compliance, opatření ISO/IEC 27002:2022 8.8, vazba na opatření 5.7 Informace o hrozbách Zenith Controls

To je důležitý bod správy a řízení. Závažnost není jen CVSS. Středně hodnocená zranitelnost aktivně zneužívaná proti vašemu odvětví může mít vyšší prioritu než teoretický kritický problém na neexponovaném testovacím systému.

Kdy se zranitelnost stává incidentem

Ne každé hlášení zranitelnosti je incident. Chybějící bezpečnostní hlavička ve staging prostředí není totéž jako zneužitý bypass autorizace, který zpřístupňuje faktury zákazníků. Každé důvěryhodné hlášení zranitelnosti však musí projít rozhodovacím bodem pro incident.

NIS2 Article 23 vyžaduje, aby základní a důležité subjekty bez zbytečného odkladu oznamovaly svému CSIRT nebo příslušnému orgánu incidenty, které významně ovlivňují poskytování služeb. Významný incident je incident, který způsobil nebo může způsobit závažné provozní narušení nebo finanční ztrátu, nebo který ovlivnil či může ovlivnit jiné osoby tím, že způsobí značnou hmotnou nebo nehmotnou újmu. Posloupnost hlášení zahrnuje včasné varování do 24 hodin od okamžiku, kdy se subjekt o incidentu dozví, oznámení incidentu do 72 hodin, průběžné zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce od 72hodinového oznámení.

DORA Articles 17 to 20 vyžadují, aby finanční subjekty detekovaly, řídily, zaznamenávaly, klasifikovaly, eskalovaly, oznamovaly a komunikovaly incidenty související s ICT a významné kybernetické hrozby. Závažné incidenty související s ICT musí být eskalovány vrcholovému vedení a vedoucímu orgánu. Komunikace s klienty může být vyžadována, pokud jsou dotčeny finanční zájmy.

U malých a středních podniků musí být kultura hlášení stejně jasná. Clarysec Politika reakce na incidenty pro malé a střední podniky Politika reakce na incidenty - SME uvádí:

„Pracovníci musí hlásit jakoukoli podezřelou aktivitu nebo potvrzený incident na incident@[company] nebo ústně generálnímu řediteli či poskytovateli IT služeb.“
Zdroj: Politika reakce na incidenty pro malé a střední podniky, požadavky na implementaci politiky, ustanovení 6.2.1

V Zenith Blueprint, fáze Opatření v praxi, krok 16: Personální opatření II, je princip ještě jednodušší:

„V případě pochybností hlaste.“
Zdroj: Zenith Blueprint: 30kroková mapa auditora, fáze Opatření v praxi, krok 16: Personální opatření II (A.6.5 až A.6.8)

Tato věta se má vztahovat na vývojáře, týmy podpory, manažery dodavatelů, vedoucí ochrany soukromí, vrcholové vedení i outsourcované poskytovatele. Zranitelnost, která může ovlivnit důvěrnost, integritu, dostupnost, důvěru zákazníků, regulační oznámení nebo finanční operace, má být zaznamenána a posouzena, nikoli neformálně řešena v chatu.

Náprava, záplatování a kompenzační opatření

Jakmile je zranitelnost ověřena, musí být ošetřena. Ošetření má být založené na riziku, podložené důkazy a časově omezené.

Politika koordinovaného zveřejňování zranitelností stanoví podnikové očekávání:

„Plán nápravy: Pro všechny potvrzené zranitelnosti musí být vypracován plán nápravy nebo zmírnění. Implementace opravy musí být prioritizována podle závažnosti. Například kritické zranitelnosti musí být opraveny nebo zmírněny do 14 dnů, je-li to proveditelné, nebo dříve, pokud je zjištěno aktivní zneužití, zatímco problémy s nižší závažností musí být řešeny v přiměřené lhůtě. Pokud je plná oprava odložena, musí být implementována kompenzační opatření nebo dočasná zmírňující opatření, například vypnutí zranitelné funkcionality nebo zvýšení monitorování.“
Zdroj: Politika koordinovaného zveřejňování zranitelností, požadavky na implementaci, ustanovení 6.6

Pro disciplínu záplatování u malých a středních podniků uvádí Politika řízení zranitelností a záplat pro malé a střední podniky Politika řízení zranitelností a záplat - SME:

„Kritické záplaty musí být aplikovány do 3 dnů od vydání, zejména u systémů dostupných z internetu“
Zdroj: Politika řízení zranitelností a záplat pro malé a střední podniky, požadavky na implementaci politiky, ustanovení 6.1.1

Tyto lhůty si neodporují. Záplata dodavatele pro systém dostupný z internetu může vyžadovat velmi rychlé nasazení. Produktová zranitelnost vyžadující změny kódu, regresní testování, koordinaci se zákazníky a fázované vydání může vyžadovat plán nápravy s dočasnými zmírněními. Klíčové je, aby rozhodnutí bylo dokumentované, vlastněné z hlediska rizika a schválené tam, kde zůstává zbytkové riziko.

Praktický průběh případu vypadá takto:

1. Výzkumník nahlásí bypass autorizace v zákaznickém fakturačním API.
2. VRT zaeviduje CVD-2026-014 s časovým razítkem a potvrdí přijetí do 2 pracovních dnů.
3. Produktová bezpečnost ověří chybu do 24 hodin a přiřadí vysokou závažnost kvůli přístupu k datům napříč tenanty.
4. Funkce ochrany soukromí provede posouzení porušení zabezpečení podle GDPR, protože fakturační záznamy mohou obsahovat osobní údaje.
5. Manažer incidentu otevře posouzení události podle opatření ISO/IEC 27002:2022 A.5.25.
6. Vlastník systému vypne zranitelný endpoint prostřednictvím dočasného feature flagu.
7. Engineering vytvoří hotfix podle opatření ISO/IEC 27002:2022 A.8.32, Řízení změn.
8. Jsou doplněna pravidla monitorování pro indikátory zneužití, propojená s A.8.15, Protokolování, a A.8.16, Monitorovací činnosti.
9. CISO informuje vrcholové vedení, protože problém je vysoce rizikový.
10. VRT koordinuje s výzkumníkem opakované testování a načasování zveřejnění.
11. Vlastník rizika schválí uzavření až po ověřovacím testování a přezkumu dopadu na zákazníky.
12. Aktualizují se SoA, registr rizik, tiket, logy, oznámení vedení a získané poznatky.

To je rozdíl mezi „záplatovali jsme to“ a „dokážeme prokázat, že jsme to řídili“.

Závislosti na dodavatelích a cloudu: skrytý bod selhání

Mnoho selhání CVD je ve skutečnosti maskovaným selháním dodavatelů. Zranitelnost se může týkat SaaS komponenty, cloudové služby, poskytovatele řízených bezpečnostních služeb, platební brány, autentizačního brokera, open-source knihovny, outsourcovaného vývojového týmu nebo subdodavatele.

NIS2 Article 21 vyžaduje zabezpečení dodavatelského řetězce, včetně vztahů s přímými dodavateli a poskytovateli služeb. Opatření dodavatelského řetězce mají zohledňovat zranitelnosti dodavatelů, kvalitu produktů, postupy kybernetické bezpečnosti a postupy bezpečného vývoje.

DORA Articles 28 to 30 jdou u finančních subjektů hlouběji. Vyžadují, aby riziko třetích stran v oblasti ICT bylo řízeno jako součást rámce rizik ICT, s registry smluv o ICT službách, rozlišením kritických nebo důležitých funkcí, předsmluvní náležitou péčí, smluvními bezpečnostními požadavky, asistencí při incidentech, spoluprací s orgány, právy na audit, právy na ukončení a strategiemi ukončení. Finanční subjekty zůstávají plně odpovědné za soulad s DORA i při využívání poskytovatelů ICT služeb z řad třetích stran.

Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro malé a střední podniky Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME obsahuje jednoduché eskalační pravidlo:

„Musí okamžitě informovat generálního ředitele o jakémkoli porušení bezpečnosti, změně nebo incidentu“
Zdroj: Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro malé a střední podniky, role a odpovědnosti, ustanovení 4.4.3

Pro podnikové smlouvy s dodavateli doporučuje Zenith Blueprint, fáze Opatření v praxi, krok 23, zahrnout povinnosti zachování důvěrnosti, odpovědnosti v oblasti řízení přístupu, technická a organizační opatření, lhůty hlášení incidentů, práva na audit, kontroly subdodavatelů a ustanovení pro konec smlouvy. Uvádí:

„Důležité je, že existují a že jim obě strany rozumí a přijímají je.“
Zdroj: Zenith Blueprint: 30kroková mapa auditora, fáze Opatření v praxi, krok 23: organizační opatření (5.19 až 5.37)

Připravenost dodavatelů na CVD má odpovědět na tyto otázky:

• Zveřejňuje dodavatel kanál pro hlášení zranitelností?
• Jsou ve smlouvě definovány lhůty pro oznámení zranitelností?
• Jsou kritické zranitelnosti dodavatelů hlášeny bez zbytečného odkladu?
• Jsou slabiny s dopadem na zákazníky propojeny s povinnostmi asistence při incidentech?
• Dokáže dodavatel poskytnout důkazy o nápravě nebo bezpečnostní oznámení?
• Jsou povinnosti týkající se zranitelností přeneseny na subdodavatele?
• Existuje strategie ukončení, pokud je náprava nedostatečná?

Právě zde se NIS2, DORA a ISO/IEC 27001:2022 sbíhají. Řízení zranitelností dodavatelů není zaškrtávací políčko v nákupu. Je součástí provozní odolnosti.

Mapování důkazů pro ISO 27001, NIS2, DORA, GDPR a COBIT

Nejsilnější programy CVD jsou založené na důkazech od začátku. Předpokládají, že jakékoli významné hlášení může být později přezkoumáno interním auditem, certifikačními auditory, regulačními orgány, zákazníky, pojistiteli nebo výborem pro rizika vedoucího orgánu.

Clarysec Politika monitorování auditu a souladu pro malé a střední podniky Politika monitorování auditu a souladu - SME zachycuje detail, který mnoha týmům uniká:

„Metadata (např. kdo je shromáždil, kdy a z jakého systému) musí být dokumentována.“
Zdroj: Politika monitorování auditu a souladu pro malé a střední podniky, požadavky na implementaci politiky, ustanovení 6.2.3

Snímek obrazovky záplatovaného serveru je slabý, pokud nikdo neví, kdo jej pořídil, kdy, z jakého systému a jak se mapuje na zranitelnost. Tiket s časovými razítky, výstupem skeneru, pull requestem, schválením změny, logy nasazení, monitorovacím dotazem, potvrzením opakovaného testování a metadaty je mnohem silnější.

Podrobnější matice dohledatelnosti pomáhá při prověrce ze strany klienta a interním auditu.

Různí auditoři budou tentýž proces testovat různými optikami.

Auditor ISO/IEC 27001:2022 začne u ISMS. Bude se ptát, zda jsou povinnosti zveřejňování zranitelností zahrnuty v požadavcích zainteresovaných stran, zda jsou rizika posuzována konzistentně, zda se opatření objevují v SoA, zda existují provozní důkazy a zda vedení přezkoumává trendy a zpožděné položky.

Přezkoumávající osoba podle DORA nebo ve finančních službách se zaměří na provozní odolnost. Prověří integraci rizik ICT, klasifikaci incidentů, eskalaci na vrcholové vedení, komunikaci s klienty, závislosti na třetích stranách, testování a získané poznatky. Pokud zranitelnost ovlivňuje kritickou nebo důležitou funkci, bude očekávat pevnou vazbu mezi technickým tiketem, obchodním dopadem, dopady na kontinuitu a povinnostmi dodavatelů.

Přezkum podle GDPR se zaměří na osobní údaje. Byly osobní údaje dotčeny? Došlo k neoprávněnému přístupu, ztrátě, změně nebo zpřístupnění? Byly jasné role správce a zpracovatele? Byla posouzena prahová hodnota porušení zabezpečení? Byla relevantní ochranná opatření, například šifrování, řízení přístupu, protokolování a minimalizace?

Auditor COBIT 2019 nebo ISACA se zaměří na správu a řízení, odpovědnost, výkonnost a zajištění. Bude hledat definované vlastnictví, metriky, eskalaci, cíle opatření, dohled vedení a sledování výjimek. Zpožděná kritická zranitelnost není jen technický problém. Pokud není formálně eskalována a riziko přijato, jde o problém správy a řízení.

Hodnotitel orientovaný na NIST bude uvažovat v kategoriích Identify, Protect, Detect, Respond a Recover. Bude požadovat vlastnictví aktiv, identifikaci zranitelností, prioritizaci, ochrannou změnu, detekci zneužití, koordinaci reakce a ověření obnovy.

Výhodou integrovaného modelu CVD je, že stejná důkazní páteř může podpořit všechna tato přezkoumání.

Měsíční kontrolní cyklus: metriky použitelné pro vedení

CVD nekončí uzavřením tiketu. Politika koordinovaného zveřejňování zranitelností vyžaduje průběžný přezkum evidence:

„VRT musí udržovat evidenci zveřejňování zranitelností, která sleduje každé hlášení od přijetí po uzavření. Evidence musí být měsíčně přezkoumávána, aby se zajistil včasný postup otevřených položek. Zpožděné položky musí být eskalovány.“
Zdroj: Politika koordinovaného zveřejňování zranitelností, monitorování a audit, ustanovení 9.1

Tento měsíční přezkum proměňuje zveřejňování zranitelností ve správu a řízení připravené pro vedoucí orgány. Vedení nepotřebuje každý technický detail. Potřebuje trend, expozici, odpovědnost a zpožděné riziko.

Ve vyspělé implementaci Clarysec tento měsíční přezkum evidence napájí registr rizik, Prohlášení o použitelnosti, backlog bezpečného vývoje, přezkumy dodavatelů, získané poznatky z incidentů, plán interního auditu a balíček reportů pro vedení.

Vybudujte proces dříve, než přijde závažné hlášení

Nejhorší doba pro návrh koordinovaného zveřejňování zranitelností je po tom, co výzkumník vaši slabinu veřejně zveřejní nebo kritický bankovní klient pozastaví onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, očekávání odolnosti ve stylu NIST a správa a řízení COBIT 2019 ukazují stejným směrem: zveřejňování zranitelností musí být plánované, vlastněné, testované, doložené důkazy a zlepšované.

Začněte těmito pěti kroky:

1. Přijměte nebo přizpůsobte Politiku koordinovaného zveřejňování zranitelností.
2. Vybudujte proces příjmu a triáže pomocí Zenith Blueprint, zejména krok 13 pro dohledatelnost SoA, krok 16 pro kulturu hlášení, krok 19 pro řízení technických zranitelností a krok 23 pro smlouvy s dodavateli.
3. Namapujte proces prostřednictvím Zenith Controls se zaměřením na opatření ISO/IEC 27002:2022 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 ustanovení vhodná pro malé a střední podniky z Politiky reakce na incidenty pro malé a střední podniky, Politiky řízení zranitelností a záplat pro malé a střední podniky, Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran pro malé a střední podniky, Politiky požadavků na zabezpečení aplikací pro malé a střední podniky a Politiky monitorování auditu a souladu pro malé a střední podniky tam, kde je důležitá přiměřenost.
5. Proveďte tabletop cvičení simulující hlášení výzkumníka, které se týká osobních údajů a komponenty hostované dodavatelem, a otestujte potvrzení přijetí, triáž, klasifikaci incidentu, záplatování, komunikaci se zákazníky, zachycení důkazů a eskalaci na vedení.

Clarysec vám může pomoci převést tento přístup do funkční politiky CVD, registru příjmu hlášení, mapy důkazů ISO/IEC 27001:2022, rozhodovacího stromu NIS2 a DORA, modelu eskalace na dodavatele a balíčku opatření připraveného na audit. Cíl je jednoduchý: až dorazí další hlášení zranitelnosti, váš tým nemá improvizovat. Má jednat s jistotou, důkazy a řízením.