Mapiranje kontrola NIS2 2024/2690 na ISO 27001 za pružatelje usluga u oblaku
U utorak u 08:17 Maria, direktorica informacijske sigurnosti (CISO) europskog pružatelja upravljanih usluga, prima upozorenje kojeg se boji svaki MSP. Jedan povlašteni račun za udaljeno upravljanje aktivirao je upozorenje o nemogućem putovanju. U dva korisnička okruženja vidljive su neuobičajene administrativne radnje. SOC je već otvorio konferencijski most za kritični incident.
Do 09:00 u poziv se uključuje glavni izvršni direktor. Pitanja se odmah mijenjaju.
Jesmo li u opsegu NIS2? Primjenjuje li se na nas Provedbena uredba Komisije (EU) 2024/2690? Moramo li poslati rano upozorenje u roku od 24 sata? Koje klijente moramo obavijestiti? Možemo li dokazati da su MFA, zapisivanje događaja, segmentacija, upravljanje ranjivostima, kontrole dobavljača i eskalacija incidenata bili operativni prije incidenta?
Marijina tvrtka certificirana je prema ISO/IEC 27001:2022. Klijentima, među kojima su logistički pružatelj i regionalna banka, pruža upravljanje oblakom, usluge podatkovnog centra i upravljanu sigurnosnu podršku. Certifikat je važan, ali sam po sebi ne odgovara na operativna pitanja. Pravni tim ima nacrt postupka obavješćivanja. Voditelj usklađenosti ima proračunsku tablicu. Revizor je zatražio Izjavu o primjenjivosti, testiranje odgovora na incidente, dnevničke zapise privilegiranog pristupa, dubinsku analizu dobavljača, dokaze o modelu podijeljene odgovornosti u oblaku i pretpostavke neprekidnosti poslovanja.
To je trenutak u kojem NIS2 prestaje biti pravni tekst i postaje operativni problem kontrola.
Za pružatelje usluga računalstva u oblaku, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga i pružatelje usluga podatkovnih centara, NIS2 i Provedbena uredba 2024/2690 podižu prag s opće sigurnosne namjere na dokazive kontrolne dokaze. Upravljanje, upravljanje rizicima, kontrola pristupa, upravljanje imovinom, postupanje s ranjivostima, odgovor na incidente, sigurnost dobavljača, zapisivanje događaja, nadzor, šifriranje, neprekidnost poslovanja i fizička otpornost moraju funkcionirati kao jedinstven sustav.
ISO/IEC 27001:2022 najbolja je okosnica za taj sustav, ali samo ako organizacija mapira zahtjeve NIS2 u ISMS, registar rizika, Izjavu o primjenjivosti, politike i model dokaza. Certifikat na zidu nije dovoljan. Pravi posao je izgraditi revizijski provjerljivu nit od regulative do rizika, od rizika do kontrole, od kontrole do politike i od politike do operativnog dokaza.
Zašto NIS2 2024/2690 mijenja razgovor o usklađenosti pružatelja usluga u oblaku i MSP-ova
NIS2 koristi model sektora i veličine, ali njegove kategorije digitalne infrastrukture i upravljanja IKT uslugama namjerno su široke. Prema NIS2 Article 2 i Article 3, u vezi s Annex I i Annex II, mnoge se organizacije mogu klasificirati kao ključni ili važni subjekti, uključujući pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, DNS pružatelje, registre TLD domena, mreže za isporuku sadržaja i pružatelje usluga povjerenja. Države članice moraju uspostaviti i periodično preispitivati popise ključnih i važnih subjekata, pri čemu je prvi rok za popis određen za 17. travnja 2025.
To je važno jer se pružatelji usluga u oblaku, MSP-ovi, MSSP-ovi i pružatelji usluga podatkovnih centara nalaze unutar lanaca rizika drugih organizacija. Kompromitacija upravljačke ravnine oblaka može utjecati na tisuće korisničkih sustava. Prekid rada podatkovnog centra može se preliti na bankarstvo, zdravstvo, logistiku i javnu upravu. Kompromitacija vjerodajnica MSP-a može prerasti u ransomware događaj kod više klijenata. Neuspjeh MSSP-a u otkrivanju može odgoditi ograničavanje incidenta kod reguliranih klijenata.
NIS2 Article 20 zahtijeva da upravljačka tijela odobre mjere upravljanja kibernetičkim rizicima i nadziru njihovu provedbu. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere utemeljene na pristupu svih opasnosti. Osnovni zahtjevi uključuju analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu i razvoj, postupanje s ranjivostima i njihovu objavu, procjenu učinkovitosti, kibernetičku higijenu, obuku, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom, MFA ili kontinuiranu autentikaciju, sigurne komunikacije i hitne komunikacije.
Article 23 uvodi fazno prijavljivanje značajnih incidenata, uključujući rano upozorenje u roku od 24 sata, obavijest o incidentu u roku od 72 sata, privremena izvješća na zahtjev i konačno izvješće u roku od mjesec dana nakon obavijesti ili nakon postupanja s incidentom ako je incident još u tijeku.
Provedbena uredba 2024/2690 čini ta očekivanja konkretnijima za relevantne digitalne pružatelje. U praksi nadležna tijela, klijenti i revizori neće pitati samo postoje li politike. Pitat će jesu li kontrole mapirane, imaju li vlasnika, jesu li testirane i jesu li potkrijepljene dokazima.
ISO/IEC 27001:2022 pretvara NIS2 u operativni kontekst ISMS-a
Česta pogreška u pripremi za NIS2 jest započeti velikim kontrolnim popisom i dodijeliti zadatke IT-u, pravnom timu, SOC-u, infrastrukturi, upravljanju dobavljačima i usklađenosti. To može stvoriti aktivnost, ali često ne prolazi reviziju jer nitko ne može pokazati zašto su kontrole odabrane, kako se odnose na rizik, tko je prihvatio preostali rizik i koji dokazi potvrđuju djelotvornost.
ISO/IEC 27001:2022 pružateljima usluga daje strukturu za izbjegavanje tog neuspjeha.
Točke 4.1 do 4.4 zahtijevaju da organizacija utvrdi interna i eksterna pitanja, identificira zainteresirane strane i njihove zahtjeve, odluči koji će se zahtjevi obuhvatiti kroz ISMS i definira opseg ISMS-a, uključujući sučelja i ovisnosti. Za pružatelja usluga u oblaku ili MSP-a opseg treba izričito obuhvatiti NIS2, Provedbenu uredbu 2024/2690, sigurnosne priloge ugovorima s klijentima, zahtjeve klijenata potaknute DORA, regije oblaka, podizvođače, ovisnosti podatkovnog centra, platforme za udaljeno upravljanje, putove privilegiranog pristupa i obveze obavješćivanja o incidentima.
Točke 5.1 do 5.3 zahtijevaju vodstvo, usklađivanje politika, resurse, komunikaciju, dodijeljene odgovornosti i odgovornost uprave. To izravno podupire NIS2 Article 20.
Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika, obradu rizika, vlasnike rizika, analizu vjerojatnosti i posljedica, odabir kontrola, usporedbu s Annex A, Izjavu o primjenjivosti, plan obrade rizika i formalno prihvaćanje preostalog rizika. Tu NIS2 postaje operativan. Svaki regulatorni zahtjev postaje pokretač rizika, obveza usklađenosti, zahtjev za kontrolu ili zahtjev za dokaz.
Clarysec započinje taj rad s Zenith Blueprint: plan implementacije u 30 koraka za revizore Zenith Blueprint, osobito u fazi upravljanja rizicima.
Od koraka 13, Planiranje obrade rizika i Izjava o primjenjivosti, Zenith Blueprint upućuje timove da izgrade sljedivost između rizika, kontrola i regulatornih pokretača:
„Unakrsno referencirajte propise: Ako su određene kontrole implementirane posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete navesti u Registru rizika ili u napomenama SoA. Npr. kontrola 8.27 (sigurno brisanje podataka) može biti vrlo relevantna za zahtjev GDPR o zbrinjavanju osobnih podataka; možete navesti ‘Primjenjivo – podupire GDPR Art.32 (sigurnost obrade)’. To ISO ne zahtijeva, ali pomaže pokazati da ste razmotrili te okvire.”
Korak 14, Politike obrade rizika i regulatorne unakrsne reference, dodaje praktičnu disciplinu mapiranja:
„Za svaki propis, ako je primjenjivo, možete izraditi jednostavnu tablicu mapiranja koja navodi ključne sigurnosne zahtjeve propisa i odgovarajuće kontrole/politike u vašem ISMS-u. To nije obvezno prema ISO 27001, ali je korisna interna vježba kako bi se osiguralo da ništa nije propušteno.”
To je razlika između tvrdnje „certificirani smo prema ISO” i dokazivanja „naš ISO/IEC 27001:2022 ISMS adresira Provedbenu uredbu NIS2 2024/2690.”
Jedinstveno mapiranje kontrola NIS2 na ISO/IEC 27001:2022
Sljedeće mapiranje nije pravni savjet niti zamjena za analizu nacionalnog prijenosa. To je praktična arhitektura kontrola za pružatelje usluga kojima je potreban revizijski provjerljiv put prema spremnosti za NIS2 kroz ISO/IEC 27001:2022.
| Tema NIS2 i Provedbene uredbe | Mehanizam ISMS-a prema ISO/IEC 27001:2022 | Ključna područja kontrola iz Annex A | Dokazi implementacije prema Clarysec |
|---|---|---|---|
| Upravljanje i odgovornost uprave | Točke 4, 5, 6 i 9 definiraju kontekst, vodstvo, planiranje rizika i pregled učinkovitosti | 5.1 Politike informacijske sigurnosti, 5.2 Uloge i odgovornosti za informacijsku sigurnost, 5.31 Pravni, zakonski, regulatorni i ugovorni zahtjevi | Opseg ISMS-a, registar zainteresiranih strana, odobrenje odbora, registar rizika, SoA, zapisnici preispitivanja uprave |
| Upravljanje uslugama u oblaku | Procjena rizika, dubinska analiza dobavljača, podijeljena odgovornost i odabir kontrola | 5.23 Informacijska sigurnost za korištenje usluga u oblaku, 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača | Popis usluga u oblaku, procjena rizika pružatelja, matrica podijeljene odgovornosti, ugovorne odredbe, dokazi zapisivanja događaja u oblaku |
| Privilegirani pristup MSP-a i MSSP-a | Obrada rizika za korisnička okruženja, administratorske platforme i alate za podršku | 5.15 Kontrola pristupa, 5.16 Upravljanje identitetom, 5.18 Prava pristupa, 8.2 Prava privilegiranog pristupa, 8.5 Sigurna autentikacija | PAM zapisi, MFA izvješća, dnevnički zapisi udaljenog pristupa, konfiguracija bastion poslužitelja ili Zero Trust pristupnika, pregledi pristupa |
| Otpornost podatkovnog centra | Analiza utjecaja na poslovanje, planiranje neprekidnosti i upravljanje ovisnostima | 5.30 IKT spremnost za neprekidnost poslovanja, 7.1 Perimetri fizičke sigurnosti, 7.2 Fizički ulaz, 8.13 Sigurnosno kopiranje informacija, 8.14 Redundantnost | BIA, RTO i RPO zapisi, izvješće o DR testu, zapisi fizičkog pristupa, dokazi testiranja napajanja i hlađenja |
| Prijavljivanje i eskalacija incidenata | Proces za incidente povezan s pravnim, ugovornim i korisničkim okidačima za obavješćivanje | 5.24 Planiranje i priprema upravljanja incidentima informacijske sigurnosti, 5.25 Procjena i odluka o događajima informacijske sigurnosti, 5.26 Odgovor na incidente informacijske sigurnosti, 5.27 Učenje iz incidenata informacijske sigurnosti | Operativne upute za rano upozorenje u roku od 24 sata, tijek obavješćivanja u roku od 72 sata, registar incidenata, pregled nakon incidenta |
| Postupanje s ranjivostima i objava | Obrada ranjivosti temeljena na riziku, postupanje s iznimkama i vrednovanje učinkovitosti | 8.8 Upravljanje tehničkim ranjivostima, 8.9 Upravljanje konfiguracijom, 8.32 Upravljanje promjenama, 8.16 Aktivnosti nadzora | Rezultati skeniranja, SLA-ovi za korektivne radnje, odobrenja iznimaka, izvješća o zakrpama, ulazni podaci obavještajnih podataka o prijetnjama |
| Sigurnost opskrbnog lanca | Zahtjevi zainteresiranih strana i rizik dobavljača integrirani u ISMS | 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, 5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača | Razvrstavanje dobavljača po razinama, upitnici za dubinsku analizu dobavljača, ugovorne odredbe, prava na reviziju, registar podizvođača, planovi izlaska |
| Zapisivanje događaja, nadzor i istraga | Otkrivanje, dokazi, vremenska korelacija i podrška incidentima | 8.15 Zapisivanje događaja, 8.16 Aktivnosti nadzora, 8.17 Sinkronizacija sata, 5.25 Procjena i odluka o događajima informacijske sigurnosti | Mapa pokrivenosti SIEM-a, dokaz o zadržavanju dnevničkih zapisa, zapisi podešavanja upozorenja, zapisi sinkronizacije sata, dokazi korelacije incidenata |
| Izolacija mreže i korisničkih okruženja | Sigurna arhitektura, segmentacija i ograničeni administrativni putovi | 8.20 Sigurnost mreže, 8.22 Razdvajanje mreža, 8.23 Web filtriranje, 8.24 Uporaba kriptografije | Mrežni dijagrami, pravila vatrozida, sigurnosne grupe u oblaku, VPC ili pravila podmreža, rezultati testiranja segmentacije |
Ovo mapiranje postaje učinkovito kada se ugradi u registar rizika i Izjavu o primjenjivosti. Na primjer, pružatelj može izraditi scenarij rizika pod nazivom „Kompromitacija platforme za udaljeno upravljanje dovodi do neovlaštenih radnji u korisničkim okruženjima.” Kontrole uključuju MFA, upravljanje privilegiranim pristupom, segmentaciju, zapisivanje događaja, upravljanje ranjivostima, sigurnost dobavljača, planiranje incidenata i postupke obavješćivanja klijenata. Napomene SoA mogu se pozvati na NIS2 Article 21, Article 23, Provedbenu uredbu 2024/2690, ugovore s klijentima i zahtjeve DORA za dubinsku analizu klijenata, gdje je relevantno.
Upravljanje oblakom: ISO kontrola 5.23 sidrište je za NIS2
Za pružatelje usluga u oblaku i MSP-ove koji koriste usluge u oblaku za pružanje korisničkih usluga, kontrola 5.23 iz ISO/IEC 27001:2022 Annex A, Informacijska sigurnost za korištenje usluga u oblaku, jedno je od najvažnijih sidrišta.
Zenith Controls: vodič za unakrsnu usklađenost Zenith Controls sažima kontrolu 5.23 kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost, povezanu sa sigurnošću odnosa s dobavljačima, upravljanjem, rizikom ekosustava i zaštitom. Obuhvaća upravljanje uslugama u oblaku, podijeljenu odgovornost, procjenu pružatelja, popise imovine, lokaciju podataka, zapisivanje događaja, šifriranje, uloge identiteta, nadzor, ugovorne odredbe, rizik dobavljača, izlazak iz oblaka i planiranje otpornosti.
Zenith Blueprint, faza Kontrole u praksi, korak 23, objašnjava praktičan razlog:
„Oblak više nije odredište, nego zadana opcija. Kontrola 5.23 prepoznaje tu stvarnost i zahtijeva da se informacijska sigurnost izričito obradi pri odabiru, korištenju i upravljanju uslugama u oblaku, ne naknadno, nego kao načelo dizajna od samog početka.”
Za MSP-a, svaka platforma za udaljeno praćenje i upravljanje, korisnički portal, alat za evidentiranje zahtjeva, platforma sigurnosne telemetrije, usluga sigurnosnog kopiranja, imenik u oblaku i SaaS administratorska konzola moraju biti obuhvaćeni upravljanjem. Za pružatelja usluga podatkovnog centra, upravljanje oblakom može se primjenjivati na platforme za nadzor, sustave upravljanja posjetiteljima, integracije kontrole fizičkog pristupa, sustave udaljenog upravljanja i infrastrukturu korisničkog portala.
Clarysecova Enterprise Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku čini dubinsku analizu prije aktivacije obveznom:
„Svako korištenje usluga u oblaku mora prije aktivacije proći dubinsku analizu dobavljača temeljenu na riziku, uključujući procjenu pružatelja, provjeru usklađenosti s pravnim zahtjevima i preglede kontrola.”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.2.
Za manje pružatelje, Cloud Usage Policy-sme Cloud Usage Policy-sme - SME uspostavlja jednostavan model odobravanja:
„Glavni direktor (GM) mora pregledati i odobriti svako korištenje usluga u oblaku prije implementacije ili pretplate.”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.1.
Oba pristupa podupiru isto očekivanje NIS2: rizik ovisnosti o oblaku mora biti razumljiv prije nego što usluga postane dio lanca isporuke.
Odgovor na incidente: sat od 24 sata počinje teći prije izrade izvješća
NIS2 Article 23 ne ostavlja mnogo prostora jer rok za prijavljivanje počinje od trenutka saznanja za značajan incident, a ne od trenutka kada je dostupna savršena analiza temeljnog uzroka. Izazov za pružatelje usluga jest brzo utvrditi je li događaj značajan, koji su klijenti pogođeni, jesu li uključeni osobni podaci, postoji li prekogranični utjecaj na uslugu i koji su ugovorni rokovi počeli teći.
Kontrola 5.24 iz ISO/IEC 27001:2022 Annex A, Planiranje i priprema upravljanja incidentima informacijske sigurnosti, planska je kontrola. Zenith Controls sažima je kao korektivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost, povezanu s konceptima odgovora i oporavka, upravljanjem, upravljanjem događajima i obranom. Uključuje uloge, odgovornosti, putove eskalacije, komunikacijske protokole, spremnost za regulatorno obavješćivanje, usklađivanje sa zapisivanjem događaja i nadzorom, integraciju s neprekidnošću poslovanja i oporavkom od katastrofe, učenje nakon incidenta i mapiranje na NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 i COBIT 2019.
Clarysecova Incident Response Policy-sme Incident Response Policy-sme - SME pretvara prvu odluku u vremenski ograničen zahtjev:
„Glavni direktor, uz doprinos pružatelja IT usluga, mora klasificirati sve incidente prema ozbiljnosti u roku od jednog sata od obavijesti.”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.3.1.
Ta klasifikacija u roku od jednog sata podupire operativnu disciplinu potrebnu za analizu ranog upozorenja NIS2 u roku od 24 sata, procjenu povrede osobnih podataka prema GDPR, eskalaciju prema klijentima u skladu s DORA i trijažu ugovornih obavijesti.
Stablo odlučivanja za incidente kod pružatelja usluga treba odgovoriti na četiri pitanja:
- Postoji li potvrđena ili sumnjiva kompromitacija povjerljivosti, cjelovitosti ili dostupnosti?
- Utječe li događaj na pružanje usluge, korisnička okruženja, regulirane klijente, osobne podatke ili kritične funkcije?
- Može li uzrokovati ozbiljan operativni poremećaj, financijski gubitak ili materijalnu ili nematerijalnu štetu?
- Koje se obveze obavješćivanja primjenjuju: NIS2, GDPR, obveze prema klijentima u skladu s DORA, ugovorni SLA-ovi ili očekivanja nacionalnog regulatora?
Stablo odlučivanja treba testirati u stolnim vježbama prije stvarnog incidenta.
Upravljanje ranjivostima: dokažite smanjenje rizika prije učinka
NIS2 zahtijeva postupanje s ranjivostima i njihovu objavu. Za klijente i regulatore, upravljanje ranjivostima jedno je od najlakše mjerljivih područja kontrola jer proizvodi jasne dokaze: obuhvat skeniranja, rokove zakrpavanja, odobrenja iznimaka, analizu iskorištenih ranjivosti i zapise o korektivnim radnjama.
Kontrola 8.8 iz ISO/IEC 27001:2022 Annex A, Upravljanje tehničkim ranjivostima, u Zenith Controls sažeta je kao preventivna kontrola kroz povjerljivost, cjelovitost i dostupnost, povezana s funkcijama identificiranja i zaštite, upravljanjem prijetnjama i ranjivostima, upravljanjem, ekosustavom, zaštitom i obranom. Uključuje identifikaciju ranjivosti, procjenu, prioritizaciju, zakrpavanje, kompenzacijske kontrole, integraciju obavještajnih podataka o prijetnjama, objavu ranjivosti, odgovornosti za ranjivosti u oblaku i aplikacijama, revizijske dokaze i rokove korektivnih radnji.
Clarysecova Enterprise Politika upravljanja ranjivostima i zakrpama Politika upravljanja ranjivostima i zakrpama revizorima daje konkretan model za testiranje:
„Organizacija mora klasificirati sve otkrivene ranjivosti koristeći standardiziranu metodologiju (npr. CVSS v3.x) i primijeniti rokove za korektivne radnje usklađene s kritičnošću za poslovanje: 5.2.1 Kritično (CVSS 9.0-10.0): neposredan pregled; rok zakrpavanja najviše 72 sata. 5.2.2 Visoko (7.0-8.9): odgovor u roku od 48 sati; rok zakrpavanja 7 kalendarskih dana. 5.2.3 Srednje (4.0-6.9): odgovor u roku od 5 dana; rok zakrpavanja 30 kalendarskih dana. 5.2.4 Nisko (<4.0): odgovor u roku od 10 dana; rok zakrpavanja 60 kalendarskih dana.”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.2.
Za pružatelja usluga u oblaku to mora obuhvatiti komponente hipervizora, slike kontejnera, orkestracijske slojeve, sučelja za programiranje aplikacija dostupna klijentima, CI/CD cjevovode, administrativne konzole i biblioteke trećih strana. Za MSP-a, ključno je pitanje jesu li interne ranjivosti odvojene od ranjivosti kojima upravlja klijent i definiraju li ugovori odgovornost. Za pružatelja usluga podatkovnog centra opseg može uključivati sustave upravljanja zgradom, sustave kontrole pristupa, platforme za nadzor, alate za udaljenu podršku na lokaciji i mrežnu infrastrukturu.
Model podijeljene odgovornosti mora biti dokumentiran. Pružatelj možda nije vlasnik svake zakrpe, ali i dalje mora upravljati rizikom, obavijestiti klijenta gdje je primjereno i dokazati da su granice odgovornosti razumljive.
Zapisivanje događaja, nadzor i segmentacija čine incidente istraživima
Kada incident kod pružatelja usluga počne utjecati na klijente, prva pitanja o dokazima su jednostavna: tko se prijavio, odakle, s kojim ovlastima, u koje korisničko okruženje, što je promijenjeno, koji dnevnički zapisi postoje i jesu li administrativni putovi bili segmentirani.
Clarysecova Enterprise Politika zapisivanja događaja i nadzora Politika zapisivanja događaja i nadzora zahtijeva da obuhvaćeni sustavi generiraju dnevničke zapise potrebne osobama zaduženima za postupanje s incidentima i revizorima:
„Svi obuhvaćeni sustavi moraju generirati dnevničke zapise koji bilježe: 6.1.1.1 autentikaciju korisnika i pokušaje pristupa 6.1.1.2 aktivnosti privilegiranih korisnika 6.1.1.3 promjene konfiguracije 6.1.1.4 neuspjele pokušaje pristupa ili sistemske događaje 6.1.1.5 detekcije zlonamjernog softvera i sigurnosna upozorenja 6.1.1.6 vanjske komunikacije i okidače pravila vatrozida”
Iz odjeljka „Zahtjevi za implementaciju politike”, odredba politike 6.1.1.
Za MSP-ove koji se oslanjaju na vanjske pružatelje, Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME dodaje ugovorni zahtjev:
„Ugovori moraju zahtijevati od pružatelja da zadržavaju dnevničke zapise najmanje 12 mjeseci i omoguće pristup na zahtjev”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.5.1.3.
Segmentacija je jednako važna. Network Security Policy-sme Network Security Policy-sme - SME navodi:
„Interne mreže moraju biti segmentirane prema funkciji (npr. financije, gosti, IoT, administrativni sustavi)”
Iz odjeljka „Zahtjevi za implementaciju politike”, odredba politike 6.2.1.
Zenith Blueprint, faza Kontrole u praksi, korak 20, daje praktičan revizijski postupak za mrežnu arhitekturu i segmentaciju. Upućuje timove da pregledaju i dokumentiraju mrežni raspored, provjere pravila vatrozida, IPS/IDS i konfiguracije udaljenog pristupa, potvrde da sigurnosne grupe u oblaku i VPC ili pravila podmreža odgovaraju planiranoj arhitekturi, navedu interne i vanjske mrežne usluge i provjere da osjetljivi sustavi nisu dostupni iz općih korisničkih VLAN-ova ili gostujućih mreža.
Za MSP-a alati za udaljeno upravljanje ne smiju biti izravno povezani s uredskom mrežom. Za pružatelja usluga podatkovnog centra upravljačka sučelja za napajanje, hlađenje, kontrolu pristupa i korisničke mrežne usluge trebaju biti izolirana i nadzirana. Za pružatelja usluga u oblaku pristup upravljačkoj ravnini treba biti ograničen kontrolama identiteta, mreže, sigurnosnog stanja uređaja i privilegiranih tijekova rada.
Sigurnost dobavljača: pružatelj usluga također je klijent
Pružatelji usluga u oblaku, MSP-ovi, MSSP-ovi i pružatelji usluga podatkovnih centara dobavljači su reguliranim klijentima, ali su istodobno i klijenti dobavljača softvera, telekomunikacijskih operatora, pružatelja identiteta, SaaS platformi, dobavljača hardvera, podizvođača i operatora infrastrukture.
NIS2 sigurnost opskrbnog lanca čini temeljnim zahtjevom. DORA, koja se primjenjuje od 17. siječnja 2025., upravljanje IKT rizicima trećih strana stavlja u središte za financijske subjekte. NIS2 Article 4 i Recital 28 priznaju DORA kao sektorski poseban pravni akt Unije za financijske subjekte ondje gdje se zahtjevi preklapaju. To ne uklanja pritisak s pružatelja usluga u oblaku i MSP-ova. Povećava ga jer financijski klijenti u ugovore s dobavljačima prenose ugovorne zahtjeve razine DORA, prava na reviziju, testiranje otpornosti, strategije izlaska i očekivanja prijavljivanja incidenata.
Clarysecova Enterprise Politika sigurnosti trećih strana i dobavljača Politika sigurnosti trećih strana i dobavljača zahtijeva kontrolirani pristup trećih strana:
„Sav pristup trećih strana mora se bilježiti i nadzirati te, gdje je izvedivo, segmentirati kroz bastion poslužitelje, VPN-ove ili Zero Trust pristupnike.”
Iz odjeljka „Zahtjevi za implementaciju politike”, odredba politike 6.3.2.
Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME izražava načelo najmanjih privilegija izravnim riječima:
„Dobavljačima se smije odobriti pristup samo minimalnim sustavima i podacima potrebnima za obavljanje njihove funkcije.”
Iz odjeljka „Zahtjevi za implementaciju politike”, odredba politike 6.2.1.
Te se odredbe prirodno mapiraju na kontrole 5.19, 5.20, 5.21 i 5.22 iz ISO/IEC 27001:2022 Annex A. Također podupiru upravljanje izvršiteljima obrade i podizvršiteljima obrade prema GDPR, preglede rizika trećih strana prema DORA i revizijske upitnike klijenata.
Neprekidnost poslovanja i otpornost podatkovnog centra: dokažite pretpostavke
NIS2 Article 21 uključuje neprekidnost poslovanja, upravljanje sigurnosnim kopijama, oporavak od katastrofe i upravljanje krizom. DORA Articles 11 to 14 zahtijevaju politike neprekidnosti IKT poslovanja, planove odgovora i oporavka, analizu utjecaja na poslovanje, politike sigurnosnog kopiranja, postupke vraćanja podataka, ciljeve oporavka, testiranje, preglede nakon incidenta i krizne komunikacije za financijske subjekte.
Za pružatelje usluga u oblaku i podatkovnih centara neprekidnost nije fascikl. To su arhitektura, kapacitet, ugovori, ovisnosti, dokazi vraćanja podataka i testirane pretpostavke.
Clarysecova Enterprise Politika neprekidnosti poslovanja i oporavka od katastrofe Politika neprekidnosti poslovanja i oporavka od katastrofe zahtijeva godišnju BIA i pregled nakon značajnih promjena:
„Analiza utjecaja na poslovanje (BIA) provodi se najmanje jednom godišnje za sve kritične poslovne jedinice i pregledava nakon značajnih promjena sustava, procesa ili ovisnosti. Izlazni rezultati BIA moraju definirati: 5.2.1. maksimalno prihvatljivo vrijeme prekida (MTD) 5.2.2. ciljeve vremena oporavka (RTO) 5.2.3. ciljeve točke oporavka (RPO) 5.2.4. kritične ovisnosti (sustavi, dobavljači, osoblje)”
Iz odjeljka „Upravljački zahtjevi”, odredba politike 5.2.
U scenariju podatkovnog centra BIA treba obuhvatiti dovode električne energije, UPS, generatore, ugovore o gorivu, hlađenje, sustave za gašenje požara, mrežne operatore, sustave fizičkog pristupa, udaljenu podršku na lokaciji, nadzor, rezervni hardver i komunikacijske kanale s klijentima. U scenariju oblaka treba obuhvatiti regije, zone dostupnosti, replikaciju, nepromjenjivost sigurnosnih kopija, ovisnosti identiteta, DNS, certifikacijska tijela, API pristupnike i sustave podrške. U scenariju MSP-a treba obuhvatiti alate za udaljeno upravljanje, trezore privilegiranog pristupa, EDR konzole, sustav za evidentiranje zahtjeva, repozitorije dokumenata i hitne komunikacije.
ISO 22301 može ojačati disciplinu upravljanja kontinuitetom poslovanja, dok ISO/IEC 27005:2022 podupire kriterije rizika, planiranje obrade, praćenje, dokaze i kontinuirano poboljšanje. To je korisno jer spremnost za NIS2 zahtijeva da organizacija objedini pravne, ugovorne, operativne, dobavljačke, tehnološke, financijske, procesne i ljudske čimbenike u jedan proces upravljanja rizicima.
Praktičan revizijski trag rizika za povredu udaljenog pristupa kod MSP-a
Praktična radionica može započeti jednim scenarijem:
„Kompromitacija privilegiranog udaljenog pristupa rezultira neovlaštenim pristupom korisničkim sustavima, prekidom usluge, mogućom izloženošću osobnih podataka i regulatornim obvezama obavješćivanja.”
Izradite redak u registru rizika i dovršite sljedivost.
| Polje | Primjer unosa |
|---|---|
| Vlasnik rizika | Voditelj upravljanih usluga |
| Imovina i procesi | Platforma za udaljeno upravljanje, korisnički administratorski računi, trezor privilegiranih pristupa, sustav za evidentiranje zahtjeva, SIEM, korisnička okruženja |
| Događaj prijetnje | Krađa vjerodajnica, MFA zamor, krađa tokena, iskorištena RMM ranjivost, zlonamjerni insider |
| Utjecaj | Kompromitacija klijenta, prekid usluge, ugovorna povreda, značajan incident prema NIS2, povreda osobnih podataka prema GDPR, eskalacija prema klijentu u skladu s DORA |
| Postojeće kontrole | MFA, PAM, načelo najmanjih ovlasti, segmentacija, zapisivanje događaja, skeniranje ranjivosti, plan odgovora na incidente |
| Potrebna obrada | Pojačati uvjetni pristup, uvesti just-in-time administratorski pristup, poboljšati izolaciju korisničkih okruženja, povećati zadržavanje revizijskih zapisa, testirati operativne upute za obavješćivanje |
| Dokazi prema ISO/IEC 27001:2022 | Procjena rizika, SoA, pregled pristupa, uzorci dnevničkih zapisa, izvješća o ranjivostima, stolna vježba, preispitivanje uprave |
| Mapiranje NIS2 | Article 21 upravljanje rizicima i Article 23 prijavljivanje incidenata, plus operativne mjere Provedbene uredbe |
| Mapiranje prema klijentu | Ugovorno obavješćivanje, prava na reviziju, sigurnosni prilog, upitnici usklađeni s DORA gdje je primjenjivo |
| Odluka o preostalom riziku | Vlasnik rizika prihvatio nakon obrade, pregledava se tromjesečno |
Zatim ažurirajte Izjavu o primjenjivosti. Za svaku relevantnu kontrolu iz Annex A objasnite zašto je primjenjiva i koju temu NIS2 podupire. Naposljetku, prikupite dokaze prije revizije: izvješća o provedbi MFA, popise privilegiranih računa, postavke zadržavanja dnevničkih zapisa, status zakrpa za RMM, SIEM upozorenja, zapise klasifikacije incidenata, odobrenja pristupa dobavljača i rezultate stolnih vježbi.
Kako će različiti revizori testirati isto kontrolno okruženje
Integrirani ISMS mora zadovoljiti različite perspektive osiguranja bez stvaranja zasebnih paketa dokaza za svaki okvir.
| Perspektiva revizora | Na što će se usredotočiti | Tipični traženi dokazi |
|---|---|---|
| Revizor ISO/IEC 27001:2022 | Jesu li zahtjevi NIS2, DORA i GDPR odraženi u kontekstu, opsegu, procjeni rizika, SoA, internoj reviziji i preispitivanju uprave | Opseg ISMS-a, registar zainteresiranih strana, metodologija rizika, registar rizika, SoA, plan obrade, politike, izvješće interne revizije, preispitivanje uprave |
| Nadležno tijelo NIS2 ili delegirani procjenitelj | Jesu li mjere upravljanja kibernetičkim rizicima odgovarajuće i razmjerne te je li prijavljivanje značajnih incidenata operativno | Mapiranje NIS2, postupak klasifikacije incidenata, tijek za 24 i 72 sata, nadzor odbora, dokazi tehničkih kontrola, dokazi sigurnosti dobavljača |
| Procjenitelj klijenta prema DORA | Ispunjavaju li IKT rizici trećih strana, testiranje otpornosti, prijavljivanje incidenata, prava na reviziju i planiranje izlaska očekivanja financijskog sektora | Ugovorne odredbe, registar podizvođača, testovi otpornosti, SLA-ovi za incidente, plan izlaska, revizijska izvješća, podrška za rizik koncentracije |
| GDPR revizor ili pregled DPO-a | Jesu li rizik povrede osobnih podataka, obveze izvršitelja obrade, povjerljivost, cjelovitost i odgovornost adresirani | Evidencija aktivnosti obrade, uvjeti DPA, tijek procjene povrede, zapisi pristupa, dokazi šifriranja, kontrole zadržavanja i brisanja |
| Procjenitelj usmjeren na NIST | Jesu li sposobnosti identificiranja, zaštite, otkrivanja, odgovora i oporavka implementirane i mjerene | Popis imovine, kontrole pristupa, podaci o ranjivostima, pokrivenost SIEM-a, operativne upute za odgovor, testovi oporavka, metrike |
| COBIT 2019 ili ISACA revizor | Jesu li uspostavljeni ciljevi upravljanja, odgovornosti, vlasništvo nad rizikom, nadzor kontrola i procesi osiguranja | Povelje upravljanja, RACI, apetit za rizik, vlasništvo nad kontrolama, KPI/KRI izvješćivanje, plan osiguranja, praćenje korektivnih radnji |
Tu Zenith Controls pomaže kao vodič za unakrsnu usklađenost. Za kontrole kao što su 5.23, 5.24 i 8.8 povezuje očekivanja kontrola ISO/IEC 27001:2022 s temama NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF i ISO 22301. Cilj nije stvoriti zasebne programe usklađenosti. Cilj je jedna arhitektura dokaza označena prema kontroli, riziku, regulatornom pokretaču i vlasniku.
Clarysec obrazac implementacije
Za pružatelje usluga u oblaku, MSP-ove, MSSP-ove i pružatelje usluga podatkovnih centara rad treba provesti u pet slojeva.
Prvo, potvrdite opseg. Utvrdite jesu li organizacija i usluge u opsegu NIS2, koja se pravila države članice primjenjuju, primjenjuje li se Provedbena uredba 2024/2690 na kategoriju pružatelja i nameću li klijenti obveze prema DORA, GDPR, NIST ili sektorski specifične obveze.
Drugo, izgradite kontekst ISMS-a. Prema točkama 4 i 5 norme ISO/IEC 27001:2022, identificirajte zainteresirane strane, pravne obveze, obveze prema klijentima, ovisnosti o dobavljačima, granice usluga i odgovornosti uprave.
Treće, provedite procjenu rizika i obradu rizika koristeći načela ISO/IEC 27005:2022. Objedinite NIS2, DORA, GDPR, ugovore, interne politike i rizike usluga u jedan registar polaznih zahtjeva. Definirajte kriterije rizika, vlasnike, vjerojatnost, utjecaj, opcije obrade, odabire kontrola i odobrenja preostalog rizika.
Četvrto, mapirajte kontrole u Izjavu o primjenjivosti. Koristite korake 13 i 14 iz Zenith Blueprint za povezivanje rizika s kontrolama iz Annex A i regulatornim očekivanjima. Koristite Zenith Controls kako biste razumjeli kako se kontrole kao što su 5.23, 5.24, 8.8, 5.20 i 5.30 mapiraju kroz okvire i revizijske perspektive.
Peto, operacionalizirajte dokaze. Politike nisu dovoljne. Clarysecova knjižnica politika pruža provedive zahtjeve za odobravanje oblaka, pristup dobavljača, zapisivanje događaja, korektivne radnje za ranjivosti, segmentaciju mreže, klasifikaciju incidenata i planiranje neprekidnosti. Paket dokaza potvrđuje da ti zahtjevi funkcioniraju.
Sljedeći korak: pretvorite pritisak NIS2 u otpornost spremnu za reviziju
Provedbena uredba NIS2 2024/2690 ne zahtijeva kaos. Zahtijeva sljedivost, vlasništvo i dokaz.
Ako ste pružatelj usluga u oblaku, MSP, MSSP ili operator podatkovnog centra, počnite od svojih usluga, klijenata, ovisnosti, scenarija incidenata i obveza dokazivanja. Zatim provedite strukturiranu vježbu mapiranja NIS2 na ISO/IEC 27001:2022:
- Potvrdite jesu li vaš subjekt i usluge u opsegu.
- Mapirajte teme NIS2 i Provedbene uredbe u opseg svojeg ISMS-a.
- Ažurirajte registar rizika i Izjavu o primjenjivosti.
- Primijenite Clarysec politike za korištenje usluga u oblaku, sigurnost dobavljača, zapisivanje događaja, upravljanje ranjivostima, odgovor na incidente, sigurnost mreže i neprekidnost.
- Koristite Zenith Blueprint Zenith Blueprint korake 13, 14, 20 i 23 za stvaranje sljedivosti i operativnih dokaza.
- Koristite Zenith Controls Zenith Controls za unakrsno mapiranje kontrola ISO/IEC 27001:2022 prema očekivanjima NIS2, DORA, GDPR, NIST i COBIT 2019.
- Testirajte dokaze kroz simulaciju revizije prije nego što ih zatraže klijent, regulator ili certifikacijski revizor.
Clarysec vam može pomoći da nadiđete usklađenost prema kontrolnom popisu i izgradite integrirani ISMS koji izdržava pritisak NIS2, DORA, GDPR i revizija klijenata. Preuzmite relevantne Clarysec alate, rezervirajte radionicu mapiranja ili zatražite procjenu spremnosti za reviziju kako biste regulatornu složenost pretvorili u dokazivo upravljanje sigurnošću i operativnu otpornost.
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
