CVD NIS2:n ja DORA:n vaatimuksiin: ISO 27001 -näyttökartta

Tiistaina kello 08.17 tietoturvapostilaatikkoon saapuu viesti riippumattomalta tutkijalta. Aihekenttä on rauhallinen, lähes kohtelias: ”Mahdollinen tilin kaappaus asiakasportaalissanne.” Viestin sisältö on epämukavampi. Tutkija väittää, että SaaS-sovelluksenne ketjutettu haavoittuvuus mahdollistaa yhden tenantin pääsyn toisen tenantin laskutustietoihin. Mukana on PoC, joka on salattu julkaisemallanne PGP-avaimella.

FinanTechSaaS:n uudelle tietoturvajohtajalle Marialle ajoitus on mahdollisimman huono. Yritys on juuri allekirjoittanut merkittävän sopimuksen johtavan EU-pankin kanssa. Asiakkaan toimittajan huolellisuusarviointia tekevä tiimi on jo pyytänyt ”haavoittuvuuksien koordinoidun julkistamisen politiikkaa” ja näyttöä sen toteutuksesta viitaten nimenomaisesti NIS2:een ja DORA:an. Yrityksellä on security@-sähköpostiosoite, mutta sitä valvoo yksi kehittäjä. Muodollista vastaanottorekisteriä ei ole, validoinnille ei ole määriteltyä palvelutasoa, johdon eskalointipolkua ei ole eikä auditointijälkeä synny.

Kolme kelloa käynnistyy samanaikaisesti.

Ensimmäinen kello on operatiivinen. Onko haavoittuvuus todellinen? Onko se hyväksikäytettävissä tuotannossa? Käyttääkö joku sitä aktiivisesti väärin?

Toinen kello liittyy sääntelyyn. Jos asiakastietoja on altistunut, GDPR:n mukainen henkilötietojen tietoturvaloukkauksen arviointi alkaa. Jos palvelun tuottamiseen kohdistuu vaikutuksia NIS2:n mukaiselle keskeiselle tai tärkeälle toimijalle, poikkeamien raportointikynnykset voivat täyttyä. Jos yritys on finanssialan toimija tai finanssipalveluja tukeva ICT-palveluntarjoaja, DORA:n poikkeamien hallintaa, luokittelua, eskalointia ja asiakasviestintää koskevat säännöt voivat tulla sovellettaviksi.

Kolmas kello koskee näyttöä. Kuuden kuukauden kuluttua ISO/IEC 27001:2022 -auditoija, finanssialan valvoja, asiakkaan varmennustiimi tai sisäinen auditointikomitea voi kysyä: ”Näyttäkää, miten tämä haavoittuvuus käsiteltiin.”

Tuo kysymys on kohta, jossa moni organisaatio huomaa, ettei haavoittuvuuksien koordinoitu julkistaminen ole pelkkä tietoturvapostilaatikko. Se on hallintamalli. Se edellyttää politiikan omistajuutta, julkista ilmoituskanavaa, luokittelu- ja priorisointityönkulkua, korjaamisen palvelutasoja, toimittajaeskalointia, poikkeamapäätöksen logiikkaa, tietosuojatarkastelua, johdon raportointia ja puolustettavissa olevaa näyttöä.

Clarysec käsittelee CVD:tä integroituna kontrollimallina, ei erillisenä postilaatikkona. Zenith Blueprint: An Auditor’s 30-Step Roadmap -julkaisussa Zenith Blueprint haavoittuvuuksien käsittely sijoittuu Controls in Action -vaiheeseen, vaiheeseen 19: Technological Controls I, jossa ohje on selkeä: organisaatioiden ei tule arkistoida haavoittuvuushavaintoja passiivisesti, vaan ne tulee luokitella, osoittaa vastuuhenkilöille ja seurata sulkemiseen saakka. Sama vaatimus koskee ulkoisia ilmoituksia. Jos joku kertoo, miten palvelunne voi epäonnistua, todellinen kysymys on: pystyttekö osoittamaan, että vastaanotitte, arvioitte, priorisoitte, korjasitte, viestitte ja opitte siitä?

Miksi CVD on nyt hallitustason kysymys NIS2:n ja DORA:n piirissä

Tietoturvatietoiset organisaatiot ovat vuosien ajan kutsuneet eettisiä hakkereita ilmoittamaan haavoittuvuuksista, koska se on ollut hyvä käytäntö. NIS2:n ja DORA:n myötä käytännöstä on tullut osa säänneltyä digitaalista häiriönsietokykyä.

NIS2 koskee monia keskisuuria ja suurempia toimijoita erittäin kriittisillä ja muilla kriittisillä sektoreilla, mukaan lukien digitaalisen infrastruktuurin tarjoajat, pilvipalvelujen tarjoajat, datakeskuspalvelujen tarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat sekä tietyt digitaaliset palveluntarjoajat, kuten verkkomarkkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat. Sitä voidaan soveltaa koosta riippumatta myös esimerkiksi luottamuspalvelujen tarjoajiin, DNS-palveluntarjoajiin, TLD-rekistereihin sekä yleisten sähköisten viestintäverkkojen tai -palvelujen tarjoajiin.

NIS2 Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset ja oikeasuhteiset tekniset, operatiiviset ja organisatoriset kyberturvallisuuden riskienhallintatoimenpiteet kaikkia uhkia koskevan lähestymistavan mukaisesti. Yksi vähimmäisalueista on verkko- ja tietojärjestelmien hankinnan, kehittämisen ja ylläpidon tietoturva, mukaan lukien haavoittuvuuksien käsittely ja julkistaminen. Sama perustaso kattaa myös poikkeamien käsittelyn, toimitusketjun tietoturvan, liiketoiminnan jatkuvuuden, pääsynhallinnan, omaisuudenhallinnan, koulutuksen, kryptografian sekä menettelyt kontrollien tehokkuuden arviointiin.

NIS2 Article 20 selkeyttää myös johdon vastuun. Hallintoelinten on hyväksyttävä kyberturvallisuuden riskienhallintatoimenpiteet, valvottava niiden toteutusta ja osallistuttava koulutukseen. CVD-ohjelman osalta tämä tarkoittaa, että hallituksen tai ylimmän johdon tulee ymmärtää ilmoituskanava, haavoittuvuuksiin reagointitiimi, validoinnin määräajat, korjausodotukset, toimittajariippuvuudet ja poikkeamien raportoinnin käynnistävät tekijät.

DORA luo finanssialan toimijoille sektorikohtaisen sääntelykehyksen 17. tammikuuta 2025 alkaen. Se kattaa ICT-riskien hallinnan, ICT:hen liittyvien poikkeamien raportoinnin, digitaalisen operatiivisen häiriönsietokyvyn testauksen, tietojenvaihdon, ICT-kolmansien osapuolten riskin, sopimusvaatimukset, kriittisten ICT-kolmansien osapuolten palveluntarjoajien valvonnan ja viranomaisyhteistyön. DORA:n piiriin kuuluvien finanssialan toimijoiden osalta DORA on yleensä ensisijainen NIS2:een nähden ICT-riskien hallinnassa ja poikkeamien raportoinnissa, koska se on sektorikohtainen unionin säädös. Käytännön vaatimus pysyy kuitenkin samana: finanssialan toimijoiden ja niitä palvelevien ICT-palveluntarjoajien on ylläpidettävä rakenteista, dokumentoitua ja testattavaa prosessia ICT-heikkouksien tunnistamiseen, analysointiin, luokitteluun, eskalointiin, korjaamiseen ja niistä oppimiseen.

Haavoittuvuusraportti voi alkaa teknisenä havaintona, muuttua tietoturvatapahtumaksi, eskaloitua poikkeamaksi, käynnistää GDPR:n mukaisen henkilötietojen tietoturvaloukkauksen arvioinnin, edellyttää toimittajan toimenpiteitä ja myöhemmin näkyä ISO/IEC 27001:2022 -standardin soveltuvuuslausunnossa. Siksi CVD tulee suunnitella yhtenä toimintamallina, joka kattaa tietoturvan, vaatimustenmukaisuuden, tuotekehityksen, lakiasiat, tietosuojan, hankinnan ja johdon.

ISO 27001 -perusta: julkistamisesta ISMS-näyttöön

ISO/IEC 27001:2022 antaa tietoturvajohtajille ja vaatimustenmukaisuudesta vastaaville johtajille hallintajärjestelmän, jonka avulla CVD:stä tulee auditoitavissa oleva prosessi.

Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset asiat, sidosryhmien vaatimukset, ISMS:n rajat ja riippuvuudet muihin organisaatioihin. Tässä NIS2, DORA, GDPR, asiakassopimukset, toimittajavelvoitteet ja haavoittuvuuksien julkistamiseen liittyvät sitoumukset tuodaan ISMS:ään.

Kohdat 5.1–5.3 luovat johdon vastuun. Ylimmän johdon on sovitettava tietoturvallisuus strategiseen suuntaan, osoitettava resurssit, määritettävä vastuut ja varmistettava, että ISMS saavuttaa sille tarkoitetut tulokset. CVD:n osalta tämä tarkoittaa haavoittuvuuksiin reagointitiimin nimeämistä, toimivallan määrittämistä jäännösriskin hyväksymiseen sekä merkittävän vaikutuksen haavoittuvuuksien eskalointia johdolle.

Kohdat 6.1.1–6.1.3 muodostavat riskimoottorin. Organisaation on määriteltävä riskikriteerit, arvioitava tietoturvariskit, nimettävä riskinomistajat, valittava riskien käsittelyvaihtoehdot, verrattava kontrolleja liitteeseen A, laadittava soveltuvuuslausunto ja hankittava hyväksyntä jäännösriskille. Kohdat 8.1–8.3 edellyttävät tämän jälkeen operatiivista ohjausta, suunniteltuja muutoksia, ulkoistettujen prosessien ohjausta, riskien arviointeja suunnitelluin väliajoin tai merkittävien muutosten jälkeen sekä näyttöä riskien käsittelyn tuloksista.

Zenith Blueprint -julkaisun Risk Management -vaiheen vaiheessa 13 soveltuvuuslausunto kuvataan muuksi kuin vaatimustenmukaisuuden laskentataulukoksi:

”SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja riskien käsittelyn käytössä oleviin todellisiin kontrolleihin.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management -vaihe, vaihe 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Haavoittuvuuksien koordinoidussa julkistamisessa SoA:n tulee yhdistää sääntelyvelvoitteet, liiketoimintariski, liitteen A kontrollit, politiikkakirjaukset ja operatiivinen näyttö.

Tavoitteena ei ole luoda rinnakkaisia vaatimustenmukaisuussiiloja. CVD-politiikan tulee olla ISMS:n ohjaama prosessi, joka tukee samanaikaisesti ISO/IEC 27001:2022 -sertifiointia, NIS2:n noudattamista, DORA-valmiutta, asiakasvarmennusta ja tietoturvaoperaatioita.

Politiikan perustaso: mitä CVD-politiikan on sanottava

Ensimmäinen näkyvä kontrolli on julkinen ilmoituskanava. Tutkijoiden, asiakkaiden, toimittajien ja kumppanien on tiedettävä, minne haavoittuvuuksista ilmoitetaan ja miten arkaluonteinen näyttö suojataan.

Clarysecin Haavoittuvuuksien koordinoidun julkistamisen politiikka Haavoittuvuuksien koordinoidun julkistamisen politiikka tarjoaa yritystason perustason:

”Julkiset julkistuskanavat: Organisaation tulee ylläpitää selkeää kanavaa haavoittuvuuksien ilmoittamiseen, kuten erillistä tietoturvayhteydenoton sähköpostiosoitetta (esimerkiksi security@company.com) tai verkkolomaketta. Nämä tiedot tulee julkaista yrityksen verkkosivuston tietoturvasivulla yhdessä organisaation julkisen PGP-avaimen kanssa salattujen lähetysten mahdollistamiseksi.”
Lähde: Haavoittuvuuksien koordinoidun julkistamisen politiikka, toteutusvaatimukset, lauseke 6.1

Tämä lauseke ratkaisee yleisen auditointipuutteen. Monet organisaatiot väittävät vastaanottavansa ilmoituksia, mutta ilmoitusreitti on piilotettu, salaamaton tai väärän tiimin omistuksessa. Kypsä kanava on julkinen, turvallinen, valvottu ja osoitettu vastuulliselle toiminnolle.

Seuraava kontrolli on reagointikuri. Kriittinen ilmoitus, jota seuraa hiljaisuus, luo julkistamisriskin, maineriskin ja hyväksikäyttöriskin. Haavoittuvuuksien koordinoidun julkistamisen politiikka asettaa konkreettisen kuittauksen ja validoinnin odotuksen:

”Luokittelu ja kuittaus: Raportin vastaanottamisen jälkeen VRT:n tulee kirjata se ja lähettää ilmoittajalle kuittaus 2 arkipäivän kuluessa sekä antaa seurantaviite. VRT:n tulee tehdä alustava vakavuusarviointi, esimerkiksi CVSS-pisteytyksellä, ja validoida ongelma tarvittaessa IT- ja kehitystiimien tuella tavoiteajassa, joka on 5 arkipäivää. Kriittiset haavoittuvuudet, kuten etäkoodin suorittamisen tai merkittävän henkilötietojen tietoturvaloukkauksen mahdollistavat haavoittuvuudet, tulee käsitellä nopeutetusti.”
Lähde: Haavoittuvuuksien koordinoidun julkistamisen politiikka, toteutusvaatimukset, lauseke 6.4

Tämä sanamuoto luo välittömät näyttöpisteet: vastaanottoaika, kuittausaika, seurantaviite, alustava vakavuus, validoinnin tulos ja päätös nopeutetusta käsittelystä.

Pk-yrityksissä Clarysec käyttää samaa logiikkaa oikeasuhtaisella toteutuksella. Sovellusturvallisuusvaatimusten politiikka - pk-yritys Sovellusturvallisuusvaatimusten politiikka - SME edellyttää organisaatioita:

”määrittämään velvoitteet haavoittuvuuksien julkistamiselle, vasteajoille ja paikkaukselle.”
Lähde: Sovellusturvallisuusvaatimusten politiikka - pk-yritys, hallinnointivaatimukset, lauseke 5.3.2

Vastuullisuus ei edellytä suurta tuoteturvallisuustiimiä. Se edellyttää nimenomaisia velvoitteita, realistisia määräaikoja, nimettyjä omistajia ja näyttöä siitä, että prosessi toimii.

CVD-vastaanoton työnkulku: tutkijan sähköpostista päätöstallenteeseen

Hyvä vastaanoton työnkulku on riittävän yksinkertainen paineen alla toteutettavaksi ja riittävän kattava auditoijan tarpeisiin. Sen tulee alkaa erillisestä kanavasta, kuten security@[company], verkkolomakkeesta tai julkaistusta security.txt-tiedostosta. Lähetysreitin tulee mahdollistaa salattu näyttö, vaikutuksen kohteena oleva tuote tai päätepiste, toistamisvaiheet, ilmoittajan yhteystiedot, toivottu julkistamisen ajoitus sekä mahdollinen tieto tietojen altistumisesta tai aktiivisesta hyväksikäytöstä.

Kun ilmoitus on vastaanotettu, haavoittuvuuksiin reagointitiimin tulee luoda tallenne GRC-työkaluun, tikettijärjestelmään, haavoittuvuuksien hallintajärjestelmään tai ohjattuun rekisteriin. Työkalua tärkeämpää ovat johdonmukaisuus ja näytön laatu.

Työnkulun tulee tämän jälkeen edetä seitsemän operatiivisen vaiheen kautta.

1. Vastaanotto: raportti vastaanotetaan julkisen kanavan kautta ja kirjataan automaattisesti tai manuaalisesti lokiin.
2. Kuittaus: VRT vastaa 2 arkipäivän kuluessa ja antaa seurantaviitteen.
3. Validointi: tekninen tiimi toistaa ongelman, vahvistaa vaikutuksen kohteena olevat järjestelmät ja tekee alustavan vakavuuspisteytyksen.
4. Tapahtuman arviointi: VRT määrittää, onko haavoittuvuus vain heikkous, tietoturvatapahtuma vai poikkeama.
5. Eskalointi: korkean tai kriittisen vakavuuden asiat toimitetaan tarpeen mukaan järjestelmäomistajille, tietoturvajohtajalle, tietosuojalle, lakiasioille, toimittajille ja johdolle.
6. Korjaaminen: vastuullinen tiimi toteuttaa korjauksen, lieventämistoimenpiteen, korvaavan kontrollin tai tilapäisen rajoituksen.
7. Sulkeminen: VRT varmistaa korjauksen, viestii ilmoittajan kanssa, päivittää näyttöaineiston ja kirjaa opit.

Clarysec kartoittaa tämän operatiivisen vaiheen ISO/IEC 27002:2022 -standardin kontrolliin A.5.25, tietoturvatapahtumien arviointi ja päätöksenteko, sekä kontrolliin A.8.8, teknisten haavoittuvuuksien hallinta, Zenith Controls: The Cross-Compliance Guide -julkaisun Zenith Controls kautta. Kontrollin A.5.25 osalta Zenith Controls selittää, että tapahtumien arviointi on luokittelu- ja priorisointitoiminto raakojen valvontahälytysten ja muodollisen poikkeamien käsittelyn välillä. Siinä käytetään lokeja, kynnysarvoja ja päätöskriteereitä eskaloinnin määrittämiseen. Kontrollin A.8.8 osalta Zenith Controls yhdistää teknisten haavoittuvuuksien hallinnan haittaohjelmasuojaukseen, konfiguraationhallintaan, muutoksenhallintaan, päätelaiteturvallisuuteen, uhkatiedusteluun, valvontaan, turvalliseen kehitykseen, tapahtumien arviointiin ja tietoturvapoikkeamiin reagointiin.

Yksi Zenith Controls -katkelma on erityisen hyödyllinen, kun epäillään aktiivista hyväksikäyttöä:

”Uhkatiedustelu kertoo, mitä haavoittuvuuksia hyödynnetään aktiivisesti, ja ohjaa korjauspäivitysten priorisointia.”
Lähde: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 -kontrolli 8.8, yhteys kontrolliin 5.7 Threat Intelligence Zenith Controls

Tämä on tärkeä hallinnointikysymys. Vakavuus ei ole pelkkä CVSS. Keskitasoiseksi pisteytetty haavoittuvuus, jota hyödynnetään aktiivisesti toimialaanne vastaan, voi olla kiireellisempi kuin teoreettinen kriittinen ongelma testijärjestelmässä, joka ei ole ulkoisesti altistunut.

Milloin haavoittuvuudesta tulee poikkeama

Kaikki haavoittuvuusraportit eivät ole poikkeamia. Puuttuva tietoturvaotsake staging-ympäristössä ei ole sama asia kuin hyväksikäytetty valtuutuksen ohitus, joka altistaa asiakkaiden laskut. Jokaisen uskottavan haavoittuvuusraportin tulee kuitenkin kulkea poikkeamapäätöksen portin kautta.

NIS2 Article 23 edellyttää, että keskeiset ja tärkeät toimijat ilmoittavat ilman aiheetonta viivytystä CSIRT-yksikölleen tai toimivaltaiselle viranomaiselle poikkeamista, joilla on merkittävä vaikutus palvelun tuottamiseen. Merkittävä poikkeama on poikkeama, joka on aiheuttanut tai voi aiheuttaa vakavan operatiivisen häiriön tai taloudellisen tappion tai joka on vaikuttanut tai voi vaikuttaa muihin aiheuttamalla huomattavaa aineellista tai aineetonta vahinkoa. Raportointijaksoon sisältyy varhaisvaroitus 24 tunnin kuluessa tietoisuuteen tulemisesta, poikkeamailmoitus 72 tunnin kuluessa, väliraportit pyydettäessä sekä loppuraportti kuukauden kuluessa 72 tunnin ilmoituksesta.

DORA Article 17–20 edellyttävät, että finanssialan toimijat havaitsevat, hallitsevat, kirjaavat, luokittelevat, eskaloivat, ilmoittavat ja viestivät ICT:hen liittyvistä poikkeamista ja merkittävistä kyberuhista. Merkittävät ICT:hen liittyvät poikkeamat on eskaloitava ylimmälle johdolle ja hallintoelimelle. Asiakasviestintä voi olla tarpeen, kun asiakkaiden taloudellisiin etuihin kohdistuu vaikutuksia.

Pk-yrityksissä raportointikulttuurin on oltava yhtä selkeä. Clarysecin Tietoturvapoikkeamien hallintapolitiikka - pk-yritys Tietoturvapoikkeamien hallintapolitiikka - SME toteaa:

”Henkilöstön on ilmoitettava kaikesta epäilyttävästä toiminnasta tai vahvistetusta poikkeamasta osoitteeseen incident@[company] tai suullisesti toimitusjohtajalle tai IT-palveluntarjoajalle.”
Lähde: Tietoturvapoikkeamien hallintapolitiikka - pk-yritys, politiikan toteutusvaatimukset, lauseke 6.2.1

Zenith Blueprint -julkaisun Controls in Action -vaiheen vaiheessa 16: People Controls II periaate on vielä yksinkertaisempi:

”Jos olet epävarma, ilmoita.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action -vaihe, vaihe 16: People Controls II (A.6.5 to A.6.8)

Tämän periaatteen tulee koskea kehittäjiä, tukitiimejä, toimittajavastaavia, tietosuojavastaavia, ylintä johtoa ja ulkoistettuja palveluntarjoajia. Haavoittuvuus, joka voi vaikuttaa luottamuksellisuuteen, eheyteen, saatavuuteen, asiakkaiden luottamukseen, sääntelyraportointiin tai finanssialan toimintaan, tulee kirjata ja arvioida, ei käsitellä epämuodollisesti chatissa.

Korjaaminen, paikkaus ja korvaavat kontrollit

Kun haavoittuvuus on validoitu, se on käsiteltävä. Käsittelyn tulee olla riskiperusteista, näyttöön perustuvaa ja määräaikaista.

Haavoittuvuuksien koordinoidun julkistamisen politiikka asettaa yritystason odotuksen:

”Korjaussuunnitelma: Kaikille vahvistetuille haavoittuvuuksille on laadittava korjaus- tai lieventämissuunnitelma. Korjauksen toteutus on priorisoitava vakavuuden perusteella. Esimerkiksi kriittiset haavoittuvuudet tulee korjata tai lieventää 14 päivän kuluessa, kun se on toteutettavissa, tai nopeammin, jos aktiivista hyväksikäyttöä havaitaan. Matalamman vakavuuden asiat tulee käsitellä kohtuullisessa ajassa. Jos täysi korjaus viivästyy, on toteutettava korvaavat kontrollit tai tilapäiset lieventämistoimenpiteet, kuten haavoittuvan toiminnallisuuden poistaminen käytöstä tai valvonnan lisääminen.”
Lähde: Haavoittuvuuksien koordinoidun julkistamisen politiikka, toteutusvaatimukset, lauseke 6.6

Pk-yritysten paikkauskuria varten Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - SME toteaa:

”Kriittiset korjauspäivitykset on asennettava 3 päivän kuluessa julkaisusta, erityisesti internetiin avautuviin järjestelmiin”
Lähde: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys, politiikan toteutusvaatimukset, lauseke 6.1.1

Nämä määräajat eivät ole ristiriidassa. Internetiin avautuvan järjestelmän toimittajakorjaus voi edellyttää erittäin nopeaa käyttöönottoa. Tuotehaavoittuvuus, joka vaatii koodimuutoksia, regressiotestausta, asiakaskoordinointia ja vaiheittaista julkaisua, voi edellyttää korjaussuunnitelmaa ja väliaikaisia lieventämistoimia. Olennaista on, että päätös dokumentoidaan, riskillä on omistaja ja hyväksyntä hankitaan, kun jäännösriskiä jää.

Käytännön tapaus etenee esimerkiksi näin:

1. Tutkija ilmoittaa valtuutuksen ohituksesta asiakkaiden laskutusrajapinnassa.
2. VRT kirjaa CVD-2026-014:n aikaleiman kanssa ja lähettää kuittauksen 2 arkipäivän kuluessa.
3. Tuoteturvallisuus validoi virheen 24 tunnissa ja määrittää vakavuudeksi korkean, koska kyse on tenanttien välisestä tietopääsystä.
4. Tietosuoja tekee GDPR:n mukaisen tietoturvaloukkauksen arvioinnin, koska laskutustiedot voivat sisältää henkilötietoja.
5. Poikkeamapäällikkö avaa tapahtuman arvioinnin ISO/IEC 27002:2022 -standardin kontrollin A.5.25 mukaisesti.
6. Järjestelmäomistaja poistaa haavoittuvan päätepisteen käytöstä tilapäisellä ominaisuuslipulla.
7. Kehitystiimi luo pikakorjauksen ISO/IEC 27002:2022 -standardin kontrollin A.8.32, muutoksenhallinta, mukaisesti.
8. Hyväksikäyttöindikaattoreille lisätään valvontasäännöt, jotka liitetään kontrolliin A.8.15, lokitus, ja A.8.16, valvontatoiminnot.
9. Tietoturvajohtaja informoi ylintä johtoa, koska asia on korkeariskinen.
10. VRT koordinoi tutkijan kanssa uudelleentestausta ja julkistamisen ajoitusta.
11. Riskinomistaja hyväksyy sulkemisen vasta varmennustestauksen ja asiakasvaikutusten tarkastelun jälkeen.
12. SoA, riskirekisteri, tiketti, lokit, johdon ilmoitus ja opit päivitetään.

Tämä erottaa toisistaan väitteet ”korjasimme sen” ja ”pystymme osoittamaan, että hallinnoimme sen asianmukaisesti”.

Toimittaja- ja pilviriippuvuudet: piilevä epäonnistumiskohta

Monet CVD-epäonnistumiset ovat todellisuudessa toimittajaepäonnistumisia. Haavoittuvuus voi koskea SaaS-komponenttia, pilvipalvelua, hallinnoitua tietoturvapalveluntarjoajaa, maksuväylää, tunnistautumisen välittäjää, avoimen lähdekoodin kirjastoa, ulkoistettua kehitystiimiä tai alihankkijaa.

NIS2 Article 21 edellyttää toimitusketjun tietoturvaa, mukaan lukien suhteet suoriin toimittajiin ja palveluntarjoajiin. Toimitusketjutoimenpiteissä tulee huomioida toimittajien haavoittuvuudet, tuotteiden laatu, kyberturvallisuuskäytännöt ja turvallisen kehityksen menettelyt.

DORA Article 28–30 menevät finanssialan toimijoiden osalta pidemmälle. Ne edellyttävät, että ICT-kolmannen osapuolen riskiä hallitaan osana ICT-riskikehystä. Tämä sisältää ICT-palvelusopimusten rekisterit, kriittisten tai tärkeiden toimintojen erottelun, sopimusta edeltävän huolellisuuden, sopimusperusteiset tietoturvavaatimukset, poikkeama-avun, yhteistyön viranomaisten kanssa, auditointioikeudet, irtisanomisoikeudet ja exit-strategiat. Finanssialan toimijat pysyvät täysin vastuussa DORA-vaatimustenmukaisuudesta myös käyttäessään ICT-kolmansien osapuolten palveluntarjoajia.

Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - SME sisältää yksinkertaisen eskalointisäännön:

”Toimitusjohtajalle on ilmoitettava välittömästi kaikista tietoturvaloukkauksista, muutoksista tai poikkeamista”
Lähde: Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, roolit ja vastuut, lauseke 4.4.3

Yritystason toimittajasopimusten osalta Zenith Blueprint, Controls in Action -vaihe, vaihe 23, suosittelee sisällyttämään sopimuksiin luottamuksellisuusvelvoitteet, pääsynhallinnan vastuut, tekniset ja organisatoriset toimenpiteet, poikkeamien ilmoitusmääräajat, tarkastusoikeudet, alihankkijakontrollit ja sopimuksen päättymistä koskevat ehdot. Siinä todetaan:

”Olennaista on, että ne ovat olemassa ja että molemmat osapuolet ymmärtävät ja hyväksyvät ne.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action -vaihe, vaihe 23: Organizational controls (5.19 to 5.37)

CVD:n toimittajavalmiuden tulee vastata seuraaviin kysymyksiin:

• Julkaiseeko toimittaja haavoittuvuuksien ilmoituskanavan?
• Onko haavoittuvuuksista ilmoittamisen määräajat määritelty sopimuksessa?
• Ilmoitetaanko kriittiset toimittajahaavoittuvuudet ilman aiheetonta viivytystä?
• Liittyvätkö asiakkaisiin vaikuttavat heikkoudet poikkeama-avun velvoitteisiin?
• Voiko toimittaja toimittaa korjausnäyttöä tai tietoturvatiedotteita?
• Onko alihankkijoille asetettu vastaavat haavoittuvuusvelvoitteet?
• Onko exit-strategia olemassa, jos korjaaminen ei ole riittävää?

Tässä NIS2, DORA ja ISO/IEC 27001:2022 kohtaavat. Toimittajien haavoittuvuuksien hallinta ei ole hankinnan valintaruutu. Se on osa operatiivista häiriönsietokykyä.

Näyttökartoitus ISO 27001:lle, NIS2:lle, DORA:lle, GDPR:lle ja COBITille

Vahvimmat CVD-ohjelmat suunnitellaan näyttö edellä. Ne olettavat, että merkittävä raportti voidaan myöhemmin tarkastella sisäisessä auditoinnissa, sertifiointiauditoinnissa, viranomaisvalvonnassa, asiakasarvioinnissa, vakuutusarvioinnissa tai hallituksen riskikomiteassa.

Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - SME nostaa esiin yksityiskohdan, jonka moni tiimi ohittaa:

”Metatiedot (esim. kuka keräsi ne, milloin ja mistä järjestelmästä) on dokumentoitava.”
Lähde: Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys, politiikan toteutusvaatimukset, lauseke 6.2.3

Kuvakaappaus paikatuista palvelimista on heikko näyttö, jos kukaan ei tiedä, kuka sen otti, milloin, mistä järjestelmästä ja miten se liittyy haavoittuvuuteen. Tiketti, jossa on aikaleimat, skannerituloste, pull request, muutoksen hyväksyntä, käyttöönoton lokit, valvontakysely, uudelleentestauksen vahvistus ja metatiedot, on huomattavasti vahvempi.

Yksityiskohtaisempi jäljitettävyysmatriisi auttaa asiakkaiden huolellisuusarvioinneissa ja sisäisessä auditoinnissa.

Eri auditoijat testaavat samaa prosessia eri näkökulmista.

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:stä. Hän kysyy, sisältyvätkö haavoittuvuuksien julkistamista koskevat velvoitteet sidosryhmävaatimuksiin, arvioidaanko riskit johdonmukaisesti, näkyvätkö kontrollit SoA:ssa, onko operatiivista näyttöä olemassa ja katselmoiko johto trendejä ja myöhässä olevia asioita.

DORA- tai finanssipalvelujen arvioija keskittyy operatiiviseen häiriönsietokykyyn. Hän tarkastelee ICT-riskin integrointia, poikkeamien luokittelua, ylimmän johdon eskalointia, asiakasviestintää, kolmansien osapuolten riippuvuuksia, testausta ja oppeja. Jos haavoittuvuus vaikuttaa kriittiseen tai tärkeään toimintoon, hän odottaa tiivistä yhteyttä teknisen tiketin, liiketoimintavaikutuksen, jatkuvuusvaikutusten ja toimittajavelvoitteiden välillä.

GDPR-arvioija keskittyy henkilötietoihin. Oliko henkilötietoja mukana? Oliko kyse luvattomasta pääsystä, katoamisesta, muuttamisesta tai luovuttamisesta? Oliko rekisterinpitäjän ja käsittelijän roolit selkeitä? Arvioitiinko tietoturvaloukkauksen kynnys? Olivatko suojatoimet, kuten salaus, pääsynhallinta, lokitus ja minimointi, merkityksellisiä?

COBIT 2019- tai ISACA-auditoija keskittyy hallinnointiin, osoitusvelvollisuuteen, suorituskykyyn ja varmentamiseen. Hän etsii määriteltyä omistajuutta, mittareita, eskalointia, kontrollitavoitteita, johdon valvontaa ja poikkeusten seurantaa. Myöhässä oleva kriittinen haavoittuvuus ei ole vain tekninen ongelma. Se on hallinnointiongelma, ellei sitä eskaloida muodollisesti ja hyväksytä riskinä.

NIST-lähtöinen arvioija ajattelee Identify-, Protect-, Detect-, Respond- ja Recover-toimintojen kautta. Hän haluaa nähdä omaisuuden omistajuuden, haavoittuvuuksien tunnistamisen, priorisoinnin, suojaavan muutoksen, hyväksikäytön havaitsemisen, reagoinnin koordinoinnin ja palautumisen validoinnin.

Integroidun CVD-mallin etu on, että sama näyttörunko tukee kaikkia näitä katselmointeja.

Kuukausittainen kontrollisilmukka: mittarit, joita johto voi käyttää

CVD ei pääty, kun tiketti suljetaan. Haavoittuvuuksien koordinoidun julkistamisen politiikka edellyttää jatkuvaa lokikatselmointia:

”VRT:n tulee ylläpitää haavoittuvuuksien julkistamislokia, jossa seurataan jokaista raporttia vastaanotosta sulkemiseen. Loki tulee katselmoida kuukausittain, jotta avoimet asiat etenevät ajallaan. Myöhässä olevat asiat on eskaloitava.”
Lähde: Haavoittuvuuksien koordinoidun julkistamisen politiikka, seuranta ja auditointi, lauseke 9.1

Tämä kuukausittainen katselmointi muuttaa haavoittuvuuksien julkistamisen hallitukselle raportoitavaksi hallinnointiprosessiksi. Johto ei tarvitse jokaista teknistä yksityiskohtaa. Se tarvitsee trendin, altistumisen, vastuun ja myöhässä olevan riskin.

Kypsässä Clarysec-toteutuksessa tämä kuukausittainen lokikatselmointi syöttää riskirekisteriä, soveltuvuuslausuntoa, turvallisen kehityksen työjonoa, toimittajakatselmointeja, poikkeamien oppeja, sisäisen auditoinnin suunnitelmaa ja johdon raportointipakettia.

Rakenna prosessi ennen vakavan ilmoituksen saapumista

Huonoin hetki suunnitella haavoittuvuuksien koordinoitu julkistaminen on se, kun tutkija on jo julkaissut heikkoutenne julkisesti tai kriittinen pankkiasiakas on pysäyttänyt käyttöönoton. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST-kehyksen mukaiset häiriönsietokyvyn odotukset ja COBIT 2019 -hallinnointi osoittavat samaan suuntaan: haavoittuvuuksien julkistaminen on suunniteltava, omistettava, testattava, osoitettava näytöllä ja parannettava.

Aloita näillä viidellä toimenpiteellä:

1. Ota käyttöön tai räätälöi Haavoittuvuuksien koordinoidun julkistamisen politiikka.
2. Rakenna vastaanoton sekä luokittelun ja priorisoinnin työnkulku Zenith Blueprint -julkaisun avulla, erityisesti vaihe 13 SoA-jäljitettävyyttä varten, vaihe 16 raportointikulttuuria varten, vaihe 19 teknisten haavoittuvuuksien hallintaa varten ja vaihe 23 toimittajasopimuksia varten.
3. Kartoita työnkulku Zenith Controls -julkaisun kautta keskittyen ISO/IEC 27002:2022 -kontrolleihin A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 ja A.8.32.
4. Lisää pk-yrityksille soveltuvat lausekkeet politiikoista Tietoturvapoikkeamien hallintapolitiikka - pk-yritys, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, Sovellusturvallisuusvaatimusten politiikka - pk-yritys ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys, kun oikeasuhtaisuudella on merkitystä.
5. Toteuta pöytäharjoitus, jossa simuloidaan tutkijan ilmoitus henkilötietoihin ja toimittajan ylläpitämään komponenttiin vaikuttavasta haavoittuvuudesta, ja testaa kuittaus, luokittelu, poikkeaman luokittelu, paikkaus, asiakasviestintä, näytön kerääminen ja johdon eskalointi.

Clarysec voi auttaa muuttamaan tämän toimivaksi CVD-politiikaksi, vastaanottorekisteriksi, ISO/IEC 27001:2022 -näyttökartaksi, NIS2- ja DORA-päätöspuuksi, toimittajaeskalointimalliksi ja auditointia varten valmiiksi kontrollipaketiksi. Tavoite on yksinkertainen: kun seuraava haavoittuvuusraportti saapuu, tiimin ei pidä improvisoida. Sen tulee toimia luottavaisesti, näyttöön perustuen ja hallitusti.