Kriittinen haavoittuvuus julkaistaan, tietoturvatiedote leviää, ja tunnin sisällä joku kysyy yrityksen chatissa: koskeeko tämä meitä? Log4Shell teki kysymyksestä kuuluisan. CVE-2021-44228 koski Log4j Corea versiosta 2.0-beta9 versioon 2.15.0 asti. Kirjasto oli useita tasoja syvällä lukemattomien Java-tuotteiden riippuvuuspuussa, ja useimmat tiimit joutuivat selvittämään kantapään kautta, missä se oli.

Kysymys kuulostaa yksinkertaiselta. Todellisuudessa se on kolme kysymystä:

  1. Onko haavoittuva komponentti jossakin, mitä rakennamme tai toimitamme?
  2. Jos on, voidaanko sitä hyödyntää tuotteessamme?
  3. Mistä lähtien, ja missä julkaisuissa?

Useimmat prosessit vastaavat kahteen ensimmäiseen. Kolmatta asiakkaat, auditoijat ja viranomaiset kysyvät seuraavaksi, ja siihen on vaikein vastata jälkikäteen.

Vaihe 1: Selvitä, onko komponentti mukana

Yritykset päätyvät vastaukseen yleensä yhdellä neljästä tavasta, suunnilleen kypsyysjärjestyksessä.

Kysele ja hae. Joku kirjoittaa Slackiin, kehittäjät hakevat paketin nimeä repositorioistaan ja lukitustiedostoistaan, ja vastaukset kerätään taulukkoon. Tämä on edelleen yleisin menetelmä. Se on hidas, riippuu siitä, kuka vastaa, eikä näe mitään, mitä ei ole ilmoitettu tiedostossa: riippuvuuksien riippuvuuksia, vendoroituja kirjastoja, pohjakuvia tai buildin aikana asennettuja työkaluja.

Tarkista skannerien näkymät. Riippuvuusskannerit liputtavat CVE:n repositoriokohtaisesti muutamassa tunnissa. Se on nopeampaa, mutta skanneri raportoi siitä koodista, joka sen edessä on tällä hetkellä, yleensä oletushaarasta. Se ei kerro, mitä julkaisuja asiakkaasi käyttävät tai mitä kolme kuukautta sitten ajettu buildi todella haki.

Kysy SBOM-inventaariolta. Tiimit, jotka säilyttävät ohjelmiston materiaaliluettelon (SBOM) jokaisesta julkaisusta, voivat esittää yhden kysymyksen kaikille niistä: mitkä tuotteet ja versiot sisältävät tämän paketin haavoittuvia versioita? Tämä on ensimmäinen menetelmä, joka vastaa toimitetun ohjelmiston osalta eikä vain repositoriossa olevan.

Vertaa jatkuvasti. Kun SBOM:eja seurataan haavoittuvuustietoja vasten, luettelo haavoittuvuuden koskemista tuotteista on olemassa ennen kuin kukaan kysyy. Chat-ketju alkaa vastauksella eikä kysymyksellä.

Jokaisen menetelmän laatu riippuu siitä, mitä inventaario todella sisältää. Tavalliset katvealueet ovat:

  • Transitiiviset riippuvuudet. Haavoittuva paketti on harvoin sellainen, jonka lisäsit itse. Se tulee mukaan kolme tai neljä tasoa syvemmältä.
  • Kaikki, mitä manifesti ei ilmoita. Build-skriptien asentamat paketit, npx-työkalut, Dockerfile-vaiheet, palautetut välimuistit sekä vendoroitu C- ja C++-koodi.
  • Vanhat julkaisut. Haaraa, joka ei enää käänny, ei voi skannata uudelleen, mutta siitä rakennettu tuote voi yhä olla käytössä kentällä.

Vaihe 2: Päätä, onko sillä merkitystä

Komponentti voi olla mukana olematta todellinen riski, joten seuraava vaihe on triage eli luokittelu ja priorisointi:

  • Versio ja konfiguraatio. Osuuko versio tarkalleen haavoittuvien versioiden välille? Onko haavoittuva ominaisuus käännetty mukaan ja käytössä?
  • Reachability-analyysi. Kutsuuko koodisi haavoittuvaa funktiota lainkaan?
  • Altistus. Onko komponenttiin pääsy verkosta tai epäluotettavasta syötteestä, vai käytetäänkö sitä vain buildin aikana?
  • Lievennykset. Onko käytössä hiekkalaatikko, verkkorajoitus tai konfiguraatio, joka estää hyödyntämisen?
  • Hyödyntämisen signaalit. CVSS kertoo vakavuuden, EPSS arvioi todennäköisyyden, että CVE:tä hyödynnetään seuraavien 30 päivän aikana, ja CISA:n Known Exploited Vulnerabilities -luettelo listaa ne, joita jo hyödynnetään. Yhdessä ne ratkaisevat, mitä tarkastellaan ensin.

Vaihe 3: Kirjaa päätös

Lopputulos kirjataan tuote- ja versiokohtaisesti, yhä useammin VEX-lausuntona (Vulnerability Exploitability eXchange). CISA:n VEX:n vähimmäisvaatimukset määrittelevät neljä tilaa: not affected, affected, fixed ja under investigation. "Not affected" -lausunnon on kerrottava syy, esimerkiksi että haavoittuvaa koodia ei ole mukana tai hyökkääjä ei pääse siihen käsiksi.

Tämä kirjaus ruokkii kaikkea, mitä seuraa: korjausta ja julkaisuja, joissa se on mukana, asiakkaille tarkoitettua tietoturvatiedotetta ja kaikkia viranomaisen odottamia raportteja. Esimerkiksi EU:n kyberkestävyyssäädöksen (Cyber Resilience Act) mukaan valmistajan on lähetettävä ennakkovaroitus tuotteessaan olevasta aktiivisesti hyödynnetystä haavoittuvuudesta 24 tunnin kuluessa siitä, kun se on saanut tiedon siitä.

Vaihe 4: Selvitä altistusikkuna

Kysymyksellä "koskeeko tämä meitä?" on toinen puolisko, joka usein ohitetaan: kuinka kauan se koski meitä?

Haavoittuvuus oli olemassa kauan ennen CVE:n julkaisua. Log4Shell oli ollut Log4j:ssä versiosta 2.0-beta9 lähtien, joka julkaistiin vuosia ennen kuin kukaan paljasti sen. Altistuksesi alkoi päivänä, jona buildi ensimmäisen kerran haki haavoittuvan version, ja päättyi päivänä, jona viimeinen sen sisältänyt buildi korvattiin. Tarvitset tämän ikkunan, jotta voit:

  • kertoa asiakkaille, mitkä heidän käyttämistään julkaisuista ovat haavoittuvia, eikä vain uusimmasta
  • rajata tietoturvapoikkeaman tutkinnan oikeaan ajanjaksoon, jos haavoittuvuutta on voitu hyödyntää
  • näyttää auditoijalle tai viranomaiselle, milloin ongelma tuli tuotteeseen ja milloin korjaus toimitettiin

Tämän päivän koodin skannaus ei anna sitä. Nykyinen lukitustiedosto kertoo, mitä repositorio haluaa nyt, ei sitä, mitä kukin aiempi buildi asensi. Ainoa luotettava lähde on tallenne jokaisesta buildista, joka tehdään buildin ajon aikana ja säilytetään sen jälkeen.

Miten CRACI vastaa siihen

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan ja tallentaa jokaisen paketin, jonka kukin buildi todella hakee, suorat ja transitiiviset, myös skriptien asentamat ja välimuisteista palautetut paketit. Jokaisen buildin SBOM säilytetään, joten historia on jo olemassa, kun CVE julkaistaan.

Kun uusi CVE ilmestyy, vastaus on jo valmiina: jokainen aiempi buildi ja sen SBOM, mitkä niistä sisälsivät haavoittuvan riippuvuuden suorana tai transitiivisena, ja ajanjakso, jona haavoittuvuus koski sinua. Ei taulukoita, ei uudelleenskannausta, ei jälkikäteistä kokoamista lukitustiedostoista. Ensimmäinen haavoittuvuuden sisältänyt buildi ja buildi, joka poisti sen, antavat altistusikkunan niin kauas taaksepäin kuin säilytysaikasi ulottuu (oletuksena 180 päivää, Enterprise-tilauksessa mukautettu säilytysaika).

Kun tiedät, käytäntöportti voi estää buildit, jotka sisältävät tämän CVE:n, joten myöhempi riippuvuuspäivitys tai palautettu välimuisti ei voi huomaamatta tuoda haavoittuvaa versiota takaisin julkaisuun.

Siitä eteenpäin muulla prosessilla on pohja, jolle rakentaa:

  • CRACI seuraa SBOM:eja jatkuvasti, joten uusia CVE:itä verrataan buildeihisi kenenkään kysymättä.
  • Tietoturvatiimit luokittelevat ja priorisoivat löydökset ja välittävät ne korjauksesta vastaaville tiimeille, ja CRACI tukee VEX:iä lopputuloksen kirjaamiseen.
  • CRACI:n inventaario näyttää, mitkä ohjelmistoversiot on otettu käyttöön missäkin tuotteessa.
  • CRA:ta varten CRACI valmistelee ennakkovaroituksen, ilmoituksen ja loppuraportin sisällön; yrityksesi edustaja lähettää ne keskitetyn raportointialustan (Single Reporting Platform) kautta.

Kun tiedät, kerro asiakkaillesi: miten vastata asiakkaille toimitusketjuhyökkäyksen jälkeen sisältää pohjat ensimmäiseen tiedotteeseen ja kuhunkin lopputulokseen. Jos kysymyksiä tulee satoja, katso PSIRT-toiminnan skaalaaminen.

Varaa demo, niin näet buildihistorian yhdestä omasta repositoriostasi.