Een verzekering tegen uitblijven van beveiligingsupdates
Het is makkelijk vaststellen dat ergens een probleem bestaat. Moeilijker is daar dan een goede oplossing voor te vinden. Dat is niet anders met problemen bij het beschermen van onze digitale infrastructuur.
Foto: Martin Kenny
Geen updates, dan broncode openbaar?
Het is stom dat we niet meer aandacht besteden aan het snel en verantwoord oplossen van kwetsbaarheden in onze digitale infrastructuur. Omdat we steeds afhankelijker zijn van die infrastructuur, is de impact van kwetsbaarheden steeds groter. Het al dan niet bedoelde misbruik van een kwetsbaarheid kan onze hele maatschappij langdurig verstoren. Daarom publiceerden12 broodnodige updates voor beveiligingsupdates we eerder een overzicht van twaalf punten waarop we dat proces van wegwerken van kwetsbaarheden moeten verbeteren.
In reactie daarop vroeg een van de lezers: “We moeten ons afvragen of software die een jaar geen updates heeft gekregen verplicht open source zou moeten worden.” Een interessante gedachte, maar zoals wel vaker is dat misschien nét iets te kort door de bocht.
If it ain't broke, don't fix it
Eerst een open deur: het is natuurlijk niet zo dat software die een jaar lang geen updates gehad heeft, dan ook kwetsbaar is. Of software een update heeft gehad of niet is op zichzelf geen goed criterium. Er is pas sprake van een probleem als er een kwetsbaarheid gevonden is en die kwetsbaarheid niet snel en op verantwoorde wijze wordt opgelost. En zelfs dat is rekbaar: want sommige kwetsbaarheden zouden met een hogere prioriteit gedicht moeten worden dan andere. Anders gezegd: updates afdwingen die niet nodig zijn verhoogt juist het risico op kwetsbaarheden.
Open source is geen panacee
Het is ook niet zo dat als de broncode vrij beschikbaar is, die software niet meer kwetsbaar kan zijn. En dus is het vrijgeven van de broncode als de software niet meer onderhouden lijkt te worden meestal ook geen oplossing. Een kwetsbaarheid in bijvoorbeeld een webcam is niet opeens weg als de broncode van de software op die webcam open source is. Nee, er moet dan nog altijd iemand zijn die de moeite neemt om de kwetsbaarheid in de software op te zoeken, te analyseren en te dichten. En dan is er nog steeds een mechanisme nodig dat er voor zorgt dat de nieuwe versie van de software op al die webcams komt te draaien.
Het al dan niet bedoelde misbruik van een kwetsbaarheid kan onze hele maatschappij langdurig verstoren.
Onopgelost probleem
En dus is de vraag hoe je het probleem dan moet oplossen. Stel dat er een kwetsbaarheid gevonden wordt in de software waarmee een uiterst populaire webcam wordt aangestuurd, terwijl die software niet meer onderhouden wordt. Dat laatste hoeft overigens geen luiheid van de fabrikant te zijn: dit kan ook voorkomen als de fabrikant in tussentijd failliet is gegaan. In zo’n situatie is het nog altijd belangrijk dat de kwetsbaarheid opgelost wordt. Zoals hierboven uitgelegd is het afdwingen dat de broncode openbaar is, onvoldoende. Maar hoe dan?
Verzekering tegen kwetsbaarheden
Wat misschien wél zou werken is als fabrikanten gedwongen worden om geld opzij te zetten waarmee anderen de kwetsbaarheden weg kunnen werken als de fabrikant dat – om welke reden dan ook – niet meer doet. Of, als dat niet meer mogelijk is, de kosten van de ontstane schade en het opruimen ervan kan worden vergoed. Een fabrikant mag dan alleen een product op de markt brengen als hij geld in een potje van een onafhankelijke derde heeft gestopt. De hoogte van die premie kan afhankelijk zijn van de mate waarin de fabrikant nadenkt over de beveiliging van zijn producten en het al dan niet beschikbaar maken van de geheime broncode.
Een kwetsbaarheid in een webcam is niet opeens weg als de broncode van de software op die webcam open source is.
Hoog tijd voor een nieuw soort oplossingen
Het is geen nieuw idee. Jonathan Zittrain beschreefZittrain's opinie: From Westworld to Best World for the Internet of Things het al eerder eens:
“Companies making a critical mass of internet-enabled products should be required to post a “networked safety bond” to be cashed in if they abandon maintenance for a product, or fold entirely. Insurers can price bonds according to companies’ security practices. There’s an example of such a system for coal mining, to provide for reclamation and cleanup should the mining company leave behind a wasteland. For internet-connected appliances, “reclamation” can entail work by nonprofit foundations to maintain the code for abandoned products, creating an “island of misfit toys […].”
In zijn opinie noemt hij nog twee andere oplossingen: internet-of-things-apparaten zouden ook zonder internetverbinding moeten kunnen werken én gebruikers moeten de mogelijkheid hebben om makkelijk over te stappen naar een andere fabrikant.
Wat denken jullie? Zou zo’n constructie werken? Of, als niet, waarom niet?
Douwe
Hey Rejo,
Interessante gedachte. Maar ik zie nog één probleem: als een fabrikant zich verzekert heeft, dan kan dat de motivatie om updates uit te brengen verkleinen. Immers; door de verzekering (waar al voor betaald is) is er minder aanleiding een update uit te brengen, aangezien (een deel van) de risico’s voor het bedrijf zijn afgedekt.
Nog sterker: de fabrikant kan denken dat hij nu alleen nog reactief (nadat er iets gevongen is) hoeft te doen en niet meer preventief.
Dan the Man
We zien tegenwoordig steeds vaker hard- en software met gaten erin, die de uitgever dan probeert te dichten nadat het produkt al verkocht is. (een uitzondering zijn de Spectre- en Meltdown bugs waarvoor Intel nog geen oplossing laat staan een inruilactie heeft).
Naderhand lekken dichten is ingewikkeld en duur. Een produkt als Windows heeft al honderden patches ondergaan, zodat je kunt concluderen dat de volgende kwetsbaarheid zich binnenkort zal aandienen.
Om het probleem op te lossen moet software daarom worden gevalideeerd, voordat ze verspreid mag worden. Dergelijke regels bestaan al voor geneesmidddelen en auto’s; sjoemelsoftware is dus verboden omdat ze deel uitmaakt van een auto, maar voor PC-software gelden bestaan geen wetten of eisen.
gs1966
Open source (FOSS) is geen panacee, zeker, maar ik denk dat het een noodzakelijke voorwaarde is om beveiligingsupdates duurzaam te organiseren. Inderdaad moet iemand het dan doen, maar ik denk dat initiatieven eerder stranden vanwege gebrek aan FOSS software (bv. drivers) dan aan een gebrek aan mensen die het willen dragen.
David
Leuk idee, jammer dat dit nooit gaat werken. Het verplicht open-sourcen van software schieten we weinig mee op zolang er geen partij is die dit wil onderhouden. Het verplicht verzekeren voor onderhoud zou alleen zin hebben als dit wereldwijde regelgeving wordt. Helaas is dat onhaalbaar, met als gevolg dat het enkel de concurrentiepositie zal verslechteren van fabrikanten die toch al het beste voor hebben met hun klanten.
Een veel betere oplossing lijkt mij, om te regelen dat de firmware van dergelijke devices altijd vervangen moet kunnen worden. Zodat de gebruiker zelf kan kiezen tussen de firmware van de fabrikant, of (mocht die niet meer onderhouden worden) een alternatieve firmware van een 3e partij of veelgebruikte open-source pakketen die wél actief ontwikkeld worden.
Fabrikanten proberen dit steeds meer in te perken. Het rooten van routers en smartphones wordt bemoeilijkt, en zelfs computers en laptops worden tegenwoordig soms hardwarematig beschermd tegen het vervangen van de firmware. Laten we liever dáár wat aan doen!
Rejo Zenger
We zijn het denk ik met elkaar eens dat het verplicht open source maken van de broncode van software niet de oplossing gaat zijn, omdat dat op zichzelf onvoldoende is. Als niemand die software onderhoud, blijft de software kwetsbaar.
Dat is ook de reden dat ik weinig zie in de door jou aangedragen oplossing: als je de mogelijkheid hebt om alternatieve firmware te installeren maakt dat nog niet dat die alternatieve (en hopelijk minder kwetsbare) firmware dan ook beschikbaar is én ook niet dat die zodanig beschikbaar is dat het makkelijk voor Jan en Alleman te installeren is.
Een verzekering zorgt er wel voor dat de schade die ontstaat op een of andere wijze kan worden vergoed of ongedaan gemaakt kan worden.
Ik ben het ook met je eens dat we dit het beste om mondiaal niveau moeten regelen. Aangezien dat niet echt realistisch is, zou een begin op Europees niveau wél goed zijn. Daar kunnen we ons al veel ellende mee besparen.
ardje
Rejo, je zegt het zelf:
Geen van beide oplossingen werken. Maar samen werken ze wel.
1) verplicht open source, met alle tools om het te builden a la GNU. Een heleboel bedrijven zijn daar eigenlijk best ver in.
2) Een verzekering die een bedrag uitkeert voor de eerste 2 of 3 fixes in 1)
3) aan de hand van 1) kan de verzekeraar in 2) extra geld eisen van de fabrikant want daaruit kan blijken dat ze zich niet hebben gehouden aan 4)
4) bedrijven verplichten om enigzins up to date beveiliging ingebouwd te hebben die overeenkomstige de threat level is.
4) heeft heel veel impact op cloud based IoT services.
Er zou nog een ketenaansprakelijkheid moeten komen.
Maar ik vind 1) het belangrijkst. Waarom: je kan gewoon niet verplichten dat een bedrijf software levert en die software tot in den treure blijft onderhouden zonder daarvoor vergoed te worden. Dat is gewoon oneerlijk.
Je kan het intel, amd en arm aanrekenen dat ze niet genoeg hebben nagedacht over spectr. Maar tot hoever strekt die verantwoordelijkheid.
Zijn al de partijen die zich gebaseerd hebben op die cpu’s ook eeuwig aansprakelijk? Of hebben we gewoon een maatschappelijk probleem.
Je kan niet verwachten dat iemand die voor een dag werk betaald heeft gekregen, nog een jaar doorwerkt.
1) en 2) is eigenlijk het afkopen van verantwoordelijkheid.
Let wel dat 1) vrijwel onmogelijk is. Als je de “source code” van een galaxy telefoon krijgt, dan krijg je die met blobs van partijen die nooit source code zullen laten zien (broadcom, ARM media voor de Mali bijvoorbeeld).