NIS2 2024/2690 ir ISO 27001 kontrolės priemonių susiejimas debesijos paslaugų teikėjams
Antradienį 08:17 Maria, Europos valdomų paslaugų teikėjo informacijos saugumo vadovė (CISO), gauna įspėjimą, kurio bijo kiekvienas MSP. Viena privilegijuotoji nuotolinio valdymo paskyra suaktyvino neįmanomos kelionės įspėjimus. Dviejuose klientų tenantuose matomi neįprasti administravimo veiksmai. SOC jau atidarė kritinio incidento koordinavimo tiltą.
09:00 prie skambučio prisijungia generalinis direktorius. Klausimai iškart pasikeičia.
Ar patenkame į NIS2 taikymo sritį? Ar mums taikomas Komisijos įgyvendinimo reglamentas (ES) 2024/2690? Ar turime pateikti 24 valandų ankstyvąjį įspėjimą? Kuriuos klientus privalome informuoti? Ar galime įrodyti, kad MFA, žurnalavimas, segmentavimas, pažeidžiamumų valdymas, tiekėjų kontrolės priemonės ir incidentų eskalavimas veikė dar iki incidento?
Marios įmonė yra sertifikuota pagal ISO/IEC 27001:2022. Ji teikia debesijos valdymo, duomenų centrų ir valdomo saugumo palaikymo paslaugas klientams, tarp kurių yra logistikos paslaugų teikėjas ir regioninis bankas. Sertifikatas svarbus, tačiau vien jis neatsako į veiklos klausimus. Teisės komanda turi pranešimo proceso projektą. Atitikties vadovas turi skaičiuoklę. Auditorius paprašė Taikomumo pareiškimo, reagavimo į incidentus testavimo, privilegijuotosios prieigos žurnalų, tiekėjų deramo patikrinimo, debesijos bendros atsakomybės įrodymų ir veiklos tęstinumo prielaidų.
Tai momentas, kai NIS2 nustoja būti teisiniu tekstu ir tampa veiklos kontrolės priemonių problema.
Debesijos paslaugų teikėjams, valdomų paslaugų teikėjams, valdomų saugumo paslaugų teikėjams ir duomenų centrų paslaugų teikėjams NIS2 ir Įgyvendinimo reglamentas 2024/2690 pakelia kartelę nuo bendro saugumo ketinimo iki patikrinamų kontrolės įrodymų. Valdysena, rizikos valdymas, prieigos kontrolė, turto valdymas, pažeidžiamumų tvarkymas, reagavimas į incidentus, tiekėjų saugumas, žurnalavimas, stebėsena, šifravimas, veiklos tęstinumas ir fizinis atsparumas turi veikti kaip viena sistema.
ISO/IEC 27001:2022 yra geriausias šios sistemos pagrindas, bet tik tada, kai organizacija NIS2 reikalavimus susieja su ISVS, rizikų registru, Taikomumo pareiškimu, politikomis ir įrodymų modeliu. Sertifikato ant sienos nepakanka. Tikrasis darbas – sukurti audituojamą giją nuo reglamento iki rizikos, nuo rizikos iki kontrolės priemonės, nuo kontrolės priemonės iki politikos ir nuo politikos iki veiklos įrodymų.
Kodėl NIS2 2024/2690 keičia debesijos ir MSP atitikties diskusiją
NIS2 taiko sektoriaus ir dydžio modelį, tačiau jos skaitmeninės infrastruktūros ir IRT paslaugų valdymo kategorijos sąmoningai plačios. Pagal NIS2 Article 2 ir Article 3, kartu su Annex I ir Annex II, daugelis organizacijų gali būti priskiriamos esminiams arba svarbiems subjektams, įskaitant debesijos paslaugų teikėjus, duomenų centrų paslaugų teikėjus, valdomų paslaugų teikėjus, valdomų saugumo paslaugų teikėjus, DNS teikėjus, TLD registrus, turinio pristatymo tinklus ir patikimumo užtikrinimo paslaugų teikėjus. Valstybės narės turi sudaryti ir periodiškai peržiūrėti esminių ir svarbių subjektų sąrašus; pirmojo sąrašo terminas – 2025 m. balandžio 17 d.
Tai svarbu, nes debesijos, MSP, MSSP ir duomenų centrų paslaugų teikėjai yra kitų organizacijų rizikos grandinėse. Debesijos valdymo plokštumos kompromitavimas gali paveikti tūkstančius klientų sistemų. Duomenų centro veiklos sutrikimas gali išplisti į bankininkystę, sveikatos priežiūrą, logistiką ir viešąjį administravimą. MSP prisijungimo duomenų pažeidimas gali virsti kelių klientų išpirkos reikalaujančios programinės įrangos incidentu. MSSP aptikimo nesėkmė gali uždelsti lokalizavimą reguliuojamų klientų aplinkose.
NIS2 Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones ir prižiūrėtų jų įgyvendinimą. Article 21 reikalauja tinkamų ir proporcingų techninių, veiklos ir organizacinių priemonių, grindžiamų visų pavojų požiūriu. Bazinis rinkinys apima rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą ir kūrimą, pažeidžiamumų tvarkymą ir atskleidimą, veiksmingumo vertinimą, kibernetinę higieną, mokymus, kriptografiją, personalo saugumą, prieigos kontrolę, turto valdymą, MFA arba tęstinį autentifikavimą, saugias komunikacijas ir avarines komunikacijas.
Article 23 nustato etapais vykdomą pranešimą apie reikšmingus incidentus, įskaitant ankstyvąjį įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas, tarpines ataskaitas, kai jų prašoma, ir galutinę ataskaitą per vieną mėnesį po pranešimo arba, jei incidentas tebesitęsia, po incidento suvaldymo.
Įgyvendinimo reglamentas 2024/2690 šiuos lūkesčius atitinkamiems skaitmeninių paslaugų teikėjams paverčia konkretesniais. Praktikoje institucijos, klientai ir auditoriai klausia ne tik, ar politikos egzistuoja. Jie klausia, ar kontrolės priemonės susietos, turi savininkus, yra testuojamos ir pagrįstos įrodymais.
ISO/IEC 27001:2022 paverčia NIS2 ISVS veikimo kontekstu
Dažna NIS2 pasirengimo klaida – pradėti nuo didelio kontrolinio sąrašo ir paskirstyti užduotis IT, teisės, SOC, infrastruktūros, tiekėjų valdymo ir atitikties komandoms. Tai gali sukurti veiklos įspūdį, bet dažnai neatlaiko audito, nes niekas negali parodyti, kodėl pasirinktos kontrolės priemonės, kaip jos susijusios su rizika, kas priėmė liekamąją riziką ir kokie įrodymai patvirtina veiksmingumą.
ISO/IEC 27001:2022 suteikia paslaugų teikėjams struktūrą, padedančią išvengti šios nesėkmės.
4.1–4.4 punktai reikalauja, kad organizacija nustatytų vidinius ir išorinius klausimus, identifikuotų suinteresuotąsias šalis ir jų reikalavimus, nuspręstų, kurie reikalavimai bus sprendžiami per ISVS, ir apibrėžtų ISVS taikymo sritį, įskaitant sąsajas ir priklausomybes. Debesijos arba MSP paslaugų teikėjui taikymo sritis turėtų aiškiai apimti NIS2, Įgyvendinimo reglamentą 2024/2690, klientų saugumo priedus, DORA nulemtus klientų reikalavimus, debesijos regionus, subtiekėjus, duomenų centrų priklausomybes, nuotolinio valdymo platformas, privilegijuotosios prieigos kelius ir pranešimo apie incidentus pareigas.
5.1–5.3 punktai reikalauja lyderystės, politikos suderinimo, išteklių, komunikacijos, priskirtų atsakomybių ir vadovybės atskaitomybės. Tai tiesiogiai palaiko NIS2 Article 20.
6.1.1–6.1.3 punktai reikalauja rizikos vertinimo, rizikos tvarkymo, rizikos savininkų, tikimybės ir pasekmių analizės, kontrolės priemonių parinkimo, palyginimo su Annex A, Taikomumo pareiškimo, rizikos tvarkymo plano ir formalaus liekamosios rizikos priėmimo. Čia NIS2 tampa veiklos praktika. Kiekvienas reglamentavimo reikalavimas tampa rizikos veiksniu, atitikties įpareigojimu, kontrolės reikalavimu arba įrodymų reikalavimu.
Clarysec šį darbą pradeda nuo Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plano Zenith Blueprint, ypač rizikos valdymo etapo.
Nuo 13 žingsnio „Rizikos tvarkymo planavimas ir Taikomumo pareiškimas“ Zenith Blueprint nurodo komandoms kurti atsekamumą tarp rizikų, kontrolės priemonių ir reglamentavimo veiksnių:
„Kryžmiškai susiekite reglamentus: jei tam tikros kontrolės priemonės įgyvendinamos konkrečiai siekiant laikytis GDPR, NIS2 arba DORA, tai galima pažymėti Rizikų registre arba SoA pastabose. Pvz., kontrolė 8.27 (saugus duomenų ištrynimas) gali būti labai aktuali GDPR reikalavimui sunaikinti asmens duomenis; galite pažymėti: „Taikoma – palaiko GDPR Art.32 (tvarkymo saugumas)“. ISO to nereikalauja, bet tai padeda įrodyti, kad atsižvelgėte į šiuos karkasus.“
14 žingsnis „Rizikos tvarkymo politikos ir reglamentavimo kryžminės nuorodos“ papildo praktinę susiejimo discipliną:
„Kiekvienam reglamentui, jei taikoma, galite sukurti paprastą susiejimo lentelę, kurioje išvardyti pagrindiniai reglamento saugumo reikalavimai ir atitinkamos kontrolės priemonės / politikos jūsų ISVS. Tai nėra privaloma pagal ISO 27001, tačiau tai naudinga vidinė praktika, padedanti užtikrinti, kad niekas neliktų nepastebėta.“
Tai ir yra skirtumas tarp teiginio „esame sertifikuoti pagal ISO“ ir įrodymo „mūsų ISO/IEC 27001:2022 ISVS apima NIS2 Įgyvendinimo reglamentą 2024/2690“.
Vieningas NIS2 ir ISO/IEC 27001:2022 kontrolės priemonių susiejimas
Toliau pateiktas susiejimas nėra teisinė konsultacija ir nepakeičia nacionalinio perkėlimo į teisę analizės. Tai praktinė kontrolės architektūra paslaugų teikėjams, kuriems reikia audituojamo ISO/IEC 27001:2022 kelio į pasirengimą NIS2.
| NIS2 ir Įgyvendinimo reglamento tema | ISO/IEC 27001:2022 ISVS mechanizmas | Pagrindinės Annex A kontrolės sritys | Clarysec įgyvendinimo įrodymai |
|---|---|---|---|
| Valdysena ir vadovybės atskaitomybė | 4, 5, 6 ir 9 punktai apibrėžia kontekstą, lyderystę, rizikos planavimą ir veiklos rezultatų peržiūrą | 5.1 Informacijos saugumo politikos, 5.2 Informacijos saugumo vaidmenys ir atsakomybės, 5.31 Teisiniai, įstatyminiai, reglamentavimo ir sutartiniai reikalavimai | ISVS taikymo sritis, suinteresuotųjų šalių registras, valdybos patvirtinimas, rizikų registras, SoA, vadovybės peržiūros protokolai |
| Debesijos paslaugų valdysena | Rizikos vertinimas, tiekėjų deramas patikrinimas, bendra atsakomybė ir kontrolės priemonių parinkimas | 5.23 Informacijos saugumas naudojant debesijos paslaugas, 5.19 Informacijos saugumas santykiuose su tiekėjais, 5.22 Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas | Debesijos apskaita, paslaugų teikėjo rizikos vertinimas, bendros atsakomybės matrica, sutartinės nuostatos, debesijos žurnalavimo įrodymai |
| MSP ir MSSP privilegijuotoji prieiga | Rizikos tvarkymas klientų aplinkoms, administravimo platformoms ir palaikymo įrankiams | 5.15 Prieigos kontrolė, 5.16 Tapatybės valdymas, 5.18 Prieigos teisės, 8.2 Privilegijuotos prieigos teisės, 8.5 Saugus autentifikavimas | PAM įrašai, MFA ataskaitos, nuotolinės prieigos žurnalai, tarpinio prieigos serverio arba nulinio pasitikėjimo šliuzo konfigūracija, prieigos peržiūros |
| Duomenų centro atsparumas | Verslo poveikio analizė, tęstinumo planavimas ir priklausomybių valdymas | 5.30 IRT pasirengimas veiklos tęstinumui, 7.1 Fizinio saugumo perimetrai, 7.2 Fizinis patekimas, 8.13 Informacijos atsarginės kopijos, 8.14 Perteklinis dubliavimas | BIA, RTO ir RPO įrašai, DR testavimo ataskaita, fizinės prieigos žurnalai, elektros tiekimo ir aušinimo testavimo įrodymai |
| Pranešimas apie incidentus ir eskalavimas | Incidentų procesas, susietas su teisiniais, sutartiniais ir klientų informavimo paleidikliais | 5.24 Informacijos saugumo incidentų valdymo planavimas ir pasirengimas, 5.25 Informacijos saugumo įvykių vertinimas ir sprendimų priėmimas, 5.26 Reagavimas į informacijos saugumo incidentus, 5.27 Mokymasis iš informacijos saugumo incidentų | 24 valandų ankstyvojo įspėjimo veiksmų planas, 72 valandų pranešimo darbo eiga, incidentų registras, po incidento atlikta peržiūra |
| Pažeidžiamumų tvarkymas ir atskleidimas | Rizika grindžiamas pažeidžiamumų tvarkymas, išimčių valdymas ir veiksmingumo vertinimas | 8.8 Techninių pažeidžiamumų valdymas, 8.9 Konfigūracijų valdymas, 8.32 Pakeitimų valdymas, 8.16 Stebėsenos veiklos | Skenavimo rezultatai, taisomųjų veiksmų SLA, išimčių patvirtinimai, pataisų ataskaitos, grėsmių žvalgybos įvestys |
| Tiekimo grandinės saugumas | Suinteresuotųjų šalių reikalavimai ir tiekėjų rizika integruoti į ISVS | 5.19 Informacijos saugumas santykiuose su tiekėjais, 5.20 Informacijos saugumo aptarimas tiekėjų susitarimuose, 5.21 Informacijos saugumo valdymas IRT tiekimo grandinėje, 5.22 Tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas | Tiekėjų lygiavimas, deramo patikrinimo klausimynai, sutartinės nuostatos, audito teisės, subtiekėjų registras, pasitraukimo planai |
| Žurnalavimas, stebėsena ir tyrimas | Aptikimas, įrodymai, laiko koreliacija ir incidentų tyrimo palaikymas | 8.15 Žurnalavimas, 8.16 Stebėsenos veiklos, 8.17 Laikrodžių sinchronizavimas, 5.25 Informacijos saugumo įvykių vertinimas ir sprendimų priėmimas | SIEM aprėpties žemėlapis, žurnalų saugojimo įrodymai, įspėjimų derinimo įrašai, laikrodžių sinchronizavimo įrašai, incidentų koreliacijos įrodymai |
| Tinklo ir tenantų izoliavimas | Saugi architektūra, segmentavimas ir riboti administravimo keliai | 8.20 Tinklo saugumas, 8.22 Tinklų atskyrimas, 8.23 Žiniatinklio filtravimas, 8.24 Kriptografijos naudojimas | Tinklo schemos, ugniasienės taisyklės, debesijos saugumo grupės, VPC arba potinklių taisyklės, segmentavimo testavimo rezultatai |
Šis susiejimas tampa veiksmingas, kai įtraukiamas į rizikų registrą ir Taikomumo pareiškimą. Pavyzdžiui, paslaugų teikėjas gali sukurti rizikos scenarijų „Nuotolinio valdymo platformos kompromitavimas lemia neautorizuotus veiksmus klientų aplinkose“. Kontrolės priemonės apima MFA, privilegijuotosios prieigos valdymą, segmentavimą, žurnalavimą, pažeidžiamumų valdymą, tiekėjų saugumą, incidentų planavimą ir klientų informavimo procedūras. SoA pastabose, kai aktualu, galima nurodyti NIS2 Article 21, Article 23, Įgyvendinimo reglamentą 2024/2690, klientų sutartis ir DORA klientų deramo patikrinimo reikalavimus.
Debesijos valdysena: ISO kontrolė 5.23 yra NIS2 atrama
Debesijos paslaugų teikėjams ir MSP, kurie debesijos paslaugas naudoja klientų paslaugoms teikti, ISO/IEC 27001:2022 Annex A kontrolė 5.23 „Informacijos saugumas naudojant debesijos paslaugas“ yra viena svarbiausių atramų.
Zenith Controls: kryžminės atitikties vadovas Zenith Controls kontrolę 5.23 apibendrina kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą, susietą su tiekėjų santykių saugumu, valdysena, ekosistemos rizika ir apsauga. Ji apima debesijos paslaugų valdyseną, bendrą atsakomybę, paslaugų teikėjų vertinimą, apskaitą, duomenų buvimo vietą, žurnalavimą, šifravimą, tapatybės vaidmenis, stebėseną, sutartines nuostatas, tiekėjų riziką, pasitraukimą iš debesijos ir atsparumo planavimą.
Zenith Blueprint, etapo „Kontrolės priemonės praktikoje“ 23 žingsnis, paaiškina praktinę priežastį:
„Debesija nebėra paskirties vieta – ji yra numatytasis veikimo būdas. Kontrolė 5.23 pripažįsta šią realybę ir reikalauja, kad informacijos saugumas būtų aiškiai įtrauktas į debesijos paslaugų pasirinkimą, naudojimą ir valdymą ne kaip vėlesnė mintis, o kaip projektavimo principas nuo pat pradžių.“
MSP atveju turi būti valdoma kiekviena nuotolinės stebėsenos ir valdymo platforma, klientų portalas, užklausų valdymo priemonė, saugumo telemetrijos platforma, atsarginių kopijų paslauga, debesijos katalogas ir SaaS administravimo konsolė. Duomenų centro paslaugų teikėjui debesijos valdysena gali būti taikoma stebėsenos platformoms, lankytojų valdymo sistemoms, fizinės prieigos kontrolės integracijoms, nuotolinio valdymo sistemoms ir klientų portalo infrastruktūrai.
Clarysec Enterprise Debesijos paslaugų naudojimo politika Debesijos paslaugų naudojimo politika nustato privalomą deramą patikrinimą prieš aktyvavimą:
„Visas debesijos naudojimas prieš aktyvavimą turi būti vertinamas taikant rizika grindžiamą deramą patikrinimą, įskaitant paslaugų teikėjo vertinimą, teisinės atitikties validavimą ir kontrolės validavimo peržiūras.“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.2.
Mažesniems paslaugų teikėjams Cloud Usage Policy-sme Cloud Usage Policy-sme - SME sukuria paprastesnį patvirtinimo modelį:
„Visą debesijos paslaugų naudojimą prieš įgyvendinimą arba prenumeratą turi peržiūrėti ir patvirtinti generalinis vadovas (GM).“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.1.
Abu metodai palaiko tą patį NIS2 lūkestį: debesijos priklausomybių rizika turi būti suprasta prieš paslaugai tampant paslaugų teikimo grandinės dalimi.
Reagavimas į incidentus: 24 valandų laikrodis pradeda tiksėti dar prieš parengiant ataskaitą
NIS2 Article 23 yra griežtas, nes pranešimo terminas pradedamas skaičiuoti nuo sužinojimo apie reikšmingą incidentą, o ne nuo momento, kai parengta tobula pagrindinės priežasties analizė. Paslaugų teikėjų iššūkis – greitai nustatyti, ar įvykis reikšmingas, kurie klientai paveikti, ar susiję asmens duomenys, ar yra tarpvalstybinis poveikis paslaugai ir kurie sutartiniai terminai jau prasidėjo.
ISO/IEC 27001:2022 Annex A kontrolė 5.24 „Informacijos saugumo incidentų valdymo planavimas ir pasirengimas“ yra planavimo kontrolė. Zenith Controls ją apibendrina kaip korekcinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą, susietą su reagavimo ir atkūrimo koncepcijomis, valdysena, įvykių valdymu ir gynyba. Ji apima vaidmenis, atsakomybes, eskalavimo kelius, komunikacijos protokolus, pasirengimą reglamentavimo pranešimams, suderinimą su žurnalavimu ir stebėsena, integraciją su veiklos tęstinumu ir atkūrimu po katastrofos, mokymąsi po incidento ir susiejimą su NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 ir COBIT 2019.
Clarysec Incident Response Policy-sme Incident Response Policy-sme - SME pirmąjį sprendimą paverčia terminuotu reikalavimu:
„Generalinis vadovas, gavęs IT paslaugų teikėjo informaciją, privalo visus incidentus pagal sunkumą klasifikuoti per vieną valandą nuo pranešimo.“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.3.1.
Ši vienos valandos klasifikacija palaiko veiklos discipliną, reikalingą NIS2 24 valandų ankstyvojo įspėjimo analizei, GDPR asmens duomenų saugumo pažeidimo vertinimui, DORA klientų eskalavimui ir sutartinių pranešimų triažui.
Paslaugų teikėjo incidentų sprendimų medis turėtų atsakyti į keturis klausimus:
- Ar patvirtintas arba įtariamas konfidencialumo, vientisumo arba prieinamumo kompromitavimas?
- Ar įvykis paveikia paslaugos teikimą, klientų aplinkas, reguliuojamus klientus, asmens duomenis arba kritines funkcijas?
- Ar jis gali sukelti didelį veiklos sutrikimą, finansinius nuostolius arba materialinę ar nematerialinę žalą?
- Kokios pranešimo pareigos taikomos: NIS2, GDPR, DORA klientų įsipareigojimai, sutartiniai SLA ar nacionalinio reguliuotojo lūkesčiai?
Sprendimų medis turi būti ištestuotas stalo pratybose prieš tikrą incidentą.
Pažeidžiamumų valdymas: įrodykite rizikos sumažinimą iki poveikio
NIS2 reikalauja pažeidžiamumų tvarkymo ir atskleidimo. Klientams ir reguliuotojams pažeidžiamumų valdymas yra viena lengviausiai matuojamų kontrolės sričių, nes ji sukuria aiškius įrodymus: skenavimo aprėptį, pataisų terminus, išimčių patvirtinimus, išnaudotų pažeidžiamumų analizę ir taisomųjų veiksmų įrašus.
ISO/IEC 27001:2022 Annex A kontrolė 8.8 „Techninių pažeidžiamumų valdymas“ Zenith Controls apibendrinama kaip prevencinė kontrolės priemonė, apimanti konfidencialumą, vientisumą ir prieinamumą, susieta su identifikavimu ir apsauga, grėsmių ir pažeidžiamumų valdymu, valdysena, ekosistema, apsauga ir gynyba. Ji apima pažeidžiamumų identifikavimą, vertinimą, prioritetizavimą, pataisų diegimą, kompensuojančias kontrolės priemones, grėsmių žvalgybos integravimą, pažeidžiamumų atskleidimą, debesijos ir taikomųjų programų pažeidžiamumų atsakomybes, audito įrodymus ir taisomųjų veiksmų terminus.
Clarysec Enterprise Pažeidžiamumų ir pataisų valdymo politika Pažeidžiamumų ir pataisų valdymo politika auditoriams suteikia konkretų testavimo modelį:
„Organizacija privalo visus aptiktus pažeidžiamumus klasifikuoti taikydama standartizuotą metodiką (pvz., CVSS v3.x) ir taikyti taisomųjų veiksmų terminus, suderintus su veiklos kritiškumu: 5.2.1 Kritinis (CVSS 9.0–10.0): nedelsiant peržiūrėti; pataisos diegimo terminas – ne daugiau kaip 72 valandos. 5.2.2 Aukštas (7.0–8.9): reakcija per 48 valandas; pataisos diegimo terminas – 7 kalendorinės dienos. 5.2.3 Vidutinis (4.0–6.9): reakcija per 5 dienas; pataisos diegimo terminas – 30 kalendorinių dienų. 5.2.4 Žemas (<4.0): reakcija per 10 dienų; pataisos diegimo terminas – 60 kalendorinių dienų.“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.2.
Debesijos paslaugų teikėjui tai turi apimti hipervizoriaus komponentus, konteinerių atvaizdus, orkestravimo sluoksnius, klientams skirtas APIs, CI/CD konvejerius, administravimo konsoles ir trečiųjų šalių bibliotekas. MSP atveju pagrindinis klausimas – ar vidiniai pažeidžiamumai atskirti nuo klientų valdomų pažeidžiamumų ir ar sutartyse apibrėžta atsakomybė. Duomenų centro paslaugų teikėjui taikymo sritis gali apimti pastato valdymo sistemas, prieigos kontrolės sistemas, stebėsenos platformas, „remote hands“ įrankius ir tinklo infrastruktūrą.
Bendros atsakomybės modelis turi būti dokumentuotas. Paslaugų teikėjas gali būti atsakingas ne už kiekvieną pataisą, bet jis vis tiek privalo valdyti riziką, kai tinkama informuoti klientą ir įrodyti, kad atsakomybės ribos suprastos.
Žurnalavimas, stebėsena ir segmentavimas padaro incidentus ištiriamus
Kai paslaugų teikėjo incidentas paveikia klientą, pirmieji įrodymų klausimai paprasti: kas prisijungė, iš kur, su kokiomis privilegijomis, prie kurio tenanto, kas pasikeitė, kokie žurnalai egzistuoja ir ar administravimo keliai buvo segmentuoti.
Clarysec Enterprise Žurnalų tvarkymo ir stebėsenos politika Žurnalų tvarkymo ir stebėsenos politika reikalauja, kad apimamos sistemos generuotų žurnalus, kurių reikia reagavimo komandoms ir auditoriams:
„Visos apimamos sistemos turi generuoti žurnalus, fiksuojančius: 6.1.1.1 Naudotojų autentifikavimą ir prieigos bandymus 6.1.1.2 Privilegijuotų naudotojų veiklą 6.1.1.3 Konfigūracijos pakeitimus 6.1.1.4 Nesėkmingus prieigos bandymus arba sistemos įvykius 6.1.1.5 Kenkimo programinės įrangos aptikimus ir saugumo įspėjimus 6.1.1.6 Išorines komunikacijas ir ugniasienės taisyklių paleidiklius“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.1.1.
MVĮ, kurios remiasi išorės paslaugų teikėjais, Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME prideda sutartinį reikalavimą:
„Sutartyse turi būti reikalaujama, kad paslaugų teikėjai saugotų žurnalus bent 12 mėnesių ir pateiktų prieigą paprašius.“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.5.1.3.
Segmentavimas toks pat svarbus. Network Security Policy-sme Network Security Policy-sme - SME nurodo:
„Vidiniai tinklai turi būti segmentuojami pagal funkciją (pvz., finansai, svečiai, IoT, administracinės sistemos).“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.2.1.
Zenith Blueprint, etapo „Kontrolės priemonės praktikoje“ 20 žingsnis, pateikia praktinę audito procedūrą tinklo architektūrai ir segmentavimui. Jis nurodo komandoms peržiūrėti ir dokumentuoti tinklo išdėstymą, patikrinti ugniasienės taisykles, IPS/IDS ir nuotolinės prieigos konfigūracijas, patvirtinti, kad debesijos saugumo grupės ir VPC arba potinklių taisyklės atitinka numatytą architektūrą, išvardyti vidines ir išorines tinklo paslaugas ir validuoti, kad jautrios sistemos nepasiekiamos iš bendrųjų naudotojų VLAN arba svečių tinklų.
MSP atveju nuotolinio valdymo priemonės neturi būti plokščiai prijungtos prie biuro tinklo. Duomenų centro paslaugų teikėjui elektros, aušinimo, prieigos kontrolės ir klientų tinklo paslaugų valdymo sąsajos turėtų būti izoliuotos ir stebimos. Debesijos paslaugų teikėjui valdymo plokštumos prieiga turėtų būti ribojama tapatybės, tinklo, įrenginio saugumo būsenos ir privilegijuotų darbo eigų kontrolės priemonėmis.
Tiekėjų saugumas: paslaugų teikėjas taip pat yra klientas
Debesijos, MSP, MSSP ir duomenų centrų paslaugų teikėjai yra tiekėjai reguliuojamiems klientams, tačiau jie taip pat yra programinės įrangos tiekėjų, telekomunikacijų operatorių, tapatybės teikėjų, SaaS platformų, aparatinės įrangos tiekėjų, subtiekėjų ir infrastruktūros operatorių klientai.
NIS2 tiekimo grandinės saugumą padaro pagrindiniu reikalavimu. DORA, taikomas nuo 2025 m. sausio 17 d., finansų subjektams paverčia IRT trečiųjų šalių rizikos valdymą centriniu reikalavimu. NIS2 Article 4 ir Recital 28 pripažįsta DORA kaip sektoriui skirtą Sąjungos teisės aktą finansų subjektams tais atvejais, kai reikalavimai persidengia. Tai nesumažina spaudimo debesijos ir MSP paslaugų teikėjams. Priešingai – jį padidina, nes finansų klientai DORA lygio sutartinius reikalavimus, audito teises, atsparumo testavimą, pasitraukimo strategijas ir pranešimo apie incidentus lūkesčius perkelia į tiekėjų sutartis.
Clarysec Enterprise Trečiųjų šalių ir tiekėjų saugumo politika Trečiųjų šalių ir tiekėjų saugumo politika reikalauja kontroliuojamos trečiųjų šalių prieigos:
„Visa trečiųjų šalių prieiga turi būti žurnaluojama ir stebima ir, kai įmanoma, segmentuojama per tarpinius prieigos serverius, VPN arba nulinio pasitikėjimo šliuzus.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.3.2.
Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME mažiausių privilegijų principą išreiškia tiesiogiai:
„Tiekėjams turi būti suteikta prieiga tik prie minimalių sistemų ir duomenų, būtinų jų funkcijai atlikti.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos nuostata 6.2.1.
Šios nuostatos natūraliai siejasi su ISO/IEC 27001:2022 Annex A kontrolėmis 5.19, 5.20, 5.21 ir 5.22. Jos taip pat palaiko GDPR tvarkytojų ir subtvarkytojų valdyseną, DORA trečiųjų šalių rizikos peržiūras ir klientų audito klausimynus.
Veiklos tęstinumas ir duomenų centro atsparumas: įrodykite prielaidas
NIS2 Article 21 apima veiklos tęstinumą, atsarginių kopijų valdymą, atkūrimą po katastrofos ir krizių valdymą. DORA Articles 11–14 finansų subjektams reikalauja IRT veiklos tęstinumo politikų, reagavimo ir atkūrimo planų, verslo poveikio analizės, atsarginių kopijų politikų, atkūrimo procedūrų, atkūrimo tikslų, testavimo, po incidento atliekamų peržiūrų ir krizių komunikacijos.
Debesijos ir duomenų centrų paslaugų teikėjams tęstinumas nėra segtuvas. Tai architektūra, pajėgumai, sutartys, priklausomybės, atkūrimo įrodymai ir patikrintos prielaidos.
Clarysec Enterprise Veiklos tęstinumo ir atkūrimo po katastrofos politika Veiklos tęstinumo ir atkūrimo po katastrofos politika reikalauja kasmetinės BIA ir peržiūros po reikšmingų pakeitimų:
„Verslo poveikio analizė (BIA) turi būti atliekama bent kartą per metus visiems kritiniams veiklos padaliniams ir peržiūrima esmingai pasikeitus sistemoms, procesams ar priklausomybėms. BIA rezultatai turi apibrėžti: 5.2.1. Maksimaliai toleruotiną prastovos trukmę (MTD) 5.2.2. Atkūrimo laiko tikslus (RTO) 5.2.3. Atkūrimo taško tikslus (RPO) 5.2.4. Kritines priklausomybes (sistemas, tiekėjus, personalą)“
Iš skyriaus „Valdysenos reikalavimai“, politikos nuostata 5.2.
Duomenų centro scenarijuje BIA turėtų apimti elektros tiekimo įvadus, UPS, generatorius, kuro sutartis, aušinimą, gaisro gesinimą, tinklo operatorius, fizinės prieigos sistemas, „remote hands“ paslaugas, stebėseną, atsarginę aparatinę įrangą ir klientų komunikacijos kanalus. Debesijos scenarijuje ji turėtų apimti regionus, prieinamumo zonas, replikaciją, atsarginių kopijų nekintamumą, tapatybės priklausomybes, DNS, sertifikavimo institucijas, API šliuzus ir palaikymo sistemas. MSP scenarijuje ji turėtų apimti nuotolinio valdymo įrankius, privilegijuotosios prieigos saugyklas, EDR konsoles, užklausų valdymą, dokumentų saugyklas ir avarines komunikacijas.
ISO 22301 gali sustiprinti veiklos tęstinumo valdymo discipliną, o ISO/IEC 27005:2022 palaiko rizikos kriterijus, rizikos tvarkymo planavimą, stebėseną, įrodymus ir nuolatinį tobulinimą. Tai naudinga, nes pasirengimas NIS2 reikalauja, kad organizacija teisinius, sutartinius, veiklos, tiekėjų, technologinius, finansinius, procesų ir žmogiškuosius veiksnius sujungtų į vieną rizikos procesą.
Praktinis MSP nuotolinės prieigos pažeidimo rizikos pėdsakas
Praktinį seminarą galima pradėti nuo vieno scenarijaus:
„Privilegijuotos nuotolinės prieigos kompromitavimas lemia neteisėtą prieigą prie klientų sistemų, paslaugos sutrikimą, galimą asmens duomenų atskleidimą ir reglamentavimo pranešimo pareigas.“
Sukurkite rizikų registro eilutę ir užpildykite pėdsaką.
| Laukas | Pavyzdinis įrašas |
|---|---|
| Rizikos savininkas | Valdomų paslaugų vadovas |
| Turtas ir procesai | Nuotolinio valdymo platforma, klientų administratoriaus paskyros, privilegijų saugykla, užklausų valdymas, SIEM, klientų aplinkos |
| Grėsmės įvykis | Prisijungimo duomenų vagystė, MFA nuovargis, žetono vagystė, išnaudotas RMM pažeidžiamumas, piktavališkas vidinis asmuo |
| Poveikis | Kliento kompromitavimas, paslaugos nepasiekiamumas, sutarties pažeidimas, NIS2 reikšmingas incidentas, GDPR asmens duomenų saugumo pažeidimas, DORA klientų eskalavimas |
| Esamos kontrolės priemonės | MFA, PAM, mažiausių privilegijų principas, segmentavimas, žurnalavimas, pažeidžiamumų skenavimas, reagavimo į incidentus planas |
| Reikalingas tvarkymas | Sugriežtinti sąlyginę prieigą, taikyti administratoriaus prieigą reikiamu laiku, pagerinti tenantų izoliavimą, padidinti žurnalų saugojimo terminą, ištestuoti pranešimo veiksmų planą |
| ISO/IEC 27001:2022 įrodymai | Rizikos vertinimas, SoA, prieigos peržiūra, žurnalų pavyzdžiai, pažeidžiamumų ataskaitos, stalo pratybos, vadovybės peržiūra |
| NIS2 susiejimas | Article 21 rizikos valdymas ir Article 23 pranešimas apie incidentus, taip pat Įgyvendinimo reglamento veiklos priemonės |
| Klientų susiejimas | Sutartinis pranešimas, audito teisės, saugumo priedas, DORA suderinti klausimynai, kai taikoma |
| Liekamosios rizikos sprendimas | Priimta rizikos savininko po tvarkymo, peržiūrima kas ketvirtį |
Tada atnaujinkite Taikomumo pareiškimą. Kiekvienai aktualiai Annex A kontrolei paaiškinkite, kodėl ji taikoma ir kurią NIS2 temą palaiko. Galiausiai prieš auditą surinkite įrodymus: MFA taikymo ataskaitas, privilegijuotųjų paskyrų sąrašus, žurnalų saugojimo nustatymus, RMM pataisų būseną, SIEM įspėjimus, incidentų klasifikavimo įrašus, tiekėjų prieigos patvirtinimus ir stalo pratybų rezultatus.
Kaip skirtingi auditoriai tikrins tą pačią kontrolės aplinką
Integruota ISVS turi tenkinti skirtingas patikinimo perspektyvas, nesukuriant atskirų įrodymų paketų kiekvienam karkasui.
| Auditoriaus perspektyva | Į ką bus sutelktas dėmesys | Įprastai prašomi įrodymai |
|---|---|---|
| ISO/IEC 27001:2022 auditorius | Ar NIS2, DORA ir GDPR reikalavimai atsispindi kontekste, taikymo srityje, rizikos vertinime, SoA, vidaus audite ir vadovybės peržiūroje | ISVS taikymo sritis, suinteresuotųjų šalių registras, rizikos metodika, rizikų registras, SoA, tvarkymo planas, politikos, vidaus audito ataskaita, vadovybės peržiūra |
| NIS2 kompetentinga institucija arba deleguotas vertintojas | Ar kibernetinio saugumo rizikos valdymo priemonės yra tinkamos ir proporcingos, ir ar pranešimas apie reikšmingus incidentus veikia veiklos lygmeniu | NIS2 susiejimas, incidentų klasifikavimo procedūra, 24 ir 72 valandų darbo eiga, valdybos priežiūra, techninių kontrolės priemonių įrodymai, tiekėjų saugumo įrodymai |
| DORA klientų vertintojas | Ar IRT trečiųjų šalių rizika, atsparumo testavimas, pranešimas apie incidentus, audito teisės ir pasitraukimo planavimas atitinka finansų sektoriaus lūkesčius | Sutartinės nuostatos, subtiekėjų registras, atsparumo testai, incidentų SLA, pasitraukimo planas, audito ataskaitos, koncentracijos rizikos pagrindimas |
| GDPR auditorius arba DAP peržiūra | Ar asmens duomenų saugumo pažeidimo rizika, tvarkytojo įsipareigojimai, konfidencialumas, vientisumas ir atskaitomybė yra įvertinti | Tvarkymo veiklos įrašai, DPA sąlygos, pažeidimo vertinimo darbo eiga, prieigos žurnalai, šifravimo įrodymai, saugojimo ir ištrynimo kontrolės priemonės |
| NIST orientuotas vertintojas | Ar identifikavimo, apsaugos, aptikimo, reagavimo ir atkūrimo gebėjimai yra įgyvendinti ir matuojami | Turto apskaita, prieigos kontrolės priemonės, pažeidžiamumų duomenys, SIEM aprėptis, reagavimo veiksmų planai, atkūrimo testai, rodikliai |
| COBIT 2019 arba ISACA auditorius | Ar nustatyti valdysenos tikslai, atsakomybės, rizikos savininkystė, kontrolės stebėsena ir patikinimo procesai | Valdysenos nuostatai, RACI, rizikos apetitas, kontrolės savininkystė, KPI/KRI ataskaitos, patikinimo planas, korekcinių veiksmų stebėsena |
Čia Zenith Controls padeda kaip kryžminės atitikties vadovas. Tokioms kontrolėms kaip 5.23, 5.24 ir 8.8 jis susieja ISO/IEC 27001:2022 kontrolės lūkesčius su NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF ir ISO 22301 temomis. Tikslas nėra kurti atskiras atitikties programas. Tikslas – viena įrodymų architektūra, pažymėta pagal kontrolės priemonę, riziką, reglamentavimo veiksnį ir savininką.
Clarysec įgyvendinimo modelis
Debesijos, MSP, MSSP ir duomenų centrų paslaugų teikėjams darbas turėtų vykti penkiais sluoksniais.
Pirma, patvirtinkite taikymo sritį. Nustatykite, ar organizacija ir paslaugos patenka į NIS2 taikymo sritį, kurios valstybės narės taisyklės taikomos, ar Įgyvendinimo reglamentas 2024/2690 taikomas paslaugų teikėjo kategorijai ir ar klientai nustato DORA, GDPR, NIST ar sektoriui būdingus įpareigojimus.
Antra, sukurkite ISVS kontekstą. Pagal ISO/IEC 27001:2022 4 ir 5 punktus identifikuokite suinteresuotąsias šalis, teisines prievoles, klientų įsipareigojimus, tiekėjų priklausomybes, paslaugų ribas ir vadovybės atsakomybes.
Trečia, atlikite rizikos vertinimą ir tvarkymą pagal ISO/IEC 27005:2022 principus. NIS2, DORA, GDPR, sutartis, vidines politikas ir paslaugų rizikas konsoliduokite į vieną bazinių reikalavimų registrą. Apibrėžkite rizikos kriterijus, savininkus, tikimybę, poveikį, tvarkymo parinktis, kontrolės priemonių pasirinkimus ir liekamosios rizikos patvirtinimus.
Ketvirta, susiekite kontrolės priemones su Taikomumo pareiškimu. Naudokite Zenith Blueprint 13 ir 14 žingsnius rizikoms susieti su Annex A kontrolėmis ir reglamentavimo lūkesčiais. Naudokite Zenith Controls, kad suprastumėte, kaip tokios kontrolės kaip 5.23, 5.24, 8.8, 5.20 ir 5.30 siejasi skirtinguose karkasuose ir audito perspektyvose.
Penkta, paverskite įrodymus veiklos praktika. Politikų nepakanka. Clarysec politikų biblioteka pateikia įgyvendinamus reikalavimus debesijos patvirtinimui, tiekėjų prieigai, žurnalavimui, pažeidžiamumų šalinimui, tinklo segmentavimui, incidentų klasifikavimui ir tęstinumo planavimui. Įrodymų paketas patvirtina, kad šie reikalavimai veikia.
Kitas žingsnis: paverskite NIS2 spaudimą auditui tinkamu atsparumu
NIS2 Įgyvendinimo reglamentas 2024/2690 nereikalauja chaoso. Jis reikalauja atsekamumo, savininkystės ir įrodymų.
Jei esate debesijos paslaugų teikėjas, MSP, MSSP arba duomenų centro operatorius, pradėkite nuo savo paslaugų, klientų, priklausomybių, incidentų scenarijų ir įrodymų pareigų. Tada atlikite struktūruotą NIS2 ir ISO/IEC 27001:2022 susiejimo pratimą:
- Patvirtinkite, ar jūsų subjektas ir paslaugos patenka į taikymo sritį.
- Susiekite NIS2 ir Įgyvendinimo reglamento temas su savo ISVS taikymo sritimi.
- Atnaujinkite rizikų registrą ir Taikomumo pareiškimą.
- Taikykite Clarysec politikas debesijos naudojimui, tiekėjų saugumui, žurnalavimui, pažeidžiamumų valdymui, reagavimui į incidentus, tinklo saugumui ir tęstinumui.
- Naudokite Zenith Blueprint Zenith Blueprint 13, 14, 20 ir 23 žingsnius atsekamumui ir veiklos įrodymams sukurti.
- Naudokite Zenith Controls Zenith Controls, kad kryžmiškai susietumėte ISO/IEC 27001:2022 kontrolės priemones su NIS2, DORA, GDPR, NIST ir COBIT 2019 lūkesčiais.
- Ištestuokite įrodymus audito simuliacijoje prieš tai, kai jų paprašys klientas, reguliuotojas ar sertifikavimo auditorius.
Clarysec gali padėti jums peržengti kontrolinių sąrašų atitiktį ir sukurti integruotą ISVS, atsparią NIS2, DORA, GDPR ir klientų auditų spaudimui. Atsisiųskite aktualius Clarysec įrankių rinkinius, užsisakykite susiejimo seminarą arba paprašykite pasirengimo auditui vertinimo, kad reglamentavimo sudėtingumą paverstumėte pagrįsta saugumo valdysena ir veiklos atsparumu.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
