NIS2 a ISO 27001: využijte kontroly znovu, prověřte mezery

Program ISO 27001 může NIS2 poskytnout silnou provozní strukturu: posouzení rizik, odpovědné vlastníky, kontroly, důkazy a zlepšování. Dalším krokem je posouzení požadavek po požadavku, co tato struktura skutečně pokrývá.

Pro CTO není užitečnou otázkou, zda se rámce překrývají. Jde o to, zda implementovaná kontrola chrání relevantní službu, splňuje platnou povinnost a vytváří důkazy, které tento závěr podporují. Tam, kde tyto podmínky platí, implementaci využijte znovu; tam, kde neplatí, zachovejte právní a provozní rozdíly.

Pochopte, co který rámec stanoví

ISO/IEC 27001 stanoví požadavky na systém řízení bezpečnosti informací (ISMS) s vymezeným rozsahem. Kapitoly 4–10 se týkají jeho řídicí struktury včetně ošetření rizik, hodnocení výkonnosti a zlepšování. Příloha A obsahuje 93 referenčních opatření v kategoriích organizačních, personálních, fyzických a technologických. Použitelnost opatření je založena na riziku; nejde o požadavek implementovat každé opatření stejně. Pokyny k implementaci poskytuje ISO 27002.

NIS2 je směrnice EU prováděná vnitrostátním právem (v Česku zákonem o kybernetické bezpečnosti). Použitelnost závisí na odvětví, velikosti, službě a konkrétních pravidlech pro zařazení. Přílohy I a II uvádějí relevantní odvětví, ale samotné odvětví neurčuje, zda je organizace základním, nebo důležitým subjektem. Některé subjekty spadají do působnosti bez ohledu na velikost.

Praktické rozdíly jsou tyto:

Certifikaci provádějí nezávislé certifikační orgány, nikoli ISO. Nezakládá soulad s NIS2 a NIS2 obecně nevyžaduje certifikaci ISO 27001. Vymáhání může zahrnovat dozorová opatření a sankce; certifikace ISO má jiný účel ujištění.

Začněte sladěním hranic

Porovnejte certifikovaný rozsah ISMS s právnickými osobami a službami, na které se vztahuje NIS2. Certifikát pokrývající vývojový tým může ponechat mimo svou hranici produkční provoz, jinou dceřinou společnost nebo další místa působení.

Vytvořte srovnání rozsahu, které zaznamenává:

• Dotčené právnické osoby, země, služby a základ pro jejich zařazení.
• Relevantní systémy, sítě, místa a podpůrné dodavatele.
• Rozsah ISMS, rozsah certifikátu a výjimky.
• Platné vnitrostátní požadavky, odvětvová pravidla a příslušné orgány, včetně platných registračních povinností, požadovaných údajů o subjektu, kanálů pro podání a povinností aktualizace.
• Kdo schválil posouzení použitelnosti a kdy je nutné je znovu prověřit.

Odlišujte mezeru v rozsahu od mezery v kontrolách. Produkční prostředí mimo ISMS již může mít dobré kontroly přístupu, ale tyto kontroly stále potřebují vlastnictví, posouzení a důkazy v rámci práce na NIS2.

Než budete povinnosti duplikovat, ověřte odvětvové právní předpisy. Článek 4 upravuje vztah k odvětvovým právním aktům Unie. U finančních subjektů vyžaduje vztah k DORA analýzu podle role. U provozů v Německu se seznamte s informacemi BSI k NIS2, místo abyste předpokládali, že stávající povinnosti KRITIS a povinnosti podle NIS2 jsou totožné.

Mapujte implementované kontroly, nikoli shodné názvy

Článek 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření. Jeho deset oblastí minimálních opatření poskytuje výchozí bod pro mapování, ale podobné znění je užitečným vodítkem, nikoli důkazem rovnocennosti.

Následující přehled používejte jako podněty k revizi, nikoli jako automatická prohlášení o pokrytí:

Prohlášení o aplikovatelnosti zaznamenává nezbytná opatření a zdůvodnění jejich zařazení nebo vyloučení. Není zaměnitelné s plánem ošetření rizik, zjištěními z interního auditu ani záznamy z přezkoumání vedením. Tyto artefakty používejte společně k vysvětlení návrhu i fungování.

Politika stanoví očekávání. Export konfigurace může ukázat implementaci. Výsledky revizí přístupů, tikety nápravy a záznamy o testech mohou ukázat fungování. Důkazy využívejte znovu pouze tam, kde se shoduje systém, období a cíl posouzení.

Vyhněte se pevným procentům překrytí. Pokrytí závisí na implementaci a právním rozsahu; univerzální číslo nemůže prokázat připravenost.

Vybudujte cestu hlášení incidentů, která funguje i pod tlakem

Plán reakce sladěný s ISO může podporovat detekci, omezení, vyšetřování a obnovu, aniž by definoval oznamování regulátorům. Článek 23 NIS2 přidává povinnosti hlášení významných incidentů.

Fáze hlášení podle směrnice obecně zahrnují:

• Včasné varování bez zbytečného odkladu a do 24 hodin od okamžiku, kdy se subjekt o významném incidentu dozvěděl.
• Oznámení incidentu bez zbytečného odkladu a do 72 hodin, které aktualizuje včasné varování a poskytuje prvotní posouzení.
• Závěrečnou zprávu zpravidla do jednoho měsíce od podání oznámení incidentu. U probíhajícího incidentu se v tomto okamžiku vyžaduje zpráva o pokroku a závěrečná zpráva je splatná do jednoho měsíce od vyřešení incidentu.

Průběžnou zprávu je rovněž nutné poskytnout, pokud o ni požádá CSIRT nebo příslušný orgán.

Ověřte platná vnitrostátní a odvětvová pravidla: směrnice stanoví pro poskytovatele služeb vytvářejících důvěru odlišné lhůty pro oznámení. Obecný práh výpadku nepoužívejte jako náhradu příslušných kritérií významnosti.

Jako praktické implementační doporučení vytvořte runbook hlášení, který určuje vlastníka posouzení, eskalační cestu, oprávněnou osobu pro podání, zástupce, kanál k orgánu a informace potřebné v každé fázi. Časové údaje detekce, zjištění, posouzení významnosti a podání zaznamenávejte odděleně.

Procvičte proces s neúplnými informacemi. Tým by měl být schopen podat požadované prvotní hlášení, aniž by čekal na dokončené forenzní vyšetřování. Uchovávejte podané verze, potvrzení o přijetí, podpůrná fakta a rozhodnutí o tom, zda incident dosahuje prahu.

Pokud platí i jiný režim hlášení, koordinujte vyšetřování, ale každou oznamovací povinnost posuzujte samostatně. Sdílený záznam o incidentu nečiní adresáty, spouštěče ani lhůty totožnými.

Učiňte správu a odolnost prokazatelnými

Článek 20 vyžaduje, aby řídicí orgány schvalovaly opatření k řízení kybernetických bezpečnostních rizik a dohlížely na jejich provádění. Upravuje také školení členů řídicích orgánů. Stávající přezkoumání vedením je užitečným důkazem, ale ověřte, zda výslovně zaznamenává příslušná schválení, dohled, rozhodnutí a navazující kroky.

Poskytněte vedení přehled připravený k rozhodnutí: dotčené služby, podstatná rizika, možnosti ošetření, nevyřešené výjimky a výsledky účinnosti. Zápisy z jednání, které pouze uvádějí „projednána bezpečnost“, poskytují jen málo důkazů o smysluplném dohledu. Každému schválenému opatření přidělte vlastníka a datum revize.

Podobně konkrétní přístup potřebuje kontinuita. Článek 21 zahrnuje zálohy, obnovu po havárii a krizové řízení; neukládá univerzální požadavek na certifikaci ISO 22301. Potřebnou hloubku určete podle služby, rizik a platných pravidel.

Testujte obnovu dat a obnovu služby, nejen dokončení zálohovacích úloh. Zahrňte závislosti, jako jsou služby identit, DNS, podpora dodavatelů, privilegované přihlašovací údaje a komunikace v situaci, kdy běžné prostředí není k dispozici. Dosažené výsledky obnovy a nevyřešené překážky zaznamenávejte oproti dohodnutým cílům.

Udržujte viditelný registr rozdílů

U každého požadavku zaznamenejte jeho zdroj a verzi, namapované kontroly, rozsah, odkazy na důkazy, revizora a zdůvodnění opětovného využití. Rozlišujte podložené pokrytí, částečné pokrytí, chybějící implementaci, chybějící důkazy a odůvodněné rozhodnutí o nepoužitelnosti. Absence dokumentu nemusí vždy znamenat absenci kontroly, ale vždy vyžaduje prošetření.

Každá mezera potřebuje vlastníka, požadovanou změnu, očekávané důkazy, termín a revizora, který ji uzavře. Upřednostněte selhání, která ohrožují služby nebo znemožňují časově kritické hlášení, místo abyste každý dokumentační úkol považovali za stejně naléhavý.

Mezi časté chyby patří mapování pouze přílohy A při přehlížení požadavků na správu, přijetí certifikátu dodavatele bez ověření jeho rozsahu, považování loňských důkazů za aktuální a uzavření úkolu ve chvíli, kdy je politika zveřejněna, ale proces zůstává neotestovaný. Registrace ani certifikace by nikdy neměly být považovány za důkaz provozní implementace.

Modelový příklad: rozšíření stávajícího ISMS

Ilustrativní předpoklady: poskytovatel řízených služeb má ISMS certifikovaný podle ISO 27001, který pokrývá jeho hlavní provozní tým. Jeho posouzení použitelnosti dospěje k závěru, že služba provozovaná prostřednictvím další právnické osoby podléhá NIS2. Tato osoba používá stejnou platformu identit a stejný tým pro incidenty, ale samostatná opatření pro obnovu.

Tým nejprve porovná hranice služeb. Stávající konfigurace autentizace mohou podporovat oba rozsahy, ale revizor ověří, zda jsou zahrnuti administrátoři, nouzové účty a servisní účty další právnické osoby. Export z revize přístupů, který pokrývá pouze původní tým, nemůže prokázat úplné pokrytí.

Dále vlastník incidentů ponechá zavedený postup reakce a doplní posouzení významného incidentu a cestu pro oznámení orgánům. Simulační cvičení (tabletop) simuluje výpadek dodavatele s nejistým dopadem na zákazníky. Účastníci zaznamenají, kdy se dozvěděli relevantní fakta, kdo rozhodl o významnosti a jak by bylo podáno včasné varování.

Nakonec vlastník infrastruktury provede cvičení obnovy pro službu další právnické osoby. Test odhalí, že přihlašovací údaje pro obnovu závisejí na nedostupné platformě identit. Registr mezer přidělí nápravné opatření a před uzavřením vyžaduje úspěšný opakovaný test.

Výslednými výstupy jsou srovnání rozsahu, zrevidovaná mapování, rozšířené důkazy z revizí přístupů, záznamy z cvičení hlášení, výsledky obnovy a schválení zbývajících opatření k ošetření ze strany vedení. Sdílené kontroly zůstávají sdílené; důkazy a rozhodnutí specifické pro jednotlivé subjekty zůstávají viditelné.

Převeďte posouzení do udržované práce

Model propojených požadavků a důkazů v Secani dává týmům strukturu pro zachování sdílené práce i rozhodnutí specifických pro jednotlivé rámce. Namodelujte služby a závislosti, připojte existující důkazy k relevantním kontrolám a z chybějícího pokrytí vytvořte úkoly s vlastníky. U mapování a závěrů z důkazů, včetně návrhů s podporou AI, ponechte lidské schválení výslovné. Náš průvodce dohledatelným mapováním napříč rámci vysvětluje, jak zachovat zdůvodnění opětovného využití.

Začněte jednou regulovanou službou. Přineste její rozsah, ošetření rizik, prohlášení o aplikovatelnosti, runbook pro incidenty a nedávné důkazy z testů na společnou technickou a compliance revizi. Vytvořte zrevidovaný registr rozdílů a poté jej v běžných revizních cyklech ISMS udržujte, jak se mění služby, dodavatelé a požadavky.