NIS2 2024/2690: preslikava kontrol v ISO 27001 za ponudnike storitev v oblaku

Ob 08:17 v torek Maria, CISO evropskega ponudnika upravljanih storitev, prejme opozorilo, ki se ga boji vsak ponudnik upravljanih storitev. En privilegirani račun za oddaljeno upravljanje je sprožil opozorila o nemogočem potovanju. Pri dveh najemnikih strank se pojavljajo neobičajna administrativna dejanja. SOC je že odprl konferenčni most za kritični incident.

Ob 09:00 se klicu pridruži generalni direktor. Vprašanja se takoj spremenijo.

Ali smo v področju uporabe NIS2? Ali se za nas uporablja Izvedbena uredba Komisije (EU) 2024/2690? Ali moramo v 24 urah poslati zgodnje opozorilo? Katere stranke je treba obvestiti? Ali lahko dokažemo, da so MFA, beleženje, segmentacija, upravljanje ranljivosti, kontrole dobaviteljev in eskalacija incidentov delovali že pred incidentom?

Marijino podjetje je certificirano po ISO/IEC 27001:2022. Strankam, med katerimi sta logistični ponudnik in regionalna banka, zagotavlja upravljanje storitev v oblaku, storitve podatkovnega centra in upravljano varnostno podporo. Certifikat je pomemben, vendar sam po sebi ne odgovori na operativna vprašanja. Pravna ekipa ima osnutek postopka obveščanja. Vodja skladnosti ima preglednico. Revizor je zahteval izjavo o uporabnosti, testiranje odziva na incidente, dnevnike privilegiranega dostopa, skrbni pregled dobaviteljev, dokazila o deljeni odgovornosti v oblaku in predpostavke neprekinjenega poslovanja.

To je trenutek, ko NIS2 preneha biti pravno besedilo in postane operativni problem kontrol.

Za ponudnike storitev računalništva v oblaku, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev in ponudnike podatkovnih centrov NIS2 in Izvedbena uredba 2024/2690 dvigujeta zahteve iz splošnega varnostnega namena na raven preverljivih dokazil o kontrolah. Upravljanje, upravljanje tveganj, nadzor dostopa, upravljanje sredstev, upravljanje ranljivosti, odziv na incidente, varnost dobaviteljev, beleženje, spremljanje, šifriranje, neprekinjeno poslovanje in fizična odpornost morajo delovati kot enoten sistem.

ISO/IEC 27001:2022 je najboljša hrbtenica takšnega sistema, vendar le, če organizacija zahteve NIS2 preslika v ISMS, register tveganj, izjavo o uporabnosti, politike in model dokazil. Certifikat na steni ni dovolj. Ključno delo je vzpostaviti preverljivo povezavo od predpisa do tveganja, od tveganja do kontrole, od kontrole do politike in od politike do operativnih dokazil.

Zakaj NIS2 2024/2690 spreminja razpravo o skladnosti v oblaku in pri ponudnikih upravljanih storitev

NIS2 uporablja model sektorja in velikosti, vendar so kategorije digitalne infrastrukture in upravljanja IKT-storitev namenoma široke. Na podlagi NIS2 Article 2 in Article 3, skupaj s Prilogo I in Prilogo II, je mogoče številne organizacije razvrstiti kot bistvene ali pomembne subjekte, vključno s ponudniki storitev računalništva v oblaku, ponudniki storitev podatkovnih centrov, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, ponudniki DNS, registri TLD, omrežji za dostavo vsebin in ponudniki storitev zaupanja. Države članice morajo vzpostaviti in periodično pregledovati sezname bistvenih in pomembnih subjektov, pri čemer je prvi rok za seznam določen za 17. april 2025.

To je pomembno, ker so ponudniki storitev v oblaku, MSP-ji, MSSP-ji in ponudniki podatkovnih centrov del verig tveganja drugih organizacij. Kompromitacija kontrolne ravnine v oblaku lahko vpliva na tisoče sistemov strank. Izpad podatkovnega centra se lahko verižno prenese na bančništvo, zdravstvo, logistiko in javno upravo. Kršitev poverilnic MSP-ja se lahko razvije v večstrankarski dogodek izsiljevalske programske opreme. Neuspeh zaznavanja pri MSSP-ju lahko odloži zajezitev pri reguliranih strankah.

NIS2 Article 20 zahteva, da organi upravljanja odobrijo ukrepe za upravljanje kibernetskih tveganj in nadzorujejo njihovo implementacijo. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, ki temeljijo na pristopu vseh nevarnosti. Izhodišče vključuje analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno nabavo in razvoj, obravnavo in razkritje ranljivosti, oceno učinkovitosti, kibernetsko higieno, usposabljanje, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev, MFA ali neprekinjeno avtentikacijo, varovane komunikacije in komunikacije v sili.

Article 23 dodaja postopno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah, vmesnimi poročili na zahtevo in končnim poročilom v enem mesecu po obvestilu oziroma po obravnavi incidenta, kadar incident še traja.

Izvedbena uredba 2024/2690 ta pričakovanja za relevantne digitalne ponudnike konkretizira. V praksi organi, stranke in revizorji ne bodo spraševali le, ali politike obstajajo. Spraševali bodo, ali so kontrole preslikane, imajo lastnike, so testirane in podprte z dokazili.

ISO/IEC 27001:2022 pretvori NIS2 v operativni kontekst ISMS

Pogosta napaka pri pripravljenosti na NIS2 je začetek z obsežnim kontrolnim seznamom in razdelitvijo nalog med IT, pravno službo, SOC, infrastrukturo, upravljanje dobaviteljev in skladnost. To lahko ustvari veliko aktivnosti, vendar pogosto odpove pri reviziji, ker nihče ne more pokazati, zakaj so bile kontrole izbrane, kako so povezane s tveganjem, kdo je sprejel preostalo tveganje in katera dokazila potrjujejo učinkovitost.

ISO/IEC 27001:2022 ponudnikom daje strukturo, s katero se tej napaki izognejo.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija določi notranja in zunanja vprašanja, prepozna zainteresirane strani in njihove zahteve, odloči, katere zahteve bo obravnavala prek ISMS, ter opredeli obseg ISMS, vključno z vmesniki in odvisnostmi. Za ponudnika storitev v oblaku ali MSP-ja mora obseg izrecno upoštevati NIS2, Izvedbeno uredbo 2024/2690, varnostne priloge pogodb s strankami, zahteve strank, ki izhajajo iz DORA, regije v oblaku, podizvajalce, odvisnosti podatkovnih centrov, platforme za oddaljeno upravljanje, poti privilegiranega dostopa in obveznosti obveščanja o incidentih.

Klavzule 5.1 do 5.3 zahtevajo vodenje, usklajenost politik, vire, komunikacijo, dodeljene odgovornosti in odgovornost vodstva. To neposredno podpira NIS2 Article 20.

Klavzule 6.1.1 do 6.1.3 zahtevajo oceno tveganja, obravnavo tveganja, lastnike tveganj, analizo verjetnosti in posledic, izbiro kontrol, primerjavo s Prilogo A, izjavo o uporabnosti, načrt obravnave tveganja in formalni sprejem preostalega tveganja. Tu NIS2 postane operativen. Vsaka regulativna zahteva postane sprožilec tveganja, obveznost skladnosti, zahteva za kontrolo ali zahteva za dokazilo.

Clarysec to delo začne z Zenith Blueprint: 30-koračni časovni načrt za presojevalce Zenith Blueprint, zlasti v fazi upravljanja tveganj.

Od koraka 13, načrtovanje obravnave tveganj in izjava o uporabnosti, Zenith Blueprint ekipam nalaga vzpostavitev sledljivosti med tveganji, kontrolami in regulativnimi podlagami:

»Navzkrižno sklicujte predpise: če so določene kontrole implementirane posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete bodisi v registru tveganj bodisi v opombah SoA. Npr. kontrola 8.27 (varno brisanje podatkov) je lahko zelo relevantna za zahtevo GDPR glede izbrisa osebnih podatkov; lahko zapišete ‘Uporabljivo – podpira GDPR Art.32 (varnost obdelave)’. ISO tega ne zahteva, vendar pomaga dokazati, da ste te okvire upoštevali.«

Korak 14, politike obravnave tveganj in regulativna navzkrižna sklicevanja, doda praktično disciplino preslikave:

»Za vsak predpis, kadar je uporaben, lahko pripravite preprosto tabelo preslikave, ki navaja ključne varnostne zahteve predpisa in ustrezne kontrole/politike v vašem ISMS. To v ISO 27001 ni obvezno, je pa koristna interna vaja, s katero zagotovite, da nič ne ostane spregledano.«

To je razlika med izjavo »smo certificirani po ISO« in dokazilom »naš ISO/IEC 27001:2022 ISMS obravnava Izvedbeno uredbo NIS2 2024/2690«.

Enotna preslikava kontrol NIS2 v ISO/IEC 27001:2022

Naslednja preslikava ni pravni nasvet in ne nadomešča analize nacionalnega prenosa. Je praktična arhitektura kontrol za ponudnike, ki potrebujejo preverljivo pot do pripravljenosti na NIS2 prek ISO/IEC 27001:2022.

Ta preslikava postane učinkovita, ko je vključena v register tveganj in izjavo o uporabnosti. Ponudnik lahko na primer ustvari scenarij tveganja »Kompromitacija platforme za oddaljeno upravljanje povzroči nepooblaščena dejanja v okoljih strank«. Kontrole vključujejo MFA, upravljanje privilegiranih dostopov, segmentacijo, beleženje, upravljanje ranljivosti, varnost dobaviteljev, načrtovanje incidentov in postopke obveščanja strank. Opombe SoA se lahko sklicujejo na NIS2 Article 21, Article 23, Izvedbeno uredbo 2024/2690, pogodbe s strankami in zahteve DORA za skrbni pregled strank, kadar je to relevantno.

Upravljanje oblaka: kontrola ISO 5.23 je sidro NIS2

Za ponudnike storitev v oblaku in MSP-je, ki uporabljajo storitve v oblaku za izvajanje storitev za stranke, je kontrola 5.23 iz ISO/IEC 27001:2022 Priloge A, Informacijska varnost pri uporabi storitev v oblaku, eno najpomembnejših sider.

Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls povzema kontrolo 5.23 kot preventivni kontrolni ukrep, ki podpira zaupnost, celovitost in razpoložljivost ter je povezan z varnostjo odnosov z dobavitelji, upravljanjem, tveganjem ekosistema in zaščito. Zajema upravljanje storitev v oblaku, deljeno odgovornost, presojo ponudnika, evidence, lokacijo hrambe podatkov, beleženje, šifriranje, vloge identitet, spremljanje, pogodbene klavzule, tveganje dobavitelja, izstop iz oblaka in načrtovanje odpornosti.

Zenith Blueprint, faza Kontrole v praksi, korak 23, pojasnjuje praktični razlog:

»Oblak ni več ciljna lokacija, temveč privzeta izbira. Kontrola 5.23 prepoznava to realnost in zahteva, da se informacijska varnost izrecno obravnava pri izbiri, uporabi in upravljanju storitev v oblaku; ne kot naknadna misel, temveč kot načelo zasnove od samega začetka.«

Za MSP-ja mora biti upravljana vsaka platforma za oddaljeno spremljanje in upravljanje, portal za stranke, sistem za upravljanje zahtevkov, platforma varnostne telemetrije, storitev varnostnega kopiranja, imenik v oblaku in administrativna konzola SaaS. Za ponudnika podatkovnega centra se upravljanje oblaka lahko nanaša na platforme za spremljanje, sisteme za upravljanje obiskovalcev, integracije nadzora fizičnega dostopa, sisteme oddaljenega upravljanja in infrastrukturo portala za stranke.

Clarysecova podjetniška Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku zahteva obvezen skrbni pregled pred aktivacijo:

»Vsaka uporaba storitev v oblaku mora pred aktivacijo opraviti skrbni pregled na podlagi tveganj, vključno s presojo ponudnika, potrditvijo pravne skladnosti in pregledi preverjanja kontrol.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.

Za manjše ponudnike Cloud Usage Policy-sme Cloud Usage Policy-sme - SME vzpostavlja lahek model odobritve:

»Vsako uporabo storitev v oblaku mora pred implementacijo ali naročnino pregledati in odobriti generalni direktor (GM).«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.1.

Oba pristopa podpirata isto pričakovanje NIS2: tveganje odvisnosti od oblaka mora biti razumljeno, preden storitev postane del verige izvajanja.

Odziv na incidente: 24-urna ura začne teči pred pripravo poročila

NIS2 Article 23 je neizprosen, ker časovnica poročanja začne teči od seznanitve s pomembnim incidentom, ne od trenutka, ko je na voljo popolna analiza temeljnega vzroka. Izziv za ponudnike je hitro ugotoviti, ali je dogodek pomemben, katere stranke so prizadete, ali so vključeni osebni podatki, ali obstaja čezmejni vpliv na storitev in kateri pogodbeni roki so začeli teči.

Kontrola 5.24 iz ISO/IEC 27001:2022 Priloge A, Načrtovanje in priprava upravljanja incidentov informacijske varnosti, je kontrola načrtovanja. Zenith Controls jo povzema kot korektivni kontrolni ukrep, ki podpira zaupnost, celovitost in razpoložljivost ter je povezan s konceptoma odziva in obnovitve, upravljanjem, upravljanjem dogodkov in obrambo. Vključuje vloge, odgovornosti, eskalacijske poti, komunikacijske protokole, pripravljenost na regulativno obveščanje, uskladitev z beleženjem in spremljanjem, integracijo z neprekinjenim poslovanjem in obnovitvijo po nesreči, učenje po incidentu ter preslikavo v NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 in COBIT 2019.

Clarysecova Incident Response Policy-sme Incident Response Policy-sme - SME prvo odločitev pretvori v časovno omejeno zahtevo:

»Generalni direktor mora ob podpori ponudnika IT vse incidente razvrstiti po resnosti v eni uri od obvestila.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.1.

Takšna enourna razvrstitev podpira operativno disciplino, potrebno za analizo 24-urnega zgodnjega opozorila po NIS2, presojo kršitve varnosti osebnih podatkov po GDPR, eskalacijo strank po DORA in pogodbeno triažo obveščanja.

Odločitveno drevo ponudnika za incidente mora odgovoriti na štiri vprašanja:

1. Ali obstaja potrjena ali domnevna kompromitacija zaupnosti, celovitosti ali razpoložljivosti?
2. Ali dogodek vpliva na izvajanje storitev, okolja strank, regulirane stranke, osebne podatke ali kritične funkcije?
3. Ali bi lahko povzročil hudo operativno motnjo, finančno izgubo ali materialno oziroma nematerialno škodo?
4. Katere obveznosti obveščanja se uporabljajo: NIS2, GDPR, obveznosti strank po DORA, pogodbene SLA ali pričakovanja nacionalnega regulatorja?

Odločitveno drevo je treba preizkusiti v namiznih vajah pred resničnim incidentom.

Upravljanje ranljivosti: dokažite zmanjšanje tveganja pred vplivom

NIS2 zahteva obravnavo in razkritje ranljivosti. Za stranke in regulatorje je upravljanje ranljivosti eno najlažje merljivih področij kontrol, ker ustvarja jasna dokazila: pokritost skeniranja, časovnice popravkov, odobritve izjem, analizo izkoriščenih ranljivosti in zapise o odpravi pomanjkljivosti.

Kontrola 8.8 iz ISO/IEC 27001:2022 Priloge A, Upravljanje tehničnih ranljivosti, je v Zenith Controls povzeta kot preventivni kontrolni ukrep za zaupnost, celovitost in razpoložljivost, povezan z identifikacijo in zaščito, upravljanjem groženj in ranljivosti, upravljanjem, ekosistemom, zaščito in obrambo. Vključuje identifikacijo ranljivosti, oceno, določanje prioritet, nameščanje popravkov, kompenzacijske kontrole, integracijo obveščevalnih podatkov o grožnjah, razkritje ranljivosti, odgovornosti za ranljivosti v oblaku in aplikacijah, revizijska dokazila in časovnice odprave pomanjkljivosti.

Clarysecova podjetniška Politika upravljanja ranljivosti in popravkov Politika upravljanja ranljivosti in popravkov revizorjem daje konkreten model za testiranje:

»Organizacija mora vse zaznane ranljivosti razvrstiti z uporabo standardizirane metodologije (npr. CVSS v3.x) in uporabiti roke za odpravo, usklajene s poslovno kritičnostjo: 5.2.1 Kritično (CVSS 9.0–10.0): takojšen pregled; rok za namestitev popravka največ 72 ur. 5.2.2 Visoko (7.0–8.9): odziv v 48 urah; rok za namestitev popravka 7 koledarskih dni. 5.2.3 Srednje (4.0–6.9): odziv v 5 dneh; rok za namestitev popravka 30 koledarskih dni. 5.2.4 Nizko (<4.0): odziv v 10 dneh; rok za namestitev popravka 60 koledarskih dni.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.

Za ponudnika storitev v oblaku mora to zajemati komponente hipervizorja, slike vsebnikov, orkestracijske plasti, vmesnike za aplikacijsko programiranje, namenjene strankam, cevovode CI/CD, administrativne konzole in knjižnice tretjih oseb. Za MSP-ja je ključno vprašanje, ali so notranje ranljivosti ločene od ranljivosti, ki jih upravljajo stranke, in ali pogodbe določajo odgovornost. Za ponudnika podatkovnega centra lahko obseg vključuje sisteme za upravljanje stavb, sisteme nadzora dostopa, platforme za spremljanje, orodja za podporo na lokaciji in omrežno infrastrukturo.

Model deljene odgovornosti mora biti dokumentiran. Ponudnik morda ni lastnik vsakega popravka, vendar mora še vedno upravljati tveganje, obvestiti stranko, kadar je to primerno, in dokazati, da so meje odgovornosti razumljene.

Beleženje, spremljanje in segmentacija omogočajo preiskovanje incidentov

Ko incident pri ponudniku začne vplivati na stranke, so prva dokazna vprašanja preprosta: kdo se je prijavil, od kod, s katerim privilegijem, v katerega najemnika, kaj se je spremenilo, kateri dnevniki obstajajo in ali so bile administrativne poti segmentirane.

Clarysecova podjetniška Politika beleženja in spremljanja Politika beleženja in spremljanja zahteva, da zajeti sistemi ustvarjajo dnevnike, ki jih potrebujejo ekipe za odzivanje in revizorji:

»Vsi zajeti sistemi morajo ustvarjati dnevnike, ki zajemajo: 6.1.1.1 avtentikacijo uporabnikov in poskuse dostopa 6.1.1.2 dejavnosti privilegiranih uporabnikov 6.1.1.3 spremembe konfiguracije 6.1.1.4 neuspešne poskuse dostopa ali sistemske dogodke 6.1.1.5 zaznave zlonamerne programske opreme in varnostna opozorila 6.1.1.6 zunanje komunikacije in sprožilce pravil požarnega zidu«

Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.1.1.

Za MSP-je, ki se zanašajo na zunanje ponudnike, Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME dodaja pogodbeno zahtevo:

»Pogodbe morajo od ponudnikov zahtevati, da hranijo dnevnike najmanj 12 mesecev in na zahtevo omogočijo dostop.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.5.1.3.

Segmentacija je enako pomembna. Network Security Policy-sme Network Security Policy-sme - SME določa:

»Notranja omrežja morajo biti segmentirana po funkciji (npr. finance, gostje, IoT, administrativni sistemi).«

Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.2.1.

Zenith Blueprint, faza Kontrole v praksi, korak 20, podaja praktični revizijski postopek za omrežno arhitekturo in segmentacijo. Ekipam nalaga, naj pregledajo in dokumentirajo postavitev omrežja, preverijo pravila požarnega zidu, konfiguracije IPS/IDS in oddaljenega dostopa, potrdijo, da se varnostne skupine v oblaku in pravila VPC ali podomrežij ujemajo z načrtovano arhitekturo, navedejo notranje in zunanje omrežne storitve ter preverijo, da občutljivi sistemi niso dosegljivi iz splošnih uporabniških VLAN-ov ali omrežij za goste.

Pri MSP-ju orodja za oddaljeno upravljanje ne smejo biti v ravnem pisarniškem omrežju. Pri ponudniku podatkovnega centra morajo biti upravljavski vmesniki za napajanje, hlajenje, nadzor dostopa in omrežne storitve strank izolirani in spremljani. Pri ponudniku storitev v oblaku mora biti dostop do kontrolne ravnine omejen s kontrolami identitete, omrežja, varnostnega stanja naprave in privilegiranega delovnega toka.

Varnost dobaviteljev: ponudnik je tudi stranka

Ponudniki storitev v oblaku, MSP-ji, MSSP-ji in ponudniki podatkovnih centrov so dobavitelji reguliranim strankam, hkrati pa so tudi stranke ponudnikov programske opreme, telekomunikacijskih operaterjev, ponudnikov identitet, platform SaaS, dobaviteljev strojne opreme, podizvajalcev in upravljavcev infrastrukture.

NIS2 postavlja varnost dobavne verige med ključne zahteve. DORA, ki se uporablja od 17. januarja 2025, postavlja upravljanje IKT-tveganj tretjih oseb v središče za finančne subjekte. NIS2 Article 4 in Recital 28 priznavata DORA kot sektorsko specifični pravni akt Unije za finančne subjekte, kadar se zahteve prekrivajo. To ne zmanjšuje pritiska na ponudnike storitev v oblaku in MSP-je. Povečuje ga, ker finančne stranke v pogodbe z dobavitelji prenašajo pogodbene zahteve na ravni DORA, pravice do revizije, testiranje odpornosti, strategije izstopa in pričakovanja glede poročanja o incidentih.

Clarysecova podjetniška Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev zahteva nadzorovan dostop tretjih oseb:

»Ves dostop tretjih oseb mora biti zabeležen in spremljan ter, kjer je izvedljivo, segmentiran prek posredniških dostopnih strežnikov, VPN-jev ali prehodov Zero Trust.«

Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.3.2.

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME načelo najmanjših privilegijev izraža neposredno:

»Dobaviteljem mora biti dodeljen dostop samo do minimalnega nabora sistemov in podatkov, potrebnih za izvajanje njihove funkcije.«

Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.2.1.

Te klavzule se naravno preslikajo v kontrole ISO/IEC 27001:2022 Priloge A 5.19, 5.20, 5.21 in 5.22. Podpirajo tudi upravljanje obdelovalcev in podobdelovalcev po GDPR, preglede tveganj tretjih oseb po DORA in varnostne vprašalnike strank.

Neprekinjeno poslovanje in odpornost podatkovnega centra: dokažite predpostavke

NIS2 Article 21 vključuje neprekinjeno poslovanje, upravljanje varnostnega kopiranja, obnovitev po nesreči in krizno upravljanje. DORA Articles 11 to 14 za finančne subjekte zahtevajo politike neprekinjenega poslovanja IKT, načrte odziva in obnovitve, analizo vpliva na poslovanje, politike varnostnega kopiranja, postopke obnovitve, cilje obnovitve, testiranje, preglede po incidentu in krizno komuniciranje.

Za ponudnike storitev v oblaku in podatkovnih centrov neprekinjeno poslovanje ni mapa na polici. Je arhitektura, zmogljivost, pogodbe, odvisnosti, dokazila o obnovitvi in preizkušene predpostavke.

Clarysecova podjetniška Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči zahteva letno BIA in pregled po pomembnih spremembah:

»Analiza vpliva na poslovanje (BIA) se mora za vse kritične poslovne enote izvesti najmanj enkrat letno in pregledati ob pomembnih spremembah sistemov, procesov ali odvisnosti. Izhodi BIA morajo opredeliti: 5.2.1. največji dopustni čas izpada (MTD) 5.2.2. ciljne čase obnovitve (RTO) 5.2.3. ciljne točke obnovitve (RPO) 5.2.4. kritične odvisnosti (sistemi, dobavitelji, osebje)«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.

V scenariju podatkovnega centra mora BIA zajeti napajalne vode, UPS, generatorje, pogodbe za gorivo, hlajenje, sisteme za gašenje požara, omrežne operaterje, sisteme fizičnega dostopa, podporo na lokaciji, spremljanje, rezervno strojno opremo in komunikacijske kanale s strankami. V scenariju oblaka mora zajeti regije, cone razpoložljivosti, replikacijo, nespremenljivost varnostnih kopij, odvisnosti identitet, DNS, overitelje digitalnih potrdil, prehode API in podporne sisteme. V scenariju MSP mora zajeti orodja za oddaljeno upravljanje, trezorje privilegiranega dostopa, konzole EDR, sistem za upravljanje zahtevkov, repozitorije dokumentacije in komunikacije v sili.

ISO 22301 lahko okrepi disciplino upravljanja neprekinjenega poslovanja, ISO/IEC 27005:2022 pa podpira merila tveganja, načrtovanje obravnave, spremljanje, dokazila in nenehno izboljševanje. To je koristno, ker pripravljenost na NIS2 od organizacije zahteva konsolidacijo pravnih, pogodbenih, operativnih, dobaviteljskih, tehnoloških, finančnih, procesnih in človeških dejavnikov v en proces upravljanja tveganj.

Praktična sled tveganja za kršitev oddaljenega dostopa pri MSP-ju

Praktična delavnica se lahko začne z enim scenarijem:

»Kompromitacija privilegiranega oddaljenega dostopa povzroči nepooblaščen dostop do sistemov strank, motnjo storitve, možno izpostavljenost osebnih podatkov in regulativne obveznosti obveščanja.«

Ustvarite vrstico v registru tveganj in dopolnite sled.

Nato posodobite izjavo o uporabnosti. Za vsako relevantno kontrolo iz Priloge A pojasnite, zakaj se uporablja in katero temo NIS2 podpira. Nazadnje pred revizijo zberite dokazila: poročila o uveljavljanju MFA, sezname privilegiranih računov, nastavitve hrambe dnevnikov, stanje popravkov RMM, opozorila SIEM, zapise o razvrstitvi incidentov, odobritve dostopa dobaviteljev in rezultate namiznih vaj.

Kako bodo različni revizorji testirali isto kontrolno okolje

Integriran ISMS mora zadovoljiti različne poglede zagotavljanja zaupanja, ne da bi za vsak okvir ustvarjal ločene pakete dokazil.

Tu Zenith Controls pomaga kot vodnik za navzkrižno skladnost. Za kontrole, kot so 5.23, 5.24 in 8.8, povezuje pričakovanja kontrol ISO/IEC 27001:2022 s temami NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF in ISO 22301. Cilj ni ustvariti ločenih programov skladnosti. Cilj je ena arhitektura dokazil, označena po kontroli, tveganju, regulativni podlagi in lastniku.

Implementacijski vzorec Clarysec

Za ponudnike storitev v oblaku, MSP-je, MSSP-je in ponudnike podatkovnih centrov mora delo potekati v petih plasteh.

Prvič, potrdite obseg. Ugotovite, ali so organizacija in storitve v področju uporabe NIS2, katera pravila držav članic se uporabljajo, ali se Izvedbena uredba 2024/2690 uporablja za kategorijo ponudnika in ali stranke nalagajo DORA, GDPR, NIST ali sektorsko specifične obveznosti.

Drugič, vzpostavite kontekst ISMS. V skladu s klavzulama 4 in 5 ISO/IEC 27001:2022 identificirajte zainteresirane strani, zakonske obveznosti, zaveze strankam, odvisnosti od dobaviteljev, meje storitev in odgovornosti vodstva.

Tretjič, izvedite oceno in obravnavo tveganj z uporabo načel ISO/IEC 27005:2022. Konsolidirajte NIS2, DORA, GDPR, pogodbe, interne politike in storitvena tveganja v en osnovni register zahtev. Opredelite merila tveganja, lastnike, verjetnost, vpliv, možnosti obravnave, izbire kontrol in odobritve preostalega tveganja.

Četrtič, preslikajte kontrole v izjavo o uporabnosti. Uporabite koraka 13 in 14 iz Zenith Blueprint za sledljivost od tveganj do kontrol iz Priloge A in regulativnih pričakovanj. Uporabite Zenith Controls, da razumete, kako se kontrole, kot so 5.23, 5.24, 8.8, 5.20 in 5.30, preslikajo med okviri in revizijskimi pogledi.

Petič, operativno vzpostavite dokazila. Politike niso dovolj. Knjižnica politik Clarysec zagotavlja izvršljive zahteve za odobritev uporabe oblaka, dostop dobaviteljev, beleženje, odpravo ranljivosti, segmentacijo omrežja, razvrščanje incidentov in načrtovanje neprekinjenega poslovanja. Paket dokazil dokazuje, da te zahteve delujejo.

Naslednji korak: pritisk NIS2 pretvorite v odpornost, pripravljeno na revizijo

Izvedbena uredba NIS2 2024/2690 ne zahteva kaosa. Zahteva sledljivost, lastništvo in dokazila.

Če ste ponudnik storitev v oblaku, MSP, MSSP ali upravljavec podatkovnega centra, začnite s svojimi storitvami, strankami, odvisnostmi, scenariji incidentov in obveznostmi glede dokazil. Nato izvedite strukturirano preslikavo NIS2 v ISO/IEC 27001:2022:

1. Potrdite, ali so vaš subjekt in storitve v področju uporabe.
2. Preslikajte teme NIS2 in Izvedbene uredbe v obseg vašega ISMS.
3. Posodobite register tveganj in izjavo o uporabnosti.
4. Uporabite politike Clarysec za uporabo oblaka, varnost dobaviteljev, beleženje, upravljanje ranljivosti, odziv na incidente, varnost omrežja in neprekinjeno poslovanje.
5. Uporabite Zenith Blueprint Zenith Blueprint, korake 13, 14, 20 in 23, za vzpostavitev sledljivosti in operativnih dokazil.
6. Uporabite Zenith Controls Zenith Controls za navzkrižno preslikavo kontrol ISO/IEC 27001:2022 glede na pričakovanja NIS2, DORA, GDPR, NIST in COBIT 2019.
7. Dokazila preizkusite z revizijsko simulacijo, preden jih zahteva stranka, regulator ali certifikacijski revizor.

Clarysec vam lahko pomaga preseči skladnost po kontrolnem seznamu in zgraditi integriran ISMS, ki zdrži pritisk NIS2, DORA, GDPR in revizij strank. Prenesite ustrezne komplete orodij Clarysec, rezervirajte delavnico preslikave ali zahtevajte presojo pripravljenosti na revizijo, da regulativno kompleksnost pretvorite v utemeljljivo upravljanje varnosti in operativno odpornost.