Mapovanie NIS2 2024/2690 na ISO 27001 pre poskytovateľov cloudových služieb

V utorok o 08:17 dostáva Maria, CISO európskeho poskytovateľa riadených služieb, upozornenie, ktorého sa obáva každý MSP. Jeden privilegovaný účet na vzdialenú správu vyvolal upozornenia na fyzicky nemožné prihlásenie z rôznych lokalít. Dvaja zákaznícki tenanti vykazujú abnormálne administrátorské aktivity. SOC už otvorilo krízový komunikačný most pre kritický incident.

O 09:00 sa k hovoru pripája CEO. Otázky sa okamžite menia.

Patríme do rozsahu NIS2? Vzťahuje sa na nás vykonávacie nariadenie Komisie (EÚ) 2024/2690? Potrebujeme 24-hodinové včasné varovanie? Ktorých zákazníkov musíme informovať? Vieme preukázať, že MFA, logovanie, segmentácia, riadenie zraniteľností, kontroly dodávateľov a eskalácia incidentov fungovali už pred incidentom?

Mariina spoločnosť je certifikovaná podľa ISO/IEC 27001:2022. Zákazníkom, medzi ktorých patrí logistický poskytovateľ a regionálna banka, poskytuje správu cloudu, služby dátového centra a riadenú bezpečnostnú podporu. Certifikát je dôležitý, ale sám osebe neodpovedá na prevádzkové otázky. Právny tím má návrh procesu oznamovania. Manažér súladu má tabuľkový prehľad. Audítor si vyžiadal Vyhlásenie o uplatniteľnosti, testovanie reakcie na incidenty, logy privilegovaného prístupu, due diligence dodávateľov, dôkazy o modeli zdieľanej zodpovednosti v cloude a predpoklady kontinuity činností.

Toto je okamih, keď NIS2 prestáva byť právnym textom a stáva sa problémom prevádzkových kontrol.

Pre poskytovateľov cloudových služieb, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb a poskytovateľov dátových centier zvyšujú NIS2 a vykonávacie nariadenie 2024/2690 latku zo všeobecného bezpečnostného zámeru na preukázateľné kontrolné dôkazy. Správa a riadenie, riadenie rizík, riadenie prístupu, správa aktív, riešenie zraniteľností, reakcia na incidenty, bezpečnosť dodávateľov, logovanie, monitorovanie, šifrovanie, kontinuita činností a fyzická odolnosť musia fungovať ako jeden systém.

ISO/IEC 27001:2022 je najlepšou kostrou takého systému, ale iba vtedy, ak organizácia premietne požiadavky NIS2 do ISMS, registra rizík, Vyhlásenia o uplatniteľnosti, politík a dôkazového modelu. Certifikát na stene nestačí. Skutočná práca spočíva vo vybudovaní auditovateľnej väzby od predpisu k riziku, od rizika ku kontrole, od kontroly k politike a od politiky k prevádzkovým dôkazom.

Prečo NIS2 2024/2690 mení diskusiu o súlade pre cloud a MSP

NIS2 používa model založený na sektore a veľkosti, no jej kategórie digitálnej infraštruktúry a riadenia IKT služieb sú zámerne široké. Podľa NIS2 Article 2 a Article 3 v spojení s Annex I a Annex II môžu byť mnohé organizácie klasifikované ako základné alebo dôležité subjekty vrátane poskytovateľov cloudových služieb, poskytovateľov služieb dátových centier, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, poskytovateľov DNS, registrov TLD, sietí na doručovanie obsahu a poskytovateľov dôveryhodných služieb. Členské štáty musia vytvoriť a pravidelne preskúmavať zoznamy základných a dôležitých subjektov, pričom prvý termín pre zoznam je stanovený na 17. apríla 2025.

Je to dôležité, pretože poskytovatelia cloudových služieb, MSP, MSSP a poskytovatelia dátových centier sú súčasťou rizikových reťazcov iných organizácií. Kompromitácia riadiacej roviny cloudu môže ovplyvniť tisíce zákazníckych systémov. Výpadok dátového centra sa môže kaskádovo preniesť do bankovníctva, zdravotníctva, logistiky a verejnej správy. Kompromitácia prihlasovacích údajov MSP sa môže zmeniť na ransomvérový incident s dopadom na viacerých klientov. Zlyhanie detekcie na strane MSSP môže oddialiť zamedzenie šírenia u regulovaných zákazníkov.

NIS2 Article 20 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík a dohliadali na ich implementáciu. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia založené na prístupe zohľadňujúcom všetky hrozby. Základná úroveň zahŕňa analýzu rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečné nadobúdanie a vývoj, riešenie a zverejňovanie zraniteľností, hodnotenie účinnosti, kybernetickú hygienu, školenia, kryptografiu, bezpečnosť v oblasti ľudských zdrojov, riadenie prístupu, správu aktív, MFA alebo priebežnú autentifikáciu, bezpečnú komunikáciu a núdzovú komunikáciu.

Article 23 dopĺňa etapové nahlasovanie významných incidentov vrátane včasného varovania do 24 hodín, oznámenia incidentu do 72 hodín, priebežných správ na požiadanie a záverečnej správy do jedného mesiaca po oznámení alebo po vyriešení incidentu, ak incident stále prebieha.

Vykonávacie nariadenie 2024/2690 robí tieto očakávania konkrétnejšími pre relevantných digitálnych poskytovateľov. V praxi sa orgány, zákazníci a audítori nebudú pýtať iba na to, či politiky existujú. Budú sa pýtať, či sú kontroly namapované, majú vlastníkov, boli testované a sú podložené dôkazmi.

ISO/IEC 27001:2022 premieňa NIS2 na prevádzkový kontext ISMS

Bežnou chybou pri príprave na NIS2 je začať rozsiahlym kontrolným zoznamom a priradiť úlohy naprieč IT, právnym oddelením, SOC, infraštruktúrou, riadením dodávateľov a súladom. To môže vytvoriť aktivitu, ale pri audite to často zlyhá, pretože nikto nevie preukázať, prečo boli kontroly vybrané, ako súvisia s rizikom, kto akceptoval zvyškové riziko a aké dôkazy potvrdzujú účinnosť.

ISO/IEC 27001:2022 poskytuje poskytovateľom štruktúru, ktorá tomuto zlyhaniu predchádza.

Články 4.1 až 4.4 vyžadujú, aby organizácia určila interné a externé otázky, identifikovala zainteresované strany a ich požiadavky, rozhodla, ktoré požiadavky budú riešené prostredníctvom ISMS, a definovala rozsah ISMS vrátane rozhraní a závislostí. Pre poskytovateľa cloudových služieb alebo MSP by mal rozsah výslovne zohľadňovať NIS2, vykonávacie nariadenie 2024/2690, bezpečnostné dodatky zákazníkov, požiadavky zákazníkov vyvolané DORA, cloudové regióny, subdodávateľov, závislosti od dátového centra, platformy vzdialenej správy, cesty privilegovaného prístupu a oznamovacie povinnosti pri incidentoch.

Články 5.1 až 5.3 vyžadujú vedenie, zosúladenie politík, zdroje, komunikáciu, pridelené zodpovednosti a zodpovednosť manažmentu. To priamo podporuje NIS2 Article 20.

Články 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, vlastníkov rizík, analýzu pravdepodobnosti a následkov, výber kontrol, porovnanie s Prílohou A, Vyhlásenie o uplatniteľnosti, plán ošetrenia rizík a formálnu akceptáciu zvyškového rizika. Tu sa NIS2 stáva prevádzkovou realitou. Každá regulačná požiadavka sa mení na zdroj rizika, povinnosť súladu, požiadavku na kontrolu alebo požiadavku na dôkaz.

Clarysec začína túto prácu s Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint, najmä vo fáze riadenia rizík.

Od kroku 13, plánovanie ošetrenia rizík a Vyhlásenie o uplatniteľnosti, Zenith Blueprint usmerňuje tímy, aby budovali sledovateľnosť medzi rizikami, kontrolami a regulačnými spúšťačmi:

„Krížovo odkazujte predpisy: Ak sú určité kontroly implementované špecificky na dosiahnutie súladu s GDPR, NIS2 alebo DORA, môžete to uviesť buď v registri rizík, alebo v poznámkach SoA. Napr. kontrola 8.27 (bezpečné vymazanie údajov) môže byť veľmi relevantná pre požiadavku GDPR na likvidáciu osobných údajov; môžete uviesť ‚Uplatniteľné – podporuje GDPR Art.32 (bezpečnosť spracúvania)‘. ISO to nevyžaduje, ale pomáha to preukázať, že ste tieto rámce zohľadnili.“

Krok 14, politiky ošetrenia rizík a regulačné krížové odkazy, pridáva praktickú disciplínu mapovania:

„Pre každý predpis, ak je relevantný, môžete vytvoriť jednoduchú mapovaciu tabuľku, ktorá uvádza kľúčové bezpečnostné požiadavky predpisu a zodpovedajúce kontroly/politiky vo vašom ISMS. V ISO 27001 to nie je povinné, ale je to užitočné interné cvičenie, ktoré pomáha zabezpečiť, aby nič neprepadlo medzi trhlinami.“

To je rozdiel medzi vyhlásením „sme certifikovaní podľa ISO“ a preukázaním „náš ISMS podľa ISO/IEC 27001:2022 rieši vykonávacie nariadenie NIS2 2024/2690“.

Jednotná mapa kontrol NIS2 na ISO/IEC 27001:2022

Nasledujúce mapovanie nie je právnym poradenstvom ani náhradou analýzy národnej transpozície. Ide o praktickú architektúru kontrol pre poskytovateľov, ktorí potrebujú auditovateľnú cestu podľa ISO/IEC 27001:2022 k pripravenosti na NIS2.

Toto mapovanie získava hodnotu vtedy, keď je vložené do registra rizík a Vyhlásenia o uplatniteľnosti. Poskytovateľ môže napríklad vytvoriť rizikový scenár s názvom „Kompromitácia platformy vzdialenej správy vedie k neoprávneným akciám v zákazníckych prostrediach“. Kontroly zahŕňajú MFA, správu privilegovaných prístupov, segmentáciu, logovanie, riadenie zraniteľností, bezpečnosť dodávateľov, plánovanie incidentov a postupy oznamovania zákazníkom. Poznámky SoA môžu podľa potreby odkazovať na NIS2 Article 21, Article 23, vykonávacie nariadenie 2024/2690, zákaznícke zmluvy a požiadavky due diligence zákazníkov podľa DORA.

Správa a riadenie cloudu: kontrola ISO 5.23 je kotvou NIS2

Pre poskytovateľov cloudových služieb a MSP, ktorí používajú cloudové služby na poskytovanie služieb zákazníkom, je kontrola ISO/IEC 27001:2022 Príloha A 5.23, Informačná bezpečnosť pri používaní cloudových služieb, jednou z najdôležitejších kotiev.

Zenith Controls: Sprievodca krížovým súladom Zenith Controls sumarizuje kontrolu 5.23 ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť, prepojenú s bezpečnosťou dodávateľských vzťahov, správou a riadením, rizikom ekosystému a ochranou. Zahŕňa správu a riadenie cloudových služieb, zdieľanú zodpovednosť, posúdenie poskytovateľa, inventáre, umiestnenie údajov, logovanie, šifrovanie, roly identít, monitorovanie, zmluvné doložky, dodávateľské riziko, ukončenie cloudu a plánovanie odolnosti.

Zenith Blueprint, fáza Controls in Action, krok 23, vysvetľuje praktický dôvod:

„Cloud už nie je cieľom, je predvoleným stavom. Kontrola 5.23 túto realitu uznáva a vyžaduje, aby sa informačná bezpečnosť výslovne riešila pri výbere, používaní a riadení cloudových služieb – nie dodatočne, ale ako návrhový princíp od úplného začiatku.“

Pre MSP musí byť riadená každá platforma vzdialeného monitorovania a správy, zákaznícky portál, tiketovací nástroj, platforma bezpečnostnej telemetrie, zálohovacia služba, cloudový adresár a administrátorská konzola SaaS. Pre poskytovateľa dátového centra sa správa a riadenie cloudu môže vzťahovať na monitorovacie platformy, systémy správy návštev, integrácie riadenia fyzického prístupu, systémy vzdialenej správy a infraštruktúru zákazníckeho portálu.

Podniková Politika používania cloudových služieb spoločnosti Clarysec Politika používania cloudových služieb vyžaduje povinnú due diligence pred aktiváciou:

„Každé používanie cloudu musí pred aktiváciou prejsť due diligence založenou na riziku vrátane posúdenia poskytovateľa, overenia súladu s právnymi požiadavkami a preskúmania validácie kontrol.“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.2.

Pre menších poskytovateľov vytvára Cloud Usage Policy-sme Cloud Usage Policy-sme - SME jednoduchý schvaľovací model:

„Každé používanie cloudových služieb musí byť pred implementáciou alebo predplatným preskúmané a schválené generálnym manažérom (GM).“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.1.

Oba prístupy podporujú rovnaké očakávanie NIS2: riziko závislosti od cloudu musí byť pochopené skôr, ako sa služba stane súčasťou dodávateľského reťazca.

Reakcia na incidenty: 24-hodinový časový limit začína plynúť pred napísaním správy

NIS2 Article 23 je nekompromisný, pretože lehota na oznámenie začína plynúť od momentu, keď sa organizácia dozvie o významnom incidente, nie až od okamihu, keď je k dispozícii dokonalá analýza koreňovej príčiny. Výzvou pre poskytovateľov je rýchlo určiť, či je udalosť významná, ktorí zákazníci sú zasiahnutí, či ide o osobné údaje, či existuje cezhraničný dopad na službu a ktoré zmluvné lehoty sa spustili.

Kontrola ISO/IEC 27001:2022 Príloha A 5.24, plánovanie a príprava riadenia incidentov informačnej bezpečnosti, je plánovacou kontrolou. Zenith Controls ju sumarizuje ako nápravnú kontrolu podporujúcu dôvernosť, integritu a dostupnosť, prepojenú s konceptmi reakcie a obnovy, správou a riadením, riadením udalostí a obranou. Zahŕňa roly, zodpovednosti, eskalačné postupy, komunikačné protokoly, pripravenosť na regulačné oznámenia, zosúladenie s logovaním a monitorovaním, integráciu s kontinuitou činností a obnovou po havárii, poučenie po incidente a mapovanie na NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 a COBIT 2019.

Incident Response Policy-sme spoločnosti Clarysec Incident Response Policy-sme - SME premieňa prvé rozhodnutie na časovo ohraničenú požiadavku:

„Generálny manažér, so vstupmi od poskytovateľa IT služieb, musí klasifikovať všetky incidenty podľa závažnosti do jednej hodiny od oznámenia.“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.3.1.

Táto hodinová klasifikácia podporuje prevádzkovú disciplínu potrebnú pre analýzu 24-hodinového včasného varovania podľa NIS2, posúdenie porušenia ochrany osobných údajov podľa GDPR, eskaláciu zákazníkom podľa DORA a triáž zmluvných oznámení.

Rozhodovací strom poskytovateľa pre incidenty by mal odpovedať na štyri otázky:

1. Ide o potvrdenú alebo podozrivú kompromitáciu dôvernosti, integrity alebo dostupnosti?
2. Ovplyvňuje udalosť poskytovanie služby, zákaznícke prostredia, regulovaných zákazníkov, osobné údaje alebo kritické funkcie?
3. Mohla by spôsobiť závažné prevádzkové narušenie, finančnú stratu alebo materiálnu či nemateriálnu škodu?
4. Ktoré oznamovacie povinnosti sa uplatňujú: NIS2, GDPR, zákaznícke povinnosti podľa DORA, zmluvné SLA alebo očakávania národného regulátora?

Rozhodovací strom by mal byť otestovaný v stolových cvičeniach ešte pred skutočným incidentom.

Riadenie zraniteľností: preukážte zníženie rizika pred dopadom

NIS2 vyžaduje riešenie a zverejňovanie zraniteľností. Pre zákazníkov a regulátorov je riadenie zraniteľností jednou z najľahšie merateľných oblastí kontrol, pretože vytvára jasné dôkazy: pokrytie skenovaním, lehoty záplatovania, schválenia výnimiek, analýzu zneužitých zraniteľností a záznamy o náprave.

Kontrola ISO/IEC 27001:2022 Príloha A 8.8, riadenie technických zraniteľností, je v Zenith Controls sumarizovaná ako preventívna kontrola naprieč dôvernosťou, integritou a dostupnosťou, prepojená s Identify a Protect, riadením hrozieb a zraniteľností, správou a riadením, ekosystémom, ochranou a obranou. Zahŕňa identifikáciu zraniteľností, posúdenie, prioritizáciu, záplatovanie, kompenzačné kontroly, integráciu spravodajstva o hrozbách, zverejňovanie zraniteľností, zodpovednosti za cloudové a aplikačné zraniteľnosti, auditné dôkazy a lehoty nápravy.

Podniková Politika riadenia zraniteľností a záplat spoločnosti Clarysec Politika riadenia zraniteľností a záplat poskytuje audítorom konkrétny model na testovanie:

„Organizácia musí klasifikovať všetky zistené zraniteľnosti pomocou štandardizovanej metodiky (napr. CVSS v3.x) a uplatňovať lehoty nápravy zosúladené s kritickosťou pre činnosť organizácie: 5.2.1 Kritická (CVSS 9.0-10.0): okamžité preskúmanie; maximálna lehota záplatovania 72 hodín. 5.2.2 Vysoká (7.0-8.9): reakcia do 48 hodín; lehota záplatovania 7 kalendárnych dní. 5.2.3 Stredná (4.0-6.9): reakcia do 5 dní; lehota záplatovania 30 kalendárnych dní. 5.2.4 Nízka (<4.0): reakcia do 10 dní; lehota záplatovania 60 kalendárnych dní.“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.2.

Pre poskytovateľa cloudových služieb to musí zahŕňať hypervízorové komponenty, kontajnerové obrazy, orchestračné vrstvy, zákaznícky dostupné rozhrania API, CI/CD pipeliny, administrátorské konzoly a knižnice tretích strán. Pre MSP je kľúčovou otázkou, či sú interné zraniteľnosti oddelené od zraniteľností spravovaných zákazníkom a či zmluvy definujú zodpovednosť. Pre poskytovateľa dátového centra môže rozsah zahŕňať systémy správy budov, systémy riadenia prístupu, monitorovacie platformy, nástroje vzdialenej technickej podpory a sieťovú infraštruktúru.

Model zdieľanej zodpovednosti musí byť zdokumentovaný. Poskytovateľ nemusí vlastniť každú záplatu, ale stále musí riadiť riziko, podľa potreby informovať zákazníka a preukázať, že hranice zodpovednosti sú pochopené.

Logovanie, monitorovanie a segmentácia robia incidenty vyšetriteľnými

Keď sa incident poskytovateľa začne prejavovať u zákazníkov, prvé dôkazové otázky sú jednoduché: kto sa prihlásil, odkiaľ, s akým oprávnením, do ktorého tenanta, čo sa zmenilo, aké logy existujú a či boli administrátorské cesty segmentované.

Podniková Politika logovania a monitorovania spoločnosti Clarysec Politika logovania a monitorovania vyžaduje, aby zahrnuté systémy generovali logy, ktoré pracovníci reakcie a audítori potrebujú:

„Všetky zahrnuté systémy musia generovať logy zachytávajúce: 6.1.1.1 autentifikáciu používateľov a pokusy o prístup 6.1.1.2 aktivity privilegovaných používateľov 6.1.1.3 zmeny konfigurácie 6.1.1.4 neúspešné pokusy o prístup alebo systémové udalosti 6.1.1.5 detekcie malvéru a bezpečnostné upozornenia 6.1.1.6 externú komunikáciu a spúšťače pravidiel firewallu“

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.1.1.

Pre MSP spoliehajúce sa na externých poskytovateľov pridáva Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME zmluvnú požiadavku:

„Zmluvy musia vyžadovať, aby poskytovatelia uchovávali logy najmenej 12 mesiacov a na požiadanie poskytli prístup.“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.5.1.3.

Rovnako dôležitá je segmentácia. Network Security Policy-sme Network Security Policy-sme - SME uvádza:

„Interné siete musia byť segmentované podľa funkcie (napr. financie, hosťovská sieť, IoT, administratívne systémy).“

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.2.1.

Zenith Blueprint, fáza Controls in Action, krok 20, poskytuje praktický audítorský postup pre sieťovú architektúru a segmentáciu. Tímom nariaďuje preskúmať a zdokumentovať sieťové usporiadanie, overiť pravidlá firewallu, konfigurácie IPS/IDS a vzdialeného prístupu, potvrdiť, že cloudové bezpečnostné skupiny a pravidlá VPC alebo podsietí zodpovedajú zamýšľanej architektúre, uviesť interné a externé sieťové služby a validovať, že citlivé systémy nie sú dostupné zo všeobecných používateľských VLAN ani hosťovských sietí.

Pre MSP nesmú byť nástroje vzdialenej správy umiestnené naplocho v kancelárskej sieti. Pre poskytovateľa dátového centra by mali byť riadiace rozhrania pre napájanie, chladenie, riadenie prístupu a zákaznícke sieťové služby izolované a monitorované. Pre poskytovateľa cloudových služieb by mal byť prístup k riadiacej rovine obmedzený prostredníctvom identity, siete, bezpečnostného stavu zariadenia a kontrol privilegovaných pracovných tokov.

Bezpečnosť dodávateľov: poskytovateľ je zároveň zákazníkom

Poskytovatelia cloudových služieb, MSP, MSSP a poskytovatelia dátových centier sú dodávateľmi regulovaných klientov, ale zároveň sú zákazníkmi softvérových dodávateľov, telekomunikačných operátorov, poskytovateľov identít, SaaS platforiem, dodávateľov hardvéru, subdodávateľov a prevádzkovateľov infraštruktúry.

NIS2 robí z bezpečnosti dodávateľského reťazca základnú požiadavku. DORA, ktorá sa uplatňuje od 17. januára 2025, robí z riadenia rizík tretích strán v oblasti IKT centrálnu tému pre finančné subjekty. NIS2 Article 4 a Recital 28 uznávajú DORA ako odvetvovo špecifický právny akt Únie pre finančné subjekty tam, kde sa požiadavky prekrývajú. To neznižuje tlak na poskytovateľov cloudových služieb a MSP. Zvyšuje ho, pretože finanční zákazníci prenášajú zmluvné požiadavky na úrovni DORA, práva na audit, testovanie odolnosti, stratégie ukončenia a očakávania nahlasovania incidentov do dodávateľských zmlúv.

Podniková Bezpečnostná politika tretích strán a dodávateľov spoločnosti Clarysec Bezpečnostná politika tretích strán a dodávateľov vyžaduje riadený prístup tretích strán:

„Všetok prístup tretích strán musí byť logovaný a monitorovaný a, kde je to realizovateľné, segmentovaný cez bastiónové servery, VPN alebo brány Zero Trust.“

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.3.2.

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME vyjadruje zásadu minimálnych oprávnení priamo:

„Dodávateľom musí byť udelený prístup iba k minimálnym systémom a údajom potrebným na výkon ich funkcie.“

Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.2.1.

Tieto ustanovenia sa prirodzene mapujú na kontroly ISO/IEC 27001:2022 Príloha A 5.19, 5.20, 5.21 a 5.22. Podporujú aj správu sprostredkovateľov a ďalších sprostredkovateľov podľa GDPR, preskúmania rizík tretích strán podľa DORA a zákaznícke auditné dotazníky.

Kontinuita činností a odolnosť dátového centra: preukážte predpoklady

NIS2 Article 21 zahŕňa kontinuitu činností, riadenie zálohovania, obnovu po havárii a krízové riadenie. DORA Articles 11 až 14 vyžadujú pre finančné subjekty politiky kontinuity činností v oblasti IKT, plány reakcie a obnovy, analýzu vplyvu na podnikanie, politiky zálohovania, postupy obnovy, ciele obnovy, testovanie, poincidentné revízie a krízovú komunikáciu.

Pre poskytovateľov cloudových služieb a poskytovateľov dátových centier kontinuita nie je šanón. Je to architektúra, kapacita, zmluvy, závislosti, dôkazy obnovy a otestované predpoklady.

Podniková Politika kontinuity činností a obnovy po havárii spoločnosti Clarysec Politika kontinuity činností a obnova po havárii vyžaduje ročnú BIA a preskúmanie po významných zmenách:

„Analýza vplyvu na podnikanie (BIA) sa musí vykonať najmenej raz ročne pre všetky kritické obchodné jednotky a preskúmať pri významných zmenách systémov, procesov alebo závislostí. Výstupy BIA musia definovať: 5.2.1. maximálne tolerovateľné trvanie výpadku (MTD) 5.2.2. cieľové časy obnovy (RTO) 5.2.3. cieľové body obnovy (RPO) 5.2.4. kritické závislosti (systémy, dodávatelia, personál)“

Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.2.

V scenári dátového centra by BIA mala pokrývať napájacie prívody, UPS, generátory, zmluvy na palivo, chladenie, protipožiarne systémy, sieťových operátorov, systémy fyzického prístupu, vzdialenú technickú podporu, monitorovanie, náhradný hardvér a zákaznícke komunikačné kanály. V cloudovom scenári by mala pokrývať regióny, zóny dostupnosti, replikáciu, nemennosť záloh, závislosti identít, DNS, certifikačné autority, API brány a podporné systémy. V scenári MSP by mala pokrývať nástroje vzdialenej správy, trezory privilegovaného prístupu, konzoly EDR, tiketovanie, dokumentačné repozitáre a núdzovú komunikáciu.

ISO 22301 môže posilniť disciplínu riadenia kontinuity činností, zatiaľ čo ISO/IEC 27005:2022 podporuje kritériá rizík, plánovanie ošetrenia, monitorovanie, dôkazy a neustále zlepšovanie. Je to užitočné, pretože pripravenosť na NIS2 vyžaduje, aby organizácia konsolidovala právne, zmluvné, prevádzkové, dodávateľské, technologické, finančné, procesné a ľudské faktory do jedného rizikového procesu.

Praktická sledovateľnosť rizika pri narušení vzdialeného prístupu MSP

Praktický workshop sa môže začať jedným scenárom:

„Kompromitácia privilegovaného vzdialeného prístupu vedie k neoprávnenému prístupu k zákazníckym systémom, prerušeniu služieb, možnému sprístupneniu osobných údajov a regulačným oznamovacím povinnostiam.“

Vytvorte riadok v registri rizík a doplňte sledovateľnosť.

Následne aktualizujte Vyhlásenie o uplatniteľnosti. Pri každej relevantnej kontrole Prílohy A vysvetlite, prečo sa uplatňuje a ktorú tému NIS2 podporuje. Napokon ešte pred auditom zhromaždite dôkazy: reporty o uplatňovaní MFA, zoznamy privilegovaných účtov, nastavenia uchovávania logov, stav záplat RMM, upozornenia SIEM, záznamy klasifikácie incidentov, schválenia prístupu dodávateľov a výsledky stolových cvičení.

Ako rôzni audítori otestujú rovnaké kontrolné prostredie

Integrovaný ISMS musí uspokojiť rôzne pohľady uistenia bez vytvárania samostatných balíkov dôkazov pre každý rámec.

Tu pomáha Zenith Controls ako sprievodca krížovým súladom. Pri kontrolách ako 5.23, 5.24 a 8.8 prepája očakávania kontrol ISO/IEC 27001:2022 s témami NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF a ISO 22301. Cieľom nie je vytvoriť samostatné programy súladu. Cieľom je jedna dôkazová architektúra označená podľa kontroly, rizika, regulačného spúšťača a vlastníka.

Implementačný vzor Clarysec

Pre poskytovateľov cloudových služieb, MSP, MSSP a poskytovateľov dátových centier by práca mala prebiehať v piatich vrstvách.

Najprv potvrďte rozsah. Určte, či organizácia a služby patria do rozsahu NIS2, ktoré pravidlá členského štátu sa uplatňujú, či sa vykonávacie nariadenie 2024/2690 vzťahuje na kategóriu poskytovateľa a či zákazníci ukladajú povinnosti podľa DORA, GDPR, NIST alebo odvetvovo špecifické povinnosti.

Po druhé, vybudujte kontext ISMS. Podľa článkov 4 a 5 ISO/IEC 27001:2022 identifikujte zainteresované strany, zákonné povinnosti, záväzky voči zákazníkom, závislosti od dodávateľov, hranice služieb a zodpovednosti manažmentu.

Po tretie, vykonajte posúdenie rizík a ošetrenie rizík podľa princípov ISO/IEC 27005:2022. Skonsolidujte NIS2, DORA, GDPR, zmluvy, interné politiky a riziká služieb do jedného registra základných požiadaviek. Definujte kritériá rizík, vlastníkov, pravdepodobnosť, dopad, možnosti ošetrenia, výber kontrol a schvaľovanie zvyškových rizík.

Po štvrté, namapujte kontroly do Vyhlásenia o uplatniteľnosti. Použite kroky 13 a 14 Zenith Blueprint na vysledovanie rizík ku kontrolám Prílohy A a regulačným očakávaniam. Použite Zenith Controls, aby ste pochopili, ako sa kontroly ako 5.23, 5.24, 8.8, 5.20 a 5.30 mapujú naprieč rámcami a audítorskými pohľadmi.

Po piate, operacionalizujte dôkazy. Politiky nestačia. Knižnica politík Clarysec poskytuje uplatniteľné požiadavky na schvaľovanie cloudu, prístup dodávateľov, logovanie, nápravu zraniteľností, segmentáciu siete, klasifikáciu incidentov a plánovanie kontinuity. Balík dôkazov preukazuje, že tieto požiadavky fungujú.

Ďalší krok: premeňte tlak NIS2 na odolnosť pripravenú na audit

Vykonávacie nariadenie NIS2 2024/2690 nevyžaduje chaos. Vyžaduje sledovateľnosť, vlastníctvo a dôkazy.

Ak ste poskytovateľ cloudových služieb, MSP, MSSP alebo prevádzkovateľ dátového centra, začnite svojimi službami, zákazníkmi, závislosťami, incidentnými scenármi a dôkazovými povinnosťami. Potom vykonajte štruktúrované mapovanie NIS2 na ISO/IEC 27001:2022:

1. Potvrďte, či váš subjekt a služby patria do rozsahu.
2. Namapujte témy NIS2 a vykonávacieho nariadenia do rozsahu vášho ISMS.
3. Aktualizujte register rizík a Vyhlásenie o uplatniteľnosti.
4. Uplatnite politiky Clarysec pre používanie cloudu, bezpečnosť dodávateľov, logovanie, riadenie zraniteľností, reakciu na incidenty, bezpečnosť sietí a kontinuitu.
5. Použite Zenith Blueprint Zenith Blueprint, kroky 13, 14, 20 a 23, na vytvorenie sledovateľnosti a prevádzkových dôkazov.
6. Použite Zenith Controls Zenith Controls na krížové mapovanie kontrol ISO/IEC 27001:2022 voči očakávaniam NIS2, DORA, GDPR, NIST a COBIT 2019.
7. Otestujte dôkazy prostredníctvom simulácie auditu skôr, než si ich vyžiada zákazník, regulátor alebo certifikačný audítor.

Clarysec vám môže pomôcť prekročiť rámec zoznamového súladu a vybudovať integrovaný ISMS, ktorý obstojí pod tlakom NIS2, DORA, GDPR a zákazníckych auditov. Stiahnite si relevantné nástroje Clarysec, objednajte si mapovací workshop alebo požiadajte o posúdenie pripravenosti na audit, aby ste regulačnú zložitosť premenili na obhájiteľné riadenie bezpečnosti a prevádzkovú odolnosť.