CPB: maak leveranciers aansprakelijk voor softwarefouten
Om de cyberveiligheid in Nederland te vergroten kunnen softwareleveranciers aansprakelijk worden gemaakt voor de schade die ontstaat uit softwarefouten, zo stelt het Centraal Planbureau in een vandaag verschenen rapport. Volgens het Planbureau neemt het risico op financiële cybercrime toe.
Het gaat dan om ransomware, phishing en andere vormen van cybercrime gericht op financieel gewin waar zowel eindgebruikers als bedrijven het slachtoffer van worden. Om de cyberveiligheid te vergroten ziet het Centraal Planbureau verschillende kansen. "Zo is het belangrijk de verantwoordelijkheid voor veiligheid neer te leggen bij de organisaties die daarvoor toegerust zijn. Dat is effectiever dan bijvoorbeeld van consumenten te eisen dat ze hun computers beveiligen, omdat zij vaak niet weten hoe de cybercriminelen van hun computers gebruik maken", aldus de organisatie.
Daarnaast wijst het erop dat softwareleveranciers aansprakelijk kunnen worden gemaakt voor de schade die ontstaat uit softwarefouten. "Onveilige software en onveilige digitale diensten blijven kansen bieden aan criminelen. Verkopers van software en digitale diensten hebben onvoldoende prikkels om te concurreren op de veiligheid van hun producten en beperken daarom hun aansprakelijkheid voor de deugdelijkheid van hun producten. Een wettelijk vereiste minimum productaansprakelijkheid kan verkopers een prikkel geven om de veiligheid van hun producten te vergroten", aldus het Planbureau in het rapport Risicorapportage Cyberveiligheid Economie (pdf).
Ook kan de overheid volgens het Centraal Planbureau slimmer gebruikmaken van ict, bijvoorbeeld door het beter naleven van de eigen beveiligingsstandaarden. Daarnaast wordt er gepleit om opsporingsdiensten de voordelen van ict beter te laten benutten, bijvoorbeeld door het instellen van één digitaal aangifteloket waar alle signalen van cybercrime met elkaar vergeleken kunnen worden. Uit cijfers van het CBS zou blijken dat 11% van de Nederlanders slachtoffer van cybercrime is geworden. Toch ontving de politie in de periode 2005 tot en met 2014 maar 16.000 aangiftes van computervredebreuk. In dezelfde periode van tien jaar werden 130 daders vanwege computervredebreuk bestraft door een rechter.
Een boete of aansprakelijkheid vind ik alleen kunnen als er sprake zou zijn van opzettelijk falen van QA of het niet fixen van reeds bekende bugs.
Als iets echt onbekend is (denk aan een voortvloeisel uit een typo die een buffer overflow toelaat) gaat dit wel ver.
Als het iets is dat de ontwikkel-club had kunnen weten (b.v. niet getest met een source-code scanner) dan is het denk ik wel terecht.
Iemand moet wel noemen wat het minimum is. Anders zal een leverancier alsnog zeggen: dat wisten we niet.
Kijk je b.v. naar websites met https://internet.nl en je zou dat het minimum noemen (feit voor overheid voor zover ik weet) dan lopen een hoop sites achter.
Zonder alernatief vind ik dit gebrul van niets.
Zonder alernatief vind ik dit gebrul van niets.
Geeft weer aan hoeveel verstand ze hebben van soft en hardware.
Zonder alernatief vind ik dit gebrul van niets.
Als we dan alleen al eens nadenken over heartbleed.
Of dat iedereen die eens iets doet in OpenSource, zou dan aansprakelijk gesteld kunnen worden voor fouten in zijn code.
[/quote]Zonder alernatief vind ik dit gebrul van niets.[/quote]Helemaal mee eens. Dit valt volgens mij gewoon onder kijk mij eens hard schreeuwen zonder eigenlijk na te denken over waar ze werkelijk over praten.
Legacy code, welke nog steeds heel veel gebruikt wordt, waar soms niemand meer iets van weet. En er aan zitten, eigenlijk zeer lasten en kostbaar is + if it ain't broke, don't fix it. Maar wat als er ergens toch een foutje in zit.
Software bevat altijd fouten... klaar..... Je kunt en moet de fouten natuurlijk tot een minimum houden. En je zou de leverancier eigenlijk wel verantwoordelijk moeten houden om updates uit te brengen. Dat zou een betere oplossing zijn naar mijn gevoel. Maar dan komt ook de zelfde vraag weer terug..... Mag je van een leverancier verwachten dat die software van 10-14 jaar geleden ondersteund? Commercieel is dat eigenlijk weer niet te doen. Aan de andere kant, als klant kun je je software weer upgraden naar ondersteunde versies, welke wel weer door de leverancier ondersteund wordt.
Lastig puntje.....
Het gaat wat ver om van huis uit te gaan dat softwarefouten en kwetsbaarheden op die manier afgestraft worden. Foutloze software maken is onmogelijk, laat staan waterdichte software. En hoe ga je gesloten software auditten dan als je geen toegang hebt tot de broncode? Wordt lastig. Maar repareren hoort een standaard onderdeel te worden van de serviceverlening. Binnen een vastgestelde tijdspanne worden de patches kosteloos geleverd, na een bepaalde periode betaal je voor extra ondersteuning. Inderdaad: zoals het nu gaat met garantiebepalingen.
Zo moeilijk hoeft het toch allemaal niet te zijn?
Voor één op zichzelf staand apparaatje met niet teveel functies zal het nog wel lukken, maar de meeste computersytemen
zijn "door de mens geschapen wondertjes" die net als mensen hun gebreken hebben of kunnen krijgen.
Als je vandaag de dag software oplevert die kwetsbaar is voor bv. SQL-injection of Cross Site Scripting, dan ben je prutser. En geen gewone prutser, maar een enorme prutser! Dit soort fouten en de oplossingen daarvoor zijn al zo lang bekend, dat iedere programmeur zijn ogen uit zijn kop moet schamen als hij/zij dit soort fouten maakt. Het zijn geen vergissingen meer, maar blunders. De programmeur heeft dan op meerdere plaatsen gefaald (in ieder geval gebrekkige input validation en output sanitation).
En ja, het is lastig om de verantwoordelijkheid bij één leverancier te leggen als de fout in de software van een service of library ligt die door een derde is geleverd. Maar toch is dat geen reden om dan maar onveilige software op te leveren. In vind dat leveranciers best wat meer aandacht mogen geven aan de veiligheid van hun software. Ik denk niet dat het haalbaar is om foutloze software te eisen, maar de veiligheid moet veel hoger kunnen dan nu vaak het geval is.
Tenslotte, dat hoeft helemaal niet te leiden tot duurdere code. Sterker, ik verwacht dat de code veelal goedkoper wordt. Immers, voor veilige code moet je eerst denken en dan pas coderen. Door validatie uit te voeren met standaard functies en routines, hoef je maar één keer na te denken en te coderen en die functies dan hergebruiken. Dat is niet zo'n nieuw en origineel idee, want in de jaren 80 van de vorige eeuw was dit de "mode".
Deze posting is gelocked. Reageren is niet meer mogelijk.
Challenge Developer
Wil je werken bij het beste securitybedrijf van Nederland en je coding skills in te zetten voor het ontwikkelen van de latest en greatest security challenges? Solliciteer dan nu naar de functie van Certified Secure Challenge Developer.