Od skenů k důkazům: ISO 27001:2022, NIS2, DORA

Je pondělí 08:16. Na řídicím panelu pro aplikační server dostupný z internetu se právě objevila kritická zranitelnost umožňující vzdálené spuštění kódu. Tým infrastruktury uvádí, že záplata dodavatele je k dispozici. Vlastník aplikace upozorňuje, že server podporuje zákaznický proces kritický z hlediska výnosů. Právní oddělení se ptá, zda by zneužití mohlo vyvolat oznamovací povinnosti podle NIS2, DORA nebo GDPR. Ředitelka informační bezpečnosti Maria otevře kalendář auditů a vidí skutečný problém: dozorový audit ISO 27001:2022 začíná příští týden, přezkum připravenosti na NIS2 již probíhá a významný fintech zákazník požádal o důkazy pro DORA.

Skener ukazuje červenou. Tabule tiketů ukazuje aktivitu. Tabulka ukazuje vynaložené úsilí. Nic z toho však samo o sobě neprokazuje, že kontrolní opatření funguje.

Právě tuto mezeru mnoho organizací zjistí příliš pozdě. Skenování zranitelností není totéž jako auditní připravenost řízení zranitelností. Sken říká, že něco může být špatně. Auditní důkazy prokazují, že organizace věděla, jaká aktiva má, posoudila riziko, přiřadila vlastnictví, postupovala podle politiky, řídila změnu, zdokumentovala výjimky, ověřila výsledky a přezkoumala výsledek.

Pro ISO/IEC 27001:2022, NIS2 a DORA je tento důkazní řetězec stejně důležitý jako technická oprava. Skener příběh zahajuje. Evidence aktiv, registr zranitelností, tiket, rozhodnutí o riziku, záznam změny, log záplat, důkaz o ověření, schválení výjimky a přezkoumání vedením jej dokončují.

Přístup Clarysec je jednoduchý: nepovažujte řízení zranitelností za měsíční technický rituál. Považujte je za řízený pracovní postup založený na důkazech.

Proč zprávy ze skenů selhávají jako auditní důkazy

Sken zranitelností je technické zjištění k určitému okamžiku. Může identifikovat CVE, chybějící záplatu, nepodporovanou knihovnu, vystavenou službu nebo slabou konfiguraci. Je užitečný, ale neúplný.

Auditor bude klást jiné otázky:

• Bylo dotčené aktivum v rozsahu?
• Kdo vlastní aktivum a obchodní službu?
• Byla zranitelnost posouzena podle expozice, zneužitelnosti, obchodního dopadu a citlivosti dat?
• Bylo nápravné opatření dokončeno ve stanovené lhůtě?
• Pokud byla náprava odložena, kdo přijal zbytkové riziko?
• Byla záplata nasazena prostřednictvím řízeného procesu řízení změn?
• Byla oprava ověřena opakovaným skenem nebo technickou validací?
• Byly důkazy uchovány a přezkoumány vedením?

Složka exportů ze skeneru na tyto otázky odpovídá jen zřídka. Při auditu ISO 27001:2022 auditor ověřuje, zda ISMS funguje tak, jak byl navržen. Podle NIS2 musí řídicí orgány schvalovat opatření pro řízení rizik kybernetické bezpečnosti a vykonávat nad nimi dohled. Podle DORA potřebují finanční subjekty zdokumentovaný rámec řízení rizik v oblasti ICT, životní cyklus incidentů, testování odolnosti a kontroly rizik třetích stran v oblasti ICT. Podle GDPR se otázka mění na to, zda osobní údaje chránila vhodná technická a organizační opatření a zda lze doložit odpovědnost.

ISO/IEC 27001:2022 články 4.1 až 4.4 vyžadují, aby organizace porozuměla svému kontextu, zainteresovaným stranám, požadavkům a rozsahu ISMS. Řízení zranitelností a záplat nelze navrhovat izolovaně. Musí zohledňovat zákaznické smlouvy, regulační orgány, závislosti na cloudu, outsourcované služby ICT, povinnosti v oblasti ochrany údajů a kritické služby.

ISO/IEC 27001:2022 články 6.1.1 až 6.1.3 vyžadují posuzování rizik, ošetření rizik, výběr bezpečnostních opatření, Prohlášení o použitelnosti a schválení zbytkového rizika vlastníkem rizika. To znamená, že důkazy ke zranitelnostem mají být propojeny s registrem rizik, plánem ošetření rizik a SoA.

ISO/IEC 27005:2022 tento model posiluje tím, že organizace vede ke konsolidaci požadavků z Annex A, odvětvových povinností, právních předpisů, smluv, interních pravidel a existujících opatření do výchozí základny pro posouzení rizik. Zároveň zdůrazňuje kritéria pravděpodobnosti, následku, právních povinností, dodavatelských vztahů, dopadu na soukromí a dopadu na třetí strany. Prakticky řečeno, zranitelnost není jen číslo CVSS. Je to riziková událost propojená s aktivy, povinnostmi, zainteresovanými stranami a obchodními důsledky.

Regulační tlak na důkazy o záplatování

Moderní regulace kybernetické bezpečnosti je k neformálnímu záplatování méně tolerantní.

NIS2 se vztahuje na mnoho středních a velkých subjektů ve vysoce kritických a kritických odvětvích a může dopadat také na určité subjekty bez ohledu na velikost. Její rozsah zahrnuje poskytovatele digitální infrastruktury, například služby cloud computingu, služby datových center, sítě pro doručování obsahu, poskytovatele veřejných elektronických komunikací, služby vytvářející důvěru, služby DNS a registry jmen domén nejvyšší úrovně, a dále poskytovatele správy služeb ICT, jako jsou poskytovatelé řízených služeb a poskytovatelé řízených bezpečnostních služeb. Zahrnuje také důležité digitální poskytovatele, například online tržiště, internetové vyhledávače a platformy sociálních sítí.

Article 20 NIS2 stanoví kybernetickou bezpečnost jako odpovědnost řídicího orgánu. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování, bezpečného vývoje, bezpečné údržby, řízení a oznamování zranitelností, posuzování účinnosti, kybernetické hygieny, řízení přístupu, správy aktiv a autentizace. Article 23 zavádí postupné oznamování významných incidentů, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy do jednoho měsíce, je-li to relevantní.

DORA od 17. ledna 2025 vytváří přímo použitelný soubor pravidel digitální provozní odolnosti pro finanční subjekty. Zahrnuje řízení rizik v oblasti ICT, oznamování významných incidentů v oblasti ICT, testování provozní odolnosti, sdílení informací o kybernetických hrozbách, řízení rizik třetích stran v oblasti ICT a dohled nad kritickými poskytovateli služeb ICT z řad třetích stran. Articles 5 a 6 svěřují řízení rizik ICT řídicímu orgánu a vyžadují zdokumentovaný, integrovaný a pravidelně přezkoumávaný rámec řízení rizik v oblasti ICT. Article 8 posiluje potřebu identifikovat obchodní funkce podporované ICT, informační aktiva, aktiva ICT a závislosti. Articles 17 až 20 vyžadují detekci, zaznamenávání, klasifikaci, eskalaci, hlášení, komunikaci, nápravu a poučení z incidentů souvisejících s ICT. Articles 28 až 30 vyžadují, aby rizika třetích stran v oblasti ICT byla řízena prostřednictvím registrů, náležité péče, smluvních ochranných mechanismů, práv na audit, plánování ukončení spolupráce a dohledu.

U finančních subjektů spadajících pod DORA DORA obecně nahrazuje rovnocenné povinnosti NIS2 v oblasti řízení rizik a oznamování. NIS2 však zůstává důležitá pro koordinaci ekosystému a pro subjekty mimo rozsah DORA. Pro poskytovatele SaaS, MSP a MSSP obsluhující finanční klienty je praktická realita přímá: zákazníci mohou požadovat vaše důkazy ke zranitelnostem, aby splnili své povinnosti podle DORA.

GDPR přidává další vrstvu. Articles 2 a 3 se mohou vztahovat na organizace usazené v EU i na organizace mimo EU, které nabízejí zboží nebo služby osobám v EU nebo monitorují jejich chování. Article 5 vyžaduje ochranu osobních údajů a odpovědnost za soulad. Article 4 definuje porušení zabezpečení osobních údajů jako bezpečnostní incident vedoucí k náhodné nebo protiprávní ztrátě, zničení, změně, neoprávněnému zpřístupnění osobních údajů nebo přístupu k nim. Odložená záplata databáze, platformy identit nebo zákaznického portálu se může stát otázkou odpovědnosti v oblasti ochrany soukromí.

Od politiky k důkazu

Prvním krokem je definovat pravidla. Silná politika řízení zranitelností a záplat není jen auditním dokumentem. Je provozní ústavou daného kontrolního opatření.

Pro podniková prostředí Politika řízení zranitelností a záplat výslovně propojuje technické záplatování s průřezovým souladem:

Tato politika podporuje soulad s ISO/IEC 27001 Annex A Control 8.8 a pokyny ISO/IEC 27002 a řeší regulační požadavky podle DORA Article 8, NIS2 Article 21, GDPR Article 32 a domén COBIT 2019 DSS a APO.

Ze sekce „Účel“.

Stejná politika stanoví očekávání v oblasti správy a řízení pro klíčový důkazní artefakt:

Tým bezpečnostního provozu musí vést centralizovaný registr zranitelností a ředitel informační bezpečnosti nebo delegovaná oprávněná osoba jej musí měsíčně přezkoumávat.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.1.

Zároveň definuje periodicitu skenování:

Všechny systémy musí být skenovány nejméně jednou měsíčně; aktiva s vysokým rizikem nebo externě vystavená aktiva musí být skenována týdně.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

A brání tomu, aby se urgentní záplatování změnilo v neřízenou technickou činnost:

Veškeré nápravné činnosti musí být koordinovány prostřednictvím procesu řízení změn (podle P5 - Politika řízení změn), aby byla zajištěna stabilita a zachování auditní stopy.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.5.

U malých a středních podniků lze stejné principy důkazů zavést jednodušeji. Politika řízení zranitelností a záplat pro malé a střední podniky uvádí:

Vést přesné záznamy o aplikovaných záplatách, nevyřešených problémech a výjimkách, aby byla zajištěna připravenost na audit.

Ze sekce „Cíle“, ustanovení politiky 3.4.

Následně definuje log záplat jako auditní důkaz:

Log záplat musí být veden a přezkoumáván během auditů a činností reakce na incidenty.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.1.

A stanoví minimální obsah:

Logy musí obsahovat název zařízení, aplikovanou aktualizaci, datum záplatování a důvod případného zpoždění.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.2.

Pro urgentní expozici dostupnou z internetu stanoví politika pro malé a střední podniky měřitelný požadavek:

Kritické záplaty musí být aplikovány do 3 dnů od vydání, zejména u systémů dostupných z internetu.

Z Politiky řízení zranitelností a záplat pro malé a střední podniky, sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Tato ustanovení mění technickou práci na důkazy. Politika stanoví očekávání. Registr zaznamenává zjištění. Tiket přiřazuje práci. Záznam změny řídí nasazení. Log záplat prokazuje provedené opatření. Registr rizik zachycuje výjimky. Zápisy z přezkoumání dokládají dohled.

Model Clarysec založený na důkazech

Model Clarysec založený na důkazech vychází z jedné zásady: každé zjištění zranitelnosti musí být dohledatelné od zjištění po rozhodnutí.

V Zenith Blueprint: 30krokový plán auditora fáze Controls in Action, krok 19: Technological Controls I, pojímá řízení zranitelností jako opakovatelnou kontrolu, nikoli jako teoretický požadavek:

Řízení zranitelností je jednou z nejkritičtějších oblastí moderní kybernetické hygieny. Firewally a antivirové nástroje poskytují ochranu, ale pokud zůstanou vystaveny nezáplatované systémy nebo nesprávně nakonfigurované služby, může být tato ochrana oslabena.

Stejný krok vysvětluje, že organizace mají používat pravidelné harmonogramy záplatování, skenery zranitelností, triáž, přiřazení, sledování nápravy, kompenzační opatření a přijetí zbytkového rizika. Nejdůležitější je, že správně nastavuje auditní pohled:

Kontrola není o dokonalosti; jde o organizovaný, transparentní a odpovědný proces.

Pro auditory je toto rozlišení zásadní. Zralá organizace může mít otevřené zranitelnosti a přesto doložit, že má proces pod kontrolou, pokud má prioritizaci založenou na rizicích, zdokumentované vlastnictví, schválené výjimky, kompenzační opatření a ověřenou nápravu.

Zenith Blueprint také upozorňuje, že auditoři tuto oblast prověří detailně:

Toto je pro auditory kontrola s vysokou prioritou a obvykle půjdou do hloubky. Očekávejte otázky, jak často systémy záplatujete, jaký proces používáte při oznámení zero-day zranitelnosti a které systémy se záplatují nejobtížněji.

Proto by ředitel informační bezpečnosti neměl přijít k auditu pouze s řídicím panelem skeneru. Balíček důkazů musí ukázat správu a řízení, proces, provedení, ověření a zlepšování.

Mapování opatření ISO 27002 na auditní důkazy

Zenith Controls: průvodce průřezovým souladem funguje jako kompas průřezového souladu tím, že mapuje opatření ISO/IEC 27002:2022 a ukazuje jejich vztah k auditním očekáváním. Pro řízení zranitelností a záplat tvoří tři opatření ISO/IEC 27002:2022 provozní trojúhelník.

ISO/IEC 27002:2022 control 8.8, Řízení technických zranitelností, je hlavním kontrolním opatřením. Je preventivní, podporuje důvěrnost, integritu a dostupnost, je v souladu s koncepty kybernetické bezpečnosti Identify a Protect a navazuje na řízení hrozeb a zranitelností.

ISO/IEC 27002:2022 control 8.32, Řízení změn, je rovněž preventivní. Propojuje záplatování s řízeným nasazením, testováním, schvalováním, vrácením změn a auditovatelností.

ISO/IEC 27002:2022 control 5.36, Soulad s politikami, pravidly a normami bezpečnosti informací, zajišťuje, že proces není volitelný ani závislý na individuálním hrdinství. Propojuje řízení zranitelností s dodržováním politik, ujištěním a dohledem.

Toto mapování předchází běžnému auditnímu selhání. Bezpečnost říká: „Záplatovali jsme to.“ Provoz říká: „Nasadili jsme to.“ Compliance říká: „Nedokážeme prokázat posloupnost.“ Namapovaný důkazní řetězec dává všem třem týmům stejný příběh.

Důkazní řetězec, který auditoři očekávají

Obhajitelný důkazní řetězec řízení zranitelností má sedm fází.

Praktický rozdíl mezi „provádíme skeny“ a „jsme připraveni na audit“ je kontinuita. Pokud zranitelnost nelze dohledat od zjištění po uzavření, kontrolní opatření je slabé. Pokud existují výjimky, ale nikdo je neschválil, proces je slabý. Pokud záplaty obcházejí řízení změn, auditní stopa je slabá. Pokud kritické zranitelnosti zůstávají otevřené bez kompenzačních opatření, správa a řízení je slabá.

Politika monitorování auditu a souladu podporuje automatizaci jako součást tohoto modelu:

Pro monitorování souladu konfigurace, řízení zranitelností, stavu záplat a privilegovaného přístupu musí být nasazeny automatizované nástroje.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Pro malé a střední podniky Politika monitorování auditu a souladu pro malé a střední podniky definuje ověřování technických kontrol prakticky:

Technické ověření kontrolních opatření (např. stav zálohování, konfigurace řízení přístupu, záznamy o záplatách).

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.2.

Malé organizace nepotřebují podnikové nástroje, aby byly připravené na audit. Potřebují konzistentní důkazy. Lehký registr, ticketovací tabule, log záplat a měsíční přezkum mohou stačit, pokud jsou úplné, aktuální a navázané na riziko.

Příklad: jedno kritické zjištění plně připravené na audit

Mariin týdenní externí sken identifikuje CVE-2026-12345 na platební API bráně dostupné z internetu. Skener ji hodnotí jako kritickou. Služba zpracovává identitu zákazníků a metadata transakcí, takže jsou možné dopady podle GDPR a DORA. Bránu vlastní Platform Engineering, ale záplata vyžaduje krátký výpadek.

Auditně připravený pracovní postup vypadá následovně.

1. Vytvořit záznam v registru zranitelností

Bezpečnostní tým zaznamená zjištění do centrálního registru:

• ID zjištění: VULN-2026-0142
• Zdroj: týdenní externí sken
• Datum a čas zjištění
• Aktivum: api-gw-prod-01
• Vlastník: Platform Engineering
• Expozice: dostupné z internetu
• Kontext dat: identita zákazníků a metadata transakcí
• Závažnost: kritická
• SLA: 72 hodin nebo přísněji podle politiky
• Tiket: SEC-4821
• Záznam změny: CHG-10988
• Stav: náprava naplánována

2. Provést triáž s využitím obchodního a regulačního kontextu

Tým ověří dostupnost exploitu, útočnou plochu, požadavky na autentizaci, obchodní dopad a citlivost dat. Protože systém je dostupný z internetu a podporuje zákaznické procesy, zranitelnost zůstává kritická. Vlastníkem rizika je Head of Platform a ředitel informační bezpečnosti je informován kvůli možným dopadům podle NIS2, DORA a GDPR.

ISO/IEC 27005:2022 články 7.1 až 7.4 podporují identifikaci rizik, vlastnictví, dopad, pravděpodobnost a prioritizaci. Články 8.2 až 8.6 podporují výběr způsobu ošetření, určení kontrolních opatření, vazbu na SoA, plánování ošetření a schválení zbytkového rizika.

3. Otevřít řízenou nouzovou změnu

Záplata je naplánována na tentýž večer. Záznam změny obsahuje referenci dodavatele, dotčené služby, testovací plán, plán návratu do původního stavu, okno údržby, rozhodnutí o komunikaci se zákazníky, schválení a požadavek na validaci po nasazení.

To přímo podporuje ISO/IEC 27002:2022 control 8.32 a požadavek podnikové politiky koordinovat nápravu prostřednictvím řízení změn.

4. Aplikovat záplatu a aktualizovat log záplat

Log záplat zaznamená název zařízení, aplikovanou aktualizaci, datum záplatování a případný důvod zpoždění. Pokud by záplatování bylo odloženo, tým by zdokumentoval kompenzační opatření, například pravidla WAF, dočasná omezení přístupu, rozšířené protokolování, izolaci nebo posílené monitorování.

5. Ověřit a uzavřít

Bezpečnost znovu oskenuje API bránu. Zranitelnost se již neobjevuje. Tiket je aktualizován o důkaz čistého skenu, verzi záplaty, časové razítko nasazení a odkaz na záznam změny. Stav v registru zranitelností se změní na „Uzavřeno, ověřeno“.

6. Přezkoumat dopad na oznamování

Pokud nedošlo ke zneužití ani k přerušení služby, oznamování incidentu podle NIS2 nebo DORA nemusí být spuštěno. Pokud jsou nalezeny indikátory kompromitace, proces řízení incidentů musí klasifikovat dopad a eskalaci. Podle NIS2 může významný incident vyžadovat včasné varování a postupné hlášení. Podle DORA vyžaduje významný incident související s ICT klasifikaci a hlášení prostřednictvím příslušného procesu příslušnému orgánu.

7. Promítnout poznatky do přezkoumání vedením

Na konci měsíce přezkum ředitele informační bezpečnosti uvádí, že zranitelnost byla detekována týdenním externím skenováním, odstraněna v rámci SLA, ověřena opakovaným skenem a uzavřena bez incidentu. Pokud se podobné problémy opakují, plán ošetření rizik může zahrnovat bezpečné výchozí konfigurace, automatizované nasazování záplat, eskalaci vůči dodavateli nebo modernizaci aplikace.

Když se auditor zeptá na CVE-2026-12345, Maria může místo e-mailů a snímků obrazovky předložit připravený balíček.

To je auditní připravenost. Ne proto, že by organizace neměla žádné zranitelnosti, ale proto, že měla proces pod kontrolou.

Jedna sada důkazů, více povinností

Dobře navržený program řízení zranitelností a záplat může splnit požadavky více rámců bez duplicitní práce.

Pro ISO 27001:2022 důkazy podporují ISMS založený na rizicích, implementaci opatření Annex A, Prohlášení o použitelnosti, plány ošetření rizik, interní audit a neustálé zlepšování. Pokud je ISO/IEC 27002:2022 control 8.8 použitelný v SoA, organizace by měla být schopna ukázat právní, regulační, rizikové nebo obchodní odůvodnění. Toto odůvodnění často zahrnuje NIS2 Article 21, povinnosti DORA v oblasti rizik ICT, odpovědnost podle GDPR, zákaznické smlouvy a potřeby provozní odolnosti.

Pro NIS2 stejné důkazy pomáhají prokázat opatření podle Article 21, včetně analýzy rizik, řízení zranitelností, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, kybernetické hygieny, řízení přístupu a posuzování účinnosti. Article 20 se dokládá přezkumem ředitelem informační bezpečnosti, reportováním správní radě, schválením vedením a školením kybernetické bezpečnosti. Article 23 se stává relevantním, pokud zneužití způsobí nebo by mohlo způsobit závažné provozní narušení, finanční ztrátu nebo újmu jiným osobám.

Pro DORA důkazy o zranitelnostech a záplatách podporují rámec řízení rizik v oblasti ICT, dohled řídicího orgánu, strategii odolnosti, detekci a klasifikaci incidentů, testování odolnosti a dohled nad třetími stranami v oblasti ICT. Pokud poskytovatel ICT hostuje nebo spravuje dotčený systém, Articles 28 až 30 vyžadují náležitou péči, smluvní ochrany, práva na audit, podporu při incidentech a zohlednění ukončení spolupráce.

Pro GDPR stejné důkazy podporují odpovědnost podle Article 5 a úroveň zabezpečení očekávanou podle Article 32. Pokud zranitelnost vede k neoprávněnému přístupu, změně, ztrátě nebo zpřístupnění osobních údajů, časová osa zranitelnosti, záznamy o záplatách, monitorovací logy a poznámky k posouzení porušení se stávají zásadními.

Pro COBIT 2019 a assurance podle stylu ISACA se řízení zranitelností posuzuje prostřednictvím provozní bezpečnosti, monitorování kontrol, umožnění změn a odpovědnosti správy a řízení. Odkazy na průřezový soulad v Zenith Blueprint uvádějí COBIT 2019 DSS05.04 a BAI09.02 a také očekávání ITAF assurance vůči řízení zranitelností, záplatování a bezpečnému řízení změn.

Podpůrné normy ISO posilují provozní model. ISO/IEC 27005:2022 podporuje posuzování a ošetření rizik. ISO/IEC 27035:2023 podporuje reakci na incidenty při zneužití zranitelností. ISO/IEC 30111 podporuje procesy zpracování zranitelností. ISO/IEC 29147 podporuje oznamování zranitelností a bezpečnostní oznámení. ISO/IEC 27017 podporuje řízení zranitelností v cloudu. ISO 22301 podporuje plánování kontinuity tam, kde by technické zranitelnosti mohly narušit obchodní služby.

Jak různí auditoři testují stejný proces

Různí hodnotitelé používají různé pohledy. Důkazy mohou být stejné, ale otázky se mění.

Politika říká, co se má stát. Provozní důkazy ukazují, co se skutečně stalo. Záznamy z přezkumu ukazují, že vedení vědělo, zpochybňovalo a jednalo.

Běžné důvody, proč řízení záplat neprojde auditem

Většina zjištění nevzniká kvůli absenci skeneru. Vzniká kvůli přerušené dohledatelnosti.

Evidence aktiv je neúplná.
Pokud skener najde aktiva, která chybí v CMDB nebo registru aktiv, vlastnictví a obchodní dopad nelze spolehlivě posoudit. To oslabuje rozsah ISO 27001:2022, posouzení rizik a ošetření rizik.

Zranitelnosti jsou sledovány pouze ve skeneru.
Řídicí panely skenerů nejsou registry správy a řízení. Často jim chybí schválení vlastníka rizika, odůvodnění výjimky, odkazy na změny a obchodní kontext.

Kritická zjištění nemají důkazy o SLA.
Politika může říkat, že kritické zranitelnosti se opravují do tří dnů. Auditní otázka zní, zda záznamy prokazují, že se to stalo.

Výjimky jsou neformální.
Starší systémy, omezení odstávek a zpoždění dodavatelů se stávají. Ale „nemohli jsme to zazáplatovat“ se musí změnit na zdokumentovanou výjimku s kompenzačními opatřeními, datem expirace a schválením zbytkového rizika.

Nouzové záplatování obchází řízení změn.
Nouzové změny jsou stále změny. Pokud neexistují důkazy o schválení, testování nebo návratu do původního stavu, auditoři mohou dojít k závěru, že náprava vytvořila provozní riziko.

Systémy třetích stran nejsou viditelné.
Podle NIS2 a DORA jsou rizika dodavatelů a třetích stran v oblasti ICT klíčová. Pokud platformu záplatuje poskytovatel, stále potřebujete důkazy, smluvní práva, reportování služby a eskalační cesty.

Nikdo nepřezkoumává trendy.
Opakující se zranitelnosti mohou ukazovat na slabé řízení konfigurace, nedostatečné postupy bezpečného vývoje, nepodporovaná aktiva nebo selhání dodavatele. Měsíční přezkum mění technická data na opatření správy a řízení.

Auditní balíček Clarysec pro zranitelnosti

Pro nadcházející přezkum připravenosti na ISO 27001:2022, NIS2 nebo DORA pomáhá Clarysec organizacím sestavit auditní balíček řízení zranitelností a záplat s těmito položkami:

• Politika řízení zranitelností a záplat, včetně rozsahu, rolí, periodicity skenování, SLA pro záplaty a pravidel výjimek
• Výpis evidence aktiv ukazující systémy v rozsahu, vlastníky, kritičnost a expozici
• Nejnovější interní a externí zprávy ze skenů zranitelností
• Centrální registr zranitelností s otevřenými, uzavřenými položkami a položkami výjimek
• Logy záplat uvádějící zařízení, aktualizaci, datum záplaty a důvody zpoždění
• Záznamy změn pro vzorkované kritické a vysoce závažné zranitelnosti
• Důkazy o opakovaných skenech nebo validaci po nápravě
• Schválení výjimek a zbytkového rizika u odložených nebo nezáplatovatelných systémů
• Proces monitorování bezpečnostních oznámení pro dodavatele, knihovny a cloudové služby
• Měsíční zápisy z přezkoumání ředitelem informační bezpečnosti nebo vedením
• Crosswalk na povinnosti ISO 27001:2022, NIS2, DORA, GDPR a COBIT 2019
• Výsledky interního auditu nebo technického ověření kontrolních opatření

Ve Zenith Blueprint, fázi Audit, Review & Improvement, kroku 24, Clarysec zdůrazňuje dohledatelnost mezi Prohlášením o použitelnosti, registrem rizik a plánem ošetření rizik:

Vaše SoA má být konzistentní s registrem rizik a plánem ošetření rizik. Znovu ověřte, že každé opatření, které jste zvolili jako ošetření rizika, je v SoA označeno jako „Použitelné“.

To je obzvlášť důležité pro řízení zranitelností. Pokud je control 8.8 použitelné, auditní balíček má prokázat nejen to, že skenování probíhá, ale také to, že zjištění jsou řízena prostřednictvím ošetření rizik a neustálého zlepšování.

30denní sprint připravenosti

Pokud se audit blíží, nezačínejte přepisováním všeho. Začněte rychlým vytvořením důkazů.

Tento sprint neodstraní veškerý technický dluh. Změní však auditní rozhovor. Namísto obhajování neuspořádaného exportu ze skeneru můžete ukázat řízený proces s vlastníky, termíny, opatřeními, rozhodnutími a dohledem.

Přejděte od skenů k obhajitelným důkazům

Auditní připravenost řízení zranitelností a záplat není o prokazování, že nemáte žádné zranitelnosti. Je o prokázání, že je umíte najít, porozumět jim, prioritizovat je, opravit je, řídit výjimky a doložit dohled.

Zenith Blueprint, Zenith Controls, Politika řízení zranitelností a záplat, Politika řízení zranitelností a záplat pro malé a střední podniky, Politika monitorování auditu a souladu a Politika monitorování auditu a souladu pro malé a střední podniky od Clarysec poskytují strukturu pro vybudování tohoto důkazního pracovního postupu.

Pokud se vaše organizace připravuje na certifikaci ISO 27001:2022, připravenost na NIS2, digitální provozní odolnost podle DORA, náležitou péči zákazníků nebo interní audit, začněte jednou otázkou:

Lze každou kritickou zranitelnost dohledat od skenu po uzavření?

Pokud je odpověď ne, Clarysec vám pomůže vybudovat registr, sadu politik, mapování průřezového souladu, balíček přezkoumání vedením a auditovatelný důkazní pracovní postup, který promění technické skenování v obhajitelnou správu a řízení.