Wordt de directie persoonlijk aansprakelijk voor IT-fouten onder de NIS2-richtlijn?

De NIS2-richtlijn lijkt nog ver weg, maar omdat de gevolgen groot kunnen zijn, moeten bedrijven niet te lang wachten met actie. Dat las ik bij Dutch IT Channel.  “Heel belangrijk detail is dat de directie van bedrijven persoonlijk aansprakelijk wordt voor het conformeren aan deze wetgeving”, zo werd uitgelegd tijdens een bijeenkomst van de Dutch Cybersecurity Assembly. Oh wacht even, heb ik iets gemist?

NIS-2 is de tweede versie van de Europese Network and Information Systems-richtlijn, die voor het eerst in 2016 uitkwam. Bij Computable leggen ze uit waar het om gaat:

[De] kern bestaat uit twee elementen: de zorgplicht en de meldplicht. De zorgplicht verplicht organisaties om de hele infrastructuur op orde te brengen. Zo wordt het verplicht om de faciliteiten te hebben om te monitoren wat er gebeurt op het netwerk. De meldplicht wil dat organisaties melding moeten maken wanneer ze te maken krijgen met een cyberincident. Voor alle organisaties die gezien worden als leverancier van ‘essentiële diensten’ is er dus (veel) werk aan de winkel.
En de ophef is groot, want waar de eerste NIS-richtlijn alleen enkele specifieke sectoren betrof, is de reikwijdte nu zo groot dat ook bijvoorbeeld managed hostingbedrijven eronder gaan vallen. Computable noemt een aantal van zesduizend bedrijven dat binnenkort met deze regels te maken krijgt.

Nou is dat niet de eerste keer – ik noem de AVG – maar er lijkt nu extra veel herrie te komen, wat mogelijk komt door die angst voor persoonlijke aansprakelijkheid. Bij de AVG viel dat wel mee, daar kun je als directeur alleen persoonlijk een claim krijgen als je niet-naleving zo ernstig is dat we van wanbestuur kunnen spreken.

Bij de NIS2-richtlijn is er meer. Het governance-artikel (20) bepaalt namelijk in lid 1:

De lidstaten zorgen ervoor dat de bestuursorganen van essentiële en belangrijke entiteiten de door deze entiteiten genomen maatregelen voor het beheer van cyberbeveiligingsrisico’s goedkeuren om te voldoen aan artikel 21, toezien op de uitvoering ervan en aansprakelijk kunnen worden gesteld voor inbreuken door de entiteiten op dat artikel.
Dus bestuursorganen van de entiteiten die onder de richtlijnen vallen, moeten zorgen dat ze toezicht houden op de uitvoering en de wetgever moet zorgen dat ze aansprakelijk gesteld kunnen worden als ze artikel 21 schenden. Artikel 21 is dan het artikel met de algemene beveiligingseisen. Maar wat is een “bestuursorgaan”? De NIS-richtlijn definieert het niet, en het begrip is duidelijk niet bedoeld als het bestuursrechtelijke begrip ‘bestuursorgaan’. Vermoedelijk zocht men een generieke term voor zaken zoals een holding, of de bestuursafdeling.

Maar het gaat verder, in artikel 29 staat letterlijk (lid 6):

De lidstaten zorgen ervoor dat elke natuurlijke persoon die verantwoordelijk is voor of optreedt als wettelijke vertegenwoordiger van een essentiële entiteit op basis van de bevoegdheid om deze te vertegenwoordigen, de bevoegdheid om namens deze entiteit beslissingen te nemen of de bevoegdheid om controle uit te oefenen op deze entiteit, de bevoegdheid heeft om ervoor te zorgen dat deze entiteit deze richtlijn nakomt. De lidstaten zorgen ervoor dat dergelijke natuurlijke personen aansprakelijk kunnen worden gesteld voor het niet nakomen van hun verplichtingen om te zorgen voor de naleving van deze richtlijn.
Kort gezegd: iedere bestuurder van een bedrijf moet wettelijk bevoegd zijn om security-maatregelen te nemen, zodat directeur A dat niet klein kan houden “vanwege de kosten” terwijl directeur B graag breed wil uitpakken. Maar ook zijn deze personen dus zélf aansprakelijk voor het niet-nakomen.

Dat wil natuurlijk niet zeggen dat iedereen ter wereld maar even geld mag komen eisen bij de directeur privé zodra een bedrijf een of andere maatregel niet is nagekomen. De crux zit hem erin dat de beveiligingseis een open norm is: je moet adequaat beveiligen, en pas als je dus écht onder maat bent gebleven, is er mogelijk een aansprakelijkheidsdiscussie te voeren. En dan moet er ook nog eens geldelijk schade geleden zijn die aan die directeur te verwijten is.

Arnoud

 

Mag ik mijn klanten scannen op kwetsbaarheden zoals ProxyShell?

GDJ / Pixabay

Een lezer vroeg me:

Wij zijn een ISP die honderden bedrijven heeft ontsloten. We weten van een kwetsbaarheid in Exchange die we kunnen scannen en detecteren. Mogen wij onze eigen klanten nu hierop scannen, ondanks dat ze geen toestemming hebben gegeven en bij ons geen dienst van softwarebeheer afnemen?
Ik heb al een aantal keer gepubliceerd over scannen op veiligheidslekken, waarbij dan het hele internet wordt gescand. Je zou zeggen dat dat dus ook moet kunnen voor het kleinere deel van internet dat jouw klant is. Zeker als het gaat om actuele lekken zoals (denk ik) de recente ProxyShell lekken.

Toch zou ik het afraden om als internettoegangsprovider of hostingprovider ongevraagd en zonder overleg je klanten te scannen. Je zit namelijk in een iets andere positie dan een partij die internet scant vanuit de motivatie het publiek te willen waarschuwen. Je hebt een contractuele relatie met die klanten, en dat brengt een aantal verantwoordelijkheden met zich mee.

Anders gezegd: je hebt een zorgplicht naar je klanten toe, en dat betekent extra zorgvuldigheid in hoe je met hun systemen omgaat. Ook hoort daarbij dat je vertrouwelijkheid in acht neemt en extra oplet dat je niets stukmaakt.

Tegelijk kan ik me voorstellen dat je juist bij gaten met grote impact expliciet wél wil handelen. Dat kun je vanuit diezelfde zorgplicht juist heel goed rechtvaardigen. En als je als provider kwalificeert als een “aanbieder van een openbare elektronische communicatiedienst” (wat de term ISP impliceert) dan moet je zelfs vanuit de wet (art. 11.2 Telecomwet) zorgen voor een goede beveiliging van je netwerk. Dat is natuurlijk dan afhankelijk van de beveiliging van je klanten, dus meekijken of waarschuwen is dan zelfs met enige goede wil je wettelijke plicht te noemen.

Alleen: voor mij blijft overeind staan dat je dit moet aankondigen, en ik denk zelfs ook laten accorderen. Dat kun je natuurlijk prima automatiseren, denk aan een regeling in je algemene voorwaarden met wat uitleg in de SLA (of op je site, zoals in de FAQ) en een bezwaarmogelijkheid voor klanten die hier niet op zitten te wachten.

Wel zou ik dan eerst de vraag beantwoord willen wat je zou doen met de scanresultaten. Ga je dat gewoon naar het contactadres van de klant mailen? En wat doe je dan als die niet reageert (of hooguit “eh, oké bedankt”) en de kwetsbaarheid blijft bestaan? Je kunt namelijk klanten niet gaan afsluiten als ze een kwetsbaar systeem hebben, tenzij je daar héle duidelijke afspraken over hebt. Of ga je de klant aanbieden het voor ze te repareren? Dat zullen ze niet willen, dan hadden ze wel een supportcontract afgenomen.

Arnoud

Mag een zoekmachine het World-Wide Web scannen op securitykwetsbaarheden?

Een lezer vroeg me:

Ik las dat in augustus tijdens de Defcon-hackerconferentie de zoekmachine Punkspider opnieuw gelanceerd zal worden. Deze zal dan dagelijks miljoenen websites op kwetsbaarheden scannen. De resultaten zijn vervolgens via de zoekmachine te vinden, wat volgens de ontwikkelaars voor een veiliger web moet zorgen. Hoe is dat in vredesnaam legaal, laat staan ethisch verantwoord?
Het voelt inderdaad een tikje raar als je het zo leest: dan kun je dus als crimineel-in-spe even naar die zoekmachine om te kijken welke sites eenvoudig kwetsbaar zijn. Zal ik ook maar de “goedkope voordeurslotenspider” beginnen, keyPunk.darkweb?

Of het legaal is, komt echter neer op de vraag wat Punkspider precies doet met hun doorzoekactie. Het leest als een vorm van portscannen, men toetst op bekende kwetsbaarheden zoals SQL injectie of cross-site scripting.

Zo te lezen publiceert men niet in detail welke kwetsbaarheid gevonden is, alleen grofweg “deze site is kwetsbaar voor gegevensdiefstal vanwege SQL injectie, laat hier niets achter alsjeblieft”. (Ik zag al de categorie “dumpster fire” dus ik hoop dat de boodschap overal in zulke duidelijke taal gecommuniceerd wordt.)

Portscannen en onderzoeken naar kwetsbaarheden is strafbaar wanneer je het doet met de bedoeling (het “oogmerk”, juridisch gezegd) om daarna computervredebreuk te plegen, of om anderen aan te zetten dat te doen. De Punkspider-eigenaren zijn dat zeker niet zelf van plan, zij publiceren immers deze rapporten juist zodat brakke sites de beoel eindelijk eens repareren en er dus géén computervredebreuk gaat plaatsvinden.

Blijft dus over, zetten zij criminelen aan tot misbruik van de gevonden kwetsbaarheden? Dat lijkt me op het eerste gezicht niet het geval. Ik zie dus niet meteen het strafbare aan deze zoekmachine, tenzij blijkt dat men het wel héél eenvoudig maakt om met een gegeven exploit direct een inbraak uit te voeren. Daarvoor moeten we de definitieve publicatie afwachten, maar het lijkt me sterk.

Arnoud

Mag je iemand zijn ontslag laten nemen als je zijn laptop onbeheerd aantreft?

Een lezer vroeg me:

Bij ons (redelijk groot) bedrijf gelden harde securityregels, waaronder de simpele eis je laptop te locken als je er van wegloopt. Als security officer zeg ik dan altijd, als ik een open laptop zie dan stuur ik vanuit jouw mailadres een ontslagmail naar je manager. Maar nu vroeg ik me af hoe bindend dat zou zijn op die persoon?
Een eis dat mensen hun laptop locken is een prima idee, en het is goed om met concrete voorbeelden te illustreren waarom. Het spreekt zeer tot de verbeelding dat iemand dan vanaf jouw mailadres iets raars naar je manager stuurt, dat geeft gedoe waar je géén zin in hebt.

Ik adviseer zelf om krokettenbeleid te voeren (in het Zuiden des lands ook wel vlaaienbeleid): je mailt alle collega’s “Mijn laptop stond open dus ik regel morgen kroketten”. En dat is dan soort van sociaal verplicht dat je dat doet.

Juridisch kun je een werknemer natuurlijk niet verplichten om kroketten (of vlaaien) te gaan kopen. En ik heb al een OR-lid in de mail gehad die dit potentieel pesten/bullying vond van de zwakkere werknemer, die zo legaal te grazen genomen kan worden door collega’s. Je daartegen wapenen vind ik wel een serieuze randvoorwaarde voor je bedrijf.

Deze constructie (je baas mailen “ik neem ontslag”) gaat voor mij nog een stapje verder. Afhankelijk van de werkrelatie, die je niet kent als langslopende security officer, kan het zijn dat deze persoon geloofd wordt (“Ha, eindelijk!”) en dan komen er processen op gang waar het héél lastig weer uit te komen is. Ik zou dit dus dringend afraden.

Formeel-juridisch is het niet bindend want die persoon heeft het niet gezegd, en daar is bewijs van want als goed werknemer ga jij natuurlijk een getuigenverklaring afleggen dat jij die mail hebt gestuurd. Maar je komt er pas achter als het ontslagproces al op gang is, en misschien is er dan al een arbeidsconflict ontstaan waardoor het hoe dan ook doorgezet wordt.

Dus misschien moeten we maar gewoon zeggen, de SO stuurt alleen mails naar de persoon zelf “Volgende keer je laptop afsluiten” of de laptop meenemen en een geel briefje achterlaten. Geen ontslagbrieven sturen, en geen kroketten aankondigen. Dan laat je iemand lopen in plaats van vettigheid eten, is nog beter voor de gezondheid ook.

Arnoud

Mag je corp.com registreren als je weet dat dat een Windows-fout is?

Een lezer vroeg me:

Bij KrebsOnSecurity las ik dat het Corp.com domein te koop gezet gaat worden. Daarmee is toegang te krijgen tot allerlei credentials en nu vroeg ik me af of dat legaal is. Immers je doet niets, andere mensen configureren hun Windows-netwerk slecht. Hoe zit dat in Nederland?

Het domein corp.com gaat inderdaad in de verkoop als ik het goed lees, al lijkt het vooral de bedoeling dat Microsoft het koopt voor een miljoen dollar. Dat zou dan zijn omdat inderdaad veel slecht geconfigureerde Windowsnetwerken verkeer naar dit domein sturen, inclusief authenticatiemiddelen zoals wachtwoorden.

De reden hierachter is dat Windows bij het maken van een intern netwerk standaard de suffix “.corp” voorstelt, wat lang niet iedereen aanpast. Interne diensten zoals gedeelde harde schijven kun je benaderen met iets als \klantdata\ in de Explorer. Echter, ga je vervolgens ergens werken waar je andermans DNS gebruikt, dan maakt Windows van die naam eerst “klantdata.corp” en vervolgens “klantdata.corp.com” omdat .corp niet bestaat bij die ander. En dan stuurt je systeem dus inderdaad logins en dergelijke naar die website.

Op zich gebeurt dit vaker. Bedrijven die een oude domeinnaam hebben overgenomen, of blijken te hebben geregistreerd, ontvangen regelmatig mails voor de oude eigenaar bijvoorbeeld. Dat is vervelend, maar in de praktijk gooi je die mail dan weg en dan is het klaar.

Hier voelt het iets anders, omdat de bedoeling van deze domeinnaam hebben nu duidelijk lijkt te zijn dat je die logins wilt hebben. Het is moeilijk daar een legitiem doel aan te koppelen. Natuurlijk is er vast een marketingblablaverhaal te verzinnen dat je corporate dienstverlening wilt verrichten en dat corp.com dan perfect aansluit bij je merkwaardebeleving, maar om eerlijk te zijn geloof ik daar dan geen bal van.

In Nederland is het strafbaar (art. 139d Strafrecht) om wachtwoorden of dergelijke authenticatiemiddelen te verwerven, in te voeren, beschikbaar te stellen of voorhanden te hebben. Althans, als je doel daarmee is om het misdrijf computervredebreuk, denial of service of aftappen van vertrouwelijke informatie te plegen. Een wetenschapper die wil onderzoeken hoe groot dit probleem is, kan dus prima monitoren wat hier gebeurt. Een security-onderzoeker die al die bedrijven wil waarschuwen handelt ook legaal. Maar voor het overige zie ik niet hoe je iets kunt doen met die informatie.

Arnoud

Heb je nou voor pentesten óók al een verwerkersovereenkomst nodig?

Wie penetration testing oftewel securityonderzoek naar binnendringmogelijkheden uitvoert, moet een verwerkersovereenkomst sluiten met zijn opdrachtgever. Dat maak ik op uit een recente Linkedinblog die me attendeerde op een uitspraak van de Saksische Autoriteit Persoonsgegevens van die strekking. Wat natuurlijk enige onrust gaf bij professionele pentesters, want je hébt al zo’n papierwinkel voordatje aan de slag kan en moet er dan ook nog een verwerkersovereenkomst bij voor het geval je persoonsgegevens tegenkomt? Nou ja, formeel wel maar er zijn trucjes.

Bij een pentest ga je bij een klant aan de slag om zwakheden in zijn systeem te vinden. Je probeert binnen te dringen, zeg maar wat je anders computervredebreuk zou noemen. Vandaar die papierwinkel: je wilt dat je klant een pentest waiver of toestemmingsverklaring tekent waarin duidelijk vaststaat dat je niets tegen zijn wil doet, en dus niets dat wederrechtelijk en daarmee strafbaar kan worden.

Dat is voor klanten dan weer spannend, want wat als je nu iets stukmaakt tijdens dat onderzoek of verder kwam dan ingeschat en daar raak je iets dat echt niet de bedoeling was? Dat geeft dus de nodige onderhandeling vaak.

Sinds de AVG is daar een extra risico bij gekomen. Het is natuurlijk mogelijk dat je bij je security-onderzoek persoonsgegevens tegenkomt, denk aan een database met klantgegevens waar je bij kunt. Als je die database dan vervolgens downloadt (“het zal toch niet waar zijn”) dan ben je persoonsgegevens aan het verwerken, in het AVG-jargon.

En dat is dan even lastig, want hoezo mág jij dat van de AVG? Als zelfstandig ingehuurd onderzoeker heb je daar geen grondslag voor, je hebt geen toestemming van de betrokken klanten en je hebt ook geen contract met ze. Vandaar het advies: werk als verwerker, als hulpje van je opdrachtgever. Dan is wat je doet met die gegevens zijn probleem (althans; waarom dat mág dat onderzoek). Alleen zit je dan met de tegenpool dat je niet meer mag doen met die gegevens dan hij je toestaat.

Nu zou dat in de praktijk wel mee moeten vallen, want wat je gaat doen is normaliter niet meer dan een kopie maken, vastleggen wat je gevonden hebt en dan vernietigen (of teruggeven). En dat is precies wat een verwerker ook zou doen.

Het wordt alleen op formele gronden ingewikkeld: oh jee we hebben een verwerker jongens, dus hier is de standaard verwerkersovereenkomst die de boekhouder ook moet tekenen. En daarin staan dan vele dingen zoals een passend securitybeleid (met auditclausule, dus de klant komt bij jou, securityonderzoeker, kijken of je wel veilig bent – de meest hilarische case die ik had was dat de verwerker verklaarde periodiek pentests op zichzelf uit te voeren), medewerking aan inzage- en verwijderverzoeken en ga zo maar door dat echt zwaar over de top is voor zo’n onderzoek. Zeker omdat het ook nog eens aan onbeperkte aansprakelijkheid gekoppeld is.

Wat mij betreft mag je dát dus afwijzen. Je kunt in je pentest waiver of AV volstaan met een verklaring dat je verwerker bent, dat je de AVG zult naleven en dat je alle kopieën van data na logging van de gebeurtenis zult wissen, behalve eventuele kopieën die nodig zijn voor de gewenste rapportage.

Arnoud

Moet ik bezoekers ons securitybeleid onthullen van de AVG?

Een lezer vroeg me:

Een bezoeker van ons bedrijf heeft via het gastennetwerk internet gebruikt. Nu krijg ik van hem een verzoek onder de AVG om precies te vertellen wat wij van hem hebben gelogd. We melden inderdaad bij het aanmelden “This network is monitored for security purposes” maar in welk detail moet ik hem dat vertellen? Ik wil geen security-gevoelige details onthullen.

Het monitoren (inclusief loggen) van internetgebruik van gasten is inderdaad iets waar de AVG wat van zegt. Het mag, want we noemen dit een eigen legitiem belang. En zolang je monitoring maar proportioneel is, oftewel dat je niet nodeloos diep zit te spitten in wat mensen op internet uitspoken via jouw verbinding, is er weinig aan de hand.

(Natuurlijk gebruik je die logs alleen voor security doeleinden en niet bijvoorbeeld om te kijken wat hij bij de concurrent aan offertes heeft uitstaan.)

De AVG kent wel diverse informatieplichten, met als doel dat mensen weten wat je over ze verzamelt en met welk doel je die gebruikt. Daar moet dus iets meer informatie komen dan enkel “we monitor for security purposes”. Wat monitor je, en voor welke precieze doeleinden dan? Enkel IP-adressen, ook tijd van gebruik, applicaties en poorten, ga zo maar door? Wat is ‘security’, bedoel je dat je verkeer analyseert op verdacht gedrag, dat je IP-adressen van bezochte sites registreert of dat je een AI loslaat om een profiel van je bezoeker te maken?

Dit moet in je privacy policy staan die je publiceert bij het aanmeldscherm. En dat moet je in eenvoudige taal doen, dus concreet en met bewoordingen die je bezoekers begrijpen. Dat betekent dus dat je inderdaad ongeveer moet uitleggen wat je ingezet hebt aan monitoring tools en wanneer je ingrijpt of naar wie een alert gaat en wat die dan gaat doen.

Het mag natuurlijk in zoverre een tikje in het midden blijven dat je niet de precieze criteria benoemt: “verdacht gedrag zoals verspreiding van bekende virussen” zou genoeg zijn, wat mij betreft. Maar je kunt je niet verschuilen achter enkel de vage frase dat securitydoeleinden in het geding zijn.

Arnoud

Hoe snel moet je van de wet een nieuwe securitystandaard implementeren?

norm-security-beveiliging-certified-gecertificeerdEen lezer vroeg me:

In de ICT zijn de beveiligingseisen volop in beweging. Het is dus welhaast onmogelijk om deze allemaal stipt na te volgen, zeker bij grote pakketten waar het doorvoeren van wijzigingen vele maanden (zo niet jaren) kan kosten vanwege complexiteit en testen en evaluatie. Is er juridisch gezien een termijn waarbinnen nieuwe standaarden geïmplementeerd moeten zijn?

Dit is een persoonlijke frustratie van mij, maar de wet kent eigenlijk überhaupt geen eis dat je enige security-standaard moet volgen, of zelfs maar dat je product enige security moet hebben. Fysieke veiligheid wel (productveiligheid, art. 6:186 BW) maar je informatiebeveiliging mag volstrekt brak zijn. Ik weet niet waarom.

De enige echte uitzondering is die van systemen die persoonsgegevens verwerken. Daar bepaalt de Wet bescherming persoonsgegevens (art. 13 Wbp) dat je “passende technische en organisatorische maatregelen” moet nemen “om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking.”

De in 2013 geformuleerde beleidsregels Beveiliging van persoonsgegevens van de Autoriteit Persoonsgegevens adviseren te handelen binnen een plan­do­check­act­cyclus: beoordeel de risico’s, gebruik erkende beveiligingsstandaarden en controleer en evalueer de resultaten. Er wordt wel naar standaarden verwezen, maar dat laat meteen zien waarom dat niet werkt: het document is uit februari 2013 en de daarin genoemde norm ISO 27002:2007 werd in oktober 2013 ingetrokken.

Uiteindelijk zal het altijd neerkomen op een evaluatie achteraf als het mis blijkt te zijn gegaan. Had dit redelijkerwijs voorkomen kunnen worden met wat voorhanden was, was het redelijkerwijs te verwachten dat deze standaard gevolgd zou worden en hadden we al redelijkerwijs mogen verwachten dat er zou worden geupgrade of was dat gezien de kosten nog niet redelijk? (Met excuses aan de vraagsteller die me nadrukkelijk vroeg de term ‘redelijk’ te vermijden maar dat is ben ik bang een MUST in de zin van RFC 2119.)

Arnoud

De brakke spullen uit het Internet der Dingen

webcam-camera-babyDe kwetsbaarheid van “Internet of Things”-dingen is zo gigantisch dat je er maar beter om kunt lachen, las ik bij Ars Technica. Maar eigenlijk is het om te huilen. Men ontdekte dat de IoT-zoekmachine Shodan een zoeksectie had voor kwetsbare webcams, met feeds van van alles en nog wat: voortuinen, achtertuinen, binnentuinen, marijuana-plantages, kinderslaapkamers en ga zo maar door. Hoe kan dat anno 2016 nog zo makkelijk bestaan?

Op brakke beveiliging is niet strafbaar, schreef ik in 2013. Tegenwoordig soms wel: als je persoonsgegevens niet adequaat beveiligt, kun je een boete van maximaal €820.000 opgelegd krijgen. (Bovendien moet je het melden, een aparte nieuwe verplichting). Maar dat gaat over bedrijven die persoonlijke gegevens beheren, niet over bedrijven die apparatuur op de markt brengen. Ik zou niet weten op grond van welk wetsartikel de leverancier van een IP-enabled webcam met fabriekswachtwoord 12345 te beboeten is.

Volgens Ars Technica is de reden hiervoor heel simpel: geld.

Consumers do not perceive value in security and privacy. As a rule, many have not shown a willingness to pay for such things. As a result, webcam manufacturers slash costs to maximize their profit, often on narrow margins. Many webcams now sell for as little as £15 or $20. “The consumers are saying ‘we’re not supposed to know anything about this stuff [cybersecurity],” he said. “The vendors don’t want to lift a finger to help users because it costs them money.”

Ik denk dat het iets subtieler ligt. Mensen geven wel om veiligheid en privacy, maar gaan er vanuit dat een apparaat in een mooi doosje op de plank bij een bekende winkel gewoon veilig is. Auto’s zitten ook netjes op slot, je brood is vers en als een blik tomatensoep ontploft in de koelkast dan verdient dat aandacht in RTL Nieuws om half acht. Dat model van vertrouwen nemen mensen gewoon mee naar digitale apparatuur, ook als die internet-enabled is. Handig joh, dat je op je smartphone de webcam thuis kunt bekijken. Maar het idee dat iedereen dan mee kan kijken omdat hij op een algemeen bekende poort draait en het standaardwachtwoord in de op internet staande handleiding te vinden is, dat speelt niet bij brood of tomatensoep. Dus ook niet bij die webcam.

En nee, het is te makkelijk om dan te zeggen “dan moeten die mensen maar beter nadenken en lezen wat er in de handleiding staat”. Want dat doen mensen niet, en ik vind het ondertussen ook steeds oneerlijker worden om te verwachten dat ze dat wel gaan doen. Ik hoef ook geen handleiding van mijn voordeurslot te lezen – daar staat politiekeurmerk 2 sterren op en de installateur had een keurige blauwe overall aan, dus dat zit wel goed met dat voordeurslot.

Deze bal hoort te liggen bij de leveranciers van deze producten. In Amerika lijkt dat al een beetje door te dringen: Ars Technica citeert een FTC-woordvoerder die zegt “If you don’t have reasonable security then that could be a violation of the FTC Act.” Bij ons vind ik het moeilijk een dergelijke kapstok te verzinnen. Om dit nu onder de conformiteitseis (wettelijke garantie) te schuiven gaat een beetje ver, dat criterium is daar volgens mij niet voor bedoeld.

Ik denk dus dat er echt een wetswijziging voor nodig is om een stok te introduceren om IoT-dingen-produceren te dwingen de veiligheid van hun producten te vergroten. Maar dat gaat een moeizaam proces worden, want het klinkt zo redelijk, dat mensen toch zelf even een handleiding kunnen lezen en een wachtwoord kunnen wijzigen. Maar eh, wees eens eerlijk: wie doet dat bij alle producten in zijn huis?

Arnoud

Waarom wordt mijn embedded Android niet geupdate?

android-open-source.pngEen lezer vroeg me:

Steeds meer apparatuur bevat Android als operating system, en daarvan is bekend dat er van tijd tot tijd gaten in worden ontdekt. Maar die software wordt eigenlijk nooit geupdate. Is dat niet tegen de wet? Hoe kan ik afdwingen dat deze software bijgewerkt wordt?

De wet zegt niets over security of het bijwerken van software. Een gemiste kans bij de wetsupdate van 2014, wat mij betreft. Je moet dus terugvallen op algemene regels en daaruit proberen te beredeneren dat het anno 2015 impliceert dat embedded software moet worden geupdate.

Een hoofdregel uit de wet is dat een product moet voldoen aan de redelijkerwijs gewekte verwachtingen (art. 7:17 BW). Als dat niet zo is, moet de winkelier dat herstellen of een vervangend product verschaffen. Wil je het hiermee rondkrijgen, dan moet je dus aantonen dat je redelijkerwijs mag verwachten dat een product veilig is en/of dat ontdekte gaten

Dat een product veilig is, is helaas nog steeds geen gebruikelijke situatie. (Ik erger me daar al tijden aan.) Bovendien worden gaten ook tijdens de levensduur van het product ontdekt, dus is het denk ik ook niet realistisch te verwachten dat producten binnenkort veilig worden en blijven. Updaten is de enige manier om daaraan tegemoet te komen.

Zijn updates an sich dan een redelijke verwachting? Nou, bij Android wel. Iedereen weet dat Android regelmatig met security- en andere updates komt, dus je mag verwachten dat dat ook bij jouw apparaat gaat gebeuren als gemeld is dat er Android in zit. Die verwachting komt dan mee.

De per 1 januari in werking tredende meldplicht datalekken + beveiligingsplicht gaat daar niets aan veranderen. Die geldt namelijk voor zakelijke partijen die persoonsgegevens van anderen opslaan. Een consument met een Androidapparaat voldoet niet aan die omschrijving en heeft dus niets te maken met die wet. Ook niet als door een gat in zijn OS zijn telefoonboek of ander bestand met persoonsgegevens lekt.

Een praktisch punt is nog wel, kúnnen die apparaten wel eenvoudig geupdate worden? Bij een telefoon lukt dat nog wel, maar bij een simpele dvd-speler zonder netwerkmogelijkheid is dat al wat ingewikkelder. Eisen dat je de firmware moet kunnen flashen is denk ik niet redelijk. Bovendien, als het apparaat geen netwerkmogelijkheid heeft, hoe wordt het dan gehackt van buitenaf?

Arnoud