Bør softwareleverandører holdes ansvarlige for usikkerhed?

En nul-dages fejl i din go-to-virksomhedssoftwareapplikation tillod angribere at komme ind på dit netværk og kompromitterede følsomme data. Det kommer til at koste meget at ordne, før du overhovedet når til lovpligtige bøder og kundesøgsmål – og ansøgningen er ikke engang din. Hvem skal betale?

Det vil sandsynligvis ikke være firmaet, der har solgt dig softwaren. Deres slutbrugerlicensaftaler (EULA'er) begrænser typisk deres ansvar. De fleste af os læser ikke disse, fordi de er for lang og for kompleks.

I løbet af de sidste par måneder er kravene om at ændre denne situation blevet højere og nået de øverste regeringsniveauer. I februar, Jen Easterly, direktør for Cybersecurity and Infrastructure Security Agency, udtrykkeligt kaldet for leverandøransvar under en tale på Carnegie Mellon University.

Verden er kommet til at acceptere usikker teknologi som reglen, når det burde være undtagelsen, sagde hun. "Teknologiproducenter skal tage ejerskab over sikkerhedsresultaterne for deres kunder."

Easterly bad regeringen om at offentliggøre lovgivning, der ville forhindre teknologivirksomheder i at fraskrive sig ansvar ved kontrakt. Biden-administrationens National Cybersikkerhedsstrategi, der blev lanceret i marts, gentog opfordringen til denne lov.

En langvarig debat

Regeringer har overvejet dette problem før. Det britiske overhus anbefales holde softwareleverandører ansvarlige i 2007, selv efter at have hørt argumenter mod leverandøransvar fra softwareudviklere på forskellige grunde.

Disse protester omfattede den rene kompleksitet af moderne softwaremiljøer. Mange typer software eksisterer sammen, påpegede udvikleren og tilføjede, at de kunne interagere med hinanden på mærkelige måder. Kan vi med rimelighed forvente, at en softwareleverandør forudsiger alle interoperabilitetskanter?

En anden bekymring var muligheden for brugerfejl. Hvad hvis en bruger fejlkonfigurerede softwaren, hvilket gør den eller en komponent, den interagerer med, usikker på grund af en dårlig brugergrænseflade? Hvad hvis brugeren undlod at anvende en patch af en legitim årsag, såsom en regulatorisk begrænsning? Er der sådan noget som delvist ansvar for fejlkonfiguration, og hvordan kan det afgøres?

Der er andre udfordringer for virksomheder, der forsøger at overholde leverandøransvarsproblemer. Meget software er ikke bygget i et vakuum; det trækker på tredjepartsbiblioteker – ofte udgivet under open source-licenser – som kan indeholde deres egne sikkerhedsproblemer. Log4Shell, fejlen i Log4J Java-logningsbiblioteket, der har påvirket cybersikkerhed for tusindvis af virksomheder ubemærket siden 2013 – er et godt eksempel. Hvem betaler, hvis den software, du har bygget, tilfældigvis bruger en usikker tredjepartskomponent?

Dit syn på software bør strække sig ud over dine egne grænser, foreslog Easterly. Hun gentog Det Hvide Hus' opfordring til en Software Bill of Materials (SBOM) til at definere herkomsten af ​​samlet software.

Hvordan ser sikker software ud?

At holde leverandører af et komplekst produkt ansvarlige rejser andre problemer, såsom hvordan vi selv definerer softwaresikkerhed. Definitioner ligger langs et kontinuum, der spænder fra den utilstrækkelige – beviser nogle grundlæggende statiske softwaretests – til den upraktiske – formelle verifikation. Sidstnævnte kontrollerer softwaredrift mod en abstrakt matematisk model. Sådanne systemer findes, men de er til specialiserede applikationer og involverer en masse kodningsomkostninger.

Den mest realistiske definition ligger et sted i midten med dokumenteret bevis på bedste praksis, der integrerer sikkerhed direkte i softwareproduktion fra designfasen og frem. NIST's Secure Software Development Framework, som NCS anbefaler, artikulerer mange af disse.

En anden anbefaling fra Easterly var brugen af ​​hukommelsessikre sprog. Masser af moderne softwaresikkerhedsfejl har deres basis i hukommelsesmisbrug. Da hurtige sprog på lavt niveau, der kræver, at programmører selv kan administrere hukommelsen, er C og C++ særligt svage her. Go, Python og Java er fortolkede sprog på højere niveau, der håndterer hukommelse på programmørens vegne. Et nyere sprog, Mozilla's Rust, er også hukommelsessikkert – og er det første sprog bortset fra C og assembly, der understøttes i Linux-kernen.

Easterly opfordrede også til gennemsigtige politikker for afsløring af sårbarheder blandt softwareleverandører. Alt for ofte gør de deres bedste for at holde sikkerhedsfejl lavmælte, ignorerer eller undertiden afskrækkende sikkerhedsfejlrapporter. Hun sagde, at et mere åbent og samarbejdende forhold med cybersikkerhedsforskere ville hjælpe med at lukke softwarehuller.

Mellemtrin

Mens det venter på Kongressen, stoler Det Hvide Hus på Bekendtgørelse om forbedring af landets cybersikkerhed, nu over to år gammel, for at skubbe sælgerne i den rigtige retning. Det Ovale Kontor kan ikke direkte straffe virksomheder for at lave dårlig kode, men EO forbyder føderale agenturer at købe det fra dem.

Vi kan også se til standardisering for at få svar. Den opdaterede ISO 27001:2022-standard omfatter Bilag A Kontrol 8.28, som definerer sikre design- og udviklingsprincipper for både internt udviklet software og genbrug af ekstern kode. Med mange virksomheder, der er afhængige af denne akkreditering som en vigtig differentiator, skaber tilføjelsen af ​​denne kontrol yderligere pres for at forbedre og dokumentere softwaresikkerhed.

Skiftende politiske tidevand

Mens leverandøransvar er et klæbrigt emne, har Kongressen ikke viget tilbage fra at bruge lovgivning til at tackle komplekse teknologiproblemer i fortiden. Virksomhedernes interesse spiller en væsentlig rolle i dens modvilje mod at tackle dette særlige problem, drevet af en softwareindustri med masser af lobbykraft.

Ikke desto mindre er flere mennesker på en mission om at stille en stærkt konkurrencepræget industri til ansvar. Facebook kunne officielt have opgivet sit gamle interne slogan, "bevæg dig hurtigt og bryd tingene", men det er stadig en de facto driftsmodel for tech-virksomheder, der ræser om at innovere. Efterhånden som software påvirker mere af vores hverdag, er en form for balance mellem hensynsløs udvikling af funktioner og målt ansvar for sikker drift mere nødvendig end nogensinde.