Pitäisikö ohjelmistotoimittajien olla vastuussa turvattomuudesta?

Nollapäiväinen virhe yritysohjelmistosovelluksessasi päästi hyökkääjät verkkoosi ja vaaransi arkaluonteisia tietoja. Sen korjaaminen tulee maksamaan paljon ennen kuin pääset edes viranomaissakkoihin ja asiakasoikeudenkäynteihin – ja sovellus ei ole edes sinun. Kenen pitäisi maksaa?

Se ei todennäköisesti ole yritys, joka myi sinulle ohjelmiston. Niiden loppukäyttäjälisenssisopimukset (EULA) rajoittavat yleensä heidän vastuutaan. Useimmat meistä eivät lue näitä, koska ne ovat liian pitkä ja liian monimutkainen.

Muutaman viime kuukauden aikana vaatimukset tilanteen muuttamiseksi ovat voimistuneet ja saavuttaneet hallinnon korkeimmat tasot. Helmikuussa kyberturvallisuuden ja infrastruktuurin turvallisuusviraston johtaja Jen Easterly nimenomaisesti kutsuttu myyjän vastuusta Carnegie Mellonin yliopistossa pidetyn puheen aikana.

Maailma on alkanut hyväksyä vaarallisen teknologian sääntönä, kun sen pitäisi olla poikkeus, hän sanoi. "Teknologian valmistajien on otettava asiakkaidensa tietoturvatulokset vastuuseen."

Easterly pyysi hallitusta julkaisemaan lainsäädäntöä, joka estäisi teknologiayrityksiä irtisanoutumasta vastuusta sopimuksella. Bidenin hallinto Kansallinen kyberturvallisuusstrategiamaaliskuussa käynnistetty versio toisti tämän lain vaatimuksen.

Pitkään jatkunut keskustelu

Hallitukset ovat pohtineet tätä ongelmaa ennenkin. Yhdistyneen kuningaskunnan ylähuone suositeltu Ohjelmistovalmistajien saattaminen vastuuseen vuonna 2007, vaikka ohjelmistokehittäjiltä on kuultu eri syitä väitteitä toimittajan vastuuta vastaan.

Näihin protesteihin sisältyi nykyaikaisten ohjelmistoympäristöjen pelkkä monimutkaisuus. Monen tyyppiset ohjelmistot toimivat rinnakkain, huomautti kehittäjä ja lisäsi, että ne saattavat olla vuorovaikutuksessa toistensa kanssa oudolla tavalla. Voimmeko kohtuudella odottaa ohjelmistotoimittajan ennustavan jokaisen yhteentoimivuuden reunatapauksen?

Toinen huolenaihe oli mahdollinen käyttäjävirhe. Entä jos käyttäjä on määrittänyt ohjelmiston väärin, jolloin se tai sen komponentti on vuorovaikutuksessa epävarmana huonon käyttöliittymän vuoksi? Entä jos käyttäjä ei ole asentanut korjaustiedostoa oikeutetusta syystä, kuten lainsäädännöllisestä rajoituksesta? Onko olemassa sellaista asiaa kuin osittainen vastuu virheellisistä määrityksistä, ja miten se voidaan päättää?

Yrityksillä on muitakin haasteita, jotka yrittävät noudattaa myyjän vastuukysymyksiä. Monet ohjelmistot eivät ole tyhjiössä; se hyödyntää kolmannen osapuolen kirjastoja – usein julkaistu avoimen lähdekoodin lisensseillä –, jotka saattavat sisältää omia tietoturvaongelmiaan. Log4Shell, Log4J Java -lokikirjaston virhe, joka vaikutti tuhansien yritysten kyberturvallisuuteen huomaamatta vuodesta 2013 lähtien – on loistava esimerkki. Kuka maksaa, jos rakentamasi ohjelmisto sattuu käyttämään suojaamattomia kolmannen osapuolen komponentteja?

Näkemyksesi ohjelmistoista tulisi ulottua omien rajojesi ulkopuolelle, Easterly ehdotti. Hän toisti Valkoisen talon pyynnön ohjelmistojen materiaaliluettelosta (SBOM), joka määrittelee kootun ohjelmiston alkuperän.

Miltä suojatut ohjelmistot näyttävät?

Monimutkaisen tuotteen toimittajien saattaminen vastuuseen herättää muita ongelmia, kuten kuinka me edes määrittelemme ohjelmiston suojauksen. Määritelmät ovat jatkumoa, joka ulottuu riittämättömästä – joistakin staattisista perusohjelmistotesteistä – epäkäytännölliseen – muodolliseen todentamiseen. Jälkimmäinen vertaa ohjelmiston toimintaa abstraktiin matemaattiseen malliin. Tällaisia ​​järjestelmiä on olemassa, mutta ne on tarkoitettu erikoissovelluksiin ja vaativat paljon koodauskustannuksia.

Realistisin määritelmä on jossain keskellä, ja dokumentoidut todisteet parhaista käytännöistä, jotka sisällyttävät tietoturvan suoraan ohjelmistotuotantoon suunnitteluvaiheesta lähtien. NISTin Secure Software Development Framework, jota NCS suosittelee, ilmaisee monet näistä.

Toinen Easterlyn suositus oli muistiturvallisten kielten käyttö. Monien nykyaikaisten ohjelmistojen tietoturvavirheiden taustalla on muistin väärinkäyttö. Nopeina, matalan tason kielinä, jotka edellyttävät ohjelmoijien hallitsevan muistia itse, C ja C++ ovat tässä erityisen heikkoja. Go, Python ja Java ovat korkeamman tason tulkittuja kieliä, jotka käsittelevät muistia ohjelmoijan puolesta. Uudempi kieli, Mozilla's Rust, on myös muistiturvallinen – ja se on ensimmäinen kieli C:n ja kokoonpanon lisäksi, jota tuetaan Linux-ytimessä.

Easterly vaati myös läpinäkyviä haavoittuvuuksien paljastamiskäytäntöjä ohjelmistotoimittajien keskuudessa. Liian usein he tekevät parhaansa pitääkseen tietoturvavirheet hillittyinä ja jättävät huomiotta tietoturvavirheraportit tai joskus estävät niitä. Hän sanoi, että avoimempi ja yhteistyökykyisempi suhde kyberturvallisuuden tutkijoiden kanssa auttaisi sulkemaan ohjelmistopuutteita.

Välivaiheet

Odottaessaan kongressia Valkoinen talo luottaa siihen Hallituksen päätös kansakunnan kyberturvallisuuden parantamisesta, nyt yli kaksi vuotta vanha, työntämään myyjiä oikeaan suuntaan. Ovaalitoimisto ei voi suoraan rangaista yrityksiä huonon koodin tekemisestä, mutta EO kieltää liittovaltion virastoja ostamasta sitä niiltä.

Voimme myös etsiä vastauksia standardoinnista. Päivitetty ISO 27001:2022 -standardi sisältää Liite A Valvonta 8.28, joka määrittelee turvalliset suunnittelu- ja kehitysperiaatteet sekä sisäisesti kehitetyille ohjelmistoille että ulkoisen koodin uudelleenkäytölle. Koska monet yritykset luottavat tähän akkreditointiin keskeisenä erottavana tekijänä, tämän hallinnan lisääminen luo lisäpaineita ohjelmistoturvallisuuden parantamiseen ja dokumentointiin.

Muuttuvat poliittiset vuorovedet

Vaikka myyjän vastuu on tahmea aihe, kongressi ei ole aiemmin väittänyt käyttämästä lainsäädäntöä monimutkaisten teknologiaongelmien ratkaisemiseen. Yritysten kiinnostus vaikuttaa merkittävästi sen haluttomuuteen puuttua tähän ongelmaan, koska ohjelmistoteollisuus, jolla on paljon lobbausvoimaa, ohjaa.

Siitä huolimatta yhä useammat ihmiset pyrkivät pitämään tiukasti kilpailtua alaa vastuussa. Facebook on saattanut virallisesti hylätä vanhan sisäisen iskulauseensa "liiku nopeasti ja riko asiat", mutta se on silti de facto toimintamalli teknologiayrityksille, jotka kilpailevat innovaatioiden kanssa. Ohjelmistot vaikuttavat yhä enemmän jokapäiväiseen elämäämme, joten jonkinlainen tasapaino holtittoman omituisen ominaisuuskehityksen ja mitatun vastuun välillä turvallisesta toiminnasta on tärkeämpää kuin koskaan.