Puolustusohjelmistojen toimitusketjun turvallisuus: SLSA, provenienssi, allekirjoitus

Käyttöön otettu puolustusbinääri on pitkän luottamusketjun pää. Se alkoi kehittäjän kirjoittamana lähdekoodina, kulki kymmenien avoimen lähdekoodin riippuvuuksien läpi, käännettiin käännöspalvelimella, paketoitiin, allekirjoitettiin ja ylennettiin julkaisurekisteriin ennen kuin se koskaan saavutti operatiivisen verkon. Jokainen tämän ketjun lenkki on kohde. Kansallisvaltiotason vastustajat ovat toistuvasti osoittaneet, että halvin tie kovetettuun puolustusverkkoon ei ole pääovi – se on käännösjärjestelmä tai luotettu riippuvuus, vaarannettu ylävirrassa niin, että haitallinen koodi toimitetaan uhrin oman putken allekirjoittamana ja siunaamana. Ohjelmiston toimitusketjun turvallisuus on sen tieteenala, jolla jokaisesta ketjun lenkistä tehdään todennettava, niin että käyttöön otettu artefakti voidaan kryptografisesti jäljittää tarkastettuun lähdekoodiin peukaloinnin paljastavan käännöksen kautta.

Puolustuksen toimitusketjun uhkamalli

Kaupallinen toimitusketjun turvallisuus ja puolustuksen toimitusketjun turvallisuus jakavat saman sanaston mutta eri vastustajan. Kaupallinen tiimi murehtii haavoittuvasta riippuvuudesta tai vahingossa vuotaneesta salaisuudesta. Puolustustiimin on oletettava hyvin resursoitu toimija, joka käyttää kuukausia implantin esiasemointiin: myrkyttäen suositun avoimen lähdekoodin paketin, vaarantaen käännösajurin tai korvaten peukaloidun kääntäjän. SolarWinds-tunkeutuminen – jossa käännösjärjestelmän implantti lisäsi takaoven laillisesti allekirjoitettuun tuotepäivitykseen – on kanoninen esimerkki, ja se muotoili uudelleen sen, miten puolustushankinnat suhtautuvat ohjelmiston alkuperään.

Uhkapinta jakautuu neljään vyöhykkeeseen. Lähde-vyöhyke kattaa versionhallintajärjestelmän ja ne ihmiset, joilla on commit-oikeudet. Riippuvuudet-vyöhyke kattaa jokaisen käännökseen vedetyn kolmannen osapuolen paketin, suorat ja transitiiviset. Käännös-vyöhyke kattaa käännöspalvelun, sen ajurit ja työkaluketjun. Jakelu-vyöhyke kattaa allekirjoituksen, julkaisurekisterin ja käyttöönoton. Puolustuksen toimitusketjun kontrollikehyksen on käsiteltävä kaikkia neljää – yhden kovettaminen toisen jäädessä auki yksinkertaisesti siirtää vastustajan sisääntulokohtaa.

Mikä tekee tästä vaikeampaa puolustukselle kuin kaupalliselle ohjelmistolle, on seurausmalli. Vaarantunut kaupallinen SaaS-päivitys voidaan peruuttaa; vaarantunut laiteohjelmistolataus käytössä olevassa radiossa tai elektronisen sodankäynnin hyötykuormassa voi olla tavoittamaton, pysyvä ja operatiivisesti katastrofaalinen. Yhden peukaloidun artefaktin kustannus on epäsymmetrinen, minkä vuoksi kehyksen on oltava ennaltaehkäisevä eikä reaktiivinen – tavoitteena on tehdä haitallisesta artefaktista kykenemätön läpäisemään putkea lainkaan, ei havaita sitä käyttöönoton jälkeen. Alla olevat kontrollit on järjestetty lähteestä käyttöönottoon juuri niin, että jokainen vyöhyke suljetaan ennen kuin seuraava perii sen tulosteet.

SLSA: käännöksen eheyden kypsyysmalli

SLSA – Supply-chain Levels for Software Artifacts – on laajimmin omaksuttu kehys käännöksen eheyden tarkasteluun. Se on tarkoituksellisesti vaiheittainen ja määrittelee etenevät tasot, jotta organisaatio voi mitata missä se on ja mikä on seuraava konkreettinen parannus.

Taso 1 edellyttää vain, että käännösprosessi tuottaa provenienssin: kuvauksen siitä, miten artefakti tehtiin. Tämä yksin saa kiinni virheet ja tarjoaa perustason analyysille, mutta provenienssia ei ole vielä suojattu peukalointia vastaan.

Taso 2 edellyttää isännöityä käännöspalvelua, joka generoi ja allekirjoittaa provenienssin. Koska palvelu kehittäjän työaseman sijaan tuottaa todisteen, vaarantuneen yksittäisen koneen tekemä peukalointi tulee havaittavaksi.

Taso 3 kovettaa itse käännösalustan: provenienssista tulee väärentämätön, ja käännökset ajetaan eristetyissä, lyhytikäisissä ympäristöissä, jotka eivät kanna tilaa ajojen välillä. Tämä on taso, jolla vaarantunut riippuvuus tai haitallinen käännösskripti ei voi enää hiljaa kirjoittaa uudelleen sitä, mitä provenienssi raportoi. Kriittiselle ohjelmistolle SLSA-tasoa 3 tulisi pitää perustasona, ei tavoitteena.

Korkeimman varmuuden taso – historiallisesti kuvattuna tasoksi 4 ja nykyään ilmaistuna lisäraidevaatimuksina – lisää kahden henkilön tarkastuksen jokaiseen muutokseen sekä hermeettiset, toistettavat käännökset. Toistettava käännös antaa riippumattomalle osapuolelle mahdollisuuden rakentaa sama lähdekoodi uudelleen ja vahvistaa bitti bitiltä, että he saavat saman artefaktin. Aseiden lähellä oleville tai kryptografisille komponenteille toistettavuus on vahvin saatavilla oleva puolustus peukaloitua työkaluketjua vastaan.

Käännösprovenienssi: miten artefakti tehtiin

Provenienssi on toimitusketjun varmuuden ydin, ja se sekoitetaan usein allekirjoitukseen. Binäärin allekirjoitus todistaa kuka sen julkaisi ja että se ei ole muuttunut allekirjoituksen lisäämisen jälkeen. Se ei kerro mitään siitä, oliko binäärin tuottanut käännös luotettava. Jos vastustaja vaarantaa käännösajurin, hän voi tuottaa haitallisen artefaktin, joka sitten allekirjoitetaan täysin laillisesti – allekirjoitus on validi, artefakti on myrkytetty.

Provenienssi sulkee tämän aukon. Provenienssitodiste on allekirjoitettu, koneluettava tietue, joka kuvaa lähdekoodin commitin, kääntäjän identiteetin, käännösparametrit sekä jokaisen syötteen ja tulosteen kryptografiset tiivisteet. Laajasti käytetty muoto on in-toto-todiste, joka tallentaa tämän jäsenneltynä lausumana, jonka käännösalusta – ei kehittäjä – allekirjoittaa. Kun todentaja myöhemmin tarkistaa artefaktin, se vahvistaa allekirjoituksen lisäksi, että provenienssi nimeää odotetun lähdekoodivaraston, odotetun kääntäjän ja commitin, joka läpäisi tarkastuksen.

Mitä todentaja tarkistaa

Provenienssitarkistus käyttöönottohetkellä vastaa täsmälliseen kysymykseen: rakennettiinko juuri tämä artefakti siitä lähdekoodista ja prosessista, jota odotamme? Todentaja vertaa artefaktin tiivistettä provenienssiin tallennettuun tiivisteeseen, vahvistaa että provenienssin allekirjoitti luotetun käännösalustan avain, ja toteaa että kääntäjän identiteetti ja lähde-URI vastaavat sallittujen luetteloa. Ristiriita – artefakti, jonka provenienssi nimeää tuntemattoman kääntäjän, tai jonka tiiviste ei täsmää – hylätään ennen kuin se saavuttaa operatiivisen ympäristön. Tämä on se kontrolli, joka olisi merkinnyt lipulla SolarWinds-tyyppisen korvauksen.

Provenienssi mahdollistaa myös tapahtumien selvityksen, joka muuten olisi mahdotonta. Kun käännöstyökalussa tai riippuvuudessa paljastuu uusi haavoittuvuus, organisaatio jolla on täydellinen provenienssi voi kysellä tarkalleen mitkä käytössä olevat artefaktit tuotettiin vaikutuksen alaisella komponentilla, minkä kääntäjän toimesta ja mistä commitista – muuttaen hätäisen arvion täsmälliseksi vaikutusalueen vastaukseksi. Artefaktin operatiivisen elinkaaren ajan säilytetty provenienssi ei siten ole vain käyttöönottoa edeltävä portti vaan auditointivara, joka tuottaa hyötyä vuosia käännöksen jälkeen.

Artefaktien allekirjoitus puolustusputkissa

Allekirjoitus on edelleen olennaista; se ei vain yksin riitä. Moderni käytäntö on avaimeton allekirjoitus, jota tukee läpinäkyvyysloki: lyhytikäinen avain myönnetään todennettua työkuormaidentiteettiä vasten, sitä käytetään artefaktin ja sen todisteiden allekirjoittamiseen, ja allekirjoitustapahtuma kirjataan vain lisäystä sallivaan julkiseen tai yksityiseen läpinäkyvyyslokiin. Tämä poistaa pitkäikäisten allekirjoitusavainten operatiivisen taakan ja riskin, jotka muutoin asuisivat käännöspalvelimilla.

Korkeimman varmuuden komponenteille – kryptografisille moduuleille, käynnistyslataimille, mille tahansa joka on sidottu laitteistopohjaiseen luottamusjuureen – puolustusohjelmat käyttävät laitepohjaisia avaimia, jotka säilytetään laitteistoturvamoduulissa (HSM). Yksityinen avain ei koskaan poistu HSM:stä; allekirjoitusoperaatiot suoritetaan sen sisällä. Tämä yhdistyy luontevasti turvalliseen käynnistykseen, jossa laitteen laiteohjelmisto todentaa kunkin vaiheen allekirjoituksen ennen sen suorittamista, laajentaen toimitusketjun luottamusketjun aina piille asti.

Riippuvuuksien todennus ja SBOM

Suurinta osaa minkä tahansa modernin puolustussovelluksen koodista ei ole kirjoittanut ohjelma itse – se on vedetty sisään avoimen lähdekoodin riippuvuuksina. Näiden riippuvuuksien todentaminen on siksi koko ketjun suurivaikutteisin kontrolli. Useat käytännöt kasautuvat tässä.

Kiinnittäminen ja tiivistäminen. Jokainen riippuvuus kiinnitetään tiettyyn versioon ja kryptografiseen tiivisteeseen, jotta ratkaistu riippuvuuspuu on deterministinen. Käännös ei voi hiljaa ajautua paketin uuteen, haitalliseen versioon, koska tiiviste ei enää täsmäisi.

Sisäinen peilaus. Hyväksytyt paketit peilataan sisäiseen rekisteriin, ja käännökset hakevat vain siitä peilistä – ei koskaan suoraan julkisesta rekisteristä käännöshetkellä. Tämä antaa ohjelmalle kontrolloidun tarkastuspisteen ja katkaisee käännöksen riippuvuuden internetin tavoitettavuudesta, mikä on pakollista ilmaeristetyissä ja luokitelluissa ympäristöissä.

Haavoittuvuusskannaus. Jokainen riippuvuus skannataan haavoittuvuustietoja, kuten OSV advisory -tietokantaa, vasten, ja tulokset portitoivat ylennyksen. Jokaisen transitiivisen komponentin luetteloinnin tuotos on ohjelmiston materiaaliluettelo. Tuohon artefaktiin nyt liittyvistä hankintavetoisista vaatimuksista lue analyysimme aiheesta ohjelmiston materiaaliluettelo (SBOM) puolustukselle. SBOM generoidaan vakiomuodossa – CycloneDX tai SPDX – ja liitetään artefaktiin allekirjoitettuna todisteena, jotta se kulkee binäärin mukana.

Käytäntöjen valvonta: hyväksyntäportti

Mikään näistä kontrolleista ei merkitse mitään, ellei se estä määräystenvastaisen artefaktin käyttöönottoa. Valvontapiste on hyväksyntäportti – hetki heti ennen kuin artefakti ylennetään julkaisurekisteriin tai otetaan käyttöön operatiivisessa ympäristössä. Tällä portilla käytäntömoottori suorittaa joukon pakollisia tarkistuksia: se todentaa artefaktin allekirjoituksen, validoi provenienssin odotettuja lähde- ja kääntäjäidentiteettejä vasten, tarkistaa SBOM:n haavoittuvuustietoja ja kiellettyjen komponenttien luetteloa vasten ja vahvistaa, että muutos läpäisi vaaditun kahden henkilön tarkastuksen.

Kriittinen suunnittelusääntö on, että käytännön on estettävä, ei vain merkittävä lipulla. Yleinen epäonnistuminen on ajaa skannereita aiemmin putkessa, jotka tuottavat varoituksia, kun taas ylennysvaiheella ei ole kovaa porttia – joten lipulla merkitty artefakti silti toimitetaan, kun insinööri ohittaa sen määräaikapaineen alla. Hyväksyntäportin on epäonnistuttava suljettuna: jos provenienssia ei voida todentaa, artefaktia ei oteta käyttöön. Näiden porttien upottaminen koodina, tarkastettuna ja versionhallittuna kuten mikä tahansa muu putken vaihe, on luonteva jatke DevSecOps-käytännölle puolustuksessa, jossa turvakontrollit ovat osa jokaista sprinttiä eivätkä julkaisua edeltävä auditointi.

Ketjun käyttö luokitelluissa ympäristöissä

Ilmaeristetyssä tai luokitellussa enklaavissa koko ketjun on toimittava ilman internetyhteyttä. Sisäiset peilit pitävät tarkastetut riippuvuudet, käännöspalvelu ja läpinäkyvyysloki toimivat enklaavin sisällä, ja todennusavaimet jaetaan hyväksyttyjen kanavien kautta. Riippuvuuspeilin päivitykset saapuvat kontrolloitujen verkkoaluerajat ylittävien siirtojen kautta, kukin kantaen omaa provenienssiaan niin, että enklaavi voi uudelleentodentaa alkuperän ennen paketin hyväksymistä. Toimitusketjun suunnittelu offline-toimintaa varten ensimmäisestä sprintistä alkaen – sen sijaan että se jälkiasennettaisiin – on se, mikä tekee eron akkreditoinnin selviävän kontrollikehyksen ja sellaisen välillä, joka romahtaa kohdatessaan todellisen luokitellun käyttöönoton.