Door een zero-day-fout in uw bedrijfssoftwareapplicatie konden aanvallers uw netwerk binnendringen en gevoelige gegevens in gevaar brengen. Het gaat veel kosten om het probleem op te lossen voordat je zelfs maar te maken krijgt met boetes van toezichthouders en rechtszaken tegen klanten – en de aanvraag is niet eens van jou. Wie moet betalen?

Het zal waarschijnlijk niet het bedrijf zijn dat u de software heeft verkocht. Hun licentieovereenkomsten voor eindgebruikers (EULA's) beperken doorgaans hun aansprakelijkheid. De meesten van ons lezen deze niet omdat ze dat wel zijn te lang en te complex.

De afgelopen maanden zijn de eisen om deze situatie te veranderen steeds luider geworden en hebben ze de hoogste regeringsniveaus bereikt. In februari zei Jen Easterly, directeur van de Cybersecurity and Infrastructure Security Agency, nadrukkelijk genoemd voor leveranciersaansprakelijkheid tijdens een toespraak op de Carnegie Mellon University.

De wereld is onveilige technologie als regel gaan accepteren, terwijl dit de uitzondering zou moeten zijn, zei ze. “Technologiefabrikanten moeten eigenaar worden van de beveiligingsresultaten voor hun klanten.”

Easterly vroeg de regering om wetgeving te publiceren die technologiebedrijven ervan zou weerhouden contractueel aansprakelijkheid af te wijzen. Die van de regering-Biden Nationale Cybersecurity Strategie, dat in maart werd gelanceerd, herhaalde de roep om deze wet.

Een al lang bestaand debat

Regeringen hebben zich al eerder over dit probleem gebogen. Het Britse House of Lords aanbevolen het ter verantwoording roepen van softwareleveranciers in 2007, zelfs nadat softwareontwikkelaars op verschillende gronden argumenten hadden gehoord tegen de aansprakelijkheid van softwareontwikkelaars.

Deze protesten omvatten de enorme complexiteit van moderne softwareomgevingen. Er bestaan ​​veel soorten software naast elkaar, benadrukt de ontwikkelaar, en voegt eraan toe dat ze op vreemde manieren met elkaar kunnen communiceren. Kunnen we redelijkerwijs van een softwareleverancier verwachten dat hij elk geval van interoperabiliteitsranden kan voorspellen?

Een andere zorg was de kans op gebruikersfouten. Wat als een gebruiker de software verkeerd heeft geconfigureerd, waardoor de software of een component waarmee deze communiceert, onveilig wordt vanwege een slechte gebruikersinterface? Wat moet er gebeuren als de gebruiker er om legitieme redenen, zoals een wettelijke beperking, niet in slaagt een patch toe te passen? Bestaat er zoiets als gedeeltelijke aansprakelijkheid voor een verkeerde configuratie, en hoe kan daarover worden beslist?

Er zijn nog andere uitdagingen voor bedrijven die proberen te voldoen aan kwesties inzake leveranciersaansprakelijkheid. Veel software wordt niet in een vacuüm gebouwd; het maakt gebruik van bibliotheken van derden – vaak uitgegeven onder open-sourcelicenties – die mogelijk hun eigen beveiligingsproblemen bevatten. Log4Shell, de bug in de Log4J Java-logboekbibliotheek die sinds 2013 onopgemerkt de cyberveiligheid van duizenden bedrijven heeft aangetast, is daar een goed voorbeeld van. Wie betaalt als de door u gebouwde software een onveilig onderdeel van derden gebruikt?

Je kijk op software moet verder reiken dan je eigen grenzen, stelde Easterly. Ze herhaalde de oproep van het Witte Huis voor een Software Bill of Materials (SBOM) om de herkomst van geassembleerde software te definiëren.

Hoe ziet veilige software eruit?

Het aansprakelijk stellen van leveranciers van een complex product brengt andere problemen met zich mee, zoals hoe we softwarebeveiliging überhaupt definiëren. Definities liggen op een continuüm, variërend van ontoereikend – wat enkele fundamentele statische softwaretests bewijst – tot onpraktisch – formele verificatie. Deze laatste controleert de werking van de software aan de hand van een abstract wiskundig model. Dergelijke systemen bestaan ​​wel, maar ze zijn bedoeld voor gespecialiseerde toepassingen en brengen veel codeeroverhead met zich mee.

De meest realistische definitie ligt ergens in het midden, met gedocumenteerd bewijs van best practices die beveiliging vanaf de ontwerpfase rechtstreeks in de softwareproductie integreren. Het Secure Software Development Framework van NIST, die de NCS aanbeveelt, verwoordt veel hiervan.

Een andere aanbeveling van Easterly was het gebruik van geheugenveilige talen. Veel moderne softwarefouten in de beveiliging vinden hun oorsprong in geheugenmisbruik. Als snelle talen op laag niveau, waarbij programmeurs zelf het geheugen moeten beheren, zijn C en C++ hier bijzonder zwak. Go, Python en Java zijn geïnterpreteerde talen van een hoger niveau die namens de programmeur met het geheugen omgaan. Een recentere taal, Mozilla's Rust, is ook geheugenveilig – en is de eerste taal, afgezien van C en assembly, die in de Linux-kernel wordt ondersteund.

Easterly riep ook op tot een transparant beleid voor het openbaar maken van kwetsbaarheden onder softwareleveranciers. Maar al te vaak doen ze hun best om beveiligingsbugs laag te houden, waarbij ze rapporten over beveiligingsbugs negeren of soms zelfs ontmoedigen. Ze zei dat een meer open en collaboratieve relatie met cybersecurity-onderzoekers zou helpen de gaten in de software te dichten.

Tussenstappen

Terwijl het op het Congres wacht, vertrouwt het Witte Huis op de Executive Order over het verbeteren van de cyberbeveiliging van de natie, nu ruim twee jaar oud, om verkopers een duwtje in de goede richting te geven. Het Oval Office kan bedrijven niet rechtstreeks straffen voor het maken van waardeloze code, maar de EO verbiedt federale instanties om deze van hen te kopen.

We kunnen ook kijken naar standaardisatie voor antwoorden. De bijgewerkte ISO 27001:2022-norm omvat: Bijlage A Controle 8.28, dat veilige ontwerp- en ontwikkelingsprincipes definieert voor zowel intern ontwikkelde software als het hergebruik van externe code. Omdat veel bedrijven vertrouwen op deze accreditatie als een belangrijke onderscheidende factor, zorgt de toevoeging van deze controle voor extra druk om de softwarebeveiliging te verbeteren en te documenteren.

Veranderende politieke getijden

Hoewel de aansprakelijkheid van leveranciers een lastig onderwerp is, heeft het Congres er in het verleden niet voor teruggeschrokken om wetgeving te gebruiken om complexe technologische problemen aan te pakken. De belangen van het bedrijfsleven spelen een belangrijke rol in de onwil om dit specifieke probleem aan te pakken, gedreven door een software-industrie met veel lobbymacht.

Niettemin zijn steeds meer mensen op een missie om een ​​intens concurrerende industrie ter verantwoording te roepen. Facebook heeft misschien officieel zijn oude interne slogan ‘beweeg snel en maak dingen kapot’ verlaten, maar dat is nog steeds een de facto bedrijfsmodel voor technologiebedrijven die racen om te innoveren. Nu software een steeds groter deel van ons dagelijks leven beïnvloedt, is een soort evenwicht tussen de roekeloze ontwikkeling van gee-whiz-functies en de afgemeten verantwoordelijkheid voor een veilige werking meer dan ooit noodzakelijk.