Zeptejte se infrastrukturního týmu, jak u nich vypadá NIS2 compliance evidence, a obvykle dostanete balík směrnic: bezpečnostní politika, plán reakce na incidenty, dotazník pro dodavatele, vše podepsané a verzované. Ty dokumenty mají smysl, ale nejsou to důkazy. Popisují, co máte v úmyslu dělat. Důkaz je záznam o tom, co jste skutečně udělali - kdo změnil pravidlo firewallu, kdy, na čí pokyn a jaká byla konfigurace předtím. Posuzovatel chce to druhé, a přesně v té mezeře je většině týmů nepříjemně.
Krátká rekapitulace, o čem se bavíme. NIS2, formálně směrnice (EU) 2022/2555, měla transpoziční lhůtu do 17. října 2024 a národní zákony od té doby přicházejí každý ve svém tempu. Rozšířila působnost daleko za původní kategorie NIS, výslovně vtáhla dodavatelské řetězce a připnula povinnosti přímo vedení, ne abstraktní organizaci. Pokud cokoli dodáváte subjektu v působnosti, počítejte s tím, že jeho povinnosti dorazí na váš stůl jako smluvní ustanovení, ať už v působnosti jste, nebo ne.
Co směrnice ve skutečnosti požaduje
Článek 21 vyjmenovává opatření k řízení rizik: politiky analýzy rizik a bezpečnosti informačních systémů, zvládání incidentů, kontinuitu činností a zálohování, bezpečnost dodavatelského řetězce, bezpečnost při pořizování a vývoji, postupy pro hodnocení účinnosti, základní kybernetickou hygienu a školení, kryptografii, řízení přístupu a evidenci aktiv a vícefaktorovou autentizaci. Čtěte ten seznam jako sadu otázek, na které budete muset odpovědět záznamy. Každá položka končí u posuzovatele stejným dotazem: ukažte mi to. Ukažte mi obnovenou zálohu, odebraný přístup, schválenou změnu.
Článek 23 je ten, který mění inženýrskou praxi, ne papírování. Včasné varování do 24 hodin od okamžiku, kdy jste se o významném incidentu dozvěděli. Podrobnější oznámení do 72 hodin, včetně prvotního posouzení závažnosti a dopadu. Závěrečná zpráva do jednoho měsíce. Ty lhůty běží od okamžiku, kdy jste se o incidentu dozvěděli, takže časová osa detekce je sama součástí důkazů. Když neumíte říct, kdy jste to věděli, neumíte doložit, že jste hlásili včas - a časovou osu složenou po týdnu z paměti nikomu neprodáte.
NIS2 compliance evidence je záznam, ne směrnice
Takhle prakticky vypadá to, co posuzovatel chce. Seznam systémů v působnosti a kdo za každý z nich odpovídá. Záznam změn bezpečnostně relevantní konfigurace za dané období. Doklad, že přístup byl udělen, přezkoumán a odebrán, s daty. Důkaz, že zálohy se nejen dělaly, ale i obnovovaly. A ke každému významnému incidentu obhajitelná časová osa: detekce, eskalace, zvládnutí, ohlášení. Všechno datované, přiřaditelné konkrétní identitě a získané odjinud než z něčí vzpomínky.
Nepříjemná pravda je, že skoro všechno tohle už v každé firmě někde existuje. Je to v ticketovacím systému, v chatovém kanálu, ve třech konzolích, v historii terminálu jednoho inženýra a v tabulce. Compliance práce se pak mění v archeologii: dva týdny někdo rekonstruuje, co se stalo, z artefaktů, které nikdy nebyly zamýšlené jako důkaz. Je to drahé, demotivující a vzniká z toho dokument, kterému úplně nevěří nikdo - včetně toho, kdo ho poskládal.
Vlastnost, která z logu dělá důkaz
Z logu se stává důkaz ve chvíli, kdy je append-only a odolný vůči nepozorované změně. Ten rozdíl je podstatnější, než zní. Tabulka, kterou může administrátor přepsat, je záznamem toho, čemu chce administrátor, abyste věřili. Posuzovatel chce posloupnost, ve které je jakákoli změna staršího záznamu odhalitelná, aniž by musel důvěřovat provozovateli systému - včetně nás. Právě tahle vlastnost mění „tady jsou naše logy“ v něco, o co se třetí strana může opřít, ne to jen převzít.
Audit trail v Sencai je append-only a zřetězený hashem. Každý záznam nese svůj vlastní hash a hash záznamu předchozího, takže záznamy tvoří řetěz, ne hromadu. CSV export obsahuje obě hodnoty, entry_hash a prev_hash, což znamená, že váš auditor nemusí nic brát na naše slovo. Řetěz si může přepočítat sám, offline, vlastním skriptem, a ověřit, jestli sedí. Kdyby byl jediný záznam pozměněný nebo odstraněný, přepočet od toho místa dál přestane odpovídat.
Otázky na dodavatelský řetězec, které přijdou
Článek 21 dává bezpečnost dodavatelského řetězce mezi opatření a článek 20 činí vedení osobně odpovědným za jejich schválení a dohled nad nimi - proto tyhle otázky dnes přicházejí s reálnou vahou. Počítejte s dotazy, kteří subdodavatelé se dotýkají vašich dat, v jakých jurisdikcích působí, jak byste odhalili kompromitaci vzniklou u některého z nich a jak rychle byste ho dokázali odstavit. Když dnes neumíte vyjmenovat své providery, neodpovíte na nic z toho - a neúplná evidence je nejrychlejší způsob, jak tuhle sekci neustát.
Tady přestává být izolace per organizace a skutečný model rolí produktovou funkcí a stává se odpovědí na auditní otázku. Kdo může zakládat infrastrukturu, kdo ji smí jen prohlížet, kdo koho a kdy pozval a které z těch pozvánek byly opravdu přijaty, ne jen odeslány - to jsou otázky s datem. Totéž platí pro konfiguraci, která vás reálně chrání: pravidla firewallů, hranice sítí a DNS záznamy, každý se záznamem, kdo je u providera změnil a kdy.
Jak se připravit bez compliance oddělení
Začněte tím, že si sepíšete otázky, na které byste v místnosti s posuzovatelem odpovídali těžko. Obvykle jsou čtyři: co provozujeme, kdo na to smí sáhnout, co se změnilo minulé čtvrtletí a jak cokoli z toho doložíme. Pak opravte zaznamenávání, ne reportování. Systém, který odpovědi zachycuje průběžně, jak práce probíhá, stojí v ten moment skoro nic; rekonstrukce zpětně stojí týdny, a to pokaždé znovu. NIS2 tuhle mezeru nevytvořila - jen ji prodražila.
Nic z toho neudělá compliance příjemnou. Změní to ale její tvar. Důkazy, které umíte vyexportovat, předat auditorovi a nechat ho je nezávisle ověřit, jsou úplně jiná konverzace než složka screenshotů a slib, že se v ní nic neupravovalo. Přesně na tuhle laťku jsme to stavěli: vaše prostředí na jednom místě, změny zaznamenané ve chvíli, kdy se dějí, a export navržený tak, aby ho zkontroloval někdo, jehož celá práce je pochybovat.