Euroopan unionin uusi kyberkestävyyssäädös mullistaa sulautettujen laitteiden turvallisuusvaatimukset. Kolmen vuoden siirtymäaika ei jätä aikaa hukattavaksi: laitevalmistajien on kyettävä päivittämään ohjelmistonsa systemaattisesti ja todennettavasti koko tuotteen elinkaaren ajan. Miten tämä käytännössä onnistuu?
| Artikkelin oin kirjoittanut Qualcomm Technologiesin Ohjelmistot-ryhmän varatoimitusjohta George Grey. Hän toimi vuosia Foundries IO:n toimitusjohtajana ja vuosina 2010-2018 Linux-talo Linaron toimitusjohtajana. |
Kyberkestävyyssäädös (Cyber Resilience Act, CRA) on yksi suurimmista teknisistä ja organisatorisista haasteista, jotka Euroopan unioni on asettanut sulautettuja laitteita markkinoiville valmistajille Euroopassa. Säädös sai lainvoiman 10. joulukuuta 2024, ja laitevalmistajilla on kolme vuotta aikaa saattaa tuotteensa sen määräysten mukaiseksi, siis 11. joulukuuta 2027 alkaen.
Laitevalmistajien CRA-vaatimustenmukaisuustavoitteen tärkeänä elementtinä on mahdollistaa laitteiden ohjelmistojen päivittäminen uusien kyberuhkien varalta ja erityisesti ottaa huomioon virallisesti dokumentoidut ja raportoidut ”Yleiset haavoittuvuudet ja paljastuneet tietoturvauhat” (Common Vulnerabilities and Exposures, CVE) sekä reagoida niihin. Siinä missä tietoturvayhteensopivien järjestelmien laitteistokomponentit, kuten esimerkiksi Hardware Security Module (HSM) ja Trusted Platform Module (TPM) -laitteet, ovat jo laitevalmistajille tuttuja, sulautettujen ohjelmistojen tietoturvasuojausten ylläpitoprosessit ja ohjelmistopäivitysten kentällä tapahtuvat toimitukset ovat vielä monille uusia ja tuntemattomia.
On ymmärrettävää, että ohjelmistopäivityksiin liittyy epävarmuuden tunteita: ne ovat jollakin tavoin monimutkaisia ja vaikeasti hallittavia toimintoja. Foundries.io onkin tarjonnut tämän alueen teknologiaa ja tukea sulautettujen laitteiden valmistajille jo monien vuosien ajan. Yhtiön näkemyksen mukaan laitevalmistajilla ei ole mitään syytä huolestua CRA-vaatimuksista aiheutuvien ohjelmistopäivitysten vuoksi. Säädöstenmukaisuuden toteuttaminen tuotteissa on kuitenkin osoittanut, että vaikka suuri osa prosessista on virtaviivaistettavissa ja automatisoitavissa, laitevalmistajien on siitä huolimatta täydennettävä prosessia tuomalla itse joitakin tärkeitä työkaluja ja apuohjelmia, jotka merkittävästi helpottavat CRA-vaatimustenmukaisuuden toteuttamista.
CRA-vaatimukset ohjelmistopäivitysten hallitsemista varten
CRA-vaatimusten tarkoituksena on EU:n mukaan suojata kuluttajia ja yrityksiä niiden ostaessa digitaalikomponentteja sisältäviä ohjelmistoja tai laitteistoja. CRA-vaatimusten tähtäimessä ovat monissa tuotteissa havaittu kyberturvallisuuden tason riittämättömyys ja puutteet säännöllisesti tapahtuvissa turvapäivityksissä laitteisiin ja ohjelmistoihin (katso kuva 1). Säädöksen tarkoituksena on, että se velvoittaa tuotteiden valmistajia ja jälleenmyyjiä tekemään säädöksen mukaisia tuotteita. Erityisesti säädös edellyttää valmistajayrityksiä tarjoamaan tukea tuotteilleen niiden koko elinkaaren ajan.
Kuva 1. Yhteydessä oleva IoT-laite kuten ovikello on altis kyberhyökkäyksille – CRA-vaatimukset edellyttävät, että valmistaja pystyy nopeasti jakamaan ja toteuttamaan ratkaisuja niiden torjumiseksi.
Ne ajat ovat menneet, jolloin elektroniikkatuotteen valmistaja lähetti tuotteensa tuotantolaitokselta ja saattoi sen jälkeen unohtaa sen olemassaolon: nykyisin vaatimus kyberhyökkäysuhkien suojauksen ylläpidosta jatkuu kauan sen jälkeen, kun tuote on toimitettu loppukäyttäjälle.
Kodifiointisäädöksellä jatketaan tätä tietoturvan velvoittavuutta monilla tavoin, joista tärkeimpinä voidaan mainita:
- Ilmoita tuotetoimituksen jälkeen sovellettavissa olevissa CVE-ilmoituksissa identifioidut haavoittuvuudet
● Ylläpidä pakollista tuoteyksikkökohtaista listausta ohjelmistoista (SBOM) tehokkaan CVE-jäljityksen takaamiseksi
● Korjaa haavoittuvuudet ’viiveettä’
● Testaa ja tarkista säännöllisesti tuoteturvallisuus
● Luo menettelytapa haavoittuvuuksien ilmaisemiseksi
● Jaa turvallisesti korjauksia ja päivityksiä ’sopivin määräajoin’ ilmaiseksi loppukäyttäjille
Laitevalmistajan tehtävänä on nykyisin pitää rekisteriä tai SBOM-listausta jokaisen tehtaalta lähtevän tuoteyksikön kaikista ohjelmistokomponenteista, ylläpitää ja päivittää tuota rekisteriä ottamalla huomioon muutokset laitteen koodikannassa johtuen päivityksistä ja korjaustiedostoista, tunnistaa milloin mikä tahansa laitteen koodikanta on alttiina tunnetulle haavoittuvuudelle sekä korjata nopeasti haavoittuvuus ja toimittaa korjaustiedosto ilmaiseksi käyttäjille (katso kuva 2).
Kuva 2. Älypuhelimen valmistaja toimittaa säännöllisesti ohjelmistopäivityksiä langattomasti. Nyt sulautettujen laitteiden valmistajien on seurattava heidän jalanjälkiään.
Ylläpidon infrastruktuuri tukee päivityksiä koko tuotteen elinkaaren ajan
Nykyisten verkkoon liitettyjen sulautettujen laitteiden, etenkin Linux-käyttöjärjestelmään perustuvien laitteiden, koodikanta on laaja ja monimutkainen: se koostuu usein sadoista tai tuhansista erillisistä kaupallisten ja avoimen koodin toimittajien komponenteista sekä sovelluskohtaisista ohjelmistoista. Useinkaan ei ole tarkoituksenmukaista kääntää näiden komponenttien rekisterilistauksia manuaalisesti, vaan tarvitaan järjestelmä, joka automaattisesti generoi SBOM-listaukset kaikille tuotevarianteille niin suunnittelun ja tuotannon aikana kuin tuotteen toimittamisen jälkeenkin.
Monimutkaisuutta lisäävät turvatoiminnot kuten turvakäynnistys, varmennus ja datan sekä ohjelmistopäivitysten kryptografinen suojaus. Rekisterit jokaiselle tuoteyksikölle kohdistetuista ainutkertaisista turva-avaimista on tallennettava ja hallittava turvallisesti. Julkisen avaimen PKI-järjestelmän hallinnointi on olennainen osa laitevalmistajan CRA-yhteensopivuuden toteuttamista.
Lisäksi laitevalmistajilla tulee olla järjestelmä kentällä olevien laitteiden seurantaa varten: se muodostaa perustan, että kullekin yksittäiselle tuotteelle toimitetaan ja suoritetaan juuri oikea päivityspaketti. Tehokas kenttälaitteiden seurantajärjestelmä on perustana turvallisuutta painottaville rekisterilistauksille kaikkien asiakkaille toimitettujen yksilöiden osalta (pois lukien tiedetysti käytöstä poistetut yksilöt), joista jokainen yksilö on varustettu yksilöllisellä turvatunnuksella. Tämä auttaa laitekannan suojaamista siltä, että kyberhyökkääjä asettaisi huijausyksikön osaksi laitekantaa yrittääkseen urkkia esimerkiksi kriittisiä tietoja tai koodeja.
Mainitut toiminnot muodostavat järjestelmällisen lähestymistavan kirjata, tallentaa ja hallita dataa yksikkökohtaisesti ja kokonaisuutena alkaen suunnittelusta tuotannon kautta aina toimituksen jälkeiseen ylläpitoon asti. Koska nämä kaikki toiminnot vahvistavat CRA-yhdenmukaisuutta, EU-säädöksen voimaantulo vauhdittaa laitevalmistajien halua ottaa käyttöön formaalinen DevOps-kehitysympäristö, josta esimerkkinä on Foundries.io:n tyyppinen FoundriesFactory-alusta (katso kuva 3).
Jokaisen tällaisen alustan tulee tarjota integroidut ohjelmistot ja työkalut seuraavien toimintojen suorittamista varten:
- PKI-hallinta
● SBOM-listausten generointi ja ylläpito
● Laitekannan hallinta
● CI/CD-prosessi tukemassa korjausten ja korjauskoodien nopeaa kehittämistä ja toteuttamista varten
● Vahvalla suojauksella varustettu päivitysten suunnittelu, jakelu ja toteutus
Kun tällainen kehitysympäristö pannaan alulle heti uuden tuotteen suunnittelun alkaessa ja käyttämällä sitä hyödyksi koko tuotteen elinkaaren ajan, laitevalmistajat voivat automatisoida, virtaviivaistaa ja yksinkertaistaa laitteen hallinta- ja turvaprosessit, jotka muutoin olisivat äärimmäisen mutkikkaita, aikaa vieviä ja alttiita inhimillisille virheille.
Kuva 3. FoundriesFactory-alusta integroi ulkoiset avoimen koodin lähteet suunnittelu-, turvallisuus- ja käyttötoimintojen toteuttamista varten.
Yhteensopivuudesta puuttuu palanen
Testattu DevOps-kehitysympäristö on tarpeellinen kaikille muille paitsi pienimmille laitevalmistajille CRA-yhteensopivuustavoitteen hallitsemiseksi, mutta se ei vielä riitä. Tarvitaan muitakin työkaluja ja järjestelmiä, sillä joitakin yhteensopivuuden saavuttamisessa tärkeitä elementtejä kuten tehokkaita avoimen koodin työkaluja ei ole saatavissa. Erityisesti kaksi tärkeää puutetta nousee esiin:
- CVE-uhkien jäljittäminen
- Yhteensovittamisen toimenpiteiden dokumentointi ja auditointi
Nykyiset CVE-testerit tuppaavat olemaan ylimalkaisia: ne antavat liian paljon hyväksyviä tuloksia. Syy tähän on, että ne säännönmukaisesti sovittavat yhteen nimen ja ohjelmistopaketin kuvauksen, jotka on identifioitu CVE-raportissa nimen ja ohjelmistokuvauksen mukaan laitteen SBOM-listauksessa. Mutta se ei ole sama asia kuin identifioida erityinen alttius. CVE-raportti soveltuu normaalisti erityiseen osaan tai osiin ohjelmistotuotteen koodikannassa eikä loppuosa koodikantaa ole vaaralle alttiina.
Jos tällöin sulautettu laite käyttää vain osaa tuotteesta jonkun toiminnon suorittamiseksi eikä se kohdistu koodikannan haavoittuvaan osaan, niin ei ole tarvetta luoda eikä suorittaa siihen kohdistuvia korjaustoimenpiteitä. Mutta ylimalkaisesti toimiva CVE-testeri liputtaa laitteen kuitenkin haavoittuvaksi, jos laite käyttää mitä tahansa osaa CVE-raportissa nimetystä ohjelmistopaketista.
On siis olemassa tarve kehittyneemmille työkaluille, jotka pystyvät tunnistamaan laitteen lähdekoodin ja etsimään sitä vastaavan CVE-raportin identifioiman haavoittuvuuskoodin. Uusien kehittyneiden tekoälymallien saatavuuden paraneminen antaa lupaavan pohjan tällaisten työkalujen kehittämiseksi tulevaisuudessa.
Toisena yhteensovittamistyökalujen haasteena on raportointia ja auditointia tukevan järjestelmän puute. CRA-säädös asettaa laitevalmistajan koosta riippuvat tiukat taloudelliset seuraamukset, jos tuote ei täytä CRA-vaatimuksia. Laitevalmistajien intressinä on siis osoittaa laitteidensa CRA-vaatimustenmukaisuus viittauksella jokaiseen kentällä olevan laitekannan yksittäiseen tuoteyksikköön.
Kun SBOM on käytössä ohjelmistossa, niin esimerkiksi FoundriesFactory-alusta automaattisesti luo listan ohjelmistokomponenteista yksikkö yksiköltä, tarvitaan tehokas yhdenmukaisuudesta raportoiva työkalu ylläpitämään rekisteriä raportoiduista haavoittuvuuksista ja suoritetuista korjaustoimenpiteistä yksikkö yksiköltä.
Ihannetapauksessa työkalut molempien mainittujen puutteiden korjaamiseksi saadaan avoimen lähdekoodin yhteisöistä ja ne otetaan riittävän laajasti käyttöön, jotta ne muodostuvat alan standardeiksi. Siellä missä standardeja avoimen lähdekoodin ratkaisuja on olemassa, alan yritykset vahvistavat asemiaan, koska niiden ei jokaisen erikseen tarvitse keksiä pyörää uudestaan, vaan voivat jakaa keskenään yhdessä oppimaansa ja kokemuksiaan.
Avoimen lähdekoodin standardoinnin aiheuttama positiivinen kierre on syynä, että esimerkiksi The Update Framework (TUF) otti käyttöön FoundriesFactory-alustan työkaluksi, jolla se jakaa ja suorittaa turvallisuuteen painottuvat ohjelmistopäivitykset. Monet muutkin FoundriesFactory-alustan elementit pohjautuvat avoimeen lähdekoodiin samasta syystä.
Ohjelmistopäivitys on prosessi, ei pelkkä paketti
Vaatimus CRA-yhteensopivuudesta luo nyt laitevalmistajille painetta käydä käsiksi ohjelmistopäivitysten vaikeuksien ratkaisemiseen. He oppivat, että ohjelmistopäivitykset ovat tärkeä osa ratkaista yhteensopivuuden ongelmat, ja että ohjelmistojen päivittäminen ei koostu pelkästään ohjelmistopaketista, vaan koko järjestelmän käsittävästä laitevalvonnasta, tietoturvasta, laitekannan hallinnasta ja ohjelmiston kehittämistoiminnoista, joiden tarkoituksena on varmistaa paras kyky reagoida nopeasti uusiin haavoittuvuuksiin ja hyökkäysuhkiin.
Laitevalmistajien kannattaakin koota oma päivitysjärjestelmänsä perustuen testattuun DevOps-kehitysympäristöön, jolla on mahdollista toteuttaa varmatoiminen automaattinen kentällä olevia tuoteyksiköitä tietoturvallisesti tunnistava ja ylläpitävä järjestelmä ja jakaa niille oikea päivityspaketti oikeaan laitteeseen oikeaan aikaan.
