-

Willen we 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.

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 publiceerden 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.

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.

Hoog tijd voor een nieuw soort oplossingen

Het is geen nieuw idee. Jonathan Zittrain beschreef 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 je? Zou zo’n constructie werken?

Deel dit bericht

1 Reactie

Marcel

Ik zie toch twee zwakke punten:
1. Alles is met geld op te lossen
2. De fabrikant is het probleem

In de praktijk zie ik juist dat veel partijen zelf hun software niet upgraden, ook al kan het. Ze werken zelf met oude systemen waarbij steeds meer van elkaar afhankelijk is en upgraden steeds moeilijker. Tevens is bij de keuze van geschikte software de beveiliging vaak geen reden om voor een partij te kiezen. Daarmee is er dus geen stimulans voor ontwikkelaars om echt veilige software prioriteit te geven.

Verder is schade niet altijd uit te drukken in geld. Als mijn bedrijf zijn database beschadigd, dan is dat einde bedrijf. Dat is niet in geld uit te drukken.

De oplossing is volgens mij veel simpeler. Zorg ervoor dat je software gebruikt die een goede API heeft waarmee exporteren van gegevens mogelijk is. Je kunt dan als gebruiker altijd overstappen naar een betere partij.

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond