Tietoturva Nyt!
IoT- ja automaatiomaailmassa haavoittuvuuksien hallinta on poikkeuksellisen haastavaa - ja samalla tärkeää. Ohjelmisto-omaisuuden yksityiskohdat ja vastuut hukkuvat helposti monimutkaisuuteen. Kyberturvallisuuskeskus suosittelee järjestelmien omistajia ottamaan avuksi 'ohjelmistojen materiaaliluettelon' (Software Bill of Materials, SBOM). SBOM auttaa tunnistamaan omissa ohjelmistoissa olevat haavoittuvuudet ja paikkaamaan ne ajoissa.
Kuluvalla vuosituhannella on viety verkkoon kaikki mahdollinen siveysvöistä raskaisiin automaatiojärjestelmiin. Samalla erilaiset ohjelmistohaavoittuvuuksia hyödyntävät hyökkäykset ovat lisääntyneet. Erityisen hankalaksi haavoittuvuuksilta suojautuminen on osoittautunut IoT- ja automaatiomaailmassa, jossa järjestelmien toimitusketjut ja elinkaaret ovat pitkiä ja päivityksen vaatimat tuotannon katkokset myrkkyä.
Vastuiden tunnistaminen elinehto
Haavoittuvuuksien tunnistamisen ja paikkaamisen lisäksi kohentamista on myös vastuiden määrittelyssä. Tarve tarkempaan määrittelyyn koskee niin ylätason vastuita järjestelmistä ja palveluista kuin laitetasoakin. IoT- ja automaatioympäristöissä pätee usein vanha sanonta "poissa silmistä, poissa mielestä". Ja vaikka asiat olisivat suoraan silmien edessä, ei IoT- ja automaatiolaitteiden aina muisteta olevan monia ohjelmistoja sisältäviä tietoteknisiä laitteita. Arkitodellisuudessa ne hahmottuvat "vain" ilmastointilaitteina, pesukoneina tai pakkauslinjoina. Monimutkaiset kokonaisuudet ovat omiaan hämärtämään yksityiskohtia ja niiden välisiä riippuvuuksia.
Niin kauan kuin asiat toimivat voi jokapäiväisessä toiminnassa unohtua, että jollain pitäisi olla tieto ja vastuu eri osatekijöiden tietoturvallisuudesta ja ylläpidosta. Kokonaisuuden tietoturvallisuuteen liittyvistä ylläpitovastuista tulisikin sopia yksiselitteisesti ja omistajan tunnistaa liiketoimintariskit. Toisinaan saatetaan kuitenkin joutua hakemaan vastausta jopa kysymykseen siitä, kuka tosiasiallisesti omistaa järjestelmän. Tietoinen riskienhallinta ja priorisointi on tällöin mahdotonta, mikä tekee organisaatiosta haavoittuvan.
SBOM auttaa haavoittuvuuksien havaitsemisessa
Hyvä puoli nykytilanteessa on se, että sitä on helppo lähteä parantamaan. Kun vastuut järjestelmistä on kartoitettu, voidaan kääriä hihat ja alkaa hommiin. Järjestelmävastuullisten on syytä ylläpitää rakennekaavioita järjestelmistä ja listoja niiden sisältämistä laitteista. Nämä tiedot ovat kallisarvioisia haavoittuvuusseurannassa ja yleisemminkin ongelmatilanteiden selvittämisessä. Ohjelmistojen osalta paras käytäntö on kuitenkin mennä pintaa syvemmälle.
Muilla toimialoilla on jo pitkään käytetty apuna menetelmää, joka tunnetaan materiaaliluettelona tai -laskuna. Aivan kuten esikuvansa, myös SBOM sisältää listauksen osista, joista tuote koostuu. SBOMia voi verrata myös elintarvikkeiden ainesosaluetteloon tai rakennuspiirustuksiin, joiden avulla pystytään paitsi kartoittamaan riskitekijöitä, myös tekemään hallittuja muutoksia ja varautumaan tuleviin tarpeisiin.
Ohjelmistojen rakennuspalikoiden tunteminen on tärkeää erityisesti siksi, että monet niistä ovat nykyisin kolmannen osapuolen valmistamia ja mahdollisesti ylläpitämiäkin. Kun toteutusta ei ole rakennettu alusta lähtien itse, puuttuu usein tietoa, joka auttaisi tunnistamaan haavoittuvuudet. Toimitusketjujen pituus vaikeuttaa asiaa entisestään. SBOM tuo näkyväksi, mitä ohjelmistot ovat syöneet. Esimerkiksi nyt vaikeiksi paikattaviksi osoittautuneiden Amnesia 33 ja Ripple20 -haavoittuvuuksien löytämisessä ja paikkaamisessa SBOMin käyttö auttaisi haavoittuvia organisaatioita tunnistamaan ylipäänsä olevansa haavoittuvia. Nyt päivityksiä on ollut pitkään saatavilla, mutta verkossa on edelleen mittava määrä haavoittuvia tuotteita. Myös ohjelmistokomponentit, joita ei enää ylläpidetä, on hyvä tunnistaa.
Tuntemattomien toimitusketjujen ongelma ei liiketoiminnan näkökulmasta koske pelkästään haavoittuvuuksia. Paljon käytetyt avoimen lähdekoodin ratkaisut voivat myös sisältää lisenssiehtoja, jotka eivät ole komponenttia hyödyntävän ratkaisun omistajan tiedossa. Lisenssiehdot puolestaan voivat edellyttää vaikkapa sitä hyödyntävän tuotteen lähdekoodin avaamista. Onkin siis syytä tietää myös liiketoimintariskin hallitsemiseksi, mistä omat järjestelmät koostuvat.
Kohti turvallisempaa tulevaisuutta
SBOM sai ensimmäisen kerran laajempaa näkyvyyttä, kun Yhdysvalloissa tehtiin sen käyttöä julkisissa hankinnoissa koskeva lakialoite vuonna 2014. Vaikka asetusluonnos ei mennyt läpi, sai asia ansaitsemaansa näkyvyyttä. Sittemmin menetelmää on ehdotettu sisällytettäväksi myös ISO 27000 -standardisarjaan. Ajatus tietoisesta ohjelmisto-omaisuuden tunnistamisesta ja hallinnasta on ylipäänsä erittäin kannattava. Kyberturvallisuuskeskus kannustaakin voimakkaasti organisaatioita keräämään SBOMista hyödyt ottamalla se käyttöön ja suosimalla sitä hyödyntäviä valmistajia ja tuotteita.
Mitä laajemmin organisaatiot käyttävät SBOMia ja vaativat sitä toimittajiltaan, sitä enemmän on motivaatiota tuottaa tietoturvallisia järjestelmiä ja ohjelmistoja. Parhaassa tapauksessa kysyntä lisää ajan mittaan turvallisten tuotteiden tarjontaa. Samalla organisaation jatkuvuudenhallinta paranee ja liiketoiminnalle koituvat riskit vähenevät.