Mapování NIS2 2024/2690 na ISO 27001 pro poskytovatele cloudových služeb

V úterý v 08:17 obdrží Maria, CISO evropského poskytovatele řízených služeb, upozornění, kterého se obává každý MSP. Jeden privilegovaný účet pro vzdálenou správu vyvolal upozornění na geograficky nemožné přihlášení. U dvou zákaznických tenantů se objevily anomální administrátorské akce. SOC již otevřelo konferenční most pro kritický incident.

V 09:00 se k hovoru připojuje CEO. Otázky se okamžitě mění.

Spadáme do rozsahu NIS2? Vztahuje se na nás prováděcí nařízení Komise (EU) 2024/2690? Musíme odeslat včasné varování do 24 hodin? Které zákazníky musíme informovat? Dokážeme doložit, že MFA, protokolování, segmentace, řízení zranitelností, dodavatelská opatření a eskalace incidentu fungovaly již před incidentem?

Mariina společnost je certifikována podle ISO/IEC 27001:2022. Poskytuje správu cloudu, služby datových center a řízenou bezpečnostní podporu zákazníkům, mezi nimiž je poskytovatel logistických služeb i regionální banka. Certifikát je důležitý, sám o sobě však neodpovídá na provozní otázky. Právní tým má návrh postupu oznamování. Manažer souladu má tabulku. Auditor si vyžádal Prohlášení o použitelnosti, testování reakce na incidenty, logy privilegovaného přístupu, prověrky dodavatelů, důkazy o sdílené odpovědnosti v cloudu a předpoklady kontinuity činností.

To je okamžik, kdy NIS2 přestává být právním textem a stává se problémem provozního řízení bezpečnostních opatření.

Pro poskytovatele služeb cloud computingu, poskytovatele řízených služeb, poskytovatele řízených bezpečnostních služeb a poskytovatele datových center zvyšují NIS2 a prováděcí nařízení 2024/2690 laťku od obecného bezpečnostního záměru k ověřitelným důkazům o fungování opatření. Správa a řízení, řízení rizik, řízení přístupu, správa aktiv, řízení zranitelností, reakce na incidenty, bezpečnost dodavatelů, protokolování, monitorování, šifrování, kontinuita činností a fyzická odolnost musí fungovat jako jeden systém.

ISO/IEC 27001:2022 je pro tento systém nejlepší páteří, ale pouze tehdy, když organizace namapuje požadavky NIS2 do ISMS, registru rizik, Prohlášení o použitelnosti, politik a modelu důkazů. Certifikát na zdi nestačí. Skutečná práce spočívá ve vybudování auditovatelné vazby od právního předpisu k riziku, od rizika k opatření, od opatření k politice a od politiky k provozním důkazům.

Proč NIS2 2024/2690 mění diskusi o souladu cloudových služeb a MSP

NIS2 používá model založený na sektoru a velikosti, její kategorie digitální infrastruktury a správy služeb ICT jsou však záměrně široké. Podle NIS2 Article 2 a Article 3 ve spojení s Annex I a Annex II může být mnoho organizací klasifikováno jako základní nebo důležité subjekty, včetně poskytovatelů služeb cloud computingu, poskytovatelů služeb datových center, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb, poskytovatelů DNS, registrů TLD, sítí pro doručování obsahu a poskytovatelů služeb vytvářejících důvěru. Členské státy musí zřídit a pravidelně přezkoumávat seznamy základních a důležitých subjektů, přičemž první lhůta pro seznamy je stanovena na 17. dubna 2025.

Je to důležité, protože poskytovatelé cloudových služeb, MSP, MSSP a datových center jsou součástí rizikových řetězců jiných organizací. Kompromitace řídicí roviny cloudu může ovlivnit tisíce zákaznických systémů. Výpadek datového centra se může kaskádově rozšířit do bankovnictví, zdravotnictví, logistiky a veřejné správy. Kompromitace přihlašovacích údajů MSP se může změnit v ransomware incident u více klientů. Selhání detekce u MSSP může zpozdit zamezení šíření incidentu u regulovaných zákazníků.

NIS2 Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření k řízení rizik kybernetické bezpečnosti a dohlížely na jejich implementaci. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření založená na přístupu zohledňujícím všechna rizika. Základní soubor zahrnuje analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování a vývoj, řízení a oznamování zranitelností, hodnocení účinnosti, kybernetickou hygienu, školení, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv, MFA nebo průběžnou autentizaci, zabezpečenou komunikaci a nouzovou komunikaci.

Article 23 doplňuje postupné hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin, průběžných zpráv na vyžádání a závěrečné zprávy do jednoho měsíce od oznámení nebo po zvládnutí incidentu, pokud incident stále probíhá.

Prováděcí nařízení 2024/2690 tato očekávání pro relevantní digitální poskytovatele konkretizuje. V praxi se orgány, zákazníci a auditoři nebudou ptát pouze na to, zda existují politiky. Budou se ptát, zda jsou opatření namapována, mají vlastníky, jsou testována a jsou doložena důkazy.

ISO/IEC 27001:2022 převádí NIS2 do provozního kontextu ISMS

Častou chybou při přípravě na NIS2 je začít rozsáhlým kontrolním seznamem a rozdělit úkoly mezi IT, právní oddělení, SOC, infrastrukturu, řízení dodavatelů a compliance. To může vyvolat aktivitu, ale při auditu často selže, protože nikdo nedokáže doložit, proč byla opatření vybrána, jak souvisejí s rizikem, kdo přijal zbytkové riziko a jaké důkazy prokazují účinnost.

ISO/IEC 27001:2022 poskytuje poskytovatelům strukturu, která tomuto selhání předchází.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace určila interní a externí otázky, identifikovala zainteresované strany a jejich požadavky, rozhodla, které požadavky budou řešeny prostřednictvím ISMS, a definovala rozsah ISMS včetně rozhraní a závislostí. U poskytovatele cloudu nebo MSP by rozsah měl výslovně zohlednit NIS2, prováděcí nařízení 2024/2690, bezpečnostní přílohy zákazníků, zákaznické požadavky vyvolané DORA, cloudové regiony, subdodavatele, závislosti datových center, platformy vzdálené správy, cesty privilegovaného přístupu a oznamovací povinnosti k incidentům.

Kapitoly 5.1 až 5.3 vyžadují vedení, sladění politik, zdroje, komunikaci, přiřazené odpovědnosti a odpovědnost vedení. Tím přímo podporují NIS2 Article 20.

Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, vlastníky rizik, analýzu pravděpodobnosti a dopadů, výběr opatření, porovnání s Annex A, Prohlášení o použitelnosti, plán ošetření rizik a formální přijetí zbytkového rizika. Zde se NIS2 stává provozní záležitostí. Každý regulační požadavek se mění na zdroj rizika, povinnost v oblasti souladu, požadavek na opatření nebo požadavek na důkaz.

Clarysec tuto práci zahajuje pomocí Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, zejména ve fázi řízení rizik.

Od kroku 13, Plánování ošetření rizik a Prohlášení o použitelnosti, Zenith Blueprint vede týmy k vybudování dohledatelnosti mezi riziky, opatřeními a regulačními zdroji:

„Křížově odkazujte právní předpisy: Pokud jsou určitá opatření implementována konkrétně za účelem souladu s GDPR, NIS2 nebo DORA, můžete to poznamenat buď v Registru rizik, nebo v poznámkách SoA. Například opatření 8.27 (bezpečné mazání dat) může být velmi relevantní pro požadavek GDPR na likvidaci osobních údajů; můžete uvést ‚Použitelné – podporuje GDPR Art.32 (zabezpečení zpracování)‘. ISO to nevyžaduje, ale pomáhá to doložit, že jste tyto rámce zohlednili.“

Krok 14, Politiky ošetření rizik a křížové odkazy na právní předpisy, doplňuje praktickou disciplínu mapování:

„Pro každý právní předpis, pokud je relevantní, můžete vytvořit jednoduchou mapovací tabulku, která uvádí klíčové bezpečnostní požadavky daného předpisu a odpovídající opatření/politiky ve vašem ISMS. V ISO 27001 to není povinné, ale jde o užitečné interní cvičení, které pomáhá zajistit, že nic nezůstalo opomenuto.“

To je rozdíl mezi tvrzením „jsme certifikováni podle ISO“ a prokázáním, že „náš ISO/IEC 27001:2022 ISMS pokrývá prováděcí nařízení NIS2 2024/2690“.

Jednotné mapování opatření NIS2 na ISO/IEC 27001:2022

Následující mapování není právním poradenstvím ani náhradou za analýzu národní transpozice. Jde o praktickou architekturu opatření pro poskytovatele, kteří potřebují auditovatelnou cestu k připravenosti na NIS2 prostřednictvím ISO/IEC 27001:2022.

Toto mapování získá sílu, když je vloženo do registru rizik a Prohlášení o použitelnosti. Poskytovatel může například vytvořit rizikový scénář „Kompromitace platformy vzdálené správy vede k neoprávněným akcím v zákaznických prostředích“. Opatření zahrnují MFA, správu privilegovaných přístupů (PAM), segmentaci, protokolování, řízení zranitelností, bezpečnost dodavatelů, plánování incidentů a postupy oznamování zákazníkům. Poznámky SoA mohou podle relevance odkazovat na NIS2 Article 21, Article 23, prováděcí nařízení 2024/2690, zákaznické smlouvy a požadavky zákaznické náležité péče podle DORA.

Správa cloudu: opatření ISO 5.23 je kotvou NIS2

Pro poskytovatele cloudových služeb a MSP, kteří používají cloudové služby k poskytování zákaznických služeb, je opatření ISO/IEC 27001:2022 Annex A 5.23, Bezpečnost informací při používání cloudových služeb, jednou z nejdůležitějších kotev.

Zenith Controls: Průvodce křížovým souladem Zenith Controls shrnuje opatření 5.23 jako preventivní kontrolu podporující důvěrnost, integritu a dostupnost, navázanou na bezpečnost vztahů s dodavateli, správu a řízení, ekosystémové riziko a ochranu. Pokrývá správu cloudových služeb, sdílenou odpovědnost, posouzení poskytovatele, evidence, umístění dat, protokolování, šifrování, identity a role, monitorování, smluvní ustanovení, dodavatelské riziko, ukončení cloudové služby a plánování odolnosti.

Zenith Blueprint, fáze Opatření v praxi, krok 23, vysvětluje praktický důvod:

„Cloud už není cílová destinace, je to výchozí stav. Opatření 5.23 tuto realitu uznává a vyžaduje, aby byla bezpečnost informací výslovně řešena při výběru, používání a správě cloudových služeb – ne jako dodatečná úvaha, ale jako návrhový princip od samého začátku.“

U MSP musí být řízena každá platforma pro vzdálené monitorování a správu, zákaznický portál, ticketovací nástroj, platforma bezpečnostní telemetrie, zálohovací služba, cloudový adresář a administrátorská konzole SaaS. U poskytovatele datového centra se správa cloudu může vztahovat na monitorovací platformy, systémy správy návštěv, integrace řízení fyzického přístupu, systémy vzdálené správy a infrastrukturu zákaznických portálů.

Podniková Politika používání cloudových služeb společnosti Clarysec Politika používání cloudových služeb stanoví povinnou náležitou péči před aktivací:

„Veškeré používání cloudu musí před aktivací projít náležitou péčí založenou na rizicích, včetně posouzení poskytovatele, validace právního souladu a validačních přezkumů opatření.“

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

Pro menší poskytovatele vytváří Cloud Usage Policy-sme Cloud Usage Policy-sme - SME zjednodušený schvalovací model:

„Veškeré používání cloudových služeb musí být před implementací nebo předplatným přezkoumáno a schváleno generálním ředitelem (GM).“

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

Oba přístupy podporují stejné očekávání NIS2: riziko závislosti na cloudu musí být pochopeno dříve, než se služba stane součástí dodavatelského řetězce.

Reakce na incidenty: 24hodinová lhůta začíná dříve, než je zpráva sepsána

NIS2 Article 23 je nekompromisní, protože časová osa hlášení začíná okamžikem, kdy si organizace významného incidentu všimne, nikoli okamžikem, kdy je k dispozici dokonalá analýza kořenové příčiny. Výzvou pro poskytovatele je rychle určit, zda je událost významná, kteří zákazníci jsou dotčeni, zda jsou zahrnuty osobní údaje, zda existuje přeshraniční dopad na službu a které smluvní lhůty byly spuštěny.

Opatření ISO/IEC 27001:2022 Annex A 5.24, Plánování a příprava řízení incidentů bezpečnosti informací, je plánovacím opatřením. Zenith Controls jej shrnuje jako nápravnou kontrolu podporující důvěrnost, integritu a dostupnost, navázanou na koncepty Respond a Recover, správu a řízení, řízení událostí a obranu. Zahrnuje role, odpovědnosti, eskalační cesty, komunikační protokoly, připravenost na regulatorní oznámení, sladění s protokolováním a monitorováním, integraci s kontinuitou činností a obnovou po havárii, poučení po incidentu a mapování na NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 a COBIT 2019.

Incident Response Policy-sme společnosti Clarysec Incident Response Policy-sme - SME převádí první rozhodnutí na časově omezený požadavek:

„Generální ředitel s podporou poskytovatele IT služeb musí klasifikovat všechny incidenty podle závažnosti do jedné hodiny od oznámení.“

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

Tato jednohodinová klasifikace podporuje provozní disciplínu potřebnou pro analýzu včasného varování NIS2 do 24 hodin, posouzení porušení zabezpečení osobních údajů podle GDPR, eskalaci vůči zákazníkům podle DORA a triáž smluvních oznámení.

Rozhodovací strom poskytovatele pro incidenty by měl odpovědět na čtyři otázky:

1. Existuje potvrzená nebo podezřelá kompromitace důvěrnosti, integrity nebo dostupnosti?
2. Ovlivňuje událost poskytování služeb, zákaznická prostředí, regulované zákazníky, osobní údaje nebo kritické funkce?
3. Mohla by způsobit závažné provozní narušení, finanční ztrátu nebo majetkovou či nemajetkovou újmu?
4. Které oznamovací povinnosti se použijí: NIS2, GDPR, zákaznické povinnosti podle DORA, smluvní SLA nebo očekávání národního regulačního orgánu?

Rozhodovací strom musí být otestován ve stolních cvičeních před skutečným incidentem.

Řízení zranitelností: prokažte snížení rizika před dopadem

NIS2 vyžaduje řízení a oznamování zranitelností. Pro zákazníky a regulační orgány je řízení zranitelností jednou z nejsnáze měřitelných oblastí opatření, protože vytváří jasné důkazy: pokrytí skenováním, lhůty pro záplatování, schválení výjimek, analýzu zneužitých zranitelností a záznamy o nápravných opatřeních.

Opatření ISO/IEC 27001:2022 Annex A 8.8, Řízení technických zranitelností, shrnuje Zenith Controls jako preventivní kontrolu napříč důvěrností, integritou a dostupností, navázanou na Identify a Protect, řízení hrozeb a zranitelností, správu a řízení, ekosystém, ochranu a obranu. Zahrnuje identifikaci zranitelností, posouzení, prioritizaci, záplatování, kompenzační opatření, integraci threat intelligence, oznamování zranitelností, odpovědnosti za cloudové a aplikační zranitelnosti, auditní důkazy a lhůty nápravy.

Podniková Politika řízení zranitelností a záplat společnosti Clarysec Politika řízení zranitelností a záplat poskytuje auditorům konkrétní model k ověření:

„Organizace musí klasifikovat všechny detekované zranitelnosti pomocí standardizované metodiky (např. CVSS v3.x) a uplatnit lhůty nápravy sladěné s kritičností pro podnikání: 5.2.1 Kritická (CVSS 9.0-10.0): Okamžitý přezkum; lhůta pro aplikaci záplaty maximálně 72 hodin. 5.2.2 Vysoká (7.0-8.9): Reakce do 48 hodin; lhůta pro aplikaci záplaty 7 kalendářních dnů. 5.2.3 Střední (4.0-6.9): Reakce do 5 dnů; lhůta pro aplikaci záplaty 30 kalendářních dnů. 5.2.4 Nízká (<4.0): Reakce do 10 dnů; lhůta pro aplikaci záplaty 60 kalendářních dnů.“

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

U poskytovatele cloudu to musí zahrnovat komponenty hypervizoru, kontejnerové obrazy, orchestrační vrstvy, zákaznická rozhraní API, CI/CD pipeline, administrátorské konzole a knihovny třetích stran. U MSP je klíčovou otázkou, zda jsou interní zranitelnosti odděleny od zranitelností spravovaných zákazníkem a zda smlouvy definují odpovědnost. U poskytovatele datového centra může rozsah zahrnovat systémy správy budov, systémy řízení přístupu, monitorovací platformy, nástroje remote hands a síťovou infrastrukturu.

Model sdílené odpovědnosti musí být dokumentován. Poskytovatel nemusí vlastnit každou záplatu, stále však musí řídit riziko, informovat zákazníka tam, kde je to vhodné, a doložit, že hranice odpovědnosti jsou pochopeny.

Protokolování, monitorování a segmentace umožňují vyšetřit incidenty

Když se incident poskytovatele začne dotýkat zákazníků, první otázky k důkazům jsou jednoduché: kdo se přihlásil, odkud, s jakým oprávněním, ke kterému tenantovi, co se změnilo, jaké logy existují a zda byly administrativní cesty segmentovány.

Podniková Politika protokolování a monitorování společnosti Clarysec Politika protokolování a monitorování vyžaduje, aby zahrnuté systémy generovaly logy potřebné pro pracovníky reagující na incidenty a pro auditory:

„Všechny zahrnuté systémy musí generovat logy zachycující: 6.1.1.1 Autentizaci uživatelů a pokusy o přístup 6.1.1.2 Aktivity privilegovaných uživatelů 6.1.1.3 Změny konfigurace 6.1.1.4 Neúspěšné pokusy o přístup nebo systémové události 6.1.1.5 Detekce malwaru a bezpečnostní upozornění 6.1.1.6 Externí komunikaci a spuštění pravidel firewallu“

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

Pro SME spoléhající na externí poskytovatele doplňuje Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME smluvní požadavek:

„Smlouvy musí vyžadovat, aby poskytovatelé uchovávali logy nejméně 12 měsíců a na vyžádání k nim poskytli přístup.“

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

Stejně důležitá je segmentace. Network Security Policy-sme Network Security Policy-sme - SME stanoví:

„Interní sítě musí být segmentovány podle funkce (např. finance, hosté, IoT, administrativní systémy).“

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

Zenith Blueprint, fáze Opatření v praxi, krok 20, poskytuje praktický auditní postup pro síťovou architekturu a segmentaci. Vede týmy k přezkoumání a dokumentaci síťového uspořádání, ověření pravidel firewallu, konfigurací IPS/IDS a vzdáleného přístupu, potvrzení, že bezpečnostní skupiny cloudu a pravidla VPC nebo podsítí odpovídají zamýšlené architektuře, vypsání interních a externích síťových služeb a ověření, že citlivé systémy nejsou dosažitelné z obecných uživatelských VLAN ani hostovských sítí.

U MSP nesmí nástroje vzdálené správy ležet v ploché kancelářské síti. U poskytovatele datového centra by rozhraní správy napájení, chlazení, řízení přístupu a zákaznických síťových služeb měla být izolována a monitorována. U poskytovatele cloudu by měl být přístup k řídicí rovině omezen prostřednictvím identity, sítě, bezpečnostního stavu zařízení a kontrol privilegovaných workflow.

Bezpečnost dodavatelů: poskytovatel je také zákazníkem

Poskytovatelé cloudových služeb, MSP, MSSP a datových center jsou dodavateli regulovaných klientů, ale současně jsou zákazníky softwarových dodavatelů, telekomunikačních operátorů, poskytovatelů identit, platforem SaaS, dodavatelů hardwaru, subdodavatelů a provozovatelů infrastruktury.

NIS2 činí zabezpečení dodavatelského řetězce klíčovým požadavkem. DORA, která se použije od 17. ledna 2025, staví řízení rizik třetích stran v oblasti ICT do centra požadavků pro finanční subjekty. NIS2 Article 4 a Recital 28 uznávají DORA jako odvětvový právní akt Unie pro finanční subjekty tam, kde se požadavky překrývají. To tlak na poskytovatele cloudových služeb a MSP nesnižuje. Naopak jej zvyšuje, protože finanční zákazníci promítají smluvní požadavky na úrovni DORA, práva na audit, testování odolnosti, exit strategie a očekávání v oblasti hlášení incidentů do dodavatelských smluv.

Podniková Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran společnosti Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran vyžaduje řízený přístup třetích stran:

„Veškerý přístup třetích stran musí být protokolován a monitorován a tam, kde je to proveditelné, segmentován prostřednictvím bastion hostů, VPN nebo Zero Trust bran.“

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

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME vyjadřuje zásadu minimálních oprávnění přímo:

„Dodavatelům musí být udělen přístup pouze k minimálním systémům a datům nezbytným k výkonu jejich funkce.“

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

Tato ustanovení se přirozeně mapují na opatření ISO/IEC 27001:2022 Annex A 5.19, 5.20, 5.21 a 5.22. Podporují také správu zpracovatelů a dílčích zpracovatelů podle GDPR, přezkumy rizik třetích stran podle DORA a zákaznické auditní dotazníky.

Kontinuita činností a odolnost datového centra: prokažte předpoklady

NIS2 Article 21 zahrnuje kontinuitu činností, správu záloh, obnovu po havárii a krizové řízení. DORA Articles 11 až 14 vyžadují pro finanční subjekty politiky kontinuity činností v oblasti ICT, plány reakce a obnovy, analýzu dopadů na obchodní činnost, politiky zálohování, postupy obnovy, cíle obnovy, testování, přezkoumání po incidentu a krizovou komunikaci.

Pro poskytovatele cloudových služeb a datových center není kontinuita složkou v šanonu. Je to architektura, kapacita, smlouvy, závislosti, důkazy o obnově a otestované předpoklady.

Podniková Politika kontinuity činností a obnovy po havárii společnosti Clarysec Politika kontinuity činností a obnovy po havárii vyžaduje každoroční BIA a přezkum po významných změnách:

„Analýza dopadů na obchodní činnost (BIA) musí být provedena alespoň jednou ročně pro všechny kritické podnikové jednotky a přezkoumána při významných změnách systémů, procesů nebo závislostí. Výstupy BIA musí definovat: 5.2.1. Maximální tolerovatelná doba výpadku (MTD) 5.2.2. Cílové doby obnovy (RTO) 5.2.3. Cílové body obnovy (RPO) 5.2.4. Kritické závislosti (systémy, dodavatelé, personál)“

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

Ve scénáři datového centra by BIA měla pokrývat napájecí přívody, UPS, generátory, smlouvy na palivo, chlazení, hasicí systémy, síťové operátory, systémy fyzického přístupu, remote hands, monitorování, náhradní hardware a komunikační kanály se zákazníky. Ve scénáři cloudu by měla pokrývat regiony, zóny dostupnosti, replikaci, neměnnost záloh, závislosti identit, DNS, certifikační autority, API brány a podpůrné systémy. Ve scénáři MSP by měla pokrývat nástroje vzdálené správy, úložiště privilegovaného přístupu, EDR konzole, ticketing, repozitáře dokumentace a nouzovou komunikaci.

ISO 22301 může posílit disciplínu řízení kontinuity činností, zatímco ISO/IEC 27005:2022 podporuje kritéria rizik, plánování ošetření, monitorování, důkazy a neustálé zlepšování. To je užitečné, protože připravenost na NIS2 vyžaduje, aby organizace spojila právní, smluvní, provozní, dodavatelské, technologické, finanční, procesní a lidské faktory do jednoho procesu řízení rizik.

Praktická riziková stopa pro narušení vzdáleného přístupu MSP

Praktický workshop může začít jedním scénářem:

„Kompromitace privilegovaného vzdáleného přístupu vede k neoprávněnému přístupu do zákaznických systémů, narušení služby, možné expozici osobních údajů a regulačním oznamovacím povinnostem.“

Vytvořte řádek v registru rizik a doplňte stopu.

Poté aktualizujte Prohlášení o použitelnosti. U každého relevantního opatření Annex A vysvětlete, proč se použije a které téma NIS2 podporuje. Nakonec shromážděte důkazy před auditem: reporty vynucení MFA, seznamy privilegovaných účtů, nastavení uchovávání logů, stav záplat RMM, upozornění SIEM, záznamy klasifikace incidentů, schválení přístupů dodavatelů a výsledky stolních cvičení.

Jak různí auditoři otestují stejné prostředí opatření

Integrovaný ISMS musí uspokojit různé pohledy na ujištění, aniž by vytvářel samostatné balíčky důkazů pro každý rámec.

Zde Zenith Controls pomáhá jako průvodce křížovým souladem. U opatření, jako jsou 5.23, 5.24 a 8.8, propojuje očekávání opatření ISO/IEC 27001:2022 s tématy NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF a ISO 22301. Cílem není vytvářet samostatné programy souladu. Cílem je jedna architektura důkazů označená podle opatření, rizika, regulačního zdroje a vlastníka.

Implementační vzorec Clarysec

U poskytovatelů cloudových služeb, MSP, MSSP a datových center by práce měla probíhat v pěti vrstvách.

Za prvé potvrďte rozsah. Určete, zda organizace a služby spadají do rozsahu NIS2, která pravidla členského státu se použijí, zda se na kategorii poskytovatele vztahuje prováděcí nařízení 2024/2690 a zda zákazníci ukládají povinnosti podle DORA, GDPR, NIST nebo odvětvově specifických předpisů.

Za druhé vybudujte kontext ISMS. Podle kapitol 4 a 5 ISO/IEC 27001:2022 identifikujte zainteresované strany, právní povinnosti, zákaznické závazky, dodavatelské závislosti, hranice služeb a odpovědnosti vedení.

Za třetí proveďte posouzení rizik a ošetření rizik podle principů ISO/IEC 27005:2022. Slučte NIS2, DORA, GDPR, smlouvy, interní politiky a rizika služeb do jednoho registru základních požadavků. Definujte kritéria rizik, vlastníky, pravděpodobnost, dopad, možnosti ošetření, výběr opatření a schválení zbytkových rizik.

Za čtvrté namapujte opatření do Prohlášení o použitelnosti. Použijte kroky 13 a 14 Zenith Blueprint k propojení rizik s opatřeními Annex A a regulačními očekáváními. Použijte Zenith Controls k pochopení, jak se opatření jako 5.23, 5.24, 8.8, 5.20 a 5.30 mapují napříč rámci a auditními pohledy.

Za páté zprovozněte důkazy. Samotné politiky nestačí. Knihovna politik Clarysec poskytuje vymahatelné požadavky na schvalování cloudu, přístup dodavatelů, protokolování, nápravu zranitelností, segmentaci sítě, klasifikaci incidentů a plánování kontinuity. Balíček důkazů prokazuje, že tyto požadavky fungují.

Další krok: proměňte tlak NIS2 v odolnost připravenou na audit

Prováděcí nařízení NIS2 2024/2690 nevyžaduje chaos. Vyžaduje dohledatelnost, vlastnictví a důkazy.

Pokud jste poskytovatel cloudových služeb, MSP, MSSP nebo provozovatel datového centra, začněte svými službami, zákazníky, závislostmi, scénáři incidentů a důkazními povinnostmi. Poté proveďte strukturované mapování NIS2 na ISO/IEC 27001:2022:

1. Potvrďte, zda váš subjekt a služby spadají do rozsahu.
2. Namapujte témata NIS2 a prováděcího nařízení do rozsahu ISMS.
3. Aktualizujte registr rizik a Prohlášení o použitelnosti.
4. Uplatněte politiky Clarysec pro používání cloudu, bezpečnost dodavatelů, protokolování, řízení zranitelností, reakci na incidenty, zabezpečení sítí a kontinuitu.
5. Použijte Zenith Blueprint Zenith Blueprint, kroky 13, 14, 20 a 23, k vytvoření dohledatelnosti a provozních důkazů.
6. Použijte Zenith Controls Zenith Controls ke křížovému mapování opatření ISO/IEC 27001:2022 proti očekáváním NIS2, DORA, GDPR, NIST a COBIT 2019.
7. Otestujte důkazy prostřednictvím simulace auditu dříve, než si je vyžádá zákazník, regulační orgán nebo certifikační auditor.

Clarysec vám může pomoci překročit rámec kontrolních seznamů souladu a vybudovat integrovaný ISMS, který obstojí pod tlakem NIS2, DORA, GDPR a zákaznických auditů. Stáhněte si příslušné sady nástrojů Clarysec, objednejte si mapovací workshop nebo požádejte o posouzení připravenosti na audit, abyste proměnili regulační složitost v obhajitelnou správu a řízení bezpečnosti a provozní odolnost.