Column: Softwaremakers verantwoordelijk houden voor lekken: Veiligheid gegarandeerd?
De prestigieuze Amerikaanse National Academy of Sciences publiceerde
recent een opzienbarend nieuw rapport, genaamd ``Cybersecurity Today and
Tomorrow: Pay Now or Pay Later''. Hierin wordt aanbevolen dat
beleidsmakers softwarebedrijven in hogere mate aansprakelijk zullen
stellen voor schade veroorzaakt door `gaten' in de software. Tevens werd
geroepen om wetten die softwaremakers zou verplichten dergelijke
onvolkomenheden te melden. Wat is het grote verschil met de huidige
situatie? Als er op dit moment computerfraude wordt gepleegd, dan wordt
de overtreder berecht. In de toekomst zou ook de leverancier van de
software voor de rechter moeten verschijnen. Bill Gates, Chairman van
Microsoft, stuurde onlangs een email naar medewerkers van het bedrijf,
waarin werd verklaard dat veiligheid voortaan de `hoogste prioriteit'
moest krijgen. ``Software dient zo veilig te zijn dat onze klanten zich
hier niet over hoeven te bekommeren.'' De gedachte hierachter is dat de
angst voor rechtszaken ontwikkelaars zal dwingen waterdichte producten
te leveren.
De wetenschappers van de Amerikaanse National Academy of Sciences
vergeten echter dat een programma niet oneindig vaak getest kan worden
voordat het op de markt wordt gebracht. De wetten van de IT-markt, met
zijn korte `time to market' en moordende concurrentie, maken het
ondenkbaar dat softwarehuizen al te lang zullen blijven testen. En zelfs
als een product 100% waterdicht is, bestaat er geen enkele garantie dat
de gebruiker bepaalde veiligheidsvoorschriften niet zal overtreden.
De verantwoordelijkheid voor het verhinderen van lekken en het tegengaan
van informatiemisbruik ligt bij de de eindgebruiker, dat wil zeggen het
bedrijf dat een bepaald softwarepakket inzet. Want mócht er toch iets
gebeuren met een `100% veilig' pakket, dan kan de ontwikkelaar wel
worden bestraft, het kwaad is echter al geschied...
Ben G. Laarhoven
CONSUL risk management
Overigens is het essentieel dat software goed geschreven worden, immers als de basis functionaliteit van een applicatie al telkens vastloopt, dan zal dit in een moorderdende competitie omgeving ook zo zijn gevolgen hebben.
Dat ging op zich best aardig. De gebruiker had de mogelijkheid om de consumentengids te lezen en zelf een afweging te maken tussen prijs en kwaliteit.
Met software en anti-virus is dat blijkbaar lastiger. Ik ken maar weinig geslaagde uitingen van consumentenorganisaties die gebruikers wijzen op problemen met software. Oftewel: waarom doet de Consumentenbond hier niet its mee?
Resultaat is in ieder geval wel dat op dit vlak niemand zich inzet voor de belangen van de gebruikers. Om dan de aansprakelijkheid enkel en alleen bij de gebruikers neer te leggen, lijkt me een utopie. Het zou zoiets zijn dat alle bestuurders van auto's volleerde monteurs zouden moeten zijn.
Ik begrijp het standpunt van van Laarhoven wel: als ontwikkelaar en aanbieder van programmatuur is zijn standpunt logisch, maar weinig constructief.
Wat mij een goed uitgangspunt lijkt is toch de combinatie van de gedeelde aansprakelijkheid. Ik trek hierbij even de vergelijking met de kwaliteit van de magnetron:
- producent test de magnetron, verkrijgt keurmerk (bv Kema) en stelt een goede gebruikershandleiding op (aardewerk wel, plastic niet, etc).
- consumentenbond test en vergelijkt werking van het apparaat en duidelijkheid van de handleiding.
- gebruiker gebruikt de magnetron, waarvoor deze is bedoeld (leest de handleiding en stopt geen natte hond in het apparaat om deze te drogen)
Waarom zouden we het anders nastreven als het om software gaat?
Bedrijven hoeven niet al te lang te testen. Ze moeten veiliger programmeren! Door 2 jaar te testen wordt geen enkel product veiliger. (Keyword == doen!) Je zult bij een (programmeer-)project uiteraard van het begin af aan beveiliging erin moeten betrekken. Wat ik maar al te vaak tegenkom is een product waarbij aan het einde wordt gedacht aan beveiliging. Vervolgens wordt er een beveiligingssauje overheen gegoten. (Niet te veel, de release datum staat al vast!)
100% veilig is een utopie en hoeft ook niet nagestreeft te worden. Het is uiteraard wel een gemakkelijke dooddoener om je verantwoordelijkheid af te schuiven.
<quote>De verantwoordelijkheid voor het verhinderen van lekken en het tegengaan van informatiemisbruik ligt bij de de eindgebruiker</quote>
De overgrote meerderheid van de (eind)gebruikers kan de gebruikte software niet onderzoeken (incompetent of onmogelijk).
<quote>het kwaad is echter al geschied... </quote> De software is al klaar(?) en uitgebracht. Dat is het grote kwaad.
Waarom gaat iedereen er automatisch vanuit dat het verantwoordelijk stellen van de vendor voor problemen betekent dat "alles veiliger wordt"? Doofpot-affaires anyone? Tuurlijk worden er veel bugs door mensen die niets met de betreffende vendors te maken hebben gevonden, maar de laatste tijd zijn zowel een zooi vendors alswel een heleboel "bugtrackende" bedrijven zowiezo al bezig met het aanpassen van hun publicatie policies. Stel nou dat M$ iets als rds zelf tegenkomt? Wat nou full disclosure? Als je hun track-record hebt zou ik best wel eens een afweging willen maken in zo'n geval..
Thejian
Stel nou dat M$ iets als rds zelf tegenkomt? Wat nou full disclosure?
Wat bedoel je met "rds", of wat betekend dat?
b.v.d. hzlz
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
