Riippuvuuksien riippuvuudet: ohjelmiston toimitusketjun riskin hallinnan kriittinen haaste

Ohjelmisto pyörittää maailmaa. Se pitää lentokoneet taivaalla, sairaalat käynnissä ja varmistaa, että maailmanlaajuinen rahoitusjärjestelmä ei koskaan missaa. Mutta yhä useammin nämä sovellukset rakennetaan käyttämällä avoimen lähdekoodin komponentteja eri lähteistä. Monimutkaisuus on uusi normaali, oli kyse sitten omistamista ohjelmistoista tai räätälöidyistä kotimaisista sovelluksista. Ja monimutkaisuus on turvallisuuden vihollinen.

Komponenttien väliset monimutkaiset suhteet ja se, kuinka helposti uhkatekijät voivat lisätä haittaohjelmia alkupään koodiin, pitäisi olla huolenaihe tietoturvapäälliköille. Herätyspuhelut ovat tulleet tiheästi ja nopeasti viime vuosina. On aika löytää tehokas tapa hallita ohjelmistojen toimitusketjua riski.

Ohjelmiston toimitusketjun toiminta

Toimitusketjut ovat kriittisiä polkuja, joita pitkin raaka-aineet ja komponentit ohjataan ennen niiden kokoamista, myyntiä ja käyttöä. Digitaalisessa maailmassa tällaisia ​​komponentteja pidetään usein paremmin toimittajalta asiakkaalle tarjottuina palveluina. Kuten me on käsitelty edellisessä artikkelissa, nämä palveluntarjoajat ovat yhä suositumpi hyökkäyskohde, koska uhkatoimijat voivat tuottaa hyvän sijoitetun pääoman tuoton. Hyökkäämällä yhteen liiketoimintaprosessien ulkoistajaan tai IT-palvelujättiläiseen, heillä on mahdollisuus varastaa tietoja ja/tai kiristää potentiaalisesti suuri joukko loppupään asiakkaita.

Ohjelmiston toimitusketju on samanlainen, mutta tässä tapauksessa järjestelmä käsittää ohjelmiston rakentamiseen tarvittavat komponentit, koodikirjastot, työkalut ja prosessit. Yksittäisen komponentin tai jopa koko sovelluksen vaarantamalla hyökkääjät voivat vaikuttaa mihin tahansa kehittäjään tai organisaatioon, joka käyttää kyseistä ohjelmistoa/komponenttia.

Missä on riski?

Ohjelmistot saattavat pyörittää maailmaa, mutta mitä tarkalleen ottaen menee sellaisten sovellusten rakentamiseen, jotka toimivat sähköisen kaupankäynnin alustoista kriittisiin liiketoiminnan ERP-järjestelmiin? Yhä useammin se on avoimen lähdekoodin komponentteja. A Sonatype raportti arvioi, että pelkästään vuonna 2022 kehittäjät tekivät 3.1 biljoonaa pyyntöä tällaisille komponenteille neljästä suurimmasta avoimen lähdekoodin ekosysteemistä: Java, JavaScript, Python ja .NET. Veto on, että lataamalla nämä valmiiksi rakennetut paketit kehittäjät voivat nopeuttaa markkinoille tuloa ja auttaa yritystä vastaamaan nopeammin nopeasti muuttuvaan markkinoiden kysyntään. Se on väitetty että 80 % nykyaikaisten sovellusten koodista tulee jo olemassa olevista avoimen lähdekoodin ohjelmistoista.

Haasteena on, että nämä komponentit - tai avoimen lähdekoodin "riippuvuudet" - sisältävät usein haavoittuvuuksia. Sonatypen mukaan viime vuonna ladattiin joka kuukausi 1.2 miljardia haavoittuvaa riippuvuutta. Jos ne ladataan tahattomasti, ne voivat aiheuttaa riskin, että uhkatoimijat käyttävät niitä hyväkseen myöhemmin. Mukaan Linux-säätiö, keskimääräinen sovelluskehitysprojekti sisältää 49 haavoittuvuutta 80 suorassa riippuvuudessa.

Vielä pahempia ovat epäsuorat tai transitiiviset riippuvuudet, jotka Sonatypen mukaan muodostavat kuusi joka seitsemästä projektin haavoittuvuudesta. Näitä riippuvuuksia on vaikeampi seurata, koska ne ovat käytännössä kirjastoja ja paketteja, joita suorat riippuvuudet kutsuvat – toisin sanoen riippuvuuksien riippuvuuksia. Tämän seurauksena ei ole heti selvää, että tietty sovellus käyttää niitä. Tämä voi piilottaa haavoittuvuudet ylimääräisen hämäräkerroksen alle.

Esimerkkinä on surullisen kuuluisa Log4j-haavoittuvuudet. Log4j on vähän tunnettu mutta suosittu lokityökalu, jota käyttää yli 35,000 10.0 Java-ohjelmistopakettia. Korjaus työkalun kriittiseen (CVSSS 2021) haavoittuvuuteen julkaistiin joulukuun 4 lopulla. Mutta koska työkalua käytettiin laajasti avoimen lähdekoodin Java-ekosysteemissä, monien organisaatioiden oli äärimmäisen vaikeaa löytää ja korjata kaikki LogXNUMXj:n esiintymät. heidän ympäristössään. Mukaan Google, useimmat vaikuttaneet Java-paketit olivat haavoittuvia, koska Log4j oli vaikeasti löydettävä transitiivinen riippuvuus.

"Mitä syvemmällä haavoittuvuus on riippuvuusketjussa, sitä enemmän vaiheita tarvitaan sen korjaamiseen", se lisäsi.

Valitettavasti uhkatoimijat eivät tuhlanneet aikaa vian hyödyntämiseen. Mukaan VerizonKolmannes (32 %) paljastuneiden järjestelmien haavoittuvuuden tarkistuksista viime vuonna tehtiin ensimmäisten 30 päivän aikana sen julkaisemisen jälkeen.

Avoimen lähdekoodin komponenttien haavoittuvuuksien löytämisen ja korjaamisen haasteen ohella organisaatiot kärsivät ylimääräisestä päänsärystä uhkatekijöiden avoimen lähdekoodin tietovarastoihin lähettämästä haitallisesta paketista. Sonatype väittää kirjanneensa tällaisten pakkausten vuosittaisen kasvun 633 % vuonna 2022 yli 88,000 XNUMX tunnettuun tapaukseen.

Toinen uhka: patentoitu ohjelmisto

Ohjelmistojen toimitusketjun riski ei kuitenkaan rajoitu avoimeen lähdekoodiin. Omistusoikeudelliset kaupalliset tuotteet voivat sisältää haavoittuvuuksia, joita hyökkäykset voivat hyödyntää ja joita käytetään säännöllisesti. Ne voivat sisältää myös bugien avoimen lähdekoodin komponentteja ja työkaluja, kuten Log4j. Itse asiassa hyvin vähän nykyään olemassa olevaa koodia voidaan aidosti kuvata "omistukseksi", sanoo Sonatypen kehittäjien edunvalvontajohtaja Steve Poole.

"Tämän seurauksena näennäisesti patentoitujen sovellusten kuluttajilla on väärä turvallisuuden tunne, ja he voivat siten olla tietämättään haavoittuvia", hän kertoo ISMS.online-sivustolle.

Kehittyneemmissä hyökkäyksissä kuten SolarWinds-kampanja, uhkatoimijat voivat jopa vaarantaa toimittajan oman IT-ympäristön ja lisätä haittaohjelmia laillisiin ohjelmistopäivityksiin. Tämä antoi Venäjän valtion toimijoille mahdollisuuden vaarantaa useita Yhdysvaltain hallituksen ministeriöitä.

”Kaikki ohjelmistot voivat vaarantua. Suurin ongelma on perusteeton epäsuora luottamus tuohon ohjelmistoon”, väittää Udo Schneider, Trend Micron Euroopan turvallisuusevankelista.

Samuel Barfoot, Checkmarxin turvallisuustiimin johtaja, sanoo, että ohjelmistotoimittajan kypsyys ja ISO-akkreditointi ovat tärkeitä.

"Vaikka ohjelmistoa itsessään ei ehkä ole suunniteltu aiheuttamaan haittaa, jos se tunkeutuu, sitä voidaan käyttää tietojen vuotamiseen", hän kertoo ISMS.online-sivustolle. "Pilveen siirtyessään organisaatiot kohtaavat myös riskejä, jotka liittyvät toimittajien hallintaan, tukeen, varmuuskopioihin ja järjestelmän saatavuuteen hakkeroinnin tai käyttökatkon sattuessa. Myyjän kypsyys on ratkaisevan tärkeä näiden riskien pienentämisessä valmistautumalla ja varautumalla."

Näkyvyys on ensimmäinen askel kohti riskinhallintaa

Trend Micron Schneiderin mukaan organisaatioiden, jotka haluavat pienentää riskejä ohjelmistojen toimitusketjussa, täytyy ensin saada käsitys "huonoista" komponenteista ja alikomponenteista riippumatta siitä, onko kyseessä patentoitu tai avoimen lähdekoodin koodi. Tämä voidaan saavuttaa pyytämällä ohjelmistoluetteloa (SBOM).

"Ohjelmistotuotteen (kirjasto, suoritettava tai jopa säilö) SBOM sisältää riippuvuuskaavion, jossa on lueteltu kaikki käytetyt ohjelmiston (ali)komponentit, mukaan lukien tarkka versionumero. SBOM:t voidaan luoda suoraan lähteestä sisällä a CI/CD-putki tai myöhemmin "kuolleille" esineille, kuten suoritettaville tiedostoille tai jopa konteille", hän selittää. 

"Tämä on erityisen hyödyllistä patentoiduissa ohjelmistoissa, joissa toimittaja ei yleensä tarjoa SBOM:ia. Lainkäyttöalueilla/toimialoilla, joissa toimittajien on toimitettava SBOM, niitä voidaan jatkuvasti tarkistaa tunnettujen haavoittuvuuksien varalta, mikä tarjoaa ajantasaisen perustan mahdollisille toimenpiteille."

Sonatypen Poole lisää, että organisaatioiden tulee myös arvioida toimittajan tietoturva-asentoa kiinnittäen erityistä huomiota haavoittuvuuksien raportointiprosessien laatuun. 

Hän väittää, että avoimen lähdekoodin komponenttien osalta organisaatioiden tulisi toteuttaa avoimen lähdekoodin komponenttien jatkuva arviointiohjelma ja tarvittaessa korjata/päivittää nopeasti nopean hyödyntämisen estäminen. Software Composition Analysis (SCA) -työkalut voivat myös auttaa selvittämään, mitä tuotteiden tai komponenttien sisällä on.

"SCA-työkalun kehittyneisyyden on kuitenkin vastattava ja ylitettävä huonojen toimijoiden, tai organisaatiolla on todellinen riski havaitsemattoman vektorin kautta tapahtuvasta hyökkäyksestä", hän varoittaa. 

"Vie lopuksi kehittäjät mukaan kouluttamaan heitä siitä, miten nykyaikaiset kyberhyökkäykset tapahtuvat ja mitkä ovat turvalliset koodausperiaatteet, ja opeta heille heidän vastuunsa ohjelmiston toimitusketjun alussa – heidän välittömillä valinnoillaan ja toimillaan on seurauksia."

Aloita ISMS:llä

Trend Micron Schneider väittää, että an tietoturvan hallintajärjestelmä (ISMS) voi olla loistava tapa vähentää ohjelmistojen toimitusketjun riskejä jatkuvasti.

"Syöttämällä tiedot SBOM-työkaluista, rikastettuina jakelutiedoilla ISMS:ään, voidaan paremmin arvioida ja dokumentoida tietoturva-asentoa ja siten koko järjestelmän kokonaisriskiä, ​​josta ohjelmisto on vain yksi osa", hän selittää. "Käytettäessä riskien vähentämisen ja tehtyjen toimien dokumentoinnin perustana tämä tarjoaa periaatteessa paljon paremman turvallisuuden kuin ohjelmistoomaisuuden manuaalinen seuranta."

Ohjelmiston toimitusketjun riskin hallinnan tarkistuslista:

1. Pyydä SBOM
2. Arvioi patentoitujen ohjelmistojen toimittajia (etenkin heidän haavoittuvuusraportointiaan)
3. Käytä SCA-työkaluja saadaksesi tietoa ohjelmistokomponenteista
4. Etsi jatkuvasti haavoittuvuuksia ja korjaa nopeasti
5. Kouluta kehittäjiä suunnittelun turvallisuuden tärkeydestä
6. Harkitse SBOM-tietojen syöttämistä ISMS:ään kokonaisvaltaista riskienhallintaa varten

Ota selvää, kuinka ISMS.online-ratkaisu mahdollistaa yksinkertaisen, turvallisen ja kestävän lähestymistavan toimitusketjun riskien hallintaan ja tiedonhallintaan ISO 27001 -standardin ja yli 100 muun maailmanlaajuisen viitekehyksen avulla.

Puhu asiantuntijalle