ENISA EUVD 2026: ISO 27001 NIS2:n ja CRA:n tukena

On tiistai vuonna 2026, kello on 08.17. Maria, nopeasti kasvavan fintech-SaaS-alustan tietoturvajohtaja, saa muutaman minuutin sisällä kaksi signaalia. Ensin tietoturvavalvomo julkaisee ENISA EU Vulnerability Database -hälytyksen poikkeamakanavaan. Vaikutuksen alainen komponentti ei ole suoraan osa Marian omaa koodikantaa. Se sijaitsee kolmannen osapuolen todennus-SDK:ssa, joka on upotettu ulkoistetun kehityskumppanin ylläpitämään mobiilisovellukseen.

Tämän jälkeen tietoturvatutkija lähettää julkiseen tietoturvayhteysosoitteeseen sähköpostin otsikolla: “Haavoittuvuuden ilmoittaminen – SaaS-tuotteenne”. Tutkijan mukaan haavoittuvuus voisi tietyissä olosuhteissa paljastaa ei-kriittisiä asiakkaan metatietoja.

Vahvistettua tietomurtoa ei ole. Yksikään asiakas ei ole ilmoittanut haitasta. Skannerin hallintanäkymä ei näytä punaista. Kysymykset tulevat silti välittömästi.

Olemmeko alttiina? Mitkä asiakasrajapinnan palvelut käyttävät SDK:ta? Onko tämä NIS2:n mukainen merkittävä poikkeama, DORA:n mukainen ICT:hen liittyvä poikkeama, GDPR:n mukainen henkilötietojen tietoturvaloukkaus vai Cyber Resilience Act -asetuksen piiriin kuuluva tuoteturvallisuusasia? Tuleeko meidän ilmoittaa toimittajalle, asiakkaalle, toimivaltaiselle viranomaiselle tai ENISA:lle? Tärkeintä on: pystymmekö osoittamaan, milloin tulimme asiasta tietoisiksi?

Tässä kohtaa moni organisaatio huomaa, ettei uhkatiedustelu ole syöteongelma. Se on toimintamalliongelma.

ENISA EUVD:stä tulee käytännön viitepiste EU:n haavoittuvuustiedustelulle, haavoittuvuuksien koordinoidulle julkistamiselle ja tuoteturvallisuuden läpinäkyvyydelle. Tietokanta ei kuitenkaan itsessään kerro Marialle, kuuluuko vaikutuksen alainen palvelu NIS2:n soveltamisalaan, soveltuuko DORA finanssipalvelutoiminnan vuoksi, onko henkilötietojen altistuminen todennäköistä tai käynnistyykö CRA-raportointivalmiuden arviointi. Nämä päätökset on tehtävä hallitussa, dokumentoidussa ja auditoitavassa tietoturvallisuuden hallintajärjestelmässä.

Clarysecin lähestymistapa on tehdä EUVD:stä operatiivinen osa ISO/IEC 27001:2022 -hallintaa, ISO/IEC 27002:2022 -hallintakeinojen toteutusta, politiikkojen omistajuutta ja usean viitekehyksen vaatimustenmukaisuusnäyttöä. Tavoitteena ei ole luoda uutta taulukkoa nimeltä “EUVD-seuranta”. Tavoitteena on rakentaa perusteltavissa oleva haavoittuvuustiedustelun ja raportoinnin malli, joka kestää viranomaiskysymykset, asiakasauditoinnit, ISO 27001 -sertifiointiauditoinnit ja hallituksen katselmoinnin.

Miksi ENISA EUVD muuttaa haavoittuvuuksien hallintaa vuonna 2026

Monet tietoturvatiimit käsittelivät vuosien ajan uhkatiedustelua paikkauksen syötteenä. CVE julkaistaan, skanneri havaitsee altistuksen, operatiivinen tiimi asentaa korjauspäivityksen ja tiketti suljetaan. Tämä malli ei enää riitä EU-sääntelyn piiriin kuuluville organisaatioille.

NIS2 siirtää kyberturvallisuuden riskienhallinnan hallinnoinnin piiriin. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat kyberturvallisuuskoulutusta. Article 21 edellyttää oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, kuten politiikkoja, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, toimitusketjun turvallisuutta, turvallista hankintaa ja ylläpitoa, haavoittuvuuksien käsittelyä ja julkistamista, vaikuttavuuden arviointia, kyberhygieniaa, kryptografiaa, henkilöstöturvallisuutta, pääsynhallintaa, omaisuudenhallintaa sekä tarvittaessa monivaiheista todennusta tai jatkuvaa todennusta.

Article 23 lisää merkittäville poikkeamille vaiheittaisen raportoinnin, mukaan lukien varhaisvaroituksen 24 tunnin kuluessa tietoiseksi tulemisesta, poikkeamailmoituksen 72 tunnin kuluessa ja loppuraportin yhden kuukauden kuluessa. Jos EUVD-hälytys muuttuu hyväksikäytetyksi palveluhäiriöksi, organisaatio tarvitsee näyttöä tietoisuudesta, luokittelusta ja priorisoinnista, vaikutusten arvioinnista, lieventämisestä ja raportointipäätöksistä.

DORA luo rinnakkaisen mutta toimialakohtaisen järjestelmän finanssialan toimijoille. Se edellyttää ICT-riskiä koskevia sisäisiä hallinnointi- ja valvontajärjestelyjä, johtoelimen vastuuvelvollisuutta, poikkeamien hallintaprosesseja, kolmansien osapuolten ICT-riskien hallintaa, testausta, häiriönsietokykyä, sopimuskontrolleja ja merkittävien ICT:hen liittyvien poikkeamien raportointia DORA Article 19:n mukaisesti. Soveltamisalaan kuuluville finanssialan toimijoille DORA toimii ICT-riskin ja poikkeamien raportoinnin toimialakohtaisena viitekehyksenä.

GDPR lisää toisen ulottuvuuden. Jos hyväksikäyttö voisi aiheuttaa henkilötietojen luvattoman pääsyn, paljastumisen, menetyksen, muuttumisen tai tuhoutumisen, haavoittuvuustyönkulun on kytkeydyttävä henkilötietojen tietoturvaloukkauksen arviointiin. GDPR:n osoitusvelvollisuuden periaate tarkoittaa, että rekisterinpitäjän on osoitettava vaatimustenmukaisuus, ei vain väitettävä toimineensa kohtuullisesti.

Cyber Resilience Act tekee haavoittuvuuksien käsittelystä ja koordinoidusta julkistamisesta tuoteturvallisuusvelvoitteen digitaalisia elementtejä sisältäville tuotteille. Se luo myös raportointiodotuksia aktiivisesti hyväksikäytetyille haavoittuvuuksille ja vakaville tietoturvapoikkeamille soveltuvin osin. Vaikka lopullinen oikeudellinen raportointipäätös edellyttäisi asiantuntija-arviointia, operatiivinen todentava aineisto on tietoturvanäyttöä: vaikutuksen alainen tuote, vaikutuksen alainen versio, hyväksikäytettävyys, lieventäminen, julkistamisen tila, asiakasvaikutus, toimittajakoordinointi ja aikajana.

Kun haavoittuvuus on julkisesti näkyvissä EUVD:n kautta, auditoijat ja viranomaiset voivat kysyä, miksi sitä ei arvioitu, miksi vaikutuksen alaisia omaisuuseriä ei tunnistettu, miksi toimittajiin ei otettu yhteyttä tai miksi raportointia ei harkittu. Vahvimmat organisaatiot pystyvät vastaamaan näyttöön perustuen kuuteen kysymykseen:

1. Mitkä EUVD-hälytykset ovat meille olennaisia?
2. Mitkä omaisuuserät, tuotteet, toimittajat ja asiakkaat ovat vaikutuksen alaisia?
3. Kuka omistaa päätöksen?
4. Mikä korjaavan toimenpiteen tai lieventämisen määräaika soveltuu?
5. Milloin haavoittuvuuksien käsittelystä tulee poikkeamaraportointia?
6. Miten osoitamme sulkemisen ja johdon valvonnan?

ISO 27001:2022 perustana EUVD-näytölle

ISO/IEC 27001:2022 on luonnollinen hallintajärjestelmän runko EUVD:n operatiiviselle käyttöönotolle, koska se alkaa toimintaympäristöstä, sidosryhmistä, soveltamisalasta, riskistä ja näytöstä.

Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset, ISMS:n soveltamisalan, rajapinnat ja riippuvuudet. EUVD-valmiudessa ISMS:n soveltamisala ei voi päättyä sisäisiin palvelimiin. Sen on huomioitava SaaS-tuotteet, pilvipalvelut, ulkoistettu kehittäminen, hallinnoidut palveluntarjoajat (MSP), ICT-toimittajat, asiakassitoumukset, sääntelyvelvoitteet ja tuotteisiin kohdistuvat haavoittuvuusodotukset.

Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkojen yhdenmukaisuutta, resursseja, viestintää, osoitusvelvollisuutta ja raportointivastuita. Tässä kohtaa ylin johto hyväksyy, ettei uhkatiedustelu ole tekninen kohteliaisuus vaan liiketoimintariskin signaali.

Kohdat 6.1.1–6.1.3 tarjoavat mekanismin riskien arvioinnille, riskien käsittelylle, hallintakeinojen valinnalle, liitteen A vertailulle, soveltuvuuslausunnolle, jäännösriskin hyväksynnälle ja käsittelysuunnittelulle. Kun EUVD-merkintä vaikuttaa ympäristöön, reagoinnin tulee käynnistää toistettava riskityönkulku, joka yhdistää vaikutuksen alaiset omaisuuserät, todennäköisyyden, vaikutuksen, olemassa olevat kontrollit, käsittelyvaihtoehdot ja riskinomistajan hyväksynnän.

Kohdat 8.1–8.3 ja 9.1–9.3 muuttavat mallin toimintasykliksi. Organisaatioiden tulee suunnitella ja ohjata ISMS-prosesseja, säilyttää dokumentoitua tietoa, ohjata ulkoistettuja prosesseja, arvioida riskit uudelleen, toteuttaa käsittelysuunnitelmat, seurata ja mitata suorituskykyä, tehdä sisäisiä auditointeja ja suorittaa johdon katselmuksia.

Käytännössä Clarysec kartoittaa EUVD:n kolmeen tasoon:

Keskeinen periaate on yksinkertainen. EUVD-hälytysten on muututtava ISMS:n sisäisiksi tallenteiksi, ei epämuodollisiksi chat-viesteiksi, jotka katoavat korjauspäivityksen asentamisen jälkeen.

ISO 27001 -hallintakeinot, jotka tekevät EUVD:stä käytännössä toimivan

EUVD-toiminnan kannalta tärkeimmät ISO/IEC 27001:2022:n liitteen A hallintakeinot ovat 5.7 Uhkatiedustelu, 8.8 Teknisten haavoittuvuuksien hallinta, 5.21 Tietoturvallisuuden hallinta ICT-toimitusketjussa ja 5.31 Lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset.

Clarysec kartoittaa nämä Zenith Controls: The Cross-Compliance Guide -oppaan Zenith Controls kautta. Se toimii usean viitekehyksen vaatimustenmukaisuuden kompassina ISO/IEC 27001:2022:n, ISO/IEC 27002:2022:n, NIS2:n, DORA:n, GDPR:n, NIST CSF:n ja auditointinäytön suunnittelussa.

Zenith Controls -kartoitus ISO/IEC 27002:2022 -hallintakeinolle 5.7, Uhkatiedustelu, luokittelee sen ennaltaehkäiseväksi, havaitsevaksi ja korjaavaksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi sekä Identify-, Detect- ja Respond-kyberturvallisuuskäsitteiden mukaiseksi. Sen operatiivinen kyvykkyys on uhkien ja haavoittuvuuksien hallinta, ja sen tietoturva-alueet ovat puolustus ja häiriönsietokyky.

Zenith Controls -kartoitus ISO/IEC 27002:2022 -hallintakeinolle 8.8, Teknisten haavoittuvuuksien hallinta, luokittelee sen ennaltaehkäiseväksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi sekä Identify- ja Protect-käsitteiden mukaiseksi. Sen operatiivinen kyvykkyys on uhkien ja haavoittuvuuksien hallinta, ja sen tietoturva-alueisiin kuuluvat hallinnointi, ekosysteemi, suojaus ja puolustus.

Zenith Controls -kartoitus ISO/IEC 27002:2022 -hallintakeinolle 5.21, Tietoturvallisuuden hallinta ICT-toimitusketjussa, luokittelee sen ennaltaehkäiseväksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi sekä Identify-käsitteen mukaiseksi. Sen operatiivinen kyvykkyys on toimittajasuhteiden turvallisuus, ja sen alueet ovat hallinnointi, ekosysteemi ja suojaus.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint korostaa myös hallintakeinoa 5.31 vaiheessa 23, Lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset:

Tietoturva ei ole olemassa tyhjiössä. Se toimii velvoiteverkostossa, jossa osa velvoitteista perustuu lakiin, osa sopimuksiin ja osa toimialakohtaiseen sääntelyyn.

Tämä on hallinnollinen silta EUVD:n ja sääntelyraportoinnin välillä. Haavoittuvuustallenne voi alkaa uhkatiedusteluna, muuttua tekniseksi haavoittuvuustiketiksi, käynnistää toimittajayhteistyön ja lopulta muuttua poikkeamaksi tai oikeudelliseksi ilmoituspäätökseksi.

Tästä syystä EUVD:tä ei pidä käsitellä vain yhtenä syötteenä muiden joukossa. Se on hallintakeinojen integraatiopiste.

Clarysecin politiikkamalli: hälytyksestä vastuutettuun päätökseen

Kypsä EUVD-toimintamalli tarvitsee politiikkatekstiä, joka kertoo tiimeille, mitä tehdään ennen kuin ensimmäinen kriittinen hälytys saapuu.

Clarysecin Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka antaa yritystiimeille selkeän seuranta- ja eskalointivaltuutuksen:

Seuraa uhkailmoituksia (esim. CVE, CISA KEV, toimittajien tiedotteet) ja eskaloi kriittiset haavoittuvuudet.

Sama politiikka edellyttää keskitettyä näyttöpohjaa:

Tietoturvaoperaatioiden tiimin on ylläpidettävä keskitettyä haavoittuvuuksien hallintarekisteriä, ja tietoturvajohtajan tai delegoidun toimivaltaisen henkilön on katselmoitava se kuukausittain.

Pk-yrityksille Clarysecin Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka – pk-yritys Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka – pk-yritys tekee lähdemallin näkyväksi sisällyttämällä siihen:

Luotetut uhkatiedotteet (esim. CISA, ENISA, kansalliset CERT-hälytykset)

Se myös säilyttää auditointijäljen:

Korjauspäivityslokia on ylläpidettävä ja katselmoitava auditointien ja tietoturvapoikkeamiin reagoinnin yhteydessä.

Nämä lausekkeet ehkäisevät yleisen epäonnistumisen. Jos EUVD-hälytys saapuu eikä kukaan tiedä, kuuluuko se haavoittuvuusrekisteriin, poikkeamajonoon, toimittajaseurantaan vai oikeudelliseen arviointiin, organisaatio menettää aikaa. Politiikkateksti tekee ensimmäisestä toimenpiteestä automaattisen.

CVD-ulottuvuus käsitellään Clarysecin Haavoittuvuuksien koordinoidun julkistamisen politiikan Haavoittuvuuksien koordinoidun julkistamisen politiikka kautta. Se määrittää vastaanoton, kuittauksen, vakavuuden arvioinnin ja validoinnin työnkulun:

Ilmoituksen vastaanottamisen jälkeen VRT:n tulee kirjata se ja lähettää ilmoittajalle kuittaus kahden työpäivän kuluessa sekä antaa seurantaviite. VRT:n tulee tehdä alustava vakavuusarviointi esimerkiksi CVSS-pisteytyksen avulla ja validoida asia tarvittaessa IT- ja kehitystiimien tuella tavoiteajassa, joka on viisi työpäivää. Kriittiset haavoittuvuudet, kuten etäkoodin suorittamisen tai merkittävän tietomurron mahdollistavat haavoittuvuudet, on käsiteltävä nopeutetusti.

Se kytkee myös kolmannen osapuolen haavoittuvuudet toimittajayhteistyöhön:

Jokaisesta vahvistetusta kriittisestä tai korkean riskin haavoittuvuudesta tietoturvajohtajan tulee välittömästi ilmoittaa ylemmälle johdolle ja asianomaisille järjestelmäomistajille. Jos haavoittuvuus vaikuttaa toimittajan tai muun kolmannen osapuolen tuottamiin tuotteisiin tai palveluihin, VRT:n tulee ilmoittaa toimittajan tietoturvayhteyshenkilölle ilman aiheetonta viivytystä ja pyrkiä yhteistyöhön korjaavien toimenpiteiden toteuttamiseksi.

Clarysecin Sovellusturvallisuusvaatimusten politiikka – pk-yritys Sovellusturvallisuusvaatimusten politiikka – pk-yritys vahvistaa tuotteisiin ja toimittajiin kohdistuvia odotuksia edellyttämällä, että tiimit:

määrittävät velvoitteet haavoittuvuuksien julkistamiselle, vasteajoille ja paikkaukselle.

Toimittajasopimuksia varten Clarysecin Kolmansien osapuolten ja toimittajaturvallisuuden politiikka – pk-yritys Kolmansien osapuolten ja toimittajaturvallisuuden politiikka – pk-yritys sisältää:

Tietoturvaloukkauksista ilmoittamisen määräajat (esim. 24–72 tunnin kuluessa)

Lopuksi Clarysecin Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka liittää sääntelyn alaiset tiedot ja toimialaraportoinnin poikkeamapäätökseen kohdan 6.4.1 kautta:

Pk-yritysversio säilyttää saman käytännön laukaisimen. Clarysecin Tietoturvapoikkeamien hallintapolitiikka – pk-yritys Tietoturvapoikkeamien hallintapolitiikka – pk-yritys toteaa:

Kun asiakastietoja on osallisena, toimitusjohtajan on arvioitava lakisääteiset ilmoitusvelvoitteet GDPR:n, NIS2:n tai DORA:n soveltuvuuden perusteella.

Tämä on silta lauseiden “näimme haavoittuvuuden” ja “arvioimme, onko tämä raportoitava” välillä.

Käytännön EUVD-vastaanottotallenne

Oletetaan, että EUVD julkaisee tai päivittää haavoittuvuusmerkinnän, joka vaikuttaa Marian mobiilisovelluksen todennus-SDK:hon. SDK:ta ylläpitää toimittaja, sen on integroinut ulkoistettu kehityskumppani, ja sitä käyttävät asiakkaat, jotka todentautuvat fintech-SaaS-tuotteeseen. Julkista keskustelua hyväksikäytöstä on olemassa, mutta asiakasympäristöjen lokeissa ei ole vahvistettua hyväksikäyttöä.

Perusteltavissa olevan vastaanottotallenteen tulee kattaa sekä tekninen että sääntelyyn liittyvä konteksti.

Tämä tallenne ei ole vaatimustenmukaisuuskoriste. Se on päätösten ohjauskeskus.

Käytännön työnkulku näyttää tältä:

1. SOC vastaanottaa EUVD-hälytyksen ja luo haavoittuvuustallenteen.
2. Omaisuuden omistaja vahvistaa, onko vaikutuksen alainen komponentti tuotantoympäristössä.
3. Tietoturvatiimi tekee vakavuusarvioinnin teknisen vakavuuden, hyväksikäytettävyyden, altistuksen, tietojen arkaluonteisuuden ja palvelun kriittisyyden perusteella.
4. Toimittajaomistaja ottaa yhteyttä SDK-toimittajaan tai ulkoistettuun kehityskumppaniin ennalta määritettyjä tietoturvayhteyshenkilöitä käyttäen.
5. Tietoturvapoikkeamiin reagoinnista vastaava henkilö päättää, onko näyttöä hyväksikäytöstä, palveluvaikutuksesta tai asiakashaitasta.
6. Lakiasiat, tietosuojavastaava (DPO) ja vaatimustenmukaisuudesta vastaava toiminto arvioivat, käynnistyvätkö GDPR-, NIS2-, DORA- tai CRA-liitännäiset työnkulut.
7. Kehitystiimi ottaa käyttöön korjauspäivityksen tai lieventävän toimenpiteen.
8. Tietoturva validoi korjaavan toimenpiteen skannauksella, version tarkistuksella, lokikatselmoinnilla tai korvaavan kontrollin testillä.
9. Tietoturvajohtaja katselmoi kriittiset ja korkeat tallenteet ja raportoi trendit johdon katselmointiin.

Zenith Blueprint selittää Hallintakeinot käytännössä -vaiheen vaiheessa 19, Teknologiset hallintakeinot I, teknisen haavoittuvuuksien hallinnan auditoinnin kannalta selkeästi:

Hallintakeinossa ei ole kyse täydellisyydestä, vaan organisoidusta, läpinäkyvästä ja vastuullisesta prosessista.

Tällä lauseella on merkitystä. Viranomaiset ja auditoijat eivät odota, että jokainen haavoittuvuus korjataan välittömästi. He odottavat, että organisaatio tietää, mitä sillä on, priorisoi sen, toteuttaa oikeasuhteiset toimet, kirjaa poikkeukset ja osoittaa jatkotoimien toteutumisen.

Uhkatiedustelu on päätöstoiminto, ei postilaatikko

Suurin virhe EUVD-suunnittelussa on antaa syöte yhdelle analyytikolle ja kutsua sitä uhkatiedusteluksi. Zenith Blueprint selittää Hallintakeinot käytännössä -vaiheen vaiheessa 22, Organisatoriset hallintakeinot, ISO/IEC 27002:2022 -hallintakeinon 5.7 näin:

Parhaat uhkatiedustelulähteet ovat usein yhdistelmä sisäistä seurantaa, ulkoisia kumppanuuksia ja yhteisöosallistumista.

Se myös varoittaa, että tiedustelun on muututtava toiminnaksi:

Tämä hallintakeino herää todella eloon päätöksenteossa. Uhkatiedustelun tulee vaikuttaa suoraan siihen, mitä kontrolleja kiristetään, mitkä omaisuuserät luokitellaan uudelleen tai eristetään, mitä skenaarioita testataan pöytäharjoituksissa ja kuinka nopeasti korjauspäivitykset tai lieventävät toimenpiteet otetaan käyttöön.

EUVD:tä varten tiedustelun käyttäjät on määriteltävä rooleittain.

NIST CSF 2.0 voi auttaa tämän mallin jäsentämisessä. Sen GOVERN-toiminto korostaa sidosryhmien odotuksia, lakisääteisiä ja sääntelyyn perustuvia velvoitteita, riskinottohalukkuutta, johdon vastuuvelvollisuutta, määriteltyjä rooleja, politiikkaa, resursseja ja valvontaa. Sen operatiiviset toiminnot auttavat järjestämään omaisuusluettelot, haavoittuvuuksien tunnistamisen, suojaamisen, havaitsemisen, reagoinnin, palautumisen ja parantamisen. NIST CSF Profile -menetelmää voidaan käyttää EUVD-toiminnan nyky- ja tavoitetilan määrittämiseen ja puutteiden muuntamiseen priorisoiduksi toimintasuunnitelmaksi.

Clarysecin näkökulmasta NIST CSF on hyödyllinen jäsentävä kerros, ISO/IEC 27001:2022 on auditoitava hallintajärjestelmä ja Zenith Controls on usean viitekehyksen vaatimustenmukaisuuden kompassi, joka pitää kartoitukset johdonmukaisina.

Toimittaja- ja tuotehaavoittuvuuksien seuranta

NIS2 Article 21 tekee toimitusketjun turvallisuudesta osan vähimmäistason kyberturvallisuuden riskienhallintatoimenpiteitä. Article 21(3) edellyttää, että toimijat huomioivat kullekin suoralle toimittajalle ja palveluntarjoajalle ominaiset haavoittuvuudet, tuotteiden laadun ja toimittajien kyberturvallisuuskäytännöt, mukaan lukien turvallisen kehittämisen menettelyt. Johdantokappaleet 85 ja 86 korostavat kolmannen osapuolen riskiä, joka liittyy tietojen käsittelyyn, hallittuihin palveluihin, ohjelmistotoimittajiin ja hallinnoituihin tietoturvapalveluntarjoajiin.

DORA on finanssialan toimijoille määräilevämpi. Se edellyttää, että kolmansien osapuolten ICT-riskiä hallitaan osana ICT-riskien viitekehystä, mukaan lukien tietorekisterit, due diligence, keskittymäriskin analyysi, kirjalliset sopimukset, auditointi- ja tarkastusoikeudet, poikkeamatuki, alihankinnan näkyvyys, tietoturvavaatimukset, päättämisoikeudet ja testatut irtautumisstrategiat.

EUVD tekee heikosta toimittajanäkyvyydestä kivuliaan ilmeistä. Jos toimittajakomponentti on vaikutuksen alainen, organisaatio tarvitsee enemmän kuin hankintayhteyshenkilön. Se tarvitsee:

1. Nimetyn toimittajan tietoturvayhteyshenkilön.
2. Sopimusperusteiset haavoittuvuuksien ilmoitusvelvoitteet.
3. Tuote- ja versioinventaarion.
4. SBOM:n tai komponenttien läpinäkyvyyden, kun se on olennaista.
5. Korjaavien toimenpiteiden SLA:t ja kiertotapavelvoitteet.
6. Auditointi- tai varmentamisoikeudet.
7. Poikkeamien tukivelvoitteet.
8. Irtautumis- tai korvaussuunnitelmat kriittisille riippuvuuksille.

Tästä syystä Clarysec kartoittaa EUVD-toiminnan ISO/IEC 27002:2022 -hallintakeinoon 5.21 Zenith Controls -oppaan kautta. Hallinnointi-, ekosysteemi- ja suojausalueet sopivat käytännön toimittajaongelmaan: et voi korjata sitä, mitä et pysty jäljittämään, etkä voi tuottaa näyttöä siitä, mitä et ole sopimuksella edellyttänyt.

CRA-raportointivalmiudessa samasta toimittaja- ja tuotehaavoittuvuustallenteesta tulee välttämätön. Vaikka lopullinen sääntelypäätös edellyttäisi oikeudellista analyysiä, operatiivinen näyttö tulee tietoturvan ja teknisen toteutuksen todentavasta aineistosta.

Milloin EUVD-haavoittuvuudesta tulee poikkeama

Kaikki haavoittuvuudet eivät ole poikkeamia. Jokaisen vakavan haavoittuvuuden tulee kuitenkin olla nopeasti muunnettavissa poikkeamatallenteeksi.

Käytännön laukaisin on tämä: jos EUVD-tiedustelu osoittaa mahdollista altistumista, avaa haavoittuvuustallenne. Jos on näyttöä hyväksikäytöstä, palveluvaikutuksesta, sääntelyn alaisten tietojen altistumisesta, asiakashaitasta tai operatiivisesta häiriöstä, linkitä se poikkeamatallenteeseen tai muunna se sellaiseksi.

NIS2 Article 23 edellyttää ilmoitusta merkittävistä poikkeamista, jotka vaikuttavat palvelun tuottamiseen, mukaan lukien poikkeamat, jotka aiheuttavat tai voivat aiheuttaa vakavan operatiivisen häiriön tai taloudellisen menetyksen tai vaikuttavat muihin huomattavan aineellisen tai aineettoman vahingon kautta. DORA edellyttää, että finanssialan toimijat kirjaavat ICT:hen liittyvät poikkeamat ja merkittävät kyberuhat, luokittelevat merkittävät ICT:hen liittyvät poikkeamat, raportoivat ne tarvittaessa Article 19:n mukaisesti, viestivät asiakkaille, kun taloudelliset edut ovat vaikutuksen alaisia, ja päättävät prosessin juurisyyanalyysiin. GDPR edellyttää henkilötietojen tietoturvaloukkauksen arviointia, kun tietoturvapoikkeama aiheuttaa henkilötietojen vahingossa tapahtuvan tai lainvastaisen tuhoutumisen, menetyksen, muuttumisen, luvattoman luovuttamisen tai luvattoman pääsyn henkilötietoihin.

Zenith Blueprint, Hallintakeinot käytännössä -vaihe, vaihe 16, Henkilöstöön liittyvät hallintakeinot II, vahvistaa ilmoittamiskulttuurin merkitystä:

Edistä matalan kynnyksen ilmoittamisen ajattelutapaa – viestin tulee olla: “Jos olet epävarma, ilmoita.”

EUVD:n osalta tämä koskee insinöörejä ja toimittajia yhtä paljon kuin työntekijöitä. Jos kehittäjä havaitsee vaikutuksen alaisen riippuvuuden, toimittaja vahvistaa hyväksikäytettävyyden tai tuki näkee epäilyttävää asiakaskäyttäytymistä, organisaation tulee suosia varhaista luokittelua ja priorisointia viivästyneen varmuuden sijaan.

Miten auditoijat testaavat EUVD-ohjelmaasi

Vahva EUVD-toimintamalli tulee suunnitella useita auditointinäkökulmia varten. Sama näyttö voi täyttää eri odotukset, jos se on rakenteistettu hyvin.

ISO 27001 -auditoija ottaa tyypillisesti otoksen korkean vakavuuden EUVD:n käynnistämästä tallenteesta ja kysyy, liittyykö se soveltamisalaan, sidosryhmävelvoitteisiin, riskien arviointiin, käsittelyyn, liitteen A hallintakeinoihin, operatiiviseen näyttöön ja katselmointiin. NIST-suuntautunut arvioija keskittyy tuloksiin. COBIT-tyylinen auditoija keskittyy hallinnointiin, omistajuuteen, suorituskykyyn ja varmennukseen. DORA-arvioija kiinnittää erityistä huomiota kolmansien osapuolten ICT-riippuvuuksiin, sopimuskontrolleihin ja poikkeamaluokitteluun.

Hallitusraportointi ilman CVE-kohinaa

NIS2 ja DORA asettavat johtoelimet kyberturvallisuuden osoitusvelvollisuuden keskiöön. Johto ei kuitenkaan tarvitse EUVD-merkintöjen tietokaatopaikkaa. Se tarvitsee päätöksenteon kannalta laadukasta raportointia.

Kuukausittaisen haavoittuvuustiedusteluraportin tulee sisältää:

1. Kriittiset ja korkeat EUVD:hen osuneet haavoittuvuudet, jotka vaikuttavat soveltamisalaan kuuluviin omaisuuseriin.
2. Avoimet haavoittuvuudet, jotka ovat korjaavien toimenpiteiden SLA:n ulkopuolella.
3. Toimittajista johtuvat viiveet ja sopimuseskaloinnit.
4. Haavoittuvuudet, jotka liittyvät poikkeamiin tai läheltä piti -tilanteisiin.
5. CRA:n tuotehaavoittuvuustyönkulun laukaisimet ja tulokset.
6. NIS2-, DORA- tai GDPR-raportointiarvioinnit.
7. Hyväksytyt jäännösriskit ja hyväksyjät.
8. Trendit liiketoimintapalvelun, tuotteen, toimittajan ja juurisyyn mukaan.
9. Kontrollin tehokkuusmittarit ja parannustoimet.

Tämä liittyy suoraan ISO/IEC 27001:2022 kohdan 9.3 johdon katselmoinnin odotuksiin, kuten toimintaympäristön muutoksiin, sidosryhmätarpeisiin, suorituskykytrendeihin, auditointituloksiin, tavoitteiden täyttymiseen, palautteeseen, riskien arvioinnin tuloksiin, käsittelyn tilaan ja parantamismahdollisuuksiin.

Yleiset EUVD-valmiuden epäonnistumiset

Organisaatiot, joilla on vaikeuksia haavoittuvuustiedustelun kanssa, epäonnistuvat yleensä ennakoitavilla tavoilla.

Ensinnäkin niillä ei ole luotettavaa omaisuus- ja ohjelmistoinventaariota. EUVD:n olennaisuutta ei voida arvioida ilman tuotenimiä, versioita, kirjastoja, pilvipalveluja, toimittajia ja tietovirtoja.

Toiseksi ne erottavat haavoittuvuuksien hallinnan tietoturvapoikkeamiin reagoinnista. Haavoittuvuustiimi sulkee tiketit, mutta poikkeamatiimi ei koskaan arvioi, tapahtuiko hyväksikäyttöä. Tämä luo raportoinnin katvealueita.

Kolmanneksi toimittajasopimukset ovat vaiti. Jos toimittajalla ei ole velvollisuutta ilmoittaa, tehdä yhteistyötä, paikata, toimittaa näyttöä tai tukea tietoturvapoikkeamiin reagointia, asiakkaalla on vähän vaikutusvaltaa kriittisen aikaikkunan aikana.

Neljänneksi lakiasiat ja tietosuojavastaava otetaan mukaan liian myöhään. Jos GDPR-, NIS2-, DORA- tai CRA-liitännäiset raportointipäätökset alkavat vasta sen jälkeen, kun tekninen tiimi on jo paikannut ja siirtynyt eteenpäin, tietoisuusaikajana hämärtyy.

Viidenneksi johdon raportointi on liian teknistä. Hallitukset saavat pitkiä CVE-listoja ilman liiketoimintavaikutusta, sääntelymerkitystä, toimittajatrendejä tai jäännösriskipäätöksiä.

Clarysecin menetelmä korjaa tämän yhdistämällä kontrollit. Zenith Blueprint -oppaassa vaihe 19 vahvistaa teknistä haavoittuvuuksien hallintaa, vaihe 22 operationalisoi uhkatiedustelun, vaihe 16 vahvistaa poikkeamien ilmoittamiskulttuuria ja vaihe 23 pitää lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset velvoitteet näkyvissä.

30 päivän EUVD-valmiussprintti

Jos organisaatiosi tarvitsee nopean etenemistavan, aloita kohdennetulla 30 päivän sprintillä.

Ensimmäinen viikko: määritä soveltamisala ja velvoitteet. Varmista, onko organisaatio mahdollisesti NIS2:n mukainen keskeinen tai tärkeä toimija, soveltuuko DORA finanssitoimintoihin, soveltuuko GDPR henkilötietojen käsittelyyn ja missä CRA-liitännäiset tuotehaavoittuvuusvelvoitteet voivat olla olennaisia. Päivitä ISMS:n lakisääteisten ja sopimusperusteisten velvoitteiden rekisteri.

Toinen viikko: rakenna vastaanottotyönkulku. Lisää EUVD, kansalliset CERT:t, toimittajatiedotteet ja toimialasyötteet haavoittuvuustiedustelun lähdeluetteloon. Määritä, kuka avaa tallenteet, kuka validoi altistuksen, kuka ottaa yhteyttä toimittajiin, kuka arvioi raportoinnin ja kuka hyväksyy jäännösriskin.

Kolmas viikko: yhdistä toimittajat ja tuotteet. Tunnista kriittiset tuotteet, asiakasrajapinnan palvelut, suorat ICT-toimittajat, ulkoistetut kehittäjät, pilvipalveluntarjoajat ja hallinnoidut tietoturvapalveluntarjoajat. Vahvista tietoturvayhteyshenkilöt, sopimuslausekkeet, haavoittuvuuksiin reagoinnin velvoitteet ja näyttöodotukset.

Neljäs viikko: testaa työnkulku. Suorita pöytäharjoitus realistisella EUVD-hälytyksellä. Edellytä, että tiimi tuottaa haavoittuvuustallenteen, toimittajaviestinnän, poikkeama-arvioinnin, oikeudellisen ilmoituspäätöksen, korjauspäivityslokin, jäännösriskin hyväksynnän ja johdon yhteenvedon.

Lopputuloksen ei pidä olla diasarja. Sen tulee olla näyttöpaketti, josta auditoija voi ottaa otoksen.

Tee EUVD:stä kontrollijärjestelmä, älä uutta syötettä

Vuoteen 2026 mennessä organisaatiot, jotka käsittelevät ENISA EUVD:tä hyvin, eivät ole niitä, jotka vain tilaavat lisää hälytyksiä. Ne ovat organisaatioita, jotka muuttavat julkisen haavoittuvuustiedustelun riskiperusteiseksi toiminnaksi, toimittajien vastuutettavuudeksi, koordinoiduksi julkistamiseksi, raportointipäätöksiksi ja auditointinäytöksi.

Clarysec voi auttaa rakentamaan tämän mallin Zenith Blueprintin Zenith Blueprint, Clarysecin politiikkakirjaston ja Zenith Controlsin Zenith Controls avulla. Kartoitamme ISO/IEC 27001:2022 -kohdat ja ISO/IEC 27002:2022 -hallintakeinot NIS2:n, DORA:n, GDPR:n, NIST CSF:n ja COBIT-tyyppisten auditointiodotusten mukaisiksi ja muutamme kartoituksen käytännön rekistereiksi, toimintapelikirjoiksi, toimittajalausekkeiksi ja johdon raportoinniksi.

Jos tiimisi valmistautuu NIS2:n mukaiseen haavoittuvuuksien käsittelyyn, CRA-raportointivalmiuteen, CVD-toimintaan tai EUVD-ohjattuun haavoittuvuustiedusteluun, aloita Clarysecin EUVD-valmiuskatselmoinnilla. Autamme tunnistamaan puutteet, priorisoimaan kontrollit ja rakentamaan todentavan aineiston ennen kuin ensimmäinen kriittinen hälytys testaa ohjelmasi.