Moet sagtewareverkopers aanspreeklik gehou word vir onsekerheid?

'n Zero-day fout in jou go-to onderneming sagteware toepassing het aanvallers in jou netwerk toegelaat en sensitiewe data in gevaar gestel. Dit gaan baie kos om reg te maak voordat jy selfs by regulatoriese boetes en kliëntregsgedinge uitkom – en die aansoek is nie eens joune nie. Wie moet betaal?

Dit sal waarskynlik nie die maatskappy wees wat die sagteware aan jou verkoop het nie. Hul eindgebruikerslisensie-ooreenkomste (EULA's) beperk gewoonlik hul aanspreeklikheid. Die meeste van ons lees dit nie omdat hulle dit is nie te lank en te kompleks.

Oor die laaste paar maande het eise om hierdie situasie te verander al hoe harder geword en die hoogste regeringsvlakke bereik. In Februarie het Jen Easterly, direkteur van die agentskap vir kuberveiligheid en infrastruktuur, uitdruklik genoem vir verkopersaanspreeklikheid tydens 'n toespraak by Carnegie Mellon Universiteit.

Die wêreld het onveilige tegnologie as die reël aanvaar wanneer dit die uitsondering moet wees, het sy gesê. "Tegnologievervaardigers moet eienaarskap neem van die sekuriteitsuitkomste vir hul kliënte."

Easterly het die regering gevra om wetgewing te publiseer wat tegnologiemaatskappye sal keer om aanspreeklikheid per kontrak te ontken. Die Biden-administrasie Nasionale Kuberveiligheidstrategie, wat hierdie Maart van stapel gestuur is, het die oproep vir hierdie wet weerspieël.

'n Langdurige debat

Regerings het hierdie probleem al voorheen besin. Die Britse House of Lords aanbeveel sagtewareverkopers aanspreeklik gehou in 2007, selfs nadat hulle argumente teen verskaffersaanspreeklikheid van sagteware-ontwikkelaars op verskeie gronde aangehoor het.

Hierdie betogings het die blote kompleksiteit van moderne sagteware-omgewings ingesluit. Baie soorte sagteware bestaan ​​saam, het die ontwikkelaar daarop gewys en bygevoeg dat hulle op vreemde maniere met mekaar kan kommunikeer. Kan ons redelikerwys van 'n sagtewareverskaffer verwag om elke interoperabiliteitsrandgeval te voorspel?

Nog 'n bekommernis was die potensiaal vir gebruikersfoute. Wat as 'n gebruiker die sagteware verkeerd gekonfigureer het, dit of 'n komponent waarmee dit in wisselwerking was, onseker maak as gevolg van 'n swak gebruikerskoppelvlak? Wat as die gebruiker om 'n wettige rede, soos 'n regulatoriese beperking, versuim het om 'n pleister toe te pas? Is daar iets soos gedeeltelike aanspreeklikheid vir wankonfigurasie, en hoe kan dit besluit word?

Daar is ander uitdagings vir maatskappye wat probeer om te voldoen aan verkopersaanspreeklikheidskwessies. Baie sagteware word nie in 'n vakuum gebou nie; dit maak gebruik van derdeparty-biblioteke – dikwels vrygestel onder oopbronlisensies – wat hul eie sekuriteitskwessies kan bevat. Log4Shell, die fout in die Log4J Java-logboekbiblioteek wat kuberveiligheid vir duisende maatskappye ongemerk sedert 2013 beïnvloed het - is 'n uitstekende voorbeeld. Wie betaal as die sagteware wat jy gebou het toevallig 'n onveilige derdeparty-komponent gebruik?

Jou siening van sagteware moet buite jou eie grense strek, het Easterly voorgestel. Sy het die Withuis se oproep om 'n Sagtewarebrief van Materiale (SBOM) weerspieël om die herkoms van saamgestelde sagteware te definieer.

Hoe lyk veilige sagteware?

Om verskaffers van 'n komplekse produk aanspreeklik te hou, bring ander kwessies na vore, soos hoe ons selfs sagtewaresekuriteit definieer. Definisies lê langs 'n kontinuum, wat wissel van die onvoldoende - wat sommige basiese statiese sagtewaretoetse bewys - tot die onpraktiese - formele verifikasie. Laasgenoemde kontroleer sagtewarewerking teen 'n abstrakte wiskundige model. Sulke stelsels bestaan ​​wel, maar hulle is vir gespesialiseerde toepassings en behels baie kodering bokoste.

Die mees realistiese definisie sit iewers in die middel, met gedokumenteerde bewys van beste praktyke wat sekuriteit direk in sagtewareproduksie vanaf die ontwerpfase insluit. NIST se veilige sagteware-ontwikkelingsraamwerk, wat die NKV aanbeveel, verwoord baie hiervan.

Nog 'n aanbeveling van Easterly was die gebruik van geheue-veilige tale. Baie moderne sagteware sekuriteitsfoute het hul basis in geheue misbruik. Soos vinnige, lae-vlak tale wat vereis dat programmeerders geheue self bestuur, C en C++ is veral swak hier. Go, Python en Java is hoër-vlak, geïnterpreteerde tale wat geheue namens die programmeerder hanteer. 'n Meer onlangse taal, Mozilla's Rust, is ook geheue-veilig – en is die eerste taal buiten C en samestelling wat in die Linux-kern ondersteun word.

Easterly het ook gevra vir deursigtige beleide oor die openbaarmaking van kwesbaarheid onder sagtewareverkopers. Al te dikwels doen hulle hul bes om sekuriteitsfoute laagtepunt te hou, en ignoreer of ontmoedig soms sekuriteitsfoutverslae. Sy het gesê 'n meer oop en samewerkende verhouding met kuberveiligheidsnavorsers sal help om sagteware-gapings te sluit.

Intermediêre stappe

Terwyl dit op die Kongres wag, maak die Withuis staat op die Uitvoerende bevel oor die verbetering van die nasie se kuberveiligheid, nou meer as twee jaar oud, om verkopers in die regte rigting te stoot. Die Oval Office kan nie maatskappye direk straf vir die maak van rowwe kode nie, maar die EO verbied federale agentskappe om dit by hulle te koop.

Ons kan ook kyk na standaardisering vir antwoorde. Die bygewerkte ISO 27001:2022-standaard sluit in Bylae A Beheer 8.28, wat veilige ontwerp- en ontwikkelingsbeginsels definieer vir beide intern ontwikkelde sagteware en die hergebruik van eksterne kode. Met baie maatskappye wat op hierdie akkreditasie staatmaak as 'n sleuteldifferensieerder, skep die toevoeging van hierdie beheer bykomende druk om sagtewaresekuriteit te verbeter en te dokumenteer.

Veranderende politieke getye

Alhoewel verskaffersaanspreeklikheid 'n taai onderwerp is, het die Kongres in die verlede nie weggeskram van die gebruik van wetgewing om komplekse tegnologiekwessies aan te pak nie. Korporatiewe belangstelling speel 'n beduidende rol in sy onwilligheid om hierdie spesifieke probleem aan te pak, gedryf deur 'n sagteware-industrie met baie lobbykrag.

Nietemin is meer mense op 'n missie om 'n intens mededingende bedryf tot verantwoording te roep. Facebook het dalk amptelik sy ou interne slagspreuk, "beweeg vinnig en breek dinge" laat vaar, maar dit is steeds 'n de facto bedryfsmodel vir tegnologiefirmas wat jaag om te innoveer. Aangesien sagteware meer van ons alledaagse lewens raak, is 'n soort balans tussen roekelose gee-whiz-funksie-ontwikkeling en gemete verantwoordelikheid vir veilige werking meer nodig as ooit.