NIS2 2024/2690 ja ISO 27001: pilvipalveluntarjoajan kontrollikartta
Tiistaina klo 08.17 eurooppalaisen hallinnoitujen palvelujen tarjoajan tietoturvajohtaja (CISO) Maria saa hälytyksen, jota jokainen MSP pelkää. Yksi etuoikeutettu etähallintatili on laukaissut mahdottomaan matkustukseen perustuvia hälytyksiä. Kahdessa asiakasympäristössä näkyy poikkeavia hallinnollisia toimia. SOC on jo avannut kriittisen poikkeaman siltapuhelun.
Klo 09.00 toimitusjohtaja liittyy puheluun. Kysymykset muuttuvat välittömästi.
Kuulummeko NIS2:n soveltamisalaan? Sovelletaanko meihin komission täytäntöönpanoasetusta (EU) 2024/2690? Tarvitsemmeko 24 tunnin ennakkovaroituksen? Mitkä asiakkaat on ilmoitettava? Voimmeko osoittaa, että MFA, lokitus, segmentointi, haavoittuvuuksien hallinta, toimittajakontrollit ja poikkeamien eskalointi olivat toiminnassa ennen poikkeamaa?
Marian yrityksellä on ISO/IEC 27001:2022 -sertifiointi. Se tuottaa pilvihallintaa, konesalipalveluja ja hallinnoitua tietoturvatukea asiakkaille, joihin kuuluu logistiikkapalvelujen tarjoaja ja alueellinen pankki. Sertifikaatilla on merkitystä, mutta se ei yksin vastaa operatiivisiin kysymyksiin. Lakitiimillä on luonnos ilmoitusprosessista. Vaatimustenmukaisuuspäälliköllä on laskentataulukko. Auditoija on pyytänyt soveltuvuuslausuntoa, näyttöä tietoturvapoikkeamien hallinnan testaamisesta, etuoikeutettujen käyttöoikeuksien lokeja, toimittajien huolellisuusarviointeja, näyttöä pilvipalvelujen jaetusta vastuusta sekä liiketoiminnan jatkuvuuden oletuksia.
Tämä on hetki, jolloin NIS2 lakkaa olemasta pelkkä säädösteksti ja muuttuu operatiiviseksi kontrolliongelmaksi.
Pilvipalvelujen tarjoajille, hallinnoitujen palvelujen tarjoajille, hallinnoitujen tietoturvapalvelujen tarjoajille ja konesalipalvelujen tarjoajille NIS2 ja täytäntöönpanoasetus 2024/2690 nostavat vaatimustason yleisestä tietoturvatavoitteesta todennettavaan kontrollinäyttöön. Hallinnointi, riskienhallinta, pääsynhallinta, omaisuudenhallinta, haavoittuvuuksien käsittely, tietoturvapoikkeamien hallinta, toimittajaturvallisuus, lokitus, valvonta, salaus, liiketoiminnan jatkuvuus ja fyysinen häiriönsietokyky tulee saada toimimaan yhtenä kokonaisuutena.
ISO/IEC 27001:2022 on paras runko tälle kokonaisuudelle, mutta vain jos organisaatio kartoittaa NIS2-vaatimukset ISMS:ään, riskirekisteriin, soveltuvuuslausuntoon, politiikkoihin ja näyttömalliin. Seinällä oleva sertifikaatti ei riitä. Varsinainen työ on auditoitavissa olevan ketjun rakentaminen sääntelystä riskiin, riskistä kontrolliin, kontrollista politiikkaan ja politiikasta operatiiviseen näyttöön.
Miksi NIS2 2024/2690 muuttaa pilvipalvelujen ja MSP-toimijoiden vaatimustenmukaisuuskeskustelua
NIS2 käyttää toimiala- ja kokoperusteista mallia, mutta sen digitaalisen infrastruktuurin ja ICT-palvelujen hallinnan kategoriat on tarkoituksella määritelty laajoiksi. NIS2:n Article 2 ja Article 3 sekä liite I ja liite II huomioon ottaen monet organisaatiot voidaan luokitella keskeisiksi tai tärkeiksi toimijoiksi, mukaan lukien pilvipalvelujen tarjoajat, konesalipalvelujen tarjoajat, hallinnoitujen palvelujen tarjoajat, hallinnoitujen tietoturvapalvelujen tarjoajat, DNS-palveluntarjoajat, TLD-rekisterit, sisällönjakeluverkot ja luottamuspalvelujen tarjoajat. Jäsenvaltioiden tulee perustaa ja katselmoida säännöllisesti keskeisten ja tärkeiden toimijoiden luettelot; ensimmäisen luettelon määräpäivä on 17. huhtikuuta 2025.
Tällä on merkitystä, koska pilvipalvelujen tarjoajat, MSP:t, MSSP:t ja konesalipalvelujen tarjoajat sijaitsevat muiden organisaatioiden riskiketjuissa. Pilvipalvelun ohjaustason vaarantuminen voi vaikuttaa tuhansiin asiakasjärjestelmiin. Konesalikatko voi heijastua pankkitoimintaan, terveydenhuoltoon, logistiikkaan ja julkishallintoon. MSP:n tunnistetietojen vuoto voi muuttua usean asiakkaan kiristyshaittaohjelmatapahtumaksi. MSSP:n havaitsemiskyvyn epäonnistuminen voi viivästyttää rajaamista säänneltyjen asiakkaiden ympäristöissä.
NIS2 Article 20 edellyttää, että johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niiden toteutusta. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä kaikkiin vaaratekijöihin perustuvan lähestymistavan mukaisesti. Perustaso sisältää riskianalyysin, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen hankinnan ja kehittämisen, haavoittuvuuksien käsittelyn ja julkistamisen, vaikuttavuuden arvioinnin, kyberhygienian, koulutuksen, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan, MFA:n tai jatkuvan todennuksen, turvallisen viestinnän ja hätäviestinnän.
Article 23 lisää vaiheistetun merkittävien poikkeamien ilmoittamisen, mukaan lukien ennakkovaroituksen 24 tunnin kuluessa, poikkeamailmoituksen 72 tunnin kuluessa, väliraportit pyydettäessä sekä loppuraportin kuukauden kuluessa ilmoituksesta tai poikkeaman käsittelystä, jos poikkeama on edelleen käynnissä.
Täytäntöönpanoasetus 2024/2690 konkretisoi näitä odotuksia asianomaisille digitaalisille palveluntarjoajille. Käytännössä viranomaiset, asiakkaat ja auditoijat eivät kysy vain, ovatko politiikat olemassa. He kysyvät, onko kontrollit kartoitettu, vastuutettu, testattu ja todennettu näytöllä.
ISO/IEC 27001:2022 muuttaa NIS2:n ISMS:n toimintaympäristöksi
Yleinen NIS2-valmiuden virhe on aloittaa laajasta tarkistuslistasta ja jakaa tehtäviä IT:n, lakiasioiden, SOC:n, infrastruktuurin, toimittajahallinnan ja vaatimustenmukaisuuden kesken. Se voi tuottaa tekemistä, mutta epäonnistuu usein auditoinnissa, koska kukaan ei pysty osoittamaan, miksi kontrollit valittiin, miten ne liittyvät riskiin, kuka hyväksyi jäännösriskin ja mikä näyttö osoittaa vaikuttavuuden.
ISO/IEC 27001:2022 antaa palveluntarjoajille rakenteen tämän epäonnistumisen välttämiseksi.
Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää sisäiset ja ulkoiset tekijät, tunnistaa sidosryhmät ja niiden vaatimukset, päättää, mitkä vaatimukset käsitellään ISMS:n kautta, ja määrittää ISMS:n soveltamisalan, mukaan lukien rajapinnat ja riippuvuudet. Pilvipalvelujen tarjoajan tai MSP:n soveltamisalassa tulisi nimenomaisesti ottaa huomioon NIS2, täytäntöönpanoasetus 2024/2690, asiakkaiden tietoturvaliitteet, DORA-vetoiset asiakasvaatimukset, pilvialueet, alihankkijat, konesaliriippuvuudet, etähallinta-alustat, etuoikeutetut pääsypolut ja poikkeamien ilmoitusvelvoitteet.
Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkojen yhdenmukaisuutta, resursseja, viestintää, määritettyjä vastuita ja johdon vastuun osoittamista. Tämä tukee suoraan NIS2 Article 20:tä.
Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, riskinomistajia, todennäköisyys- ja vaikutusanalyysiä, kontrollien valintaa, vertailua liitteeseen A, soveltuvuuslausuntoa, riskienkäsittelysuunnitelmaa ja muodollista jäännösriskin hyväksyntää. Tässä NIS2 muuttuu operatiiviseksi. Jokaisesta sääntelyvaatimuksesta tulee riskiajuri, vaatimustenmukaisuusvelvoite, kontrollivaatimus tai näyttövaatimus.
Clarysec aloittaa tämän työn tuotteella Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, erityisesti Risk Management -vaiheessa.
Vaiheesta 13, Risk Treatment Planning and Statement of Applicability, alkaen Zenith Blueprint ohjeistaa tiimejä rakentamaan jäljitettävyyden riskien, kontrollien ja sääntelyajureiden välille:
“Ristiinviittaa sääntelyyn: Jos tiettyjä kontrolleja toteutetaan nimenomaisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit merkitä tämän joko riskirekisteriin tai SoA:n huomautuksiin. Esimerkiksi kontrolli 8.27 (tietojen turvallinen poistaminen) voi olla erittäin olennainen GDPR:n vaatimukselle hävittää henkilötietoja; voit kirjata ‘Sovellettava – tukee GDPR Art.32:ta (käsittelyn turvallisuus)’. ISO ei edellytä tätä, mutta se auttaa osoittamaan, että olet huomioinut kyseiset viitekehykset.”
Vaihe 14, Risk Treatment Policies and Regulatory Cross-References, lisää käytännön kartoituskurinalaisuuden:
“Kunkin sääntelyn osalta voit tarvittaessa laatia yksinkertaisen kartoitustaulukon, jossa luetellaan sääntelyn keskeiset tietoturvavaatimukset ja niitä vastaavat ISMS:n kontrollit/politiikat. Tämä ei ole pakollista ISO 27001 -standardissa, mutta se on hyödyllinen sisäinen harjoitus sen varmistamiseksi, ettei mikään jäänyt väliin.”
Tämä on ero väitteen “olemme ISO-sertifioituja” ja näytön “ISO/IEC 27001:2022 -pohjainen ISMS:mme käsittelee NIS2-täytäntöönpanoasetuksen 2024/2690” välillä.
Yhtenäinen NIS2–ISO/IEC 27001:2022 -kontrollikartta
Seuraava kartoitus ei ole oikeudellista neuvontaa eikä korvaa kansallisen täytäntöönpanon analyysia. Se on käytännön kontrolliarkkitehtuuri palveluntarjoajille, jotka tarvitsevat auditoitavissa olevan ISO/IEC 27001:2022 -reitin NIS2-valmiuteen.
| NIS2:n ja täytäntöönpanoasetuksen teema | ISO/IEC 27001:2022 ISMS -mekanismi | Keskeiset liitteen A kontrollialueet | Clarysecin toteutusnäyttö |
|---|---|---|---|
| Hallinnointi ja johdon vastuun osoittaminen | Kohdat 4, 5, 6 ja 9 määrittävät toimintaympäristön, johtajuuden, riskisuunnittelun ja suorituskyvyn katselmoinnin | 5.1 Tietoturvapolitiikat, 5.2 tietoturvaroolit ja -vastuut, 5.31 lakisääteiset, sääntelyperusteiset ja sopimusperusteiset vaatimukset | ISMS:n soveltamisala, sidosryhmärekisteri, hallituksen hyväksyntä, riskirekisteri, SoA, johdon katselmuksen pöytäkirjat |
| Pilvipalvelujen hallinnointi | Riskien arviointi, toimittajien huolellisuusarviointi, jaettu vastuu ja kontrollien valinta | 5.23 Tietoturva pilvipalvelujen käytössä, 5.19 tietoturva toimittajasuhteissa, 5.22 toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta | Pilvi-inventaario, palveluntarjoajan riskien arviointi, jaetun vastuun matriisi, sopimuslausekkeet, pilvilokituksen näyttö |
| MSP:n ja MSSP:n etuoikeutettu pääsy | Riskien käsittely asiakasympäristöille, ylläpitoalustoille ja tukityökaluille | 5.15 pääsynhallinta, 5.16 identiteetinhallinta, 5.18 käyttöoikeudet, 8.2 etuoikeutetut käyttöoikeudet, 8.5 turvallinen todennus | PAM-tallenteet, MFA-raportit, etäkäytön lokit, hyppypalvelimen tai Zero Trust -yhdyskäytävän konfiguraatio, käyttöoikeuskatselmoinnit |
| Konesalin häiriönsietokyky | Liiketoimintavaikutusten arviointi, jatkuvuussuunnittelu ja riippuvuuksien hallinta | 5.30 ICT-valmius liiketoiminnan jatkuvuutta varten, 7.1 fyysisen turvallisuuden rajat, 7.2 fyysinen sisäänpääsy, 8.13 tietojen varmuuskopiointi, 8.14 redundanssi | BIA, RTO- ja RPO-tallenteet, DR-testiraportti, fyysisen pääsyn lokit, sähkönsyötön ja jäähdytyksen testinäyttö |
| Poikkeamien ilmoittaminen ja eskalointi | Poikkeamaprosessi, joka on kytketty lakisääteisiin, sopimusperusteisiin ja asiakasilmoitusten herätteisiin | 5.24 Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, 5.25 tietoturvatapahtumien arviointi ja päätöksenteko, 5.26 tietoturvapoikkeamiin reagointi, 5.27 tietoturvapoikkeamista oppiminen | 24 tunnin ennakkovaroituksen toimintapelikirja, 72 tunnin ilmoitustyönkulku, poikkeamarekisteri, poikkeaman jälkiarviointi |
| Haavoittuvuuksien käsittely ja julkistaminen | Riskiperusteinen haavoittuvuuksien käsittely, poikkeusten käsittely ja vaikuttavuuden arviointi | 8.8 teknisten haavoittuvuuksien hallinta, 8.9 konfiguraationhallinta, 8.32 muutoksenhallinta, 8.16 valvontatoiminnot | Skannaustulokset, korjaavien toimenpiteiden palvelutasosopimukset, poikkeusten hyväksynnät, paikkausraportit, uhkatiedustelusyötteet |
| Toimitusketjun turvallisuus | Sidosryhmävaatimukset ja toimittajariski integroituna ISMS:ään | 5.19 Tietoturva toimittajasuhteissa, 5.20 tietoturvan käsittely toimittajasopimuksissa, 5.21 tietoturvan hallinta ICT-toimitusketjussa, 5.22 toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta | Toimittajien riskiluokitus, huolellisuuskyselyt, sopimuslausekkeet, auditointioikeudet, alihankkijarekisteri, exit-suunnitelmat |
| Lokitus, valvonta ja tutkinta | Havaitseminen, näyttö, aikasidonnainen korrelaatio ja poikkeamien tuki | 8.15 lokitus, 8.16 valvontatoiminnot, 8.17 kellon synkronointi, 5.25 tietoturvatapahtumien arviointi ja päätöksenteko | SIEM-kattavuuskartta, lokien säilytyksen todentava aineisto, hälytysten viritystiedot, kellon synkronointitallenteet, poikkeamien korrelointinäyttö |
| Verkon ja asiakasympäristöjen eristäminen | Turvallinen arkkitehtuuri, segmentointi ja rajoitetut hallinnolliset polut | 8.20 verkkoturvallisuus, 8.22 verkkojen eriyttäminen, 8.23 verkkosuodatus, 8.24 kryptografian käyttö | Verkkokaaviot, palomuurisäännöt, pilven tietoturvaryhmät, VPC- tai aliverkkosäännöt, segmentointitestien tulokset |
Tästä kartoituksesta tulee vaikuttava, kun se upotetaan riskirekisteriin ja soveltuvuuslausuntoon. Palveluntarjoaja voi esimerkiksi luoda riskiskenaarion “Etähallinta-alustan vaarantuminen johtaa luvattomiin toimiin asiakasympäristöissä”. Kontrolleihin kuuluvat MFA, etuoikeutetun pääsyn hallinta (PAM), segmentointi, lokitus, haavoittuvuuksien hallinta, toimittajaturvallisuus, poikkeamien suunnittelu ja asiakasilmoitusmenettelyt. SoA:n huomautuksissa voidaan viitata NIS2 Article 21:een, Article 23:een, täytäntöönpanoasetukseen 2024/2690, asiakassopimuksiin ja DORA-asiakkaiden huolellisuusarviointivaatimuksiin, kun se on olennaista.
Pilvipalvelujen hallinnointi: ISO-kontrolli 5.23 on NIS2:n ankkuri
Pilvipalvelujen tarjoajille ja MSP-toimijoille, jotka käyttävät pilvipalveluja asiakaspalvelujen tuottamiseen, ISO/IEC 27001:2022 liitteen A kontrolli 5.23, tietoturva pilvipalvelujen käytössä, on yksi tärkeimmistä ankkureista.
Zenith Controls: The Cross-Compliance Guide Zenith Controls tiivistää kontrollin 5.23 ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja liittyy toimittajasuhteiden turvallisuuteen, hallinnointiin, ekosysteemiriskiin ja suojaukseen. Se kattaa pilvipalvelujen hallinnoinnin, jaetun vastuun, palveluntarjoajan arvioinnin, inventaariot, tietojen sijainnin, lokituksen, salauksen, identiteettiroolit, valvonnan, sopimuslausekkeet, toimittajariskin, pilvipalvelusta irtautumisen ja häiriönsietokyvyn suunnittelun.
Zenith Blueprint, Controls in Action -vaihe, vaihe 23, selittää käytännön perusteen:
“Pilvi ei ole enää kohde, vaan oletusarvo. Kontrolli 5.23 tunnistaa tämän todellisuuden ja edellyttää, että tietoturva käsitellään nimenomaisesti pilvipalvelujen valinnassa, käytössä ja hallinnassa – ei jälkikäteisenä lisäyksenä vaan suunnitteluperiaatteena alusta alkaen.”
MSP:lle jokaisen etävalvonta- ja hallinta-alustan, asiakasportaalin, tikettijärjestelmän, tietoturvan telemetria-alustan, varmuuskopiointipalvelun, pilvihakemiston ja SaaS-hallintakonsolin tulee olla hallittu. Konesalipalvelujen tarjoajalla pilvipalvelujen hallinnointi voi koskea valvonta-alustoja, vierailijahallintajärjestelmiä, fyysisen pääsynhallinnan integraatioita, etähallintajärjestelmiä ja asiakasportaalin infrastruktuuria.
Clarysecin Enterprise Cloud Usage Policy Cloud Usage Policy tekee käyttöönottoa edeltävästä huolellisuusarvioinnista pakollisen:
“Kaikelle pilvikäytölle tulee tehdä riskiperusteinen huolellisuusarviointi ennen aktivointia, mukaan lukien palveluntarjoajan arviointi, lakisääteisen noudattamisen validointi ja kontrollien validointikatselmoinnit.”
Osasta “Governance Requirements”, politiikkalauseke 5.2.
Pienemmille palveluntarjoajille Cloud Usage Policy-sme Cloud Usage Policy-sme - SME luo kevyen hyväksyntämallin:
“Toimitusjohtajan (GM) tulee katselmoida ja hyväksyä kaikki pilvipalvelujen käyttö ennen toteutusta tai tilausta.”
Osasta “Governance Requirements”, politiikkalauseke 5.1.
Molemmat lähestymistavat tukevat samaa NIS2-odotusta: pilviriippuvuuteen liittyvä riski tulee ymmärtää ennen kuin palvelusta tulee osa toimitusketjua.
Tietoturvapoikkeamiin reagointi: 24 tunnin kello käynnistyy ennen raportin laatimista
NIS2 Article 23 on vaativa, koska ilmoitusaikataulu alkaa merkittävän poikkeaman havaitsemisesta, ei siitä hetkestä, kun täydellinen juurisyyanalyysi on käytettävissä. Palveluntarjoajien haasteena on määrittää nopeasti, onko tapahtuma merkittävä, mihin asiakkaisiin se vaikuttaa, liittyykö siihen henkilötietoja, onko sillä rajat ylittävä palveluvaikutus ja mitkä sopimusperusteiset aikarajat ovat käynnistyneet.
ISO/IEC 27001:2022 liitteen A kontrolli 5.24, tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, on suunnittelukontrolli. Zenith Controls tiivistää sen korjaavaksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä liittyy Respond- ja Recover-käsitteisiin, hallinnointiin, tapahtumien hallintaan ja puolustukseen. Se sisältää roolit, vastuut, eskalointipolut, viestintäprotokollat, valmiuden sääntelyperusteisiin ilmoituksiin, yhdenmukaisuuden lokituksen ja valvonnan kanssa, integraation liiketoiminnan jatkuvuuteen ja katastrofipalautukseen, poikkeamien jälkeisen oppimisen sekä kartoituksen NIS2:een, GDPR:ään, DORA:an, ISO 22301:een, NIST CSF:ään, NIST SP 800-53:een ja COBIT 2019:ään.
Clarysecin Incident Response Policy-sme Incident Response Policy-sme - SME muuttaa ensimmäisen päätöksen aikarajoitetuksi vaatimukseksi:
“Toimitusjohtajan tulee IT-palveluntarjoajan tuella luokitella kaikki poikkeamat vakavuuden mukaan tunnin kuluessa ilmoituksesta.”
Osasta “Governance Requirements”, politiikkalauseke 5.3.1.
Tämä yhden tunnin luokittelu tukee operatiivista kurinalaisuutta, jota tarvitaan NIS2:n 24 tunnin ennakkovaroituksen analyysiin, GDPR:n henkilötietojen tietoturvaloukkauksen arviointiin, DORA-asiakkaan eskalointiin ja sopimusperusteisten ilmoitusten luokitteluun.
Palveluntarjoajan poikkeamapäätöspuun tulisi vastata neljään kysymykseen:
- Onko luottamuksellisuuden, eheyden tai saatavuuden vaarantuminen vahvistettu tai epäilty?
- Vaikuttaako tapahtuma palvelun tuottamiseen, asiakasympäristöihin, säänneltyihin asiakkaisiin, henkilötietoihin tai kriittisiin toimintoihin?
- Voiko se aiheuttaa vakavan operatiivisen häiriön, taloudellisen menetyksen tai aineellisen tai aineettoman vahingon?
- Mitkä ilmoitusvelvoitteet soveltuvat: NIS2, GDPR, DORA-asiakasvelvoitteet, sopimusperusteiset SLA:t tai kansallisen viranomaisen odotukset?
Päätöspuu tulisi testata pöytäharjoituksissa ennen todellista poikkeamaa.
Haavoittuvuuksien hallinta: osoita riskin vähentäminen ennen vaikutusta
NIS2 edellyttää haavoittuvuuksien käsittelyä ja julkistamista. Asiakkaille ja viranomaisille haavoittuvuuksien hallinta on yksi helpoimmin mitattavista kontrollialueista, koska se tuottaa selkeää näyttöä: skannauskattavuus, paikkausaikataulut, poikkeusten hyväksynnät, hyväksikäytettyjen haavoittuvuuksien analyysi ja korjaavien toimenpiteiden tallenteet.
ISO/IEC 27001:2022 liitteen A kontrolli 8.8, teknisten haavoittuvuuksien hallinta, kuvataan Zenith Controls -oppaassa ennaltaehkäiseväksi kontrolliksi luottamuksellisuuden, eheyden ja saatavuuden alueilla. Se liittyy Identify- ja Protect-käsitteisiin, uhkien ja haavoittuvuuksien hallintaan, hallinnointiin, ekosysteemiin, suojaukseen ja puolustukseen. Se sisältää haavoittuvuuksien tunnistamisen, arvioinnin, priorisoinnin, paikkauksen, korvaavat kontrollit, uhkatiedustelun integroinnin, haavoittuvuuksien julkistamisen, pilvi- ja sovellushaavoittuvuuksien vastuut, auditointinäytön ja korjaavien toimenpiteiden aikarajat.
Clarysecin Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy antaa auditoijille konkreettisen testattavan mallin:
“Organisaation tulee luokitella kaikki havaitut haavoittuvuudet standardoidulla menetelmällä (esim. CVSS v3.x) ja soveltaa korjaavien toimenpiteiden aikarajoja liiketoimintakriittisyyden mukaisesti: 5.2.1 Kriittinen (CVSS 9.0–10.0): Välitön katselmointi; korjauspäivityksen määräaika enintään 72 tuntia. 5.2.2 Korkea (7.0–8.9): Reagointi 48 tunnin kuluessa; korjauspäivityksen määräaika 7 kalenteripäivää. 5.2.3 Keskitaso (4.0–6.9): Reagointi 5 päivän kuluessa; korjauspäivityksen määräaika 30 kalenteripäivää. 5.2.4 Matala (<4.0): Reagointi 10 päivän kuluessa; korjauspäivityksen määräaika 60 kalenteripäivää.”
Osasta “Governance Requirements”, politiikkalauseke 5.2.
Pilvipalveluntarjoajalla tämän tulee kattaa hypervisor-komponentit, konttikuvat, orkestrointikerrokset, asiakasrajapinnan ohjelmointirajapinnat, CI/CD-putket, hallintakonsolit ja kolmannen osapuolen kirjastot. MSP:n osalta keskeinen kysymys on, erotetaanko sisäiset haavoittuvuudet asiakkaan hallinnoimista haavoittuvuuksista ja määrittävätkö sopimukset vastuun. Konesalipalvelujen tarjoajalla soveltamisala voi sisältää kiinteistöautomaatiojärjestelmät, pääsynhallintajärjestelmät, valvonta-alustat, remote hands -työkalut ja verkkoinfrastruktuurin.
Jaetun vastuun malli tulee dokumentoida. Palveluntarjoaja ei välttämättä omista jokaista korjauspäivitystä, mutta sen tulee silti hallita riskiä, ilmoittaa asiakkaalle tarvittaessa ja osoittaa, että vastuurajat ymmärretään.
Lokitus, valvonta ja segmentointi tekevät poikkeamista tutkittavia
Kun palveluntarjoajan poikkeama vaikuttaa asiakkaisiin, ensimmäiset näyttökysymykset ovat yksinkertaisia: kuka kirjautui sisään, mistä, millä käyttöoikeudella, mihin asiakasympäristöön, mitä muutettiin, mitä lokeja on olemassa ja olivatko hallinnolliset polut segmentoituja.
Clarysecin Enterprise Logging and Monitoring Policy Logging and Monitoring Policy edellyttää, että soveltamisalaan kuuluvat järjestelmät tuottavat lokit, joita reagointitiimit ja auditoijat tarvitsevat:
“Kaikkien soveltamisalaan kuuluvien järjestelmien tulee tuottaa lokit, jotka tallentavat: 6.1.1.1 Käyttäjän todennus- ja pääsyyritykset 6.1.1.2 Etuoikeutettujen käyttäjien toimet 6.1.1.3 Konfiguraatiomuutokset 6.1.1.4 Epäonnistuneet pääsyyritykset tai järjestelmätapahtumat 6.1.1.5 Haittaohjelmahavainnot ja tietoturvahälytykset 6.1.1.6 Ulkoinen viestintä ja palomuurisääntöjen laukaisut”
Osasta “Policy Implementation Requirements”, politiikkalauseke 6.1.1.
Ulkoisiin palveluntarjoajiin tukeutuville pk-yrityksille Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME lisää sopimusperusteisen vaatimuksen:
“Sopimusten tulee edellyttää, että palveluntarjoajat säilyttävät lokit vähintään 12 kuukauden ajan ja tarjoavat pääsyn pyynnöstä.”
Osasta “Governance Requirements”, politiikkalauseke 5.5.1.3.
Segmentointi on yhtä tärkeää. Network Security Policy-sme Network Security Policy-sme - SME toteaa:
“Sisäiset verkot tulee segmentoida toiminnon perusteella (esim. taloushallinto, vieraat, IoT, hallinnolliset järjestelmät).”
Osasta “Policy Implementation Requirements”, politiikkalauseke 6.2.1.
Zenith Blueprint, Controls in Action -vaihe, vaihe 20, antaa käytännön auditointimenettelyn verkkoarkkitehtuurille ja segmentoinnille. Se ohjeistaa tiimejä katselmoimaan ja dokumentoimaan verkkorakenteen, tarkistamaan palomuurisäännöt, IPS/IDS- ja etäkäyttömääritykset, varmistamaan, että pilven tietoturvaryhmät ja VPC- tai aliverkkosäännöt vastaavat suunniteltua arkkitehtuuria, luetteloimaan sisäiset ja ulkoiset verkkopalvelut sekä validoimaan, että arkaluonteiset järjestelmät eivät ole tavoitettavissa yleisistä käyttäjä-VLAN-verkoista tai vierasverkoista.
MSP:llä etähallintatyökalut eivät saa sijaita segmentoimattomassa toimistoverkossa. Konesalipalvelujen tarjoajalla sähkön, jäähdytyksen, pääsynhallinnan ja asiakkaiden verkkopalvelujen hallintaliittymät tulisi eristää ja niitä tulisi valvoa. Pilvipalveluntarjoajalla ohjaustason pääsy tulisi rajoittaa identiteetin, verkon, laitteen tietoturvan tilan ja etuoikeutettujen työnkulkujen kontrollien avulla.
Toimittajaturvallisuus: palveluntarjoaja on myös asiakas
Pilvipalvelujen tarjoajat, MSP:t, MSSP:t ja konesalipalvelujen tarjoajat ovat toimittajia säännellyille asiakkaille, mutta ne ovat myös ohjelmistotoimittajien, teleoperaattorien, identiteetin tarjoajien, SaaS-alustojen, laitteistotoimittajien, alihankkijoiden ja infrastruktuurioperaattorien asiakkaita.
NIS2 tekee toimitusketjun turvallisuudesta ydinvaatimuksen. DORA, jota sovelletaan 17. tammikuuta 2025 alkaen, tekee ICT-kolmansien osapuolten riskienhallinnasta keskeisen finanssialan toimijoille. NIS2 Article 4 ja johdanto-osan 28 perustelukappale tunnistavat DORA:n finanssialan toimijoita koskevaksi alakohtaiseksi unionin säädökseksi silloin, kun vaatimukset ovat päällekkäisiä. Tämä ei vähennä pilvipalvelu- ja MSP-toimijoihin kohdistuvaa painetta. Se lisää sitä, koska finanssiasiakkaat sisällyttävät DORA-tasoisia sopimusvaatimuksia, auditointioikeuksia, häiriönsietokyvyn testausta, exit-strategioita ja poikkeamien ilmoitusodotuksia toimittajasopimuksiin.
Clarysecin Enterprise Third party and supplier security policy Third party and supplier security policy edellyttää hallittua kolmannen osapuolen pääsyä:
“Kaikki kolmannen osapuolen pääsy tulee kirjata lokiin ja sitä tulee seurata, ja mahdollisuuksien mukaan se tulee segmentoida hyppypalvelinten, VPN-yhteyksien tai Zero Trust -yhdyskäytävien kautta.”
Osasta “Policy Implementation Requirements”, politiikkalauseke 6.3.2.
Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME ilmaisee vähimpien oikeuksien periaatteen suoraan:
“Toimittajille tulee myöntää pääsy vain niihin vähimmäisjärjestelmiin ja tietoihin, joita niiden tehtävän suorittaminen edellyttää.”
Osasta “Policy Implementation Requirements”, politiikkalauseke 6.2.1.
Nämä lausekkeet karttuvat luontevasti ISO/IEC 27001:2022 liitteen A kontrolleihin 5.19, 5.20, 5.21 ja 5.22. Ne tukevat myös GDPR:n käsittelijä- ja alikäsittelijähallinnointia, DORA:n kolmansien osapuolten riskikatselmointeja ja asiakkaiden auditointikyselyjä.
Liiketoiminnan jatkuvuus ja konesalin häiriönsietokyky: osoita oletukset
NIS2 Article 21 sisältää liiketoiminnan jatkuvuuden, varmuuskopioiden hallinnan, katastrofipalautuksen ja kriisinhallinnan. DORA Articles 11–14 edellyttävät finanssialan toimijoilta ICT-liiketoiminnan jatkuvuuspolitiikkoja, reagointi- ja palautumissuunnitelmia, liiketoimintavaikutusten arviointia, varmuuskopiointipolitiikkoja, palautusmenettelyjä, palautustavoitteita, testausta, poikkeamien jälkiarviointeja ja kriisiviestintää.
Pilvi- ja konesalipalvelujen tarjoajille jatkuvuus ei ole kansio. Se on arkkitehtuuria, kapasiteettia, sopimuksia, riippuvuuksia, palautusnäyttöä ja testattuja oletuksia.
Clarysecin Enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy edellyttää vuosittaista BIA:ta ja katselmointia merkittävien muutosten jälkeen:
“Business Impact Analysis (BIA) tulee suorittaa vähintään vuosittain kaikille kriittisille liiketoimintayksiköille ja katselmoida merkittävien järjestelmä-, prosessi- tai riippuvuusmuutosten yhteydessä. BIA-tulosten tulee määrittää: 5.2.1. Suurin hyväksyttävä keskeytysaika (MTD) 5.2.2. Toipumisaikatavoitteet (RTO) 5.2.3. Palautuspistetavoitteet (RPO) 5.2.4. Kriittiset riippuvuudet (järjestelmät, toimittajat, henkilöstö)”
Osasta “Governance Requirements”, politiikkalauseke 5.2.
Konesaliskenaariossa BIA:n tulisi kattaa sähkönsyötöt, UPS-järjestelmät, generaattorit, polttoainesopimukset, jäähdytys, palonsammutus, verkkoyhteyksien operaattorit, fyysisen pääsyn järjestelmät, remote hands -palvelut, valvonta, varaosalaitteet ja asiakasviestintäkanavat. Pilviskenaariossa sen tulisi kattaa alueet, saatavuusvyöhykkeet, replikointi, varmuuskopioiden muuttumattomuus, identiteettiriippuvuudet, DNS, varmentajat (CA), API-yhdyskäytävät ja tukijärjestelmät. MSP-skenaariossa sen tulisi kattaa etähallintatyökalut, etuoikeutetun pääsyn holvit, EDR-konsolit, tikettijärjestelmä, dokumentaatiotietovarastot ja hätäviestintä.
ISO 22301 voi vahvistaa liiketoiminnan jatkuvuuden hallinnan kurinalaisuutta, kun taas ISO/IEC 27005:2022 tukee riskikriteerejä, käsittelyn suunnittelua, seurantaa, näyttöä ja jatkuvaa parantamista. Tämä on hyödyllistä, koska NIS2-valmius edellyttää, että organisaatio yhdistää lakisääteiset, sopimusperusteiset, operatiiviset, toimittajiin liittyvät, teknologiset, taloudelliset, prosessi- ja inhimilliset tekijät yhdeksi riskiprosessiksi.
Käytännön riskijälki MSP:n etäkäyttöloukkaukselle
Käytännön työpaja voi alkaa yhdestä skenaariosta:
“Etuoikeutetun etäkäytön vaarantuminen johtaa luvattomaan pääsyyn asiakasjärjestelmiin, palveluhäiriöön, mahdolliseen henkilötietojen altistumiseen ja sääntelyperusteisiin ilmoitusvelvoitteisiin.”
Luo riskirekisteriin rivi ja täydennä jälki.
| Kenttä | Esimerkkimerkintä |
|---|---|
| Riskinomistaja | Hallinnoiduista palveluista vastaava johtaja |
| Omaisuuserät ja prosessit | Etähallinta-alusta, asiakkaiden ylläpitäjätilit, etuoikeutettujen tunnusten holvi, tikettijärjestelmä, SIEM, asiakasympäristöt |
| Uhkatapahtuma | Tunnistetietojen varkaus, MFA-väsymys, tokenin varkaus, hyväksikäytetty RMM-haavoittuvuus, pahantahtoinen sisäpiiriläinen |
| Vaikutus | Asiakkaan vaarantuminen, palvelukatkos, sopimusrikkomus, NIS2:n mukainen merkittävä poikkeama, GDPR:n mukainen henkilötietojen tietoturvaloukkaus, DORA-asiakkaan eskalointi |
| Olemassa olevat kontrollit | MFA, PAM, vähimpien oikeuksien periaate, segmentointi, lokitus, haavoittuvuusskannaus, tietoturvapoikkeamiin reagointisuunnitelma |
| Vaadittava käsittely | Tiukenna ehdollista pääsyä, ota käyttöön just-in-time-ylläpito, paranna asiakasympäristöjen eristämistä, pidennä lokien säilytystä, testaa ilmoitusten toimintapelikirja |
| ISO/IEC 27001:2022 -näyttö | Riskien arviointi, SoA, käyttöoikeuskatselmointi, lokinäytteet, haavoittuvuusraportit, pöytäharjoitus, johdon katselmointi |
| NIS2-kartoitus | Article 21 riskienhallinta ja Article 23 poikkeamien ilmoittaminen sekä täytäntöönpanoasetuksen operatiiviset toimenpiteet |
| Asiakaskartoitus | Sopimusperusteinen ilmoittaminen, auditointioikeudet, tietoturvaliite, DORA-yhdenmukaiset kyselyt soveltuvin osin |
| Jäännösriskipäätös | Riskinomistaja hyväksynyt käsittelyn jälkeen, katselmoidaan neljännesvuosittain |
Päivitä sen jälkeen soveltuvuuslausunto. Selitä jokaisen olennaisen liitteen A kontrollin osalta, miksi sitä sovelletaan ja mitä NIS2-teemaa se tukee. Kerää lopuksi näyttö ennen auditointia: MFA:n toteutusta koskevat raportit, etuoikeutettujen tilien luettelot, lokien säilytysasetukset, RMM-paikkaustila, SIEM-hälytykset, poikkeamien luokittelutallenteet, toimittajapääsyn hyväksynnät ja pöytäharjoitusten tulokset.
Miten eri auditoijat testaavat samaa kontrolliympäristöä
Integroidun ISMS:n tulee täyttää eri varmennusnäkökulmat ilman erillisten näyttöpakettien luomista jokaista viitekehystä varten.
| Auditoijan näkökulma | Mihin he keskittyvät | Tyypillisesti pyydetty näyttö |
|---|---|---|
| ISO/IEC 27001:2022 -auditoija | Näkyvätkö NIS2-, DORA- ja GDPR-vaatimukset toimintaympäristössä, soveltamisalassa, riskien arvioinnissa, SoA:ssa, sisäisessä auditoinnissa ja johdon katselmoinnissa | ISMS:n soveltamisala, sidosryhmärekisteri, riskimenetelmä, riskirekisteri, SoA, käsittelysuunnitelma, politiikat, sisäisen auditoinnin raportti, johdon katselmointi |
| NIS2-toimivaltainen viranomainen tai delegoitu arvioija | Ovatko kyberturvallisuuden riskienhallintatoimenpiteet asianmukaisia ja oikeasuhteisia ja onko merkittävien poikkeamien ilmoittaminen operatiivista | NIS2-kartoitus, poikkeamien luokittelumenettely, 24 ja 72 tunnin työnkulku, hallituksen valvonta, teknisten kontrollien näyttö, toimittajaturvallisuuden näyttö |
| DORA-asiakkaan arvioija | Täyttävätkö ICT-kolmansien osapuolten riski, häiriönsietokyvyn testaus, poikkeamien ilmoittaminen, auditointioikeudet ja exit-suunnittelu finanssialan odotukset | Sopimuslausekkeet, alihankkijarekisteri, häiriönsietokykytestit, poikkeamien SLA:t, exit-suunnitelma, auditointiraportit, tuki keskittymäriskin arviointiin |
| GDPR-auditoija tai DPO-katselmointi | Onko henkilötietojen tietoturvaloukkauksen riski, käsittelijävelvoitteet, luottamuksellisuus, eheys ja osoitusvelvollisuus käsitelty | Käsittelytoimien seloste, DPA-ehdot, loukkauksen arviointityönkulku, käyttölokit, salausnäyttö, säilytys- ja poistokontrollit |
| NIST-suuntautunut arvioija | Onko identify-, protect-, detect-, respond- ja recover-kyvykkyydet toteutettu ja mitattu | Omaisuusluettelo, pääsynhallintakontrollit, haavoittuvuustiedot, SIEM-kattavuus, reagoinnin toimintapelikirjat, palautustestit, mittarit |
| COBIT 2019- tai ISACA-auditoija | Onko hallinnointitavoitteet, vastuut, riskinomistajuus, kontrollien valvonta ja varmennusprosessit määritetty | Hallinnointimandaatit, RACI, riskinottohalukkuus, kontrollinomistajuus, KPI/KRI-raportointi, varmennussuunnitelma, korjaavien toimenpiteiden seuranta |
Tässä Zenith Controls auttaa poikkivaatimustenmukaisuuden oppaana. Kontrolleissa kuten 5.23, 5.24 ja 8.8 se yhdistää ISO/IEC 27001:2022 -kontrolliodotukset NIS2-, GDPR-, DORA-, NIST SP 800-53-, COBIT 2019-, NIST CSF- ja ISO 22301 -teemoihin. Tavoitteena ei ole luoda erillisiä vaatimustenmukaisuusohjelmia. Tavoitteena on yksi näyttöarkkitehtuuri, joka on merkitty kontrollin, riskin, sääntelyajurin ja omistajan mukaan.
Clarysecin toteutusmalli
Pilvipalvelujen tarjoajien, MSP-, MSSP- ja konesalipalvelujen tarjoajien työn tulisi edetä viidessä kerroksessa.
Ensiksi vahvista soveltamisala. Määritä, kuuluvatko organisaatio ja palvelut NIS2:n soveltamisalaan, mitkä jäsenvaltion säännöt soveltuvat, sovelletaanko täytäntöönpanoasetusta 2024/2690 kyseiseen palveluntarjoajaluokkaan ja asettavatko asiakkaat DORA-, GDPR-, NIST- tai toimialakohtaisia velvoitteita.
Toiseksi rakenna ISMS:n toimintaympäristö. ISO/IEC 27001:2022 -standardin kohtien 4 ja 5 mukaisesti tunnista sidosryhmät, lakisääteiset velvoitteet, asiakassitoumukset, toimittajariippuvuudet, palvelurajat ja johdon vastuut.
Kolmanneksi tee riskien arviointi ja käsittely ISO/IEC 27005:2022 -periaatteiden mukaisesti. Yhdistä NIS2, DORA, GDPR, sopimukset, sisäiset politiikat ja palveluriskit yhdeksi perustason vaatimusrekisteriksi. Määritä riskikriteerit, omistajat, todennäköisyys, vaikutus, käsittelyvaihtoehdot, kontrollivalinnat ja jäännösriskin hyväksynnät.
Neljänneksi kartoita kontrollit soveltuvuuslausuntoon. Käytä Zenith Blueprint -vaiheita 13 ja 14 jäljittääksesi riskit liitteen A kontrolleihin ja sääntelyodotuksiin. Käytä Zenith Controls -opasta ymmärtääksesi, miten kontrollit kuten 5.23, 5.24, 8.8, 5.20 ja 5.30 karttuvat eri viitekehyksiin ja auditointinäkökulmiin.
Viidenneksi operoi näyttö. Politiikat eivät riitä. Clarysecin politiikkakirjasto tarjoaa täytäntöönpantavia vaatimuksia pilvikäytön hyväksynnälle, toimittajapääsylle, lokitukselle, haavoittuvuuksien korjaaville toimenpiteille, verkon segmentoinnille, poikkeamien luokittelulle ja jatkuvuussuunnittelulle. Näyttöpaketti osoittaa, että nämä vaatimukset toimivat.
Seuraava askel: muuta NIS2-paine auditointivalmiiksi häiriönsietokyvyksi
NIS2-täytäntöönpanoasetus 2024/2690 ei edellytä kaaosta. Se edellyttää jäljitettävyyttä, omistajuutta ja näyttöä.
Jos olet pilvipalveluntarjoaja, MSP, MSSP tai konesalioperaattori, aloita palveluista, asiakkaista, riippuvuuksista, poikkeamaskenaarioista ja näyttövelvoitteista. Suorita sen jälkeen jäsennelty NIS2–ISO/IEC 27001:2022 -kartoitus:
- Vahvista, kuuluvatko toimijasi ja palvelusi soveltamisalaan.
- Kartoita NIS2:n ja täytäntöönpanoasetuksen teemat ISMS:n soveltamisalaan.
- Päivitä riskirekisteri ja soveltuvuuslausunto.
- Sovella Clarysecin politiikkoja pilvikäyttöön, toimittajaturvallisuuteen, lokitukseen, haavoittuvuuksien hallintaan, tietoturvapoikkeamiin reagointiin, verkkoturvallisuuteen ja jatkuvuuteen.
- Käytä Zenith Blueprint Zenith Blueprint -vaiheita 13, 14, 20 ja 23 jäljitettävyyden ja operatiivisen näytön luomiseen.
- Käytä Zenith Controls Zenith Controls -opasta ristiinkartoittaaksesi ISO/IEC 27001:2022 -kontrollit NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -odotuksiin.
- Testaa näyttö auditointisimulaatiolla ennen kuin asiakas, viranomainen tai sertifiointiauditoija pyytää sitä.
Clarysec voi auttaa sinua siirtymään tarkistuslistapohjaisesta vaatimustenmukaisuudesta integroituun ISMS:ään, joka kestää NIS2-, DORA-, GDPR- ja asiakasauditointipaineen. Lataa soveltuvat Clarysec-työkalupaketit, varaa kartoitustyöpaja tai pyydä arviointia auditointivalmiudesta, jotta sääntelyn monimutkaisuus muuttuu perusteltavissa olevaksi tietoturvan hallinnoinniksi ja operatiiviseksi häiriönsietokyvyksi.
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
