Haavoittuvuuksien hallinnan elinkaari ohjelmistotoimittajille

Mikä on haavoittuvuuksien hallinnan elinkaari?

Haavoittuvuuksien hallinnan elinkaari on toistettava prosessi, jota tuotetoimittaja noudattaa käsitellessään haavoittuvuutta toimittamassaan ohjelmistossa: haavoittuvuus vastaanotetaan tai löydetään, varmennetaan, selvitetään mihin se vaikuttaa, korjataan, korjaus julkaistaan ja asiakkaille kerrotaan. Toimittajaorganisaatiossa prosessia vetää yleensä tuoteturvallisuuden häiriötilanteisiin reagoiva tiimi (PSIRT), ja kehitystiimit tekevät korjaukset.

Tämä sivu käsittelee toimittajan näkökulmaa. IT-ympäristön haavoittuvuuksien hallinta, eli organisaation omien palvelinten ja kannettavien skannaus ja paikkaus, jakaa saman sanaston mutta ei vaikeita osia. Toimittajan on vastattava jokaisesta tuetusta julkaisusta, joka on asiakkaiden käytössä, ja sen on julkaistava, mitä se löysi.

Elinkaaren vaiheet

1. Vastaanota tai löydä. Haavoittuvuuksia tulee ulkopuolisilta tutkijoilta julkistamisohjelmasi kautta, asiakkailta, koordinaattoreilta, kuten kansallisilta CSIRT-yksiköiltä, sekä omasta valvonnastasi: uusi CVE avoimen lähdekoodin riippuvuudessa, skannerin löydös tai sisäinen testi. Kirjaa jokainen seurantatunnuksella ja kuittaa ulkopuolisille ilmoittajille.
2. Varmenna ja tee triage. Toista ongelma tai vahvista riippuvuusosuma, päätä, onko kyse haavoittuvuudesta tuotteessasi, ja arvioi, kuinka vakava ja kiireellinen se on. Sulje se, mikä ei koske tuotettasi, perusteella, jonka voit näyttää myöhemmin. Priorisointisignaalit, kuten EPSS ja CISA KEV -luettelo, auttavat järjestämään jäljelle jäävät.
3. Arvioi haavoittuvat tuotteet ja versiot. Etsi jokainen tuote, julkaisu ja tuettu haara, joka sisältää haavoittuvan koodin tai komponentin, ja jokainen asiakasasennus, joka ajaa sellaista. Tämä vaihe ratkaisee korjauksen ja tietoturvatiedotteen laajuuden.
4. Korjaa. Vastuussa oleva tiimi kehittää ja testaa korjauksen: päivitetyn riippuvuuden, koodimuutoksen tai lievennyksen, kuten määritysmuutoksen, kun korjaus ei ole vielä mahdollinen.
5. Julkaise korjaus. Toimita päivitetyt versiot jokaiseen haavoittuvaan tuettuun haaraan kanavan kautta, johon asiakkaat voivat luottaa.
6. Tiedota ja julkista. Julkaise tietoturvatiedote, joka kertoo, mihin haavoittuvuus vaikuttaa, kuinka vakava se on ja mitä pitää tehdä, anna CVE-tunnus tai viittaa siihen ja mainitse ilmoittaja. Koneluettavat muodot, kuten CSAF ja VEX, antavat asiakkaiden käsitellä tiedotteet automaattisesti.
7. Valvo ja opi. Seuraa hyödyntämistä ja uutta tietoa, päivitä tiedotetta ja vie juurisyy takaisin kehitykseen, jotta samanlainen vika ei pääse taas toimitukseen.

ISO/IEC 30111 ja ISO/IEC 29147

Kaksi kansainvälistä standardia kuvaa tämän elinkaaren toimittajille. Ne jakavat sen organisaation rajalla:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Nimi	Haavoittuvuuksien käsittelyprosessit	Haavoittuvuuksien julkistaminen
Kattaa	Sen, mitä tapahtuu sisäisesti: varmentamisen, tutkimisen, priorisoinnin ja korjaamisen	Rajapinnat: ilmoitusten vastaanottamisen ja tietoturvatiedotteiden julkaisemisen
Keskeinen sisältö	Käytännöt ja organisointi, PSIRT-tiimin vastuut, käsittelyvaiheet, toimitusketjunäkökohdat	Sidosryhmien roolit, ilmoitusten käsittely, tiedotteiden sisältö, koordinointi, julkistamiskäytäntö
Kohderyhmä	Toimittajat, jotka käsittelevät ilmoitettuja haavoittuvuuksia	Toimittajat, jotka vastaanottavat ilmoituksia ja julkistavat haavoittuvuuksia

Standardit on suunniteltu käytettäviksi yhdessä. ISO/IEC 30111 nimeää kuusi käsittelyvaihetta: valmistelu, vastaanotto, varmentaminen, korjauksen kehittäminen, julkaisu ja julkaisun jälkeinen vaihe. Se edellyttää myös prosessin seurantaa, haavoittuvuustietojen luottamuksellisuutta ja huomiota toimitusketjuun, koska monet haavoittuvuudet ovat komponenteissa, joita et itse kirjoittanut. Molemmat standardit ovat voimassa olevia painoksia, jotka vahvistettiin ISO:n viimeisimmissä katselmuksissa, ja ne on merkitty uudistettaviksi.

Muut viitekehykset noudattavat samaa rakennetta. FIRST PSIRT Services Framework jakaa työn haavoittuvuuksien löytämiseen, triageen ja analyysiin, korjaamiseen ja julkistamiseen, ja IEC 62443-4-1 sisällyttää tietoturvapäivitysten ja vikojen hallinnan teollisuustuotteiden turvalliseen kehityksen elinkaareen.

Roolit

• PSIRT tai tuoteturvallisuustiimi: omistaa prosessin, vastaanottaa ilmoitukset, tekee triagen, koordinoi korjaukset ja julkaisee tietoturvatiedotteet. Katso CRACI PSIRT-tiimeille ja miten PSIRT eroaa CSIRT-yksiköstä.
• Tuote- ja kehitystiimit: omistavat koodin, kehittävät ja testaavat korjaukset ja toimittavat julkaisut.
• Julkaisunhallinta: päättää, mitkä tuetut haarat saavat korjauksen ja milloin.
• Asiakastuki ja viestintä: hoitavat asiakkaiden kysymykset ja tietoturvatiedotteen yleisön.
• Lakiasiat: neuvoo julkistamisessa, sopimuksissa ja viranomaisilmoituksissa.
• Ulkopuoliset osapuolet: ilmoittajat, koordinaattorit, kuten CERT/CC tai kansallinen CSIRT-yksikkö, haavoittuvien komponenttien upstream-ylläpitäjät ja asiakkaat, joiden on otettava korjaus käyttöön.

Aikataulut ja SLA:t

Yhtä vaadittua aikataulua ei ole. Useimmat toimittajat asettavat sisäiset tavoitteet vakavuuden mukaan ja julkaisevat ulkoiset julkistamiskäytännössään. Tyypillinen rakenne:

• Kuittaa ulkopuolinen ilmoitus muutaman arkipäivän kuluessa.
• Tee triage päivien kuluessa, jotta ilmoittaja ja vastuussa oleva tiimi tietävät, missä mennään.
• Korjaa vakavuuden ja hyödyntämisen mukaan asetetussa ajassa, lyhimmässä kriittisille löydöksille ja kaikelle, jota tiedetään hyödynnettävän.
• Julkista, kun korjaus on saatavilla, tai sovittuna määräpäivänä, jos korjaus viivästyy.

Ulkoinen paine asettaa ylärajan. Tutkijat asettavat usein julkistamisen määräajan (Google Project Zero antaa toimittajille 90 päivää), ja sääntely tuo omansa: EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) edellyttää valmistajilta haavoittuvuuksien korjaamista "viipymättä" ja asettaa raportointimääräajat aktiivisesti hyödynnetyille haavoittuvuuksille (katso, mitä kyberkestävyyssäädös vaatii). Kun haavoittuvuutta jo hyödynnetään, kuten nollapäivähaavoittuvuuden kohdalla, jokainen vaihe etenee lyhimmällä aikataululla.

Missä elinkaari katkeaa

Useimmat viiveet eivät johdu korjauksen kirjoittamisesta. Ne johtuvat siitä, ettei tiedetä, mitä on toimitettu.

• Ei tiedetä, mitkä julkaisut sisältävät komponentin. Kirjastoon tulee uusi CVE. Mitkä viime vuoden julkaisuista sisältävät sen, ja mitkä asiakkaat ajavat niitä? Ilman julkaisukohtaista kirjausta tiimit rakentavat vanhoja tageja uudelleen tai etsivät repositorioista käsin, ja tietoturvatiedotteen haavoittuvien versioiden luettelo on arvaus.
• Transitiiviset riippuvuudet. Monet haavoittuvat paketit eivät ole itse valitsemiasi. Ne tulevat transitiivisina riippuvuuksina useamman tason syvyydeltä, joten manifestien haku ei löydä niitä.
• Kehitysriippuvuuksien kohina. Lukitustiedostoja lukevat skannerit raportoivat testikehyksiä ja build-työkaluja, jotka eivät koskaan päädy toimitukseen. Jokainen niistä vie triage-aikaa ja hautaa alleen olennaiset löydökset.
• Paketinhallinnan ulkopuoliset komponentit. Build-skriptien lataamat binäärit, peruskuvat ja toimittajien komponentit eivät näy lukitustiedostossa lainkaan.
• Epäselvä omistajuus. Löydös, jota mikään tiimi ei omista, jää odottamaan. Triage on valmis vasta, kun korjauksella on omistaja.
• Korjaukset, jotka eivät pysy. Haavoittuva versio palaa toisen riippuvuuden tai vanhan haaran kautta, koska mikään ei estä sitä pääsemästä seuraavaan buildiin.

Pienet tiimit törmäävät näihin katkoksiin ensimmäisinä, koska jokainen niistä toistuu jokaisen CVE:n kohdalla. Haavoittuvuuksien hallinnan automatisointi kertoo, mitä automatisoida ja missä järjestyksessä, ja haavoittuvuuskohinan vähentäminen käsittelee kehitysriippuvuudet, kaksoiskappaleet ja omistajattomat löydökset, jotka hautaavat alleen olennaiset.

Mittarit

Mittari	Mitä se näyttää
Aika kuittaukseen	Saavatko ilmoittajat vastauksen silloin, kun käytäntösi lupaa
Aika triageen	Kuinka kauan löydös odottaa, ennen kuin kukaan tietää, onko sillä merkitystä
Aika korjaukseen vakavuuden mukaan	Kuinka nopeasti korjaukset toimitetaan, vastaanotosta saatavilla olevaan julkaisuun
Aika tiedotteeseen	Kuinka kauan asiakkaat odottavat tietoa korjauksen jälkeen
Tavoitteessa pysyvien osuus	Pitävätkö sisäiset SLA:t, erityisesti kriittisten ja hyödynnettyjen löydösten osalta
Jono iän mukaan	Juuttuneet löydökset ja se, missä ne ovat juuttuneet
Ei koske -osuus	Kuinka paljon triage-työtä menee löydöksiin, jotka eivät koske tuotetta

Mittaa jokainen vaihe erikseen. Pitkä korjausaika osoittautuu usein pitkäksi ajaksi haavoittuvien julkaisujen löytämisessä.

Aja elinkaarta kirjauksen pohjalta siitä, mitä toimitit

Jokainen triagen jälkeinen vaihe riippuu siitä, että tiedät, mitä kussakin julkaisussa on. CRACI ajaa GitHub Actions -buildisi omilla runnereillaan ja kirjaa paketit, jotka kukin jobi oikeasti haki, mukaan lukien transitiiviset riippuvuudet, CI-välimuisteista palautetut paketit ja riippuvuudet, joita mikään lukitustiedosto ei listaa. Jokaisella SBOM:lla on kattavuustila, ja sen voi viedä CycloneDX- tai SPDX-muodossa.

CRACI arvioi valvottuja SBOM:ia jatkuvasti uudelleen ja kokoaa ne buildien ja repositorioiden yli, ja toimittajien SBOM:ja voi lisätä, jotta ostettuja komponentteja valvotaan omiesi rinnalla. Kun uusi CVE ilmestyy, build-historia näyttää, mitkä aiemmat buildit sisälsivät haavoittuvan riippuvuuden, suoran tai transitiivisen, joten tiedät ajanjakson, jolloin olit altis, ja inventaarionäkymä näyttää, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa. Tietoturvatiimit tekevät löydösten triagen CRACI:ssa ja lähettävät ne korjauksesta vastaaville tiimeille, CRACI tukee VEX:iä, ja käytäntöportit voivat estää buildit, jotka sisältävät tietyn CVE:n, jotta korjattu haavoittuvuus pysyy poissa. Katso haavoittuvuuksien seuranta.

Haavoittuvuuksien hallinnan elinkaari: usein kysytyt kysymykset

Mitkä ovat haavoittuvuuksien hallinnan elinkaaren vaiheet?

Tuotetoimittajalle: haavoittuvuuden vastaanotto tai löytäminen, varmentaminen ja triage, haavoittuvien tuotteiden ja versioiden selvittäminen, korjauksen kehittäminen, korjauksen julkaisu, tietoturvatiedotteen julkaisu sekä valvonta ja oppiminen. ISO/IEC 30111 nimeää vaiheet valmisteluksi, vastaanotoksi, varmentamiseksi, korjauksen kehittämiseksi, julkaisuksi ja julkaisun jälkeiseksi vaiheeksi.

Mikä on ISO/IEC 30111?

ISO/IEC 30111:2019 on haavoittuvuuksien käsittelyprosessien kansainvälinen standardi. Se antaa toimittajille vaatimuksia ja suosituksia tuotteidensa ja palvelujensa ilmoitettujen haavoittuvuuksien käsittelyyn ja korjaamiseen, käytännöistä ja PSIRT-tiimin roolista käsittelyvaiheisiin ja toimitusketjunäkökohtiin.

Mitä eroa on ISO/IEC 30111:llä ja ISO/IEC 29147:llä?

ISO/IEC 29147 kattaa ulospäin näkyvän osan: ilmoitusten vastaanottamisen ja tietoturvatiedotteiden julkaisemisen. ISO/IEC 30111 kattaa niiden välissä olevan sisäisen käsittelyn: varmentamisen, tutkimisen, priorisoinnin ja korjaamisen. Ne on tarkoitettu käytettäviksi yhdessä. Katso 29147:n puolelta koordinoitu haavoittuvuuksien julkistaminen.

Mitä haavoittuvuuksien triage on?

Triage on vaihe, jossa tietoturvatiimi vahvistaa, että ilmoitettu tai löydetty haavoittuvuus on todellinen, arvioi, kuinka vakava ja kiireellinen se on tuotteellesi, ja lähettää sen korjauksesta vastaavalle tiimille. Hyvä triage myös sulkee löydökset, jotka eivät koske tuotetta, ja kirjaa perusteen.

Miten tuotteiden haavoittuvuuksien hallinta eroaa IT-ympäristön haavoittuvuuksien hallinnasta?

IT-ympäristön haavoittuvuuksien hallinta paikkaa järjestelmiä, joita organisaatio ajaa. Tuotteiden haavoittuvuuksien hallinta käsittelee vikoja ohjelmistoissa, jotka organisaatio rakentaa ja toimittaa muille, joten siihen kuuluu vaiheita, joita IT-tiimeillä ei ole: sen selvittäminen, mitkä julkaistut versiot ovat haavoittuvia, korjauksen toimittaminen asiakkaille ja heidän tiedottamisensa tietoturvatiedotteella.

Mitä mittareita haavoittuvuuksien käsittelyprosessin pitäisi seurata?

Aika ilmoituksen kuittaukseen, aika triageen, aika korjaukseen ja aika tietoturvatiedotteeseen, kukin vakavuuden mukaan, sekä sisäiset tavoitteesi täyttävien löydösten osuus, avoin jono iän mukaan ja se, kuinka monta löydöstä suljettiin, koska ne eivät koskeneet tuotetta.