Haavoittuvuuksien korjaus-SLA:t NIS2:n ja DORA:n näkökulmasta

Tiistaiaamuna alkuvuodesta 2026 kello 08.17 nopeasti kasvavan fintech-yhtiön tietoturvajohtaja Anna saa ensimmäisen viestin ennen kuin kahvi on juotu loppuun.

Tietoturvavalvomo (SOC) on havainnut aktiivista keskustelua asiakasrajapinnan API-yhdyskäytävän haavoittuvuuden hyväksikäytöstä. Kehitystiimin mukaan korjauspäivitys on saatavilla, mutta sen käyttöönotto on riskialtista, koska yhdyskäytävä sijaitsee maksutyönkulkujen edessä. Vaatimustenmukaisuuspäällikkö välittää kansallisen toimivaltaisen viranomaisen muodollisen pyynnön saada näyttöä ”haavoittuvuuksien käsittelystä ja julkistamisesta” sekä todisteet siitä, että prosessi on ollut vaikuttava viimeisten 12 kuukauden aikana. Hankinta lisää kolmannen ongelman: yhdyskäytävää hallinnoi MSP-palveluntarjoaja, ja sopimuksessa todetaan vain, että palveluntarjoaja asentaa ”tietoturvapäivitykset kohtuullisessa ajassa”.

Kello 09.00 kyse ei ole enää pelkästä paikkauksesta. Kyse on ISO/IEC 27001:2022 -näytöstä, NIS2-kyberhygieniasta, DORA:n ICT-riskien hallinnasta, toimittajahallinnasta ja mahdollisesti poikkeamien ilmoittamisesta, jos hyväksikäyttö vaikuttaa palvelun jatkuvuuteen tai henkilötietoihin.

Tämä on käytännön vaatimustenmukaisuuden aukko, jonka moni organisaatio kohtaa vuonna 2026. Niillä on skannereita, hallintanäkymiä, tikettejä ja paikkaustyökaluja, mutta ne eivät pysty vastaamaan auditointikysymyksiin selkeästi:

• Kuka hyväksyi korjaus-SLA:n?
• Miten SLA on riskiperusteinen?
• Mitä tapahtuu, jos kriittinen korjauspäivitys ylittää määräajan?
• Miten internetiin avautuvat omaisuuserät priorisoidaan?
• Miten toimittajat velvoitetaan noudattamaan samoja aikatauluja?
• Missä on riskin hyväksyntää koskeva tallenne paikkaamattomasta järjestelmästä?
• Mikä näyttö osoittaa, että hallintakeino toimi eikä vain ollut olemassa?

Vastaus ei ole uusi määräaikataulukko. Haavoittuvuuksien korjaus-SLA:ita tulee hallita elävänä hallintajärjestelmänä, joka yhdistää omaisuuden omistajuuden, haavoittuvuuksien pisteytyksen, uhkatiedustelun, muutoksenhallinnan, toimittajien SLA:t, poikkeusten käsittelyn, seurannan, tietoturvapoikkeamiin reagoinnin ja johdon katselmoinnin.

Tässä Clarysecin suuryrityksille tarkoitettu Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka (VPMP), pk-yrityksille tarkoitettu Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka (VPMP-SME), pk-yrityksille tarkoitettu Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka (TPSSP-SME), Zenith Blueprint (ZB) ja Zenith Controls (ZC) ovat hyödyllisiä. Yhdessä ne muuttavat ajatuksen ”paikatkaa nopeammin” puolustettavaksi hallinnointiprosessiksi, joka kestää ISO-, NIS2-, DORA-, GDPR-, NIST- ja ISACA-tyyppisen auditointitarkastelun.

Miksi haavoittuvuuksien korjaus-SLA:ista tuli hallintoelintason näyttöä

Haavoittuvuuksien korjaamista pidettiin aiemmin IT-hygienian mittarina. Vuonna 2026 se on lähempänä säänneltyä toiminnallisen häiriönsietokyvyn sitoumusta.

NIS2 tekee kyberturvallisuudesta johdon vastuun. Keskeisten ja tärkeiden toimijoiden hallintoelinten tulee hyväksyä kyberturvallisuuden riskienhallintatoimenpiteet, valvoa niiden toteutusta ja saada koulutusta, jotta ne ymmärtävät riskit ja tietoturvakäytäntöjen vaikutukset palveluihin. NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta ja ylläpito, haavoittuvuuksien käsittely ja julkistaminen, kyberhygienia, koulutus, pääsynhallinta, omaisuudenhallinta ja todennus.

Rahoitusalan toimijoille DORA on toiminnalliseen häiriönsietokykyyn erikoistunut sääntelykehys. Se edellyttää ICT-riskeihin liittyviä hallinnointi- ja valvontajärjestelyjä, joissa hallintoelin määrittää, hyväksyy ja valvoo ICT-riskien hallintaa sekä säilyttää siitä vastuun. Se edellyttää myös ICT-omaisuuserien ja riippuvuuksien tunnistamista, suojaus- ja ennaltaehkäiseviä hallintakeinoja, kuten paikkausta ja muutoksenhallintaa, ICT:hen liittyvien poikkeamien hallintaa, digitaalisen toiminnallisen häiriönsietokyvyn testausta sekä ICT-kolmansien osapuolten riskien hallintaa.

Käytännön vaikutus on merkittävä. Paikkausmääräajan ylitys voi osoittaa puutteen seuraavissa:

• Hallinnointi, jos johto ei ole hyväksynyt riskiperusteisia SLA:ita
• Omaisuudenhallinta, jos vaikutuksen kohteena olevan järjestelmän omistaja ei ole tiedossa
• Muutoksenhallinta, jos hätäpaikkausta ei hallita kontrolloidusti
• Toimittajahallinta, jos palveluntarjoajan aikataulut ovat epämääräisiä
• Tietoturvapoikkeamiin reagointi, jos hyväksikäytön merkkejä ei luokitella ja priorisoida
• Näytön hallinta, jos tiketit ja lokit eivät osoita sulkemista
• Riskien käsittely, jos poikkeuksia ei hyväksytä ja katselmoida

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rungon. Kohdat 4.1–4.3 edellyttävät, että organisaatiot ymmärtävät sisäiset ja ulkoiset tekijät, sidosryhmien vaatimukset, lakisääteiset ja sopimusperusteiset velvoitteet sekä rajapinnat muihin organisaatioihin. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa ja riskinomistajan hyväksyntää jäännösriskille. Kohdat 9.1, 9.2, 9.3, 10.1 ja 10.2 edellyttävät seurantaa, sisäistä auditointia, johdon katselmointia, jatkuvaa parantamista, korjaavia toimenpiteitä ja säilytettävää näyttöä.

Käytännössä, jos haluat haavoittuvuuksien korjaus-SLA:iden olevan auditointivalmiita, niiden tulee olla osa ISMS:ää, eivät vain DevOps-mittari.

SLA-malli, jonka auditoijat odottavat näkevänsä

Haavoittuvuuksien korjaus-SLA:n tulee vastata kolmeen kysymykseen:

1. Kuinka nopeasti meidän tulee toimia?
2. Kuka on vastuussa?
3. Mikä näyttö osoittaa lopputuloksen?

Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka määrittää käytännöllisen lähtökohdan riskiperusteisille korjausaikatauluille:

Organisaation tulee luokitella kaikki havaitut haavoittuvuudet standardoidulla menetelmällä (esim. CVSS v3.x) ja soveltaa liiketoiminnan kriittisyyteen suhteutettuja korjausaikatauluja: 5.2.1 Kriittinen (CVSS 9.0-10.0): välitön arviointi; paikkausmääräaika enintään 72 tuntia. 5.2.2 Korkea (7.0-8.9): reagointi 48 tunnin kuluessa; paikkausmääräaika 7 kalenteripäivää. 5.2.3 Keskitaso (4.0-6.9): reagointi 5 päivän kuluessa; paikkausmääräaika 30 kalenteripäivää. 5.2.4 Matala (<4.0): reagointi 10 päivän kuluessa; paikkausmääräaika 60 kalenteripäivää.

Tämä kohta on vahva, koska se erottaa vasteajan paikkausmääräajasta. Korkean tason haavoittuvuus ei saa olla kuutta päivää huomaamatta ja tulla paikatuksi vasta seitsemäntenä päivänä. Vastekello vahvistaa luokittelun ja priorisoinnin, omistajuuden, vaikutusten arvioinnin ja korjaussuunnittelun. Paikkausmääräaika vahvistaa teknisen sulkemisen tai hyväksytyn poikkeuksen.

Pienemmille organisaatioille Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka käyttää yksinkertaisempaa mutta edelleen auditoitavissa olevaa kieltä:

Kriittiset korjauspäivitykset tulee asentaa 3 päivän kuluessa julkaisusta, erityisesti internetiin avautuvissa järjestelmissä

Ja laajemmalle paikkauskannalle:

Kaikki muut korjauspäivitykset tulee asentaa 30 päivän kuluessa, ellei voimassa olevaa poikkeusta ole dokumentoitu

Tarkoitus ei ole, että jokainen organisaatio käyttää samoja määräaikoja. ISO/IEC 27001:2022, NIS2 ja DORA tukevat kaikki suhteellisuusperiaatetta. Tarkoitus on, että korjaus-SLA:t määritellään, hyväksytään ja perustetaan riskiin, niitä seurataan ja niistä tuotetaan näyttö.

Tässä moni yritys epäonnistuu. Ne määrittelevät SLA:n mutta eivät määrittele näyttöä. Auditoijan näkökulmasta toimintapolitiikka ilman operatiivisia tallenteita on lupaus, ei hallintakeino.

Omaisuuden omistajuus on piilevä riippuvuus

Skanneri voi kertoa, että palvelimella on CVE. Se ei voi kertoa, tukeeko palvelin kriittistä maksuprosessia, tallentaako se erityisiin henkilötietoryhmiin kuuluvia henkilötietoja, liittyykö se selvityspalveluntarjoajaan tai onko se suunniteltu poistettavaksi käytöstä.

Tämä konteksti tulee omaisuudenhallinnasta, tietojen luokittelusta, toimittajaluettelosta ja riskien arvioinnista.

ISO/IEC 27001:2022:n liitteen A hallintakeino 8.8, teknisten haavoittuvuuksien hallinta, on keskeinen, mutta se ei toimi yksin. Se riippuu vahvasti konfiguraationhallinnasta, muutoksenhallinnasta, toimittajien seurannasta, pilvipalvelujen hallinnasta, lokituksesta, seurannasta ja riskien käsittelystä.

NIST CSF 2.0 ilmaisee saman ongelman tavoitetulosten kielellä. GOVERN-toiminto odottaa, että kyberturvallisuutta koskevat lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset ymmärretään ja hallitaan, riskinottohalukkuus ja riskinsietokyky dokumentoidaan, roolit ja resurssit osoitetaan sekä kyberturvallisuuspolitiikat laaditaan, otetaan käyttöön, katselmoidaan ja päivitetään. IDENTIFY-tavoitetuloksiin kuuluvat laitteisto-, ohjelmisto-, palvelu-, järjestelmä-, tieto- ja elinkaariluettelot sekä haavoittuvuuksien tunnistaminen, riskianalyysi, poikkeustenhallinta ja haavoittuvuuksien julkistamisprosessit.

Annan tiistaiaamun skenaariossa ensimmäinen tekninen kysymys on ”missä haavoittuva komponentti sijaitsee?” Ensimmäinen hallinnointikysymys on ”mihin palveluun ja riskiin se vaikuttaa?”

Zenith Blueprint, riskienhallintavaihe, Step 13: Risk Treatment Planning and Statement of Applicability, käsittelee tätä yhdistämällä riskit hallintakeinoihin, omistajiin ja aikatauluihin:

Määritä myös jokaiselle toimenpiteelle omistaja ja aikataulu (esimerkiksi erilliseen sarakkeeseen tai kommentteihin). Esim. “Owner: IT Manager, Timeline: by Q3 2025.” Tämä tekee siitä todellisen suunnitelman.

Juuri tätä haavoittuvuuksien korjaaminen edellyttää. Havainto ilman omistajaa muuttuu backlog-kohinaksi. Havainto, jolla on omistaja, aikataulu, riskienkäsittelypäätös ja todentava jälki, muuttuu auditoitavaksi hallintakeinoksi.

Miten Zenith Controls mallintaa hallintakeinojen suhteet

Zenith Controls käsittelee ISO/IEC 27002:2022 -hallintakeinoa 8.8, teknisten haavoittuvuuksien hallintaa, ennaltaehkäisevänä hallintakeinona, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se yhdistyy kyberturvallisuuskäsitteisiin Identify ja Protect, uhkien ja haavoittuvuuksien hallinnan operatiiviseen kyvykkyyteen sekä hallinnoinnin, ekosysteemin, suojauksen ja puolustuksen tietoturva-alueisiin.

Tämä on tärkeää, koska korjaus-SLA:t eivät ole vain suojausmekanismi. Ne ovat myös hallinnointimekanismi ja ekosysteemimekanismi. Altistumista muokkaavat toimittajat, pilvialustat, hallinnoidut palvelut, avoimen lähdekoodin komponentit ja internetiin avautuvat riippuvuudet.

Zenith Controls liittää 8.8:n useisiin tukeviin hallintakeinoihin:

Zenith Controls yhdistää haavoittuvuuksien hallinnan myös ISO/IEC 27005:2024:ään, erityisesti haavoittuvuuksien tunnistamiseen ja paikkaamattomia järjestelmiä koskeviin riskiskenaarioihin. Tämä vahvistaa perustetta sille, että paikkausmääräaikojen tulee olla riskiperusteisia eikä mielivaltaisia. Se yhdistää toimittajien seurannan myös ISO/IEC 27036-4:2016:n pilvipalvelusopimusten tietoturvatasoihin ja ISO/IEC 20000-1:2018:n palvelun tuottamisen suunnitteluun ja muutoksenhallintaan.

Tällä standardien välisellä rakenteella on merkitystä auditoinnissa. Jos organisaatio sanoo, että ”kriittiset haavoittuvuudet paikataan 72 tunnin kuluessa”, auditoija testaa, tukeeko väitettä riskien arviointi, omaisuuden luokittelu, toimittajavelvoitteet, muutostallenteet ja seurantaan liittyvä näyttö.

NIS2-kyberhygienia: haavoittuvuuksien käsittelystä korjaaviin toimenpiteisiin

NIS2 Article 21 edellyttää kaikki vaaratekijät huomioon ottavaa lähestymistapaa verkko- ja tietojärjestelmiin. Haavoittuvuuksien korjaus-SLA:iden kannalta useat Article 21:n osatekijät ovat suoraan merkityksellisiä:

• Riskianalyysi ja tietojärjestelmien turvallisuutta koskevat toimintapolitiikat
• Poikkeamien käsittely
• Liiketoiminnan jatkuvuus ja kriisinhallinta
• Toimitusketjun turvallisuus
• Turvallinen hankinta, kehittäminen ja ylläpito, mukaan lukien haavoittuvuuksien käsittely ja julkistaminen
• Menettelyt kyberturvallisuuden vaikuttavuuden arvioimiseksi
• Peruskyberhygienia ja koulutus
• Pääsynhallinta ja omaisuudenhallinta
• Monivaiheinen todennus tai jatkuva todennus tarvittaessa

NIS2 Article 20 asettaa hallintoelimet vastuuseen kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta. Tämä tarkoittaa, että haavoittuvuuksien korjaamisen mittarit eivät voi elää vain kehitystiimin hallintanäkymässä. Niiden tulee näkyä johdon raportoinnissa, riskikomitean aineistoissa tai ISMS:n johdon katselmoinnin tallenteissa.

Article 21 odottaa myös, että toimijat, jotka tunnistavat vaadittujen toimenpiteiden noudattamatta jättämisen, toteuttavat korjaavat toimenpiteet ilman aiheetonta viivytystä. Tällä ilmaisulla on merkitystä. Jos hallintanäkymä näyttää myöhässä olevia kriittisiä haavoittuvuuksia, vaatimustenmukaisuusnäytön ei tule päättyä toteamukseen ”tiedämme”. Sen tulee osoittaa eskalointi, riskikatselmointi, johdon näkyvyys, korjaavat toimenpiteet ja uudelleenarviointi.

NIS2 Article 23 lisää toisen ulottuvuuden. Jos paikkaamattoman haavoittuvuuden hyväksikäyttö aiheuttaa tai voi aiheuttaa vakavan operatiivisen häiriön, taloudellisen menetyksen tai vahinkoa muille henkilöille, siitä voi tulla merkittävä poikkeama. Raportoinnin elinkaareen kuuluu varhaisvaroitus 24 tunnin kuluessa merkittävän poikkeaman havaitsemisesta, poikkeamailmoitus 72 tunnin kuluessa, väliraportit pyynnöstä sekä loppuraportti kuukauden kuluessa poikkeamailmoituksesta. Loppuraportin tulee sisältää vakavuus, vaikutus, todennäköinen juurisyy, lieventämistoimenpiteet ja rajat ylittävät vaikutukset soveltuvin osin.

Siksi SLA-prosessin tulee kytkeytyä tietoturvapoikkeamiin reagointiin. Kriittisen haavoittuvuuden, johon liittyy näyttöä aktiivisesta hyväksikäytöstä, tulee käynnistää tietoturvan luokittelu ja priorisointi, seuranta, todistusaineiston säilyttäminen ja raportointiarviointi, ei vain rutiininomainen paikkaustiketti.

DORA:n ICT-riski: korjausaikataulut häiriönsietokyvyn näyttönä

Rahoitusalan toimijoihin DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhtenäiset vaatimukset ICT-riskien hallinnalle, merkittävien ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen toiminnallisen häiriönsietokyvyn testaukselle, tietojen jakamiselle ja ICT-kolmansien osapuolten riskien hallinnalle. Sitä käsitellään NIS2:n kansallisissa säännöissä tunnistettujen katettujen rahoitusalan toimijoiden toimialakohtaisena EU-säädöksenä.

DORA:n toimintamalli on lähellä integroitua ISMS:ää. Articles 5 ja 6 edellyttävät hallinnointia, toimintapolitiikkoja, menettelyjä, työkaluja, vuosittaista tai säännöllistä katselmointia, auditointia, kriittisten auditointihavaintojen korjaamista ja digitaalisen toiminnallisen häiriönsietokyvyn strategiaa. Article 8 edellyttää ICT-tuettujen liiketoimintatoimintojen, tietovarojen, ICT-omaisuuserien, riippuvuuksien, kolmannen osapuolen prosessien ja legacy-ICT-riskien tunnistamista ja luettelointia. Article 9 edellyttää suojaus- ja ennaltaehkäiseviä hallintakeinoja, mukaan lukien paikkaus ja muutoksenhallinta. Articles 11 ja 12 edellyttävät jatkuvuutta, reagointia, toipumista, varmuuskopiointia, palautusta ja palautumistavoitteita.

DORA Articles 17 to 19 edellyttävät ICT:hen liittyvien poikkeamien hallintaprosessia, joka havaitsee, hallitsee, kirjaa, luokittelee, eskaloi, raportoi, viestii, analysoi juurisyyn ja palauttaa turvallisen toiminnan. Articles 24 to 26 edellyttävät digitaalisen toiminnallisen häiriönsietokyvyn testausta, mukaan lukien ICT-työkalujen ja -järjestelmien asianmukainen testaus, haavoittuvuuksien arvioinnit, verkkoturvallisuuden arvioinnit, puuteanalyysit, lähdekoodikatselmoinnit silloin kun mahdollista, penetraatiotestaus ja tietyille rahoitusalan toimijoille uhkaperusteinen penetraatiotestaus. Articles 28 ja 30 edellyttävät ICT-kolmansien osapuolten riskien hallintaa, ICT-palvelusopimusten rekistereitä, due diligence -selvityksiä, auditointi- ja tarkastusoikeuksia, palvelutasoja, palveluntarjoajan apua poikkeamien aikana, päättämisoikeuksia ja exit-järjestelyjä.

Korjaus-SLA:iden osalta DORA muuttaa näyttöodotuksia kolmella tavalla.

Ensinnäkin testauksesta syntyvien haavoittuvuushavaintojen tulee syöttää priorisoitua korjausprosessia. Skannausraportti ei riitä.

Toiseksi kriittisten havaintojen korjaamista tulee seurata hallinnoinnin ja auditoinnin kautta. DORA odottaa muilta kuin mikroyrityksiltä kriittisten auditointihavaintojen muodollista korjaamista.

Kolmanneksi ICT-kolmannen osapuolen palveluntarjoajat tulee sitoa mitattaviin velvoitteisiin. Jos pilvi-, SaaS- tai MSP-palveluntarjoaja hallitsee paikkausikkunaa, sopimuksen ja rekisterin tulee osoittaa, miten sen korjausaikataulut tukevat organisaation häiriönsietokykyvelvoitteita.

Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka käsittelee tätä suoraan:

Kolmansien osapuolten paikkausten ja SaaS-riskien valvonta 6.6.1 Kaikkien kolmannen osapuolen järjestelmien (SaaS, PaaS, MSP:n hallinnoimat) tulee osoittaa riittävät haavoittuvuuksien ja korjauspäivitysten hallintakeinot. 6.6.2 Toimittajien SLA:iden tulee sisältää korjausaikataulut, jotka vastaavat sisäisesti määriteltyjä, kriittisyyteen perustuvia kynnysarvoja.

Tämä kohta on usein puuttuva silta sisäisen ISO-näytön ja DORA:n toimittajavalvonnan välillä.

GDPR: kun paikkausviiveistä tulee henkilötietojen osoitusvelvollisuuden puutteita

GDPR ei ole haavoittuvuuksien hallinnan standardi, mutta se muuttaa paikkausvirheen seurauksia.

GDPR Article 5 edellyttää henkilötietojen turvallista käsittelyä ja rekisterinpitäjän kykyä osoittaa vaatimustenmukaisuus. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä, joilla varmistetaan riskiä vastaava turvallisuustaso. Kun paikkaamattomat järjestelmät käsittelevät henkilötietoja, erityisesti identiteettitietoja, taloudellisia tietoja, biometrisiä tietoja, terveystietoja, työsuhdetietoja tai KYC-tietoja, korjaus-SLA:t ovat osa käsittelyn turvallisuuden osoitusvelvollisuutta.

Viivästynyt paikkaus voi olla puolustettavissa, jos riski on arvioitu, korvaavat hallintakeinot on otettu käyttöön ja jäännösriski on hyväksytty oikean henkilön toimesta. Sitä on paljon vaikeampi puolustaa, jos haavoittuvuus oli myöhässä, internetiin avautuva ja ilman omistajaa.

Zenith Controls liittää haavoittuvuuksien hallinnan GDPR Articles 32 ja 5(1)(f):ään, koska oikea-aikainen paikkaus vähentää henkilötietojen luottamuksellisuuteen ja eheyteen kohdistuvia riskejä. Se liittää myös muutoksenhallinnan GDPR Article 24:ään ja Article 32:een, koska henkilötietoja käsittelevien järjestelmien muutokset tulee arvioida riskiperusteisesti, hyväksyä, dokumentoida ja katselmoida.

Vaatimustenmukaisuuden opetus on suoraviivainen: jos henkilötietoja on mukana, paikkausnäytön tulee sisältää tietokonteksti. Auditoijat ja valvontaviranomaiset eivät kysy vain ”paikattiinko se?” vaan myös ”mitkä tiedot olivat alttiina riskille, kuinka pitkään ja mitkä hallintakeinot pienensivät riskiä?”

Käytännön Clarysec-työnkulku auditointivalmiille SLA-näytölle

Kypsä haavoittuvuuksien korjausprosessi ei ala silloin, kun auditoija pyytää tallenteita. Se suunnitellaan tuottamaan tallenteita joka kuukausi.

Vaihe 1: Hyväksy SLA-politiikka

Aloita Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikasta tai pk-yrityksille tarkoitetusta Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikasta toimintamallisi mukaan. Räätälöi SLA-kynnysarvot riskinottohalukkuuden, sääntelyn soveltamisalan, palvelun kriittisyyden, tietojen arkaluonteisuuden ja teknisten rajoitteiden mukaan. Varmista hyväksyntä tietoturvajohtajalta, riskikomitealta tai hallintoelimeltä.

Yritysympäristöissä käytä CVSS-pisteytystä, omaisuuserän kriittisyyttä, hyväksikäytettävyyttä, internet-altistusta, tietojen arkaluonteisuutta ja liiketoimintavaikutusta. Pk-yrityksissä pidä malli yksinkertaisena mutta täsmällisenä: kriittiset korjauspäivitykset kolmen päivän kuluessa, muut korjauspäivitykset 30 päivän kuluessa, ellei voimassa olevaa poikkeusta ole.

Vaihe 2: Liitä omaisuuserät omistajiin ja kriittisiin palveluihin

Jokaisen haavoittuvuushavainnon tulee yhdistyä seuraaviin:

• Omaisuuserän nimi ja yksilöllinen tunniste
• Liiketoimintapalvelu tai sovellus
• Järjestelmäomistaja
• Tekninen omistaja
• Tietojen luokittelu
• Internet-altistus
• Toimittajariippuvuus, jos soveltuu
• Tuetun toiminnon kriittisyys

Tämä tukee ISO/IEC 27001:2022:n riskinomistajuutta, NIS2:n omaisuudenhallintaa, DORA:n ICT-omaisuuserien ja riippuvuuksien luetteloa sekä NIST CSF IDENTIFY -tavoitetuloksia.

Vaihe 3: Luokittele ja priorisoi haavoittuvuus

Luo tiketti jokaiselle havainnolle tai havaintoryhmälle. Sisällytä CVSS-pisteet, lähdeskanneri, vaikutuksen kohteena oleva omaisuuserä, hyväksikäyttötila, uhkatiedustelu, liiketoiminnan kriittisyys ja vaadittu SLA. Jos hyväksikäyttöä epäillään, liitä tiketti poikkeama-arviointiin.

Vaihe 4: Toteuta muutoksenhallinnan kautta

Paikkaus on muutos. Käytä rutiinipäivityksiin vakiomuutosta ja kriittisiin hyväksikäytettyihin haavoittuvuuksiin hätämuutosta. Sisällytä testausnäyttö, hyväksyntä, toteutuksen aikaleima, palautussuunnitelma ja muutoksen jälkeinen validointi.

Tämä vastaa Zenith Controls -suhdetta 8.8:n ja 8.32:n välillä: korjauspäivitysten asentamista hallitaan muutoksenhallinnan kautta, jotta kiireellisyys ja operatiivinen vakaus pysyvät tasapainossa.

Vaihe 5: Validoi sulkeminen

Älä sulje tikettejä pelkän ”korjauspäivitys asennettu” -tiedon perusteella. Edellytä validointia uudelleenskannauksella, version vahvistuksella, konfiguraation tarkistuksella tai korvaavan hallintakeinon vahvistuksella. Jos korjauspäivitystä ei voi asentaa, avaa poikkeus.

Vaihe 6: Kirjaa poikkeukset ja jäännösriski

Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka määrittää poikkeuspyynnön vaaditun sisällön:

Poikkeuspyyntöjen tulee sisältää: 7.2.1 Liiketoimintaperuste viivästykselle tai korjaamatta jättämiselle 7.2.2 Riskien arviointi (perustuu CVSS-pisteisiin, omaisuuserän kriittisyyteen ja uhkatiedusteluun) 7.2.3 Ehdotetut korvaavat hallintakeinot 7.2.4 Aikataulu korjaamiselle tai uudelleenarvioinnille

Se määrittää myös hyväksynnän ja katselmoinnin:

Poikkeukset tulee hyväksyä tietoturvajohtajan tai delegoidun riskikomitean toimesta ja kirjata ISMS-poikkeusrekisteriin; katselmointiväli saa olla enintään 90 päivää.

Tästä poikkeusrekisteristä tulee olennainen näyttö ISO/IEC 27001:2022 Clause 6.1.3:n riskien käsittelystä ja jäännösriskin hyväksynnästä sekä johdon katselmoinnista.

Tämä tallenne osoittaa, ettei organisaatio sivuuttanut haavoittuvuutta. Se arvioi riskin, otti käyttöön korvaavat hallintakeinot, hyväksyi jäännösriskin ja määritti katselmointipäivän.

Vaihe 7: Rakenna kuukausittainen näyttöpaketti

Kuukausittaisen haavoittuvuuksien korjaamisen näyttöpaketin tulee sisältää:

Pk-yrityksissä näyttö voi olla kevyempi, mutta sen tulee silti olla johdonmukaista. Pk-yrityksille tarkoitettu Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka edellyttää jäljitettävyyden sisältäviä paikkauslokeja:

Lokien tulee sisältää laitteen nimi, asennettu päivitys, paikkauspäivä ja mahdollisen viivästyksen syy

Tämä yksittäinen kohta on auditoinnin kannalta erittäin arvokas. Se muuttaa paikkauksen väitteestä tallenteeksi.

Toimittajien paikkaus: sopimuksen tulee vastata SLA:ta

Jos MSP, SaaS-palveluntarjoaja, PaaS-palveluntarjoaja tai pilvipalveluntarjoaja hallitsee korjauspäivitysten käyttöönottoa, sisäiset SLA:t ovat hyödyttömiä, elleivät toimittajavelvoitteet vastaa niitä.

Pk-yrityksille tarkoitettu Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka sisältää tietoturvavelvoitteet hallinnointivaatimuksena. Haavoittuvuuksien korjaamisessa näiden velvoitteiden tulee muuttua mitattavaksi sopimuskieleksi:

• Kriittisten haavoittuvuuksien ilmoitusajat
• Kriittisten, korkeiden, keskitasoisten ja matalien haavoittuvuuksien korjausaikataulut
• Hätämuutosprosessi
• Asiakkaan hyväksyntävaatimukset käyttökatkoille
• Näytön muoto korjauspäivityksen valmistumisesta
• Haavoittuvuuksien julkistamisprosessi
• Poikkeamanaikaiset avustusvelvoitteet
• Oikeus auditoida tai vastaanottaa varmennusraportteja
• Alikäsittelijän tai alihankkijan paikkausvelvoitteet
• Exit- ja siirtymätuki kriittisille palveluille

Zenith Blueprint, Controls in Action -vaihe, Step 20, Control 8.21 Security of network services, ilmaisee periaatteen selkeästi:

Kun palveluja tuotetaan ulkoisesti, mukaan lukien internet-palveluntarjoajat, SD-WAN-toimittajat tai yksityiset pilvipalveluntarjoajat, tietoturvavaatimukset tulee sisällyttää sopimuksiin ja SLA:ihin. Tämä sisältää käyttöaikatakuut, vasteajat poikkeamiin, velvoitteet paikata tai lieventää haavoittuvuuksia sekä selkeät tietojen käsittelyn rajat. Palveluntarjoajan ei tule koskaan olettaa täyttävän odotuksia, ellei se ole kirjattu, mitattavissa ja auditoitavissa.

DORA tekee tästä erityisen tärkeää rahoitusalan toimijoille. ICT-kolmannen osapuolen järjestelyjen tulee sisältää palvelutasot, palveluntarjoajan apu ICT-poikkeamien aikana, tietojen saatavuus ja palautus, yhteistyö viranomaisten kanssa, päättämisoikeudet sekä vahvemmat määräykset kriittisille tai tärkeille toiminnoille, mukaan lukien seuranta, auditointioikeudet, varautumissuunnitelmat ja turvatoimet.

NIST CSF 2.0 sanoo saman toimitusketjun riskitulosten kautta: toimittajat tulee tuntea, priorisoida kriittisyyden mukaan, arvioida ennen sitoutumista, hallita sopimusvaatimuksilla, seurata koko suhteen ajan, sisällyttää poikkeamasuunnitteluun ja hallita yhteistyön päättyessä.

Mitä auditoijat todella kysyvät

Auditointikeskustelu muuttuu auditoijan taustan mukaan.

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:stä. Hän tarkistaa, sisältyykö haavoittuvuuksien hallinta soveltuvuuslausuntoon, tunnistaako riskien arviointi paikkaamattomat järjestelmät riskiksi, onko riskienkäsittelysuunnitelmilla omistajat ja aikataulut, onko liitteen A hallintakeino 8.8 toteutettu, säilytetäänkö näyttö ja arvioivatko sisäinen auditointi ja johdon katselmointi suorituskykyä.

Zenith Blueprint, Controls in Action -vaihe, Step 19, tekee auditointiodotuksesta täsmällisen:

Tämä on auditoijille korkean prioriteetin hallintakeino, ja he yleensä perehtyvät siihen perusteellisesti. Odota kysymyksiä siitä, kuinka usein järjestelmät paikataan, mitä prosessia noudatatte, kun zero-day-haavoittuvuus julkistetaan, ja mitkä järjestelmät ovat vaikeimpia paikata.

Se jatkaa käytännön näyttöodotuksilla:

Auditoijat pyytävät todennäköisesti haavoittuvuusskannausten tuloksia. Jos käytössä on Nessus-, OpenVAS- tai Qualys-työkaluja, vie raportti, joka näyttää viimeaikaiset havaitut haavoittuvuudet ja miten ne käsiteltiin. Ihannetilanteessa raportin tulee sisältää riskiluokitukset (CVSS) ja korjausaikataulut.

NIS2-painotteinen auditoija tai toimivaltainen viranomainen etsii hallintoelintason hyväksyntää, suhteellisuutta, kyberhygieniaa, haavoittuvuuksien käsittelyä, toimittajaturvallisuutta, poikkeamien käsittelyä, vaikuttavuuden arviointia, korjaavia toimenpiteitä ilman aiheetonta viivytystä sekä raportointipäätösten tallenteita, jos hyväksikäyttö aiheutti merkittävän vaikutuksen.

DORA-valvoja testaa, onko haavoittuvuushavainnot integroitu ICT-riskien hallintaan, digitaalisen toiminnallisen häiriönsietokyvyn testaukseen, poikkeamien luokitteluun, juurisyyanalyysiin, kolmansien osapuolten rekistereihin, sopimusvelvoitteisiin, auditointioikeuksiin ja kriittisten havaintojen korjaamiseen.

NIST CSF -arvioija jäsentää katselmoinnin todennäköisesti GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-toimintojen ympärille. Hän kysyy, ymmärretäänkö lakisääteiset ja sopimusperusteiset vaatimukset, onko riskinsietokyky dokumentoitu, tunnistetaanko ja priorisoidaanko haavoittuvuudet, hallitaanko poikkeuksia, havaitseeko seuranta hyväksikäytön ja koordinoidaanko reagointi- ja palautustoimet.

COBIT 2019- tai ISACA-tyyppinen auditoija keskittyy hallinnointitavoitteisiin, prosessin kyvykkyyteen, johtamiskäytäntöihin, mittareihin, omistajuuteen, hallintakeinojen suunnitteluun, hallintakeinojen toimintaan ja näytön riittävyyteen. Hän kysyy, onko haavoittuvuuksien korjaaminen toistettavaa, mitattua, eskaloitua, parannettua ja yhdenmukaista yrityksen tavoitteiden ja riskinottohalukkuuden kanssa.

Eskalointi ja mittarit: miten osoitat, että SLA:ta hallitaan

SLA ilman eskalointia on vain tavoite. Puolustettava haavoittuvuuksien korjausohjelma tarvitsee eskalointia ennen rikkomusta, rikkomuksen yhteydessä ja toistuvan epäonnistumisen jälkeen.

Clarysec suosittelee nelitasoista eskalointimallia:

1. Operatiivinen eskalointi, tiketin omistajalle ja tekniselle vastuuhenkilölle ilmoitetaan ennen rikkomusta.
2. Riskieskalointi, omaisuuden omistaja ja riskinomistaja tarkastelevat vaikutusta, kun rikkomus on todennäköinen.
3. Tietoturvan hallinnoinnin eskalointi, tietoturvajohtaja tai riskikomitea hyväksyy poikkeuksen tai hätätoimenpiteen.
4. Johdon eskalointi, toistuvat tai kriittiset SLA-rikkomukset raportoidaan johdon katselmointiin korjaavien toimenpiteiden kanssa.

Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka vahvistaa tämän auditointiodotuksen:

Sisäisen auditoinnin tai riippumattoman kolmannen osapuolen tulee suorittaa säännöllisiä auditointeja varmistaakseen: 5.6.1 SLA:iden noudattaminen 5.6.2 Näyttö riskiperusteisesta priorisoinnista 5.6.3 Käyttöönotettujen korjauspäivitysten toimivuus 5.6.4 Hallintakeinot paikkaamattomille järjestelmille

Mittareiden tulee tukea päätöksiä, ei koristella hallintanäkymiä. Vahvimpia vuoden 2026 mittareita ovat:

• Kriittisten SLA:iden noudattamisprosentti
• Korkeiden SLA:iden noudattamisprosentti
• Keskimääräinen luokittelu- ja priorisointiaika
• Keskimääräinen korjausaika omaisuuseräluokittain
• Myöhässä olevien kriittisten haavoittuvuuksien määrä
• Hyväksyttyjen poikkeusten määrä iän mukaan
• Yli 90 päivää avoinna olevat poikkeukset
• Internetiin avautuvien kriittisten altistusten määrä
• Toimittajien SLA-rikkomukset
• Validoinnin jälkeen uudelleen avatut haavoittuvuudet
• Hyväksikäytettyjen haavoittuvuuksien aiheuttamat hätämuutokset
• Paikkausvirheet alustan tai liiketoimintayksikön mukaan

Liitä nämä mittarit ISO/IEC 27001:2022 Clause 9.3:n johdon katselmointiin, DORA:n hallinnointiraportointiin ja NIS2:n johdon valvontaan. NIST CSF 2.0:ssa käytä niitä nykyisten ja tavoiteprofiilien, puuteanalyysin ja toimintasuunnitelmien päivittämiseen.

Clarysecin korjaus-SLA-tarkistuslista

Käytä tätä tarkistuslistaa nykyisen ohjelmasi arviointiin:

• Onko hyväksytty haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka olemassa?
• Onko korjaus-SLA:t määritelty vakavuuden ja liiketoiminnan kriittisyyden perusteella?
• Nopeutetaanko internetiin avautuvien ja hyväksikäytettyjen haavoittuvuuksien käsittelyä?
• Onko omaisuuserät liitetty omistajiin, palveluihin, tietoihin ja toimittajiin?
• Muunnettiinko skannerihavainnot osoitetuiksi tiketeiksi?
• Toteutetaanko korjauspäivitykset muutoksenhallinnan kautta?
• Dokumentoidaanko ja katselmoidaanko hätämuutokset?
• Validoidaanko korjaustulokset uudelleenskannauksilla tai versiotarkistuksilla?
• Arvioidaanko, hyväksytäänkö ja katselmoidaanko poikkeukset riskiperusteisesti vähintään 90 päivän välein?
• Dokumentoidaanko korvaavat hallintakeinot paikkauskelvottomille järjestelmille?
• Ovatko toimittajasopimukset yhdenmukaisia sisäisten korjauskynnysten kanssa?
• Ovatko korjauspäivityslokit riittävän täydellisiä osoittamaan, mitä tapahtui ja milloin?
• Eskaloidaanko ja korjataanko SLA-rikkomukset?
• Katselmoiko johto mittarit?
• Käynnistyvätkö poikkeama- ja loukkausarvioinnit, kun hyväksikäyttöä epäillään?

Jos useaan kysymykseen vastaus on ”ei”, ongelma ei ole työkalustossa. Ongelma on hallintakeinojen suunnittelussa.

Seuraavat vaiheet: muuta paikkausmääräajat auditoinnissa osoitettavaksi häiriönsietokyvyksi

Vuonna 2026 haavoittuvuuksien korjaus-SLA:iden tulee tehdä enemmän kuin tyydyttää skannerin hallintanäkymä. Niiden tulee osoittaa, että organisaatio pystyy tunnistamaan altistumisen, priorisoimaan riskin, toimimaan hyväksytyissä aikatauluissa, hallitsemaan poikkeuksia, hallinnoimaan toimittajia ja tuottamaan näyttöä päätöksistä ISO/IEC 27001:2022:n, NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019:n auditointiodotuksissa.

Clarysec auttaa siirtymään hajanaisista paikkaustiketeistä integroituun, näyttöön perustuvaan haavoittuvuuksien korjausohjelmaan seuraavien avulla:

• Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka
• Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka pk-yrityksille
• Kolmansien osapuolten ja toimittajien turvallisuuspolitiikka pk-yrityksille
• Zenith Blueprint: auditoijan 30-vaiheinen tiekartta
• Zenith Controls: vaatimustenmukaisuuksien välinen opas

Aloita yhdestä korkean riskin palvelusta. Kartoita sen omaisuuserät, toimittajat, haavoittuvuudet, tiketit, muutokset, poikkeukset ja näyttö. Suorita sen jälkeen auditointikysymykset sitä vasten. Jos et pysty osoittamaan SLA:ta havaitsemisesta sulkemiseen, se on ensimmäinen korjausprojektisi.

Tavoite ei ole täydellinen paikkaus. Tavoite on hallinnoitu, riskiperusteinen, mitattava ja auditoitavissa oleva korjaaminen. Lataa Clarysecin politiikkamallit, suorita kohdennettu puuteanalyysi tai varaa Clarysec-demo ja muuta haavoittuvuuksien korjaaminen auditointipaineesta toiminnalliseksi häiriönsietokyvyksi.