Overheid publiceert wetsvoorstel meldplicht datalekken

Het ministerie van Economische Zaken heeft een wetsvoorstel gepubliceerd over een meldplicht voor datalekken. Volgens het voorstel moeten partijen die persoonsgegevens verliezen dit verplicht melden bij het CBP en de getroffenen.

Het voorstel is gepubliceerd op Internetconsultatie.nl. Inspraak is mogelijk tot en met eind februari. De voorgestelde wetgeving stelt dat iedere partij die persoonsgegevens verwerkt en deze verliest, bijvoorbeeld door een hack, dit direct aan het College Bescherming Persoonsgegevens moet melden. In de melding moet het lek beschreven worden evenals de maatregelen die genomen zijn om de gevolgen te beperken. Ook moeten alle getroffenen ingelicht worden over de hack, behalve als de gelekte data versleuteld is.

Het CBP kan een boete van maximaal 200.000 euro opleggen als een organisatie nalaat een melding te maken en dus de meldplicht ontduikt. Dit relatief hoge bedrag moet volgens de opstellers van de meldplicht duidelijk maken dat transparantie bij een datalek een noodzaak is, evenals het voldoende beveiligen van systemen.

Bits of Freedom, die lange tijd heeft geijverd voor een meldplicht bij datalekken, is in grote lijnen tevreden met het wetsvoorstel. Wel stelt de organisatie enkele verbeteringen voor; zo zouden diverse criteria aangescherpt moeten worden omdat deze te vaag of subjectief zouden zijn. Ook zou een datalek niet alleen op de website van een getroffen partij gemeld moeten worden. Bits of Freedom pleit verder voor het openbaar maken van alle meldingen bij het CBP.

Reacties (28)

[Xorifelse]

Goed initiatief, alleen die boete is precies het gene wat het is. Intimidatie.
Hoe ga je bewijzen welke data er is gestolen tot op het moment dat het publiek word gemaakt door de hacker?

Daar boven op, hoe gaat de overheid bewijzen dat het jouw data is, inval doen op jouw servers?

[Verwijderd]

ik had liever een wet gezien die op een bepaalde hoogte de aannemer aansprakelijk stelde op een zekere hoogte. het is niet de overheid die de fout maakt, maar wel de overheid de te weinig geld neerlegt om jouw gegevens moest beschermen (de baas vroeg om een werkende site, niet een veilige site). als de wet een developer aansprakelijk stelt voor simpele knullige fouten, dan denk je 10x na voor je JA tegen een bedrijf zeg die vroeg "kan je me helpen, je bent het voordeligst dus kan je een site maken waar ook persoons gegevens aan verbonden zitten"

als je de vermeende schuldige als gaat vragen om te bewijzen dat hun gelekte data WEL jouw data is zijn ver heen.......

preventie werkt misschien wat beter dan aantonen dat de gelekte gegevens mogelijk jouw gegevens waren of andersom..... want als je zo kijkt wie de dader is van de afkomstige data is het einde ver zoek. je gegevens hebben een grote waarschijnlijkheid al op straat te liggen puur omdat er al zoveel servers gehackt zijn in zo een lange tijd dat het niet veel moeite kost alles aan elkaar te linken en meer te weten dan de bedrijven die de gegevens vragen.

waarom bewijzen dat een bedrijf haar data gestolen is en mogelijk ook jouw persoons gegevens waren als je de gene aansprakelijk kan stellen die de klus aan nam alles online te publiceren? die moest weten wat er veilig was en niet. en natuurlijk snap ik dat je niet tegen alle hacks kan dekken. maar VAAK is het wel zo dat die alledaagse hacks gewoon alsmede nog werken omdat de developers op zo een lage prijs niet zouden weten wat er rond gaat na 10 jaar bekendheid.

"Het CBP kan een boete van maximaal 200.000 euro opleggen als een organisatie nalaat een melding te maken en dus de meldplicht ontduikt."... echt een losse letter uit de wet.. straffen voor het niet melden garandeert niet de veiligheid dat het kan gebeuren....
dus gewoon goedkope mensen inhuren, niet luisteren naar ze adviseren (als dat al gedaan word, want daar heb ik ook nog wel commentaar op) en later zeggen "wij wisten er niets van omdat we er geen verstand van hebben". wat heeft dat dan nog voor nut?

ik stel voor een om een veiligheids commissie op te starten met een minimale basis kennis om te testen op de meest debiele simpele basis hacks te testen... dan is kjiken hoeveel minder hack reports er komen...

het gaat om JOUW gegevens! strafbaar stellen van inbraak voorkomt nog geen inbraak!

[Reactie gewijzigd door Verwijderd op 29 juli 2024 08:49]

[Nibble]

In eerste instantie zou dat aannemelijk zijn, maar stel dat je iets ontwikkeld op een platform versie X. Dat is veilig getest en werkend, vervolgens wordt dit geinstalleerd op de servers van de klant die veilig zijn(?). Er gaat tijd overeen en servers worden gepatched, software geupgrade en nieuwe lekken ontdekt waardoor platform versie X helemaal niet zo veilig bleek achteraf, maar jij hebt inmiddels alweer een andere klant en het spul overgedragen. Dan zou je met die constructie nog steeds aansprakelijk zijn. Ik denk dat de verantwoordelijkheid juist moet liggen bij de klant, het is zijn systeem en uiteindelijk is hij verantwoordelijk wat hij ermee doet. Een autofabriekant is ook niet aansprakelijk als jij met zijn auto iemand anders doodrijd, het zou eruit ziet....

Los daarvan denk ik niet dat het een kwestie is van geld in deze. Overheids projecten kosten miljoenen zo niet miljarden. Het probleem is gebrek aan kennis bij deze organisaties. Mede daarom is alles zo duur, men laat zich alles op de mouw spelden.
Tel daarbij de enorme wirwar van regels, procedures en met de dag veranderende voorwaarden, wetten en regels op en het is niet zo heel verwonderlijk dat temidden van dit alles er lekken ontstaan omdat er geen focus gegeven kan worden op de kern van een systeem door alle larie die eromheen hangt.

De kern zit hem in decentralisatie van alles, er is geen coordinerend geheel, losse gekoppelde systemen van een ieder op zijn eigen stoeptegel. Heen en weer gegooi van informatie en mensen die te trots zijn om interfaces af te stemmen om een coherent geheel te maken en politieke belangen zijn mijn inziens de oorzaak hiervan. Dit is niet alleen bij de overheid zo, ik heb bij veel bedrijven gewerkt en veel organisaties gezien en overal is dit het probleem in dergelijke gevallen.

Die boete zorgt er in elk geval voor dat zaken niet meer onder de pet gehouden worden en mensen zelf actie kunnen ondernemen (persoonlijk vind ik het wel prettig dat ik het direct weet als mijn creditcards gelekt zijn in plaats van dat ik dat via bankafschriften moet merken). Er kan nooit een goede reden zijn om informatie achter te houden die mensen nodig hebben om zichzelf te kunnen beschermen, echter zijn de politieke belangen hierbij aantrekkelijk en daarom moet een boete extra gewicht in de schaal brengen om de balans voor de eindgebruiker gunstig te laten uitslaan.

[Ghost Dog]

Ik denk dat de verantwoordelijkheid juist moet liggen bij de klant, het is zijn systeem en uiteindelijk is hij verantwoordelijk wat hij ermee doet. Een autofabriekant is ook niet aansprakelijk als jij met zijn auto iemand anders doodrijd

Zoals vaker met vergelijkingen tussen digitale en tastbare producten is deze in mijn ogen niet passend.

Als ik een auto heb die technisch gewoon werkt heeft de fabrikant zijn werk goed gedaan. De auto doet dan waar hij voor gemaakt is: rijden.
Als ik met die auto dan een ongeluk veroorzaak door een niet-technische reden is dat volledig mijn schuld, en heeft de fabrikant daar niets mee te maken.

Als ik een website laat maken die belangrijke gegevens moet hosten maar dit niet veilig doet en dus vatbaar is voor datalekken, is dat de schuld van de maker. De site doet dan namelijk niet waar ik hem voor heb laten maken, namelijk veilig gegevens hosten.
In dat geval is een 'ongeluk' (een lek) met de site dus de schuld van de bouwer, niet van de gebruiker.

Als we het voorbeeld van de auto erbij pakken is een datalek in een site analoog aan een auto met een productiefout. Dat is de schuld van de fabrikant, niet van de klant.

[Wortelsoep]

Wat een onzin. Natuurlijk gaat er wel een preventieve werking uit van een dreiging met een boete. Jouw voorstel van een veiligheidscommissie is absoluut niet haalbaar. Ten eerste: wat gaat die commissie dan allemaal controleren? En ten tweede: wie gaat dat in hemelsnaam betalen?

[Verwijderd]

Geweldig zo'n nieuwe wet, maar ik zie het als mosterd na de maaltijd. Ik denkt dat het beter is om richtlijnen op te stellen waaraan een website moet voldoen voordat het fout gaat.

De meeste bedrijven geven (haast) niets om de beveiliging van persoonsgegevens. Snel en met veel winst verkopen is hun eerste streven en pas al het fout gaat wordt er misschien actie ondernomen op de beveiliging.

Het OS waar de server op draait wordt even snel geinstalleerd met de standaard, maar onveilige settings. Dan wordt er nog een knulletje van begin 20 ingehuurd om de website te maken (m.b.v een gratis CMS) die vaak barst van de beveiligingsfouten. Het mag allemaal niets meer kosten tegenwoordig en het moet binnen twee dagen online staan.

Kleine webwinkels maken voornamelijk gebruik van shared hosting oplossingen (vaak met Plesk of dergelijke erop geinstalleerd). Bij dit soort configuraties is het vaak kinderlijk eenvoudig om de database van je buurman te plunderen.


Motto van dit verhaal: Voorkomen is beter dan genezen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:03]

[The Zep Man]

Ook moeten alle getroffenen ingelicht worden over de hack, behalve als de gelekte data versleuteld is.

Gevaarlijke uitzondering. Immers is iets al gecodeerd als het bijvoorbeeld achterstevoren is geschreven.

[phosporus]

Had precies dezelfde gedachte. Zet md5 encryptie op je gegevens en je hoeft het vervolgens niet meer te melden terwijl dat natuurlijk dikke onzin is.

[Gomez12]

"Dikke onzin"?

Sowieso is md5 geen encryptie en daarnaast ben ik wel eens benieuwd waarom het "dikke onzin" zou zijn?

Het is niet de beste beveiliging (zwak uitgedrukt) maar het is ook niet alsof je binnen 5 minuten 100.000 entries gegarandeerd goed gekraakt hebt. Je hebt hooguit 100.000 mogelijke entries.

[Chip.]

Hoezo is geen md5 geen encryptie? Is het poep dan ofzo?

[Verwijderd]

Het is een cryptografische hashing. Encryptie is het versleutelen van gegevens, versleutelen impliceert dat het ook weer ontsleuteld kan worden, en dat kan bij MD5 (althans dat is de bedoeling) niet.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 08:49]

[.oisyn]

(althans dat is de bedoeling)

Het is niet "de bedoeling", het is per definitie onmogelijk om een hash om te keren. Er zijn (in het geval van MD5) namelijk slechts 2¹²⁸ verschillende uitkomsten, terwijl er feitelijk een oneindig aantal inputs zijn. Het enige wat je kunt doen is zoeken naar een input die dezelfde hash geeft, maar je zult nooit weten of dat de originele input was. Sterker nog, MD5 is dermate compromized dat het vrij makkelijk is om 2 verschillende datareeksen te maken die dezelfde hash genereren, of om een datareeks zo aan te passen dat de hash hetzelfde blijft, en daarom is het niet meer geschikt om data mee te ondertekenen.

In het geval van wachtwoorden boeit het feit dat je de originele input niet terug kan vinden natuurlijk niet zo heel veel, als je iets vindt dat dezelfde hash heeft dan is dat afdoende om in te kunnen loggen. Daarnaast is het probleem van wachtwoorden dat de input space veel te klein is - het typische aantal tekens dat men gebruikt voor een wachtwoord is niet voldoende om de hele 128 bit output space af te dekken, dus als je een collision vindt dan is dat meestal ook daadwerkelijk de input geweest. De reden dat MD5 niet meer geschikt is voor wachtwoorden is omdat een hash veel te snel berekend kan worden, waardoor brute forcing interessant wordt.

[Reactie gewijzigd door .oisyn op 29 juli 2024 08:49]

[Verwijderd]

Ben het met je eens. Standaard MD5 hashing is zeer vatbaar voor rainbow tables. Tegenwoordig moet er volgens een aantal experts al gebruik gemaakt worden van SHA1 hashing.

Zelf vindt ik dat op het randje en daarom gebruik ik zelf sha128 en sha256 voor het hashen van gegevens.

Maar het is beter om AES256 encryption met een tweevoudige seed te gebruiken.

[Verwijderd]

Sowiezo, bedrijven luisteren soms niet naar je als je lekken meld. Daarna dreigen ze met rechtzaken etc... Ik weet niet of dit een goed voorstel is, het heeft wel wat lekken.

[watercoolertje]

het heeft wel wat lekken.

Haha en jij voelde je verplicht om dat te melden, anders kreeg je een boete tot 200k

[Soldaatje]

6. De kennisgeving aan de betrokkene is niet vereist indien de verantwoordelijke naar het
oordeel van het College gepaste technische beschermingsmaatregelen heeft genomen waardoor de
persoonsgegevens die het betreft versleuteld zijn of anderszins onbegrijpelijk zijn gemaakt voor
eenieder die geen recht heeft op kennisname van de gegevens.

Als je codering gekraakt kan worden zal je het toch moeten melden lijkt me.
En dat is naar het oordeel van het CBP.
Je kan dus beter niet het risico lopen en het gewoon melden of gewoon geen zwakke codering gebruiken natuurlijk.

[Gomez12]

[...]
Als je codering gekraakt kan worden zal je het toch moeten melden lijkt me.

Elke codering kan gekraakt worden. Het is enkel een kwestie van tijd, dus moet je alles maar melden?

[.oisyn]

Gevaarlijke uitzondering. Immers is iets al gecodeerd als het bijvoorbeeld achterstevoren is geschreven.

Het probleem is dat er nu gewoonweg vaak niet over wordt nagedacht. Natuurlijk kun je het ook achterstevoren opslaan om onder de regel uit te komen, maar als je die moeite al doet waarom zou je het dan niet meteen goed encrypten? Het zijn geen stel kinderen die de regels proberen te ontwijken, het is gewoon een essentiele mindset die momenteel mist bij veel bedrijven/developers.

[Reactie gewijzigd door .oisyn op 29 juli 2024 08:49]

[FiRePaTH]

Hoe zit dit met de zgn "white hat hackers" die deze lekken als "hobby" opsporen?

Worden hun volledige namen ook gepubliceerd als zijne "vinder" van het probleem?

Zou geen slechte zaak zijn, want dan weet je meteen welke mensen zich onder de "white hat hackers" scharen en wie zich met deze zaken bezig houden.

[thegve]

Dit gaat om de gegevens in de database, niet om de gegevens van de hackers.

[Gomez12]

Lever eerst maar bewijs af dat iemand een white hat hacker is.

Over het algemeen is er enkel bekend dat er gekraakt is en dat de "white/grey/black" hat hacker de gegevens heeft. Er is veelal niets bekend over wat hij met die gegevens gedaan heeft.

[Verwijderd]

Als je als whitehat je naam laat vermelden, dan is de kans groot dat je een rechtzaak van "het slachtoffer" aan je broek krijgt. Het opsporen van beveiligingsfouten wordt nog te vaak gelinkt aan het illegaal hacken van servers/websites.

Zover ik weet is een whitehat (nog) niet onschendbaar na het melden van een lek en ben je nu niet erg slim bezig als je je naam en nummer vermeldt bij jou "hack".

[Reactie gewijzigd door Verwijderd op 29 juli 2024 08:49]

[thegve]

Met naam en toenaam op de website van het CPB plaatsen vind ik wel weer een stap te ver gaan, dit is een soort "publieke straf", terwijl als je naar eer en geweten je best hebt gedaan om je systemen te beveiligen, en een hacker mocht er toch in slagen om gegevens buit te maken, dit het bedrijf niet valt te verwijten.
Het moeten melden naar de personen die het betreft is wel een goede zaak, hier is de waarde van de privacy van de persoon hoger dan het commerciele belang van het bedrijf.

[psyBSD]

Met naam en toenaam op de website van het CPB plaatsen vind ik wel weer een stap te ver gaan, dit is een soort "publieke straf", terwijl als je naar eer en geweten je best hebt gedaan om je systemen te beveiligen, en een hacker mocht er toch in slagen om gegevens buit te maken, dit het bedrijf niet valt te verwijten.

Dat ben ik slechts gedeeltelijk met je eens. Als je naar eer en geweten hebt gehandeld dan kun je ook goed uitleggen dat het probleem bij detectie direct is verholpen. Er zijn echter genoeg bedrijven die zich niets aantrekken van security, ook niet als ze er op gewezen worden of wanneer het wettelijk verplicht is.

Als de schandpaal de enige manier is om deze bedrijven een beetje ethiek bij te brengen, then 'so be it'. (ik kan er zo wel een paar noemen)

[CyberFly]

Het voorstel is naar mijn idee nog niet helemaal lekker.
Een aantal punten om het te verbeteren:

De maximale hoogte van de boete slaat nergens op.
Bedrijven met meer vermogen kunnen de maximale boete makkelijker betalen dan bedrijven met minder vermogen. Zo is het dus niet mogelijk om ieder bedrijf even hard te straffen.
Een boete van een aantal procent van de omzet/winst van het bedrijf is veel eerlijker. Hoe groter/ernstiger het lek hoe hoger de boete in procenten. Zo krijgt ieder bedrijf een passende boete.

Een datalek zou altijd gemeld moeten worden ongeacht de encryptie van de data. Zodra de data gelekt is weet je niet wat ''ze'' er mee doen. Altijd melden dus!


Zou het niet handig zijn als er een keurmerk komt voor fabriekanten van websites?
Dan is het makkelijk om te zien welke toko veilige websites maakt.

[Xubby]

[...]
Zou het niet handig zijn als er een keurmerk komt voor fabriekanten van websites?
Dan is het makkelijk om te zien welke toko veilige websites maakt.

Keurmerken, dat stelt niet altijd wat voor, zie Kassa hierover: die kregen op een "namaak" winkel website zonder keuring elf keurmerken ...

[Gamebuster]

Wat zijn "persoonsgegevens"?

[zx9r_mario]

Als de boetes ook voor overheden zouden gelden, dan zouden ze gelijk failliet zijn gezien het aantal lekken.