NIS2 2024/2690 ja ISO 27001 kontrollimeetmete vastendus pilveteenuse pakkujatele
Teisipäeval kell 08.17 saab Euroopa hallatud teenuse pakkuja infoturbejuht Maria teavituse, mida kardab iga MSP. Üks privilegeeritud kaughalduse konto on käivitanud võimatu liikumise hoiatused. Kahe kliendi keskkonnas on näha ebatavalisi haldustoiminguid. SOC on juba avanud kriitilise intsidendi kriisikoosoleku.
Kell 09.00 liitub kõnega tegevjuht. Küsimused muutuvad kohe.
Kas kuulume NIS2 kohaldamisalasse? Kas komisjoni rakendusmäärus (EL) 2024/2690 kohaldub meile? Kas vajame 24-tunnist varajast hoiatust? Milliseid kliente tuleb teavitada? Kas suudame tõendada, et MFA, logimine, segmenteerimine, haavatavuste haldus, tarnijate kontrollimeetmed ja intsidendi eskaleerimine toimisid juba enne intsidenti?
Maria ettevõttel on ISO/IEC 27001:2022 sertifikaat. Ettevõte osutab pilvehalduse, andmekeskuse ja hallatud turbeteenuseid klientidele, kelle hulka kuuluvad logistikateenuse pakkuja ja piirkondlik pank. Sertifikaat on oluline, kuid ei vasta iseenesest operatiivsetele küsimustele. Õigusmeeskonnal on teavitusprotsessi kavand. Vastavusjuhil on tabel. Audiitor on küsinud kohaldatavusdeklaratsiooni, intsidentidele reageerimise testimise tõendeid, privilegeeritud juurdepääsu logisid, tarnijate taustakontrolli tõendeid, pilve jagatud vastutuse tõendusmaterjali ja talitluspidevuse eeldusi.
See on hetk, mil NIS2 lakkab olemast õigustekst ja muutub operatiivsete kontrollimeetmete probleemiks.
Pilveteenuse pakkujate, hallatud teenuse pakkujate, hallatud turbeteenuse pakkujate ja andmekeskuse teenusepakkujate jaoks tõstavad NIS2 ja rakendusmäärus 2024/2690 lati üldisest turbeeesmärgist kontrollitava tõendusmaterjalini. Juhtimine, riskijuhtimine, juurdepääsukontroll, varahaldus, haavatavuste käsitlemine, intsidentidele reageerimine, tarnijate turve, logimine, seire, krüpteerimine, talitluspidevus ja füüsiline vastupidavus peavad toimima ühe süsteemina.
ISO/IEC 27001:2022 on selle süsteemi jaoks parim selgroog, kuid ainult juhul, kui organisatsioon vastendab NIS2 nõuded ISMS-i, riskiregistri, kohaldatavusdeklaratsiooni, poliitikate ja tõendusmudeliga. Seinal olevast sertifikaadist ei piisa. Tegelik töö seisneb auditikõlbliku seose loomises regulatsioonist riskini, riskist kontrollimeetmeni, kontrollimeetmest poliitikani ja poliitikast toimiva tõendusmaterjalini.
Miks NIS2 2024/2690 muudab pilve- ja MSP-teenusepakkujate vastavusarutelu
NIS2 kasutab sektori- ja suuruspõhist mudelit, kuid selle digitaalse taristu ja IKT-teenuste halduse kategooriad on teadlikult laiad. NIS2 Article 2 ja Article 3 alusel, koostoimes Annex I ja Annex II-ga, võib paljusid organisatsioone liigitada olulisteks või tähtsateks üksusteks, sealhulgas pilveteenuse pakkujad, andmekeskuse teenusepakkujad, hallatud teenuse pakkujad, hallatud turbeteenuse pakkujad, DNS-teenuse pakkujad, TLD registripidajad, sisuedastusvõrgud ja usaldusteenuse pakkujad. Liikmesriigid peavad koostama ja perioodiliselt läbi vaatama oluliste ja tähtsate üksuste loendid; esimese loendi tähtaeg on 17. aprill 2025.
See on oluline, sest pilve-, MSP-, MSSP- ja andmekeskuse teenusepakkujad asuvad teiste organisatsioonide riskiahelates. Pilve juhtimistasandi kompromiteerimine võib mõjutada tuhandeid kliendisüsteeme. Andmekeskuse katkestus võib kanduda pangandusse, tervishoidu, logistikasse ja avalikku haldusse. MSP autentimisandmete rikkumine võib muutuda mitut klienti hõlmavaks lunavaraintsidendiks. MSSP tuvastustõrge võib reguleeritud klientide puhul ohjeldamist edasi lükata.
NIS2 Article 20 nõuab, et juhtorganid kiidaksid heaks küberturvalisuse riskijuhtimismeetmed ja teostaksid rakendamise üle järelevalvet. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, mis põhinevad kõiki ohte hõlmaval lähenemisel. Baastase hõlmab riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist ja arendust, haavatavuste käsitlemist ja avalikustamist, tõhususe hindamist, küberhügieeni, koolitust, krüptograafiat, personaliturvet, juurdepääsukontrolli, varahaldust, MFA-d või pidevat autentimist, turvalist sidet ja hädaolukorra sidet.
Article 23 lisab olulistest intsidentidest etapiviisilise teavitamise, sealhulgas varajase hoiatuse 24 tunni jooksul, intsidenditeavituse 72 tunni jooksul, vahearuanded nõudmise korral ja lõpparuande ühe kuu jooksul pärast teavitust või pärast intsidendi käsitlemist, kui intsident on jätkuv.
Rakendusmäärus 2024/2690 muudab need ootused asjakohaste digiteenuse pakkujate jaoks konkreetsemaks. Praktikas ei küsi ametiasutused, kliendid ja audiitorid üksnes seda, kas poliitikad on olemas. Nad küsivad, kas kontrollimeetmed on vastendatud, omanikele määratud, testitud ja tõendatud.
ISO/IEC 27001:2022 muudab NIS2 ISMS-i toimimiskontekstiks
Levinud NIS2 valmisoleku viga on alustada suure kontrollnimekirjaga ja jagada ülesanded IT, õigusvaldkonna, SOC-i, taristu, tarnijahaldus- ja vastavusfunktsiooni vahel. See võib tekitada tegevust, kuid sageli ebaõnnestub auditis, sest keegi ei suuda näidata, miks kontrollimeetmed valiti, kuidas need riskiga seonduvad, kes jääkriski aktsepteeris ja milline tõendusmaterjal tõendab tõhusust.
ISO/IEC 27001:2022 annab teenusepakkujatele struktuuri selle ebaõnnestumise vältimiseks.
Punktid 4.1 kuni 4.4 nõuavad, et organisatsioon määraks kindlaks sisemised ja välised tegurid, tuvastaks huvitatud osapooled ja nende nõuded, otsustaks, milliseid nõudeid käsitletakse ISMS-i kaudu, ning määratleks ISMS-i kohaldamisala, sealhulgas liidesed ja sõltuvused. Pilve- või MSP-teenusepakkuja puhul peab kohaldamisala selgesõnaliselt arvestama NIS2, rakendusmäärust 2024/2690, klientide turbelisasid, DORA-st tulenevaid kliendinõudeid, pilvepiirkondi, alltöövõtjaid, andmekeskuse sõltuvusi, kaughaldusplatvorme, privilegeeritud juurdepääsu teekondi ja intsidentidest teavitamise kohustusi.
Punktid 5.1 kuni 5.3 nõuavad juhtimist, poliitikaga kooskõla, ressursse, teabevahetust, määratud vastutusi ja juhtkonna aruandekohustust. See toetab otseselt NIS2 Article 20 nõudeid.
Punktid 6.1.1 kuni 6.1.3 nõuavad riskihindamist, riskikäsitlust, riskiomanikke, tõenäosuse ja tagajärgede analüüsi, kontrollimeetmete valikut, võrdlust Annex A-ga, kohaldatavusdeklaratsiooni, riski käsitlemise plaani ja ametlikku jääkriski aktsepteerimist. Siin muutub NIS2 operatiivseks. Iga regulatiivne nõue muutub riskiteguriks, vastavuskohustuseks, kontrollinõudeks või tõendusnõudeks.
Clarysec alustab seda tööd lahendusega Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, eriti riskijuhtimise etapis.
Alates sammust 13, riski käsitlemise planeerimine ja kohaldatavusdeklaratsioon, juhendab Zenith Blueprint meeskondi looma jälgitavust riskide, kontrollimeetmete ja regulatiivsete ajendite vahel:
„Regulatsioonide ristviitamine: kui teatud kontrollimeetmed rakendatakse spetsiaalselt GDPR, NIS2 või DORA nõuete täitmiseks, võib selle märkida kas riskiregistrisse või SoA märkustesse. Nt kontrollimeede 8.27 (andmete turvaline kustutamine) võib olla väga asjakohane GDPR-i isikuandmete kõrvaldamise nõude jaoks; võite märkida „Kohaldatav – toetab GDPR Art.32 (töötlemise turvalisus)“. ISO seda ei nõua, kuid see aitab näidata, et olete neid raamistikke arvesse võtnud.“
Samm 14, riski käsitlemise poliitikad ja regulatiivsed ristviited, lisab praktilise vastendamise distsipliini:
„Iga regulatsiooni kohta, kui see on kohaldatav, võite luua lihtsa vastendustabeli, mis loetleb regulatsiooni peamised turbenõuded ja vastavad kontrollimeetmed/poliitikad teie ISMS-is. ISO 27001 järgi ei ole see kohustuslik, kuid see on kasulik sisemine harjutus veendumaks, et midagi ei jäänud kahe silma vahele.“
See on erinevus väite „meil on ISO sertifikaat“ ja tõenduse „meie ISO/IEC 27001:2022 ISMS käsitleb NIS2 rakendusmäärust 2024/2690“ vahel.
Ühtne NIS2 ja ISO/IEC 27001:2022 kontrollimeetmete vastendus
Järgmine vastendus ei ole õigusnõuanne ega asenda riigisisese ülevõtmise analüüsi. See on praktiline kontrolliarhitektuur teenusepakkujatele, kes vajavad auditikõlblikku ISO/IEC 27001:2022 teed NIS2 valmisolekuni.
| NIS2 ja rakendusmääruse teema | ISO/IEC 27001:2022 ISMS-i mehhanism | Peamised Annex A kontrollivaldkonnad | Clarysec rakendamise tõendusmaterjal |
|---|---|---|---|
| Juhtimine ja juhtkonna vastutus | Punktid 4, 5, 6 ja 9 määratlevad konteksti, juhtimise, riskide planeerimise ja toimivuse ülevaatuse | 5.1 infoturbepoliitikad, 5.2 infoturbe rollid ja vastutused, 5.31 õiguslikud, seadusest tulenevad, regulatiivsed ja lepingulised nõuded | ISMS-i kohaldamisala, huvitatud osapoolte register, juhatuse heakskiit, riskiregister, SoA, juhtkonnapoolse ülevaatuse protokollid |
| Pilveteenuste juhtimine | Riskihindamine, tarnijate taustakontroll, jagatud vastutus ja kontrollimeetmete valik | 5.23 infoturve pilveteenuste kasutamisel, 5.19 infoturve tarnijasuhetes, 5.22 tarnijateenuste seire, ülevaatus ja muudatuste haldus | Pilveteenuste register, teenuseosutaja riskihindamine, jagatud vastutuse maatriks, lepinguklauslid, pilvelogimise tõendusmaterjal |
| MSP ja MSSP privilegeeritud juurdepääs | Riskikäsitlus kliendikeskkondade, haldusplatvormide ja tugivahendite jaoks | 5.15 juurdepääsukontroll, 5.16 identiteedihaldus, 5.18 juurdepääsuõigused, 8.2 privilegeeritud juurdepääsuõigused, 8.5 turvaline autentimine | PAM-i kirjed, MFA aruanded, kaugjuurdepääsu logid, bastion- või nullusalduse lüüsi konfiguratsioon, juurdepääsuõiguste ülevaatused |
| Andmekeskuse vastupidavus | Ärimõju analüüs, talitluspidevuse planeerimine ja sõltuvuste haldus | 5.30 IKT-valmidus talitluspidevuseks, 7.1 füüsilise turbe perimeetrid, 7.2 füüsiline sissepääs, 8.13 teabe varundamine, 8.14 liiasus | BIA, RTO ja RPO kirjed, DR testiaruanne, füüsilise juurdepääsu logid, elektri- ja jahutussüsteemide testitõendid |
| Intsidenditeavitus ja eskaleerimine | Intsidendiprotsess, mis on seotud õiguslike, lepinguliste ja klienditeavituse käivitajatega | 5.24 infoturbeintsidentide haldamise planeerimine ja ettevalmistus, 5.25 infoturbesündmuste hindamine ja otsustamine, 5.26 infoturbeintsidentidele reageerimine, 5.27 infoturbeintsidentidest õppimine | 24-tunnise varajase hoiatuse tööjuhis, 72-tunnine teavitustöövoog, intsidentide register, intsidendijärgne ülevaatus |
| Haavatavuste käsitlemine ja avalikustamine | Riskipõhine haavatavuste käsitlus, erandite käsitlemine ja tõhususe hindamine | 8.8 tehniliste haavatavuste haldus, 8.9 konfiguratsioonihaldus, 8.32 muudatuste juhtimine, 8.16 seiretegevused | Skannimistulemused, parandusmeetmete SLA-d, erandite heakskiidud, paikamisaruanded, ohuteabe sisendid |
| Tarneahela turve | Huvitatud osapoolte nõuded ja tarnijarisk integreerituna ISMS-i | 5.19 infoturve tarnijasuhetes, 5.20 infoturbe käsitlemine tarnijalepingutes, 5.21 infoturbe haldamine IKT-tarneahelas, 5.22 tarnijateenuste seire, ülevaatus ja muudatuste haldus | Tarnijate tasemestamine, taustakontrolli küsimustikud, lepinguklauslid, auditeerimisõigused, alltöövõtjate register, väljumisplaanid |
| Logimine, seire ja uurimine | Tuvastus, tõendusmaterjal, ajakorreleerimine ja intsidenditugi | 8.15 logimine, 8.16 seiretegevused, 8.17 kella sünkroniseerimine, 5.25 infoturbesündmuste hindamine ja otsustamine | SIEM-i katvuse kaart, logide säilitamise tõendid, hoiatuste häälestamise kirjed, kella sünkroniseerimise kirjed, intsidendi korrelatsiooni tõendusmaterjal |
| Võrgu ja kliendikeskkondade isoleerimine | Turvaline arhitektuur, segmenteerimine ja piiratud haldusrajad | 8.20 võrguturve, 8.22 võrkude eraldamine, 8.23 veebifiltreerimine, 8.24 krüptograafia kasutamine | Võrguskeemid, tulemüürireeglid, pilve turbegrupid, VPC või alamvõrgu reeglid, segmenteerimise testitulemused |
See vastendus muutub mõjusaks, kui see lõimitakse riskiregistrisse ja kohaldatavusdeklaratsiooni. Näiteks võib teenusepakkuja luua riskistsenaariumi „kaughaldusplatvormi kompromiteerimine põhjustab kliendikeskkondades loata toiminguid“. Kontrollimeetmed hõlmavad MFA-d, privilegeeritud juurdepääsu haldust, segmenteerimist, logimist, haavatavuste haldust, tarnijate turvet, intsidendiplaanimist ja klientide teavitamise protseduure. SoA märkustes saab viidata NIS2 Article 21-le, Article 23-le, rakendusmäärusele 2024/2690, kliendilepingutele ja asjakohasel juhul DORA kliendi taustakontrolli nõuetele.
Pilve juhtimine: ISO kontrollimeede 5.23 on NIS2 tugipunkt
Pilveteenuse pakkujate ja MSP-de jaoks, kes kasutavad klientidele teenuste osutamiseks pilveteenuseid, on ISO/IEC 27001:2022 Annex A kontrollimeede 5.23, infoturve pilveteenuste kasutamisel, üks olulisemaid tugipunkte.
Zenith Controls: The Cross-Compliance Guide Zenith Controls võtab kontrollimeetme 5.23 kokku ennetava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust ning on seotud tarnijasuhete turbe, juhtimise, ökosüsteemiriski ja kaitsega. See hõlmab pilveteenuste juhtimist, jagatud vastutust, teenuseosutaja hindamist, registreid, andmete asukohta, logimist, krüpteerimist, identiteedirolle, seiret, lepinguklausleid, tarnijariski, pilveteenusest väljumist ja vastupidavuse planeerimist.
Zenith Blueprint, kontrollimeetmete praktilise rakendamise etapp, samm 23, selgitab praktilist põhjust:
„Pilv ei ole enam sihtkoht, see on vaikimisi valik. Kontrollimeede 5.23 tunnistab seda tegelikkust ja nõuab, et infoturvet käsitletaks pilveteenuste valikul, kasutamisel ja haldamisel selgesõnaliselt – mitte järelmõttena, vaid disainipõhimõttena algusest peale.“
MSP puhul tuleb hallata iga kaugseire ja -halduse platvormi, kliendiportaali, piletihaldusvahendit, turbe telemeetria platvormi, varundusteenust, pilve kataloogiteenust ja SaaS-i halduskonsooli. Andmekeskuse teenusepakkuja puhul võib pilve juhtimine kohalduda seireplatvormidele, külastajahaldussüsteemidele, füüsilise juurdepääsukontrolli integratsioonidele, kaughaldussüsteemidele ja kliendiportaali taristule.
Clarysec ettevõtte Cloud Usage Policy Cloud Usage Policy muudab aktiveerimiseelse taustakontrolli kohustuslikuks:
„Kogu pilveteenuste kasutus peab enne aktiveerimist läbima riskipõhise taustakontrolli, sealhulgas teenuseosutaja hindamise, õigusliku vastavuse valideerimise ja kontrollimeetmete valideerimise ülevaatused.“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.2.
Väiksemate teenusepakkujate jaoks loob Cloud Usage Policy-sme Cloud Usage Policy-sme - SME lihtsustatud heakskiidumudeli:
„Pilveteenuste kogu kasutus tuleb enne rakendamist või tellimist tegevjuhi (GM) poolt läbi vaadata ja heaks kiita.“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.1.
Mõlemad lähenemised toetavad sama NIS2 ootust: pilvesõltuvuse risk peab olema mõistetud enne, kui teenus muutub tarneahela osaks.
Intsidentidele reageerimine: 24-tunnine kell käivitub enne aruande koostamist
NIS2 Article 23 on nõudlik, sest teavitustähtaeg hakkab jooksma olulise intsidendi teadvustamisest, mitte hetkest, mil täiuslik algpõhjuse analüüs on olemas. Teenusepakkujate väljakutse on kiiresti otsustada, kas sündmus on oluline, millised kliendid on mõjutatud, kas kaasatud on isikuandmed, kas esineb piiriülene mõju teenusele ja millised lepingulised tähtajad on käivitunud.
ISO/IEC 27001:2022 Annex A kontrollimeede 5.24, infoturbeintsidentide haldamise planeerimine ja ettevalmistus, on planeerimise kontrollimeede. Zenith Controls võtab selle kokku korrigeeriva kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust ning on seotud reageerimise ja taastamise kontseptsioonide, juhtimise, sündmusehalduse ja kaitsega. See hõlmab rolle, vastutusi, eskaleerimisteid, suhtlusprotokolle, regulatiivse teavitamise valmisolekut, kooskõla logimise ja seirega, integratsiooni talitluspidevuse ja katastroofitaastega, intsidendijärgset õppimist ning vastendust NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 ja COBIT 2019-ga.
Clarysec Incident Response Policy-sme Incident Response Policy-sme - SME muudab esimese otsuse ajaliselt piiratud nõudeks:
„Tegevjuht peab IT-teenuseosutaja sisendi alusel klassifitseerima kõik intsidendid tõsiduse järgi ühe tunni jooksul alates teavitusest.“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.3.1.
See ühe tunni klassifitseerimine toetab operatiivset distsipliini, mida on vaja NIS2 24-tunnise varajase hoiatuse analüüsiks, GDPR-i isikuandmetega seotud rikkumise hindamiseks, DORA kliendi eskaleerimiseks ja lepinguliste teavituste triaažiks.
Teenusepakkuja intsidendi otsustuspuu peab vastama neljale küsimusele:
- Kas konfidentsiaalsuse, tervikluse või käideldavuse kompromiteerimine on kinnitatud või kahtlustatav?
- Kas sündmus mõjutab teenuse osutamist, kliendikeskkondi, reguleeritud kliente, isikuandmeid või kriitilisi funktsioone?
- Kas see võib põhjustada tõsise tegevushäire, finantskahju või varalise või mittevaralise kahju?
- Millised teavitamiskohustused kohalduvad: NIS2, GDPR, DORA kliendikohustused, lepingulised SLA-d või riikliku regulaatori ootused?
Otsustuspuud tuleb testida lauaõppustel enne tegelikku intsidenti.
Haavatavuste haldus: tõendage riski vähendamist enne mõju avaldumist
NIS2 nõuab haavatavuste käsitlemist ja avalikustamist. Klientide ja regulaatorite jaoks on haavatavuste haldus üks lihtsamini mõõdetavaid kontrollivaldkondi, sest see tekitab selge tõendusmaterjali: skannimise katvus, paikamise tähtajad, erandite heakskiidud, ärakasutatud haavatavuste analüüs ja parandusmeetmete kirjed.
ISO/IEC 27001:2022 Annex A kontrollimeede 8.8, tehniliste haavatavuste haldus, on Zenith Controls käsitluses ennetav kontrollimeede konfidentsiaalsuse, tervikluse ja käideldavuse lõikes ning seotud tuvastamise ja kaitsmise, ohtude ja haavatavuste halduse, juhtimise, ökosüsteemi, kaitse ja tõrjega. See hõlmab haavatavuste tuvastamist, hindamist, prioritiseerimist, paikamist, kompenseerivaid kontrollimeetmeid, ohuteabe integreerimist, haavatavuste avalikustamist, pilve- ja rakendushaavatavuste vastutusi, auditi tõendusmaterjali ja parandusmeetmete tähtaegu.
Clarysec ettevõtte Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy annab audiitoritele testimiseks konkreetse mudeli:
„Organisatsioon peab kõik tuvastatud haavatavused klassifitseerima standardiseeritud metoodika alusel (nt CVSS v3.x) ja rakendama parandusmeetmete tähtaegu kooskõlas ärikriitilisusega: 5.2.1 Kriitiline (CVSS 9.0-10.0): viivitamatu läbivaatamine; paikamise tähtaeg maksimaalselt 72 tundi. 5.2.2 Kõrge (7.0-8.9): reageerimine 48 tunni jooksul; paikamise tähtaeg 7 kalendripäeva. 5.2.3 Keskmine (4.0-6.9): reageerimine 5 päeva jooksul; paikamise tähtaeg 30 kalendripäeva. 5.2.4 Madal (<4.0): reageerimine 10 päeva jooksul; paikamise tähtaeg 60 kalendripäeva.“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.2.
Pilveteenuse pakkuja puhul peab see hõlmama hüperviisori komponente, konteinerikujutisi, orkestreerimiskihte, kliendile suunatud rakendusliideseid, CI/CD torustikke, halduskonsoole ja kolmanda osapoole teeke. MSP puhul on põhiküsimus, kas sisemised haavatavused on eraldatud kliendi hallatavatest haavatavustest ja kas lepingud määratlevad vastutuse. Andmekeskuse teenusepakkuja puhul võib kohaldamisala hõlmata hoonehaldussüsteeme, juurdepääsukontrolli süsteeme, seireplatvorme, remote hands töövahendeid ja võrgutaristut.
Jagatud vastutuse mudel peab olema dokumenteeritud. Teenusepakkuja ei pruugi omada iga paika, kuid peab siiski riski haldama, vajaduse korral klienti teavitama ja tõendama, et vastutuse piirid on mõistetud.
Logimine, seire ja segmenteerimine muudavad intsidendid uuritavaks
Kui teenusepakkuja intsident muutub kliendimõjuga intsidendiks, on esimesed tõendusküsimused lihtsad: kes logis sisse, kust, milliste õigustega, millisesse kliendikeskkonda, mida muudeti, millised logid on olemas ja kas haldusrajad olid segmenteeritud.
Clarysec ettevõtte Logging and Monitoring Policy Logging and Monitoring Policy nõuab, et hõlmatud süsteemid genereeriksid logid, mida reageerijad ja audiitorid vajavad:
„Kõik hõlmatud süsteemid peavad genereerima logid, mis salvestavad: 6.1.1.1 kasutaja autentimise ja juurdepääsukatsed 6.1.1.2 privilegeeritud kasutajate tegevused 6.1.1.3 konfiguratsioonimuudatused 6.1.1.4 ebaõnnestunud juurdepääsukatsed või süsteemisündmused 6.1.1.5 pahavara tuvastused ja turbehoiatused 6.1.1.6 välissuhtluse ja tulemüürireeglite käivitused“
Jaotisest „Poliitika rakendamise nõuded“, poliitikaklausel 6.1.1.
Välistest teenuseosutajatest sõltuvate VKE-de jaoks lisab Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME lepingulise nõude:
„Lepingud peavad nõudma, et teenuseosutajad säilitaksid logisid vähemalt 12 kuud ja annaksid juurdepääsu nõudmisel.“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.5.1.3.
Segmenteerimine on sama oluline. Network Security Policy-sme Network Security Policy-sme - SME sätestab:
„Sisemised võrgud tuleb segmenteerida funktsiooni järgi (nt finants, külalisvõrk, IoT, haldussüsteemid).“
Jaotisest „Poliitika rakendamise nõuded“, poliitikaklausel 6.2.1.
Zenith Blueprint, kontrollimeetmete praktilise rakendamise etapp, samm 20, annab praktilise auditiprotseduuri võrguarhitektuuri ja segmenteerimise jaoks. See juhendab meeskondi võrgu ülesehitust üle vaatama ja dokumenteerima, kontrollima tulemüürireegleid, IPS/IDS-i ja kaugjuurdepääsu konfiguratsioone, kinnitama, et pilve turbegrupid ja VPC või alamvõrgu reeglid vastavad kavandatud arhitektuurile, loetlema sisemised ja välised võrguteenused ning valideerima, et tundlikud süsteemid ei ole üldkasutajate VLAN-idest ega külalisvõrkudest kättesaadavad.
MSP puhul ei tohi kaughaldusvahendid paikneda lamedalt kontorivõrgus. Andmekeskuse teenusepakkuja puhul peavad elektri, jahutuse, juurdepääsukontrolli ja kliendi võrguteenuste haldusliidesed olema isoleeritud ja jälgitud. Pilveteenuse pakkuja puhul tuleb juhtimistasandi juurdepääs piirata identiteedi, võrgu, seadme turvaseisundi ja privilegeeritud töövoo kontrollimeetmete kaudu.
Tarnijate turve: teenusepakkuja on ka klient
Pilve-, MSP-, MSSP- ja andmekeskuse teenusepakkujad on reguleeritud klientidele tarnijad, kuid nad on ka tarkvaratarnijate, sideoperaatorite, identiteedipakkujate, SaaS-platvormide, riistvaratarnijate, alltöövõtjate ja taristuoperaatorite kliendid.
NIS2 muudab tarneahela turbe põhinõudeks. DORA, mida kohaldatakse alates 17. jaanuarist 2025, muudab IKT kolmanda osapoole riskijuhtimise finantsüksuste jaoks keskseks. NIS2 Article 4 ja Recital 28 tunnustavad DORA-t kui finantsüksuste sektoripõhist liidu õigusakti kattuvate nõuete korral. See ei vähenda survet pilve- ja MSP-teenusepakkujatele. See suurendab seda, sest finantssektori kliendid toovad tarnijalepingutesse DORA tasemel lepingulised nõuded, auditeerimisõigused, vastupidavuse testimise, väljumisstrateegiad ja intsidentidest teavitamise ootused.
Clarysec ettevõtte Third party and supplier security policy Third party and supplier security policy nõuab kontrollitud kolmandate isikute juurdepääsu:
„Kogu kolmandate isikute juurdepääs tuleb logida ja jälgida ning võimaluse korral segmenteerida bastion-hostide, VPN-ide või nullusalduse lüüside kaudu.“
Jaotisest „Poliitika rakendamise nõuded“, poliitikaklausel 6.3.2.
Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME väljendab vähima privileegi põhimõtet otseselt:
„Tarnijatele tuleb anda juurdepääs ainult nende funktsiooni täitmiseks minimaalselt vajalikele süsteemidele ja andmetele.“
Jaotisest „Poliitika rakendamise nõuded“, poliitikaklausel 6.2.1.
Need klauslid vastenduvad loomulikult ISO/IEC 27001:2022 Annex A kontrollimeetmetega 5.19, 5.20, 5.21 ja 5.22. Need toetavad ka GDPR-i volitatud töötleja ja alltöötleja juhtimist, DORA kolmandate osapoolte riskide ülevaatusi ning kliendi auditiküsimustikke.
Talitluspidevus ja andmekeskuse vastupidavus: tõendage eeldused
NIS2 Article 21 hõlmab talitluspidevust, varundushaldust, katastroofitaastet ja kriisijuhtimist. DORA Articles 11 kuni 14 nõuavad finantsüksustelt IKT talitluspidevuse poliitikaid, reageerimis- ja taastamisplaane, ärimõju analüüsi, varunduspoliitikaid, taastamisprotseduure, taaste-eesmärke, testimist, intsidendijärgseid ülevaatusi ja kriisikommunikatsiooni.
Pilve- ja andmekeskuse teenusepakkujate jaoks ei ole talitluspidevus kaust dokumentidega. See on arhitektuur, võimekus, lepingud, sõltuvused, taastamise tõendusmaterjal ja testitud eeldused.
Clarysec ettevõtte Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy nõuab iga-aastast BIA-d ja ülevaatust pärast olulisi muudatusi:
„Kõigi kriitiliste äriüksuste puhul tuleb ärimõju analüüs (BIA) teha vähemalt kord aastas ning see tuleb üle vaadata süsteemide, protsesside või sõltuvuste oluliste muudatuste korral. BIA väljundid peavad määratlema: 5.2.1. maksimaalne talutav katkestuse kestus (MTD) 5.2.2. taasteaja eesmärgid (RTO-d) 5.2.3. taastepunkti eesmärgid (RPO-d) 5.2.4. kriitilised sõltuvused (süsteemid, tarnijad, personal)“
Jaotisest „Juhtimisnõuded“, poliitikaklausel 5.2.
Andmekeskuse stsenaariumis peab BIA hõlmama elektritoite sisendeid, UPS-e, generaatoreid, kütuselepinguid, jahutust, tulekustutust, võrguoperaatoreid, füüsilise juurdepääsu süsteeme, remote hands teenuseid, seiret, varuriistvara ja kliendisuhtluse kanaleid. Pilvestsenaariumis peab see hõlmama piirkondi, käideldavustsoone, replikatsiooni, varukoopiate muutmatust, identiteedisõltuvusi, DNS-i, sertifitseerimiskeskusi, API-lüüse ja tugisüsteeme. MSP stsenaariumis peab see hõlmama kaughaldusvahendeid, privilegeeritud juurdepääsu hoidlaid, EDR konsoole, piletihaldust, dokumentide hoidlaid ja hädaolukorra sidet.
ISO 22301 võib tugevdada talitluspidevuse juhtimise distsipliini, samas kui ISO/IEC 27005:2022 toetab riskikriteeriume, käsitlusplaanimist, seiret, tõendusmaterjali ja pidevat täiustamist. See on kasulik, sest NIS2 valmisolek nõuab organisatsioonilt õiguslike, lepinguliste, operatiivsete, tarnija-, tehnoloogia-, finants-, protsessi- ja inimtegurite koondamist ühte riskiprotsessi.
Praktiline riskijälg MSP kaugjuurdepääsu rikkumise korral
Praktiline töötuba võib alata ühe stsenaariumiga:
„Privilegeeritud kaugjuurdepääsu kompromiteerimine põhjustab loata juurdepääsu kliendisüsteemidele, teenusekatkestuse, võimaliku isikuandmete avalikustumise ja regulatiivsed teavitamiskohustused.“
Looge riskiregistri rida ja täitke jälg.
| Väli | Näidiskanne |
|---|---|
| Riskiomanik | Hallatud teenuste juht |
| Varad ja protsessid | Kaughaldusplatvorm, kliendi halduskontod, privilegeeritud hoidla, piletihaldus, SIEM, kliendikeskkonnad |
| Ohusündmus | Autentimisandmete vargus, MFA väsitusrünne, tokenivargus, ärakasutatud RMM-i haavatavus, pahatahtlik sisekasutaja |
| Mõju | Kliendi kompromiteerimine, teenusekatkestus, lepingurikkumine, NIS2 oluline intsident, GDPR-i isikuandmetega seotud rikkumine, DORA kliendi eskaleerimine |
| Olemasolevad kontrollimeetmed | MFA, PAM, vähima privileegi põhimõte, segmenteerimine, logimine, haavatavuse skannimine, intsidentidele reageerimise plaan |
| Nõutav käsitlus | Tingimusliku juurdepääsu karmistamine, õigeaegsete administraatoriõiguste rakendamine, kliendikeskkondade isoleerimise parandamine, logide säilitamise pikendamine, teavituse tööjuhise testimine |
| ISO/IEC 27001:2022 tõendusmaterjal | Riskihindamine, SoA, juurdepääsuõiguste ülevaatus, logide näidised, haavatavuste aruanded, lauaõppus, juhtkonnapoolne ülevaatus |
| NIS2 vastendus | Article 21 riskijuhtimine ja Article 23 intsidentidest teavitamine, lisaks rakendusmääruse operatiivmeetmed |
| Kliendi vastendus | Lepinguline teavitus, auditeerimisõigused, turbelisa, DORA-ga kooskõlastatud küsimustikud, kui kohaldatav |
| Jääkriski otsus | Riskiomanik aktsepteerib pärast käsitlemist, vaadatakse üle kord kvartalis |
Seejärel ajakohastage kohaldatavusdeklaratsiooni. Iga asjakohase Annex A kontrollimeetme puhul selgitage, miks see kohaldub ja millist NIS2 teemat see toetab. Lõpuks koguge tõendusmaterjal enne auditit: MFA rakendamise aruanded, privilegeeritud kontode loendid, logide säilitamise seaded, RMM-i paikamisstaatus, SIEM-i hoiatused, intsidendi klassifitseerimise kirjed, tarnijate juurdepääsu heakskiidud ja lauaõppuse tulemused.
Kuidas erinevad audiitorid testivad sama kontrollikeskkonda
Integreeritud ISMS peab rahuldama erinevaid kindlusvaateid, loomata iga raamistiku jaoks eraldi tõenduspakette.
| Audiitori vaade | Millele keskendutakse | Tavaliselt küsitav tõendusmaterjal |
|---|---|---|
| ISO/IEC 27001:2022 audiitor | Kas NIS2, DORA ja GDPR nõuded kajastuvad kontekstis, kohaldamisalas, riskihindamises, SoA-s, siseauditis ja juhtkonnapoolses ülevaatuses | ISMS-i kohaldamisala, huvitatud osapoolte register, riskimetoodika, riskiregister, SoA, käsitlusplaan, poliitikad, siseauditi aruanne, juhtkonnapoolne ülevaatus |
| NIS2 pädev asutus või volitatud hindaja | Kas küberturvalisuse riskijuhtimismeetmed on asjakohased ja proportsionaalsed ning kas olulistest intsidentidest teavitamine toimib operatiivselt | NIS2 vastendus, intsidendi klassifitseerimise protseduur, 24- ja 72-tunnine töövoog, juhatuse järelevalve, tehniliste kontrollimeetmete tõendusmaterjal, tarnijate turbe tõendusmaterjal |
| DORA kliendihindaja | Kas IKT kolmanda osapoole risk, vastupidavuse testimine, intsidentidest teavitamine, auditeerimisõigused ja väljumisplaanimine vastavad finantssektori ootustele | Lepinguklauslid, alltöövõtjate register, vastupidavustestid, intsidendi SLA-d, väljumisplaan, auditiaruanded, kontsentratsiooniriski tugi |
| GDPR audiitor või DPO ülevaatus | Kas isikuandmetega seotud rikkumise risk, volitatud töötleja kohustused, konfidentsiaalsus, terviklus ja vastutuse tõendatavus on käsitletud | Töötlemistoimingute register, DPA tingimused, rikkumise hindamise töövoog, juurdepääsulogid, krüpteerimise tõendusmaterjal, säilitamise ja kustutamise kontrollimeetmed |
| NIST-põhine hindaja | Kas tuvastamise, kaitsmise, avastamise, reageerimise ja taastamise võimekused on rakendatud ja mõõdetud | Varade register, juurdepääsukontrollid, haavatavuste andmed, SIEM-i katvus, reageerimise tööjuhised, taastamistestid, mõõdikud |
| COBIT 2019 või ISACA audiitor | Kas juhtimise eesmärgid, vastutused, riskivastutus, kontrollimeetmete seire ja kindlust andvad protsessid on kehtestatud | Juhtimishartad, RACI, riskivalmidus, kontrollimeetmete omamine, KPI/KRI aruandlus, kindlust andvate tegevuste plaan, parandusmeetmete jälgimine |
Siin aitab Zenith Controls ristvastavuse juhendina. Selliste kontrollimeetmete puhul nagu 5.23, 5.24 ja 8.8 seob see ISO/IEC 27001:2022 kontrolliootused NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF ja ISO 22301 teemadega. Eesmärk ei ole luua eraldi vastavusprogramme. Eesmärk on üks tõendusarhitektuur, mis on märgendatud kontrollimeetme, riski, regulatiivse ajendi ja omaniku järgi.
Clarysec rakendusmuster
Pilve-, MSP-, MSSP- ja andmekeskuse teenusepakkujate jaoks peaks töö liikuma viies kihis.
Esiteks kinnitage kohaldamisala. Tehke kindlaks, kas organisatsioon ja teenused kuuluvad NIS2 kohaldamisalasse, millised liikmesriigi reeglid kohalduvad, kas rakendusmäärus 2024/2690 kohaldub teenusepakkuja kategooriale ning kas kliendid seavad DORA, GDPR, NIST või sektoripõhiseid kohustusi.
Teiseks looge ISMS-i kontekst. ISO/IEC 27001:2022 punktide 4 ja 5 alusel tuvastage huvitatud osapooled, õiguslikud kohustused, kliendikohustused, tarnijasõltuvused, teenusepiirid ja juhtkonna vastutused.
Kolmandaks viige läbi riskihindamine ja riskikäsitlus, kasutades ISO/IEC 27005:2022 põhimõtteid. Koondage NIS2, DORA, GDPR, lepingud, sisepoliitikad ja teenuseriskid ühte baastaseme nõuete registrisse. Määratlege riskikriteeriumid, omanikud, tõenäosus, mõju, käsitlusvõimalused, kontrollivalikud ja jääkriski heakskiidud.
Neljandaks vastendage kontrollimeetmed kohaldatavusdeklaratsiooniga. Kasutage Zenith Blueprint samme 13 ja 14, et siduda riskid Annex A kontrollimeetmete ja regulatiivsete ootustega. Kasutage Zenith Controls juhendit, et mõista, kuidas kontrollimeetmed nagu 5.23, 5.24, 8.8, 5.20 ja 5.30 vastenduvad raamistikesse ja auditi vaadetesse.
Viiendaks muutke tõendusmaterjal operatiivseks. Poliitikatest üksi ei piisa. Clarysec poliitikateek annab jõustatavad nõuded pilveteenuste heakskiitmiseks, tarnijate juurdepääsuks, logimiseks, haavatavuste parandusmeetmeteks, võrgu segmenteerimiseks, intsidentide klassifitseerimiseks ja talitluspidevuse planeerimiseks. Tõenduspakett näitab, et need nõuded toimivad.
Järgmine samm: muutke NIS2 surve auditivalmis vastupidavuseks
NIS2 rakendusmäärus 2024/2690 ei nõua kaost. See nõuab jälgitavust, vastutust ja tõendust.
Kui olete pilveteenuse pakkuja, MSP, MSSP või andmekeskuse käitaja, alustage oma teenustest, klientidest, sõltuvustest, intsidendistsenaariumidest ja tõenduskohustustest. Seejärel viige läbi struktureeritud NIS2 ja ISO/IEC 27001:2022 vastendusharjutus:
- Kinnitage, kas teie üksus ja teenused kuuluvad kohaldamisalasse.
- Vastendage NIS2 ja rakendusmääruse teemad oma ISMS-i kohaldamisalaga.
- Ajakohastage riskiregistrit ja kohaldatavusdeklaratsiooni.
- Rakendage Clarysec poliitikaid pilveteenuste kasutuse, tarnijate turbe, logimise, haavatavuste halduse, intsidentidele reageerimise, võrguturbe ja talitluspidevuse jaoks.
- Kasutage Zenith Blueprint Zenith Blueprint samme 13, 14, 20 ja 23, et luua jälgitavus ja operatiivne tõendusmaterjal.
- Kasutage Zenith Controls Zenith Controls juhendit, et ristvastendada ISO/IEC 27001:2022 kontrollimeetmed NIS2, DORA, GDPR, NIST ja COBIT 2019 ootustega.
- Testige tõendusmaterjali auditisimulatsiooni kaudu enne, kui klient, regulaator või sertifitseerimisaudiitor seda küsib.
Clarysec aitab teil liikuda kontrollnimekirjapõhisest vastavusest kaugemale ja ehitada integreeritud ISMS-i, mis peab vastu NIS2, DORA, GDPR ja klientide auditite survele. Laadige alla asjakohased Clarysec tööriistakomplektid, broneerige vastendustöötuba või küsige auditivalmiduse hindamist, et muuta regulatiivne keerukus kaitstavaks turbejuhtimiseks ja operatiivseks vastupidavuseks.
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
