Is Sony aansprakelijk voor gestolen Playstation-gegevens?

sony-playstation.pngSony stelt zichzelf niet aansprakelijk in het geval een onbevoegde buitenstaander zichzelf toegang verschaft tot persoonlijke gegevens, las ik bij Nu.nl. Dat zou blijken uit de TOS van de dienst. Bij een inbraak werden persoonsgegevens en creditcardinformatie gestolen uit de databases van het Playstation Network van Sony. Hoewel het CVV-getal niet is gestolen, kan er toch misbruik worden gemaakt van de informatie omdat lang niet elke creditcard-acceptant deze code vraagt. Sony

Het is me onduidelijk of Sony dit nu daadwerkelijk heeft gezegd of dat Nu.nl (en Gamer.nl) het klakkeloos overnemen van Edge, dat de pechgehadclausule in de terms of service ontdekte:

We exclude all liability for loss of data or unauthorised access to your data, Sony Online Network account or Sony Online Network wallet and for damage caused to your software or hardware as a result of using or accessing Sony Online Network.

Kan dat zomaar? Natuurlijk niet. Een bedrijf kan haar aansprakelijkheid proberen te beperken, maar de wet (zowel in Nederland als in de Verenigde Staten) stelt daar grenzen aan. Eén van die grenzen is “opzet en grove nalatigheid”: daarvoor ben je te allen tijde aansprakelijk, ongeacht je voorwaarden.

Voor specifieke soorten datadiefstal zijn er strengere regels. Zo kent de Wet bescherming persoonsgegevens de plicht om data “adequaat” te beschermen tegen diefstal en ongeautoriseerd gebruik. Die plicht is niet in de voorwaarden weg te tekenen, en aansprakelijkheid bij schending van die plicht is niet uit te sluiten. Een probleem is wel om aan te tonen wélke schade je hebt geleden door deze schending. Ik blijf het een goed idee vinden om gewoon een vast bedrag, zeg 300 euro, in de wet te zetten als schadebedrag als er geen hogere schade is geleden. Als Sony een risico van 70 miljoen maal 300 euro loopt, vinden ze een investering in een beveiligingsbedrijf misschien wel een goed idee.

En specifiek voor creditcardgegevens is er nog artikel 7:529 BW. (Voor de mensen met e-commerce achtergrond: artikel 7:46g BW bestaat niet meer.). Dit bepaalt dat de kaarthouder slechts aansprakelijk is tot een bedrag van ten hoogste ” 150 voor niet-toegestane betalingstransacties met een verloren of gestolen betaalinstrument. Uitzondering is als de kaarthouder “frauduleus of opzettelijk of met grove nalatigheid heeft gehandeld”. Het lijkt me niet dat het geven van je creditcardgegevens aan Sony telt als grove nalatigheid, dus het risico voor de Playstation-Netwerkgebruikers is beperkt.

Het blijft een goed idee om je creditcardstatements te controleren en meteen de bank te bellen als er een ongeautoriseerde transactie verschijnt. (Dit níet doen zou kunnen worden gezien als grove nalatigheid.) En misschien kun je maar beter sowieso een nieuwe creditcard aanvragen om elk risico uit te sluiten.

Arnoud

26 reacties

  1. Ik vind dat zo’n minimum bedrag van de schade (te betalen aan de persoon wiens gegevens zo gelekt zijn) een leuk idee. Maar het bedrag is redelijk precies, te hoog en je bent steeds als klant je gegevens weer en weer aan het invullen, te laag en je verzekert het gewoon weg als bedrijf. Schaalgrootte van het bedrijf speelt hier ook mee mee, voor kleine bedrijven is het lastig om de juiste nivo te kunnen bekostigen per account dan (dit is het gebied waarin in de credit card wereld EMVco’s PCI een getrapte schaal probeert te geven juist om de kleine merchants het niet te lastig te maken maar toch voldoende beveiliging te leveren).

    In dreigingsmodellen waar de aanvaller commercieel opereert(*), werkt in mijn ervaring het goed om de beveiliging te richten op duidelijk boven de waarde van hetgeen je beschermt, i.e. de waarde voor de aanvaller * veiligheidsmarge. In die veiligheidsmarge kun je ook PR/imago schade zetten, maar hij is voornamelijk om een buffer te leveren tegen fouten in de inschatting van de moeite die de aanvaller doet (of hoeft te doen, i.e. zoals de geruchten nu zijn dat de aanval ging via een niet-gehardende server met bekende root exploits beschikbaar).

    De gelekte gegevens (creditcard behalve CVV, volle naam, adres, email etc) zijn op de ondergrondse markt in de orde van 10-30 Euro waard. Net als al dit soort diefstal is de schade aan de kant van de houder van de kaart (en/of diens bank en dus impliciet de houder) een veelvoud daarvan, maar uiteindelijk ga je uit dat de aanvaller niet meer werk doet dan het oplevert. Dus 300 Euro klinkt als een forse veiligheidsmarge hier, correct voor zeer grote hoeveelheden van dat soort gegevens.

    (*) Niet-commerci?le aanvallers, zoals mensen die weer Linux willen draaien op hun PS3, daar maanden high-end werk aan besteden en dan het resultaat gewoon weggeven, zijn een stuk lastiger te vangen in dit model. Een verveelde student/hacker die ongehoord veel tijd en vaardigheid gewoon weggeeft, is lastig tegen te beschermen 😉

  2. Leuk, schade claimen bij Sony. Enige probleem is dat Sony internationaal opereert en je moet kiezen in welk land je de schadeclaim neerlegt. Voor Nederlandse Sony-leden is dat in beginsel Nederland. En Sony heeft vestigingen in Nederland dus is dat redelijk goed te doen. Dit maakt het ook voor de gehele Europese Unie redelijk goed te doen, hoewel het natuurlijk afhangt van de locale wetgeving in hoeverre die schadeclaim van toepassing is.

    Maar wat als Sony beweert dat die licentie is afgesloten volgens de Japanse wetgeving? Geen idee hoe die wetgever met dit soort zaken omgaat maar dit maakt het wel een lastige, internationale kwestie…

    Kortom, dit is eigenlijk een kwestie waarbij de consumenten zich beter eerst kunnen organiseren in een groep en gezamelijk een schadeclaim indienen. Zaakje voor Tros Radar misschien? De Rijdende Rechter? Tros Opgelicht? Tja… Dit gaat een lange kwestie worden.

    En dat na de Rootkit affaire waar Sony ook behoorlijk wat schade had veroorzaakt! Terwijl ze daar toch redelijk goedkoop onder uit kwamen, mede omdat ze in de USA werden veroordeeld voor deze misstand.

    Sony en beveiliging… Die twee gaan gewoon niet goed samen, lijkt het wel…

    (De Rootkit affaire resulteerde in een maximale claim van $150 per computer die opgeschoond moest worden van die troep. Veel minder dan de voorgestelde EUR 300 terwijl het risico van de rootkit ook behoorlijk groot was.)

  3. @Wim: Het probleem van jurisdictie is op te lossen, Nederland kan in de wet zetten dat bij overtreding van dat wetsartikel Nederlands recht geldt als de getroffen partij in Nederland woont (“of haar gewone verblijfplaats heeft”).

    Iets dergelijks staat er ook bij algemene voorwaarden: een Nederlandse consument heeft ?ltijd recht op de bescherming tegen onredelijk bezwarende algemene voorwaarden uit de wet, ook als de wederpartij buiten Nederland opereert. Natuurlijk is afdwingen van die bepaling wat lastig maar het principe staat.

  4. @Arnoud, de wet is er wel, maar wat ik in Nederland zo lastig vind is ook het verkrijgen van hetgeen je recht op hebt! Een dergelijke kwestie tussen consument en grote speler als Sony loopt vaak af in het voordeel van de grote partij. Een minimale schade-bedrag toekennen bij wet is aardig, maar beter is het als consumenten tesamen als een enkele groep kunnen samenwerken en tesamen een forse schadeclaim kunnen indienen, waarbij alle consumenten samen de advocaat-kosten kunnen delen voor zolang het nodig is.

    En wat lastiger is in dit soort kwesties is dat dit alleen de Nederlandse klanten helpt. Onze zuiderburen, de Belgen, moeten ook iets vergelijkbaars doen. En alle andere lidstaten binnen de EU moeten ieder zelf iets ondernemen. Waar hebben we de Unie voor indien dit soort kwesties per land opgelost moet worden?

  5. Helemaal gelijk Maarten! Je bent alleen aansprakelijk bij 1) het gebruik van een verloren of gestolen betaalinstrument of, 2) onrechtmatig gebruik van een betaalinstrument, als je hebt nagelaten de veiligheid van de gepersonaliseerde veiligheidskenmerken ervan te waarborgen.

    De consument heeft in deze situatie niets fout gedaan door zijn CC-gegevens bij Sony op te slaan en is dus gewoon niet aansprakelijk voor enige financi?le schade.

  6. Sony lijkt nalatig als je de beschikbare informatie mag geloven. Ze gebruikten blijkbaar een server waarvan de software reeds bekende bugs bevatte maar bovenal hadden ze de creditcard gegevens op een server staan die aan het internet was gekoppeld.

    Een zeer onwenselijke praktijk. Dergelijk gegevens moet je apart bewaren, dus niet binnen het PlayStation Netwerk(PSN) zelf maar in een aparte beveiligde zone die vanuit het PSN alleen via een hoog beveiligde service benaderbaar is.

  7. Makkelijk gezegd, dat Sony nalatig is geweest. Maar wat vaak vergeten wordt is dat er wel veel meer bedrijven vrij slordig omgaan met client-data! Zeker nu Cloud computing steeds populairder wordt en men steeds vaker gebruik maakt van grote datacenters om belangrijke data in op te slaan. Steeds minder bedrijven hebben goede controle over de complete architectuur van hun servers en moeten maar vertrouwen op de betrouwbaarheid van betreffende dataservers en Cloud Providers. Zo ook Sony… Een een netwerk te beheren dat zo groot is als dit Sony netwerk kun je gewoon niet zonder datacenter. Ook de database moet goed benaderbaar zijn en omdat de creditcard gegevens noodzakelijk zijn om de consument te laten betalen voor de diverse diensten is het ook lastig om die gegevens goed beschermd te houden. Maar het kan natuurlijk wel! Maar een database met dergelijke, beschermde gegevens zal ook zeer vaak geraadpleegd worden en is dus ook het meest bruikbaar binnen de Cloud zelf. En daar is deze kwetsbaar…

    Maar de Sony kwestie leert ons veel over hoe bedrijven soms met belangrijke data omgaan. Een beetje webwinkel is mogelijk nog slordiger met onze gegevens. Heeft b.v. bol.com hun boeltje wel goed beveiligd? Want ook Bol heeft enorm veel klanten en betalingen en dus staan hun servers ook in een groot datacenter te draaien. En al die andere bedrijven die prive-informatie bijhouden? Of zelfs de belastingdienst, bij de online inkomsten-aangiftes?

    Hoe garandeer je de beveiliging van je data indien je zoveel bezoekers hebt dat je de data in een datacenter moet opslaan?

  8. @ Wim: dat kun je nooit garanderen, want een beveiliging is zo sterk als de zwakste schakel.

    In Sony’s specifieke case zijn er meerdere zwakke schakels aan te wijzen:

    1 – CC-gegevens worden in plain tekst verstuurd 2 – Gegevens zijn opgeslagen op een Red Hat-server waarvan recent ontdekte veiligheidslekken niet waren gedicht 3 – In februari hebben hackers al gepubliceerd over het beveiligingsrisico’s op PSN, met de waarschuwingen is niks gedaan.

    Nu kan ik niet de gedachten lezen van de mensen die bij Sony werken, maar het lijkt erop alsof onderschatting een grote rol heeft gespeeld. De les die de Belastingdienst, Bol.com et cetera daaruit kunnen trekken is dat je toch wel een hoop kan doen om een dergelijk lek te voorkomen, zoals een goede risico-analyse en voldoende recourses voor het uitbannen van kwetsbaarheden.

  9. @Wim: Ik weet niet wat datacenters hiermee van doen hebben. Alle servers hangen in datacenters, daarbij maakt het niet uit of je er nou 1 hebt of 1000. If anything is het juist makkelijker om dit soort dingen veilig te doen wanneer je een grote speler bent, omdat je de fysieke toegang beter kunt beveiligen wanneer een hele vleugel van een datacenter van jou is.

    Dit soort dingen hoor je defense-in-depth te beveiligen. Dat wil zeggen: zorg dat je een heleboel lagen neerzet waar een potientiele aanvallen doorheen moet. Zet de gevoelige gegevens op een aparte database-server, versleutel CC-gegevens zodat alleen de database kraken niet genoeg is, want je moet dan ook ergens de sleutel vandaan halen, die bewaar je uiteraard op een andere server. Daardoor moet je als aanvaller meerdere servers zien te kraken. En dan moet je natuurlijk zorgen dat die twee servers niet hetzelfde beveiligingslek bevatten, of dat je met 1 password op beide machines kunt inloggen.

    Als je grote speler bent met veel data, moet je toch al dingen uitsplitsen om de hoeveelheid gebruikers aan te kunnen. Als je duizend servers beheert zijn de kosten voor eentje extra veel kleiner dan wanneer je applicatie qua aantal gebruikers eigenlijk nog makkelijk op 1 server zou passen.

  10. Zet de gevoelige gegevens op een aparte database-server

    Sterker nog, zet de server met gevoelige data in een gescheiden netwerk. Creeer een heel beperkte tunnel tussen de twee netwerken waarover alleen enkele specifieke SOAP services naar de gevoelige gegevens aangeboden worden.

  11. @Marten, op kleinere schaal is het mogelijk om via een VPN verbinding een database server neer te zetten buiten het datacenter zodat de data op een veilige plaats weg van de server staat. Maar tegenwoordig verhuist er veel naar de datacenters zelf, inclusief complete databases. Een ander verschil is natuurlijk hoe exclusief een datacenter uiteindelijk is. Grotere bedrijven kunnen het permitteren om hun eigen datacenter op te zetten, net zoals ze het kunnen veroorloven om grote kantoren te bouwen en te gebruiken. Alleen, grote kantoren en datacenters worden lang niet allemaal volledig gevuld en dan blijft er ruimte over om aan anderen door te verhuren. Dat levert extra inkomsten op maar brengt ook extra risico’s met zich mee.

    Toch kun je je gegevens in een datacenter goed beveiligd wegzetten, maar het opzetten van een goede software-architectuur om dat te bereiken is vaak te hoog gegrepen voor velen. De suggestie om de database op een andere server te plaatsen met een tunnel is al gemaakt, maar niet ideaal. De server heeft dan immers nog steeds rechtstreeks toegang tot de database. Wil je het veiliger doen dan moet er een aparte business server erbij die via de tunnel wordt benaderd. De webserver is dan beperkt tot die functies die de business server mogelijk maakt. De business server is dan de enige met directe toegang tot de database. Jammer alleen dat dit ontwerp-model door veel ontwikkelaars gewoon overbodig wordt gezien omdat ze erop gokken dat de webserver zelf niet gekraakt zal worden…

    @hAl, ja, SOAP is een methode voor zo’n Business Server. Of REST. Of welke andere techniek je maar kunt bedenken. DCOM, COM+ of gewoon Plain Old HTTP. De techniek die je gebruikt is van ondergeschikt belang, maar die extra business server vergroot de beveiliging al behoorlijk! Tenzij die business server gewoon alle gegevens kan opvragen zonder enige authenticatie. SOAP en REST geven de hacker al snel goed inzicht in welke methodes gebruikt kunnen worden en het enige wat ze dan nodig hebben is toegang tot de tunnel. Beveiliging door obfuscation is dan eigenlijk je laatste redmiddel dus moet je zorgen dat de methodes die je nodig hebt om de business server aan te roepen niet bekend gemaakt worden. Voor SOAP dus geen WSDL aanbieden! En bij REST ook de logica-informatie verborgen houden…

  12. Tenzij die business server gewoon alle gegevens kan opvragen zonder enige authenticatie

    Zelfs dan valt het niet mee als je de services zo hebt opgegezet dat je aan een uitvraag altijd al een geldig creditcardnummer mee moeten geven. (om het nummer te verifieren, toe te voegen of te wijzigen).

  13. @hAl, dat klopt. Sowieso moet je creditcard nummers -net als wachtwoorden- nooit meer zichtbaar maken aan de gebruiker zelf. Ze mogen deze gegevens wel invoeren maar uitlezen is verboden! Maar het probleem is niet alleen de invoer en verwerking… Op een gegeven moment doet de klant een bestelling en zijn de creditcard-gegevens nodig om de daadwerkelijke betaling uit te voeren. Dat gebeurt vanaf de webserver die dan met een authenticatie-server van een bank of creditcard maatschappij communiceert en daarbij de creditcard gegevens door moet geven. En al zitten die gegevens veilig achter een tunnel, voor het afrekenen moeten die gegevens doorgestuurd worden naar een systeem met internet-toegang. En daar zijn die gegevens dus kwetsbaar. De web server zal in bijzondere gevallen toch het creditcard nummer moeten opvragen, wat betekent dat er een methode bestaat die het kan opvragen. En dat is een zwakke plek. Tja. Betaal-opdracht door de tunnel sturen en het systeem achter de tunnel weer via een tweede tunnel doorverwijzen naar een speciale server die weer het internet kan benaderen en dus de betaling kan regelen. Dan is de server die de betaling regelt een andere dan de server waar de gebruiker op inlogt! Maar die setup levert al gauw 4 specifieke servers op: webserver, business server, betaal-server en database server. En dan ook even zorgen dat je dagelijks 5.000 requests per uur kunt verwerken, met mogelijk duizenden betalingen met een maandelijkse interval… Dit zijn vier server-groepen dus eigenlijk vier datacenters. Of een datacenter verdeeld in vier delen…

  14. En misschien kun je maar beter sowieso een nieuwe creditcard aanvragen om elk risico uit te sluiten.

    Kun je de eventuele kosten daarvan dan declareren bij sony, zonder dat je daarvoor eerst moet gaan dreigen met een rechtszaak?

  15. Betreffende dit onderwerp heeft TechDirt weer eens een interessant artikel over dit alles! Eerst en vooral, in de USA in geval van een “data breach” moet je als consument eerst aantonen dat je schade hebt ondervonden door het verlies van die gegevens alsvorens je een schadeclaim kunt indienen. Zo zijn veel bedrijven in het verleden veel kosten bespaard. Zo ook in deze Sony kwestie. Indien de hackers de “gestolen” data niet misbruiken is er geen schade. Geen schade, dus ook geen schadeclaims! Heb je direct een nieuwe creditcard aangeschaft omdat je bang was dat deze anders misbruikt zou worden? Tja… Mogelijk dat Sony niet voor dergelijke claims verantwoordelijk gehouden zal worden in de USA.

    Brengt mij tot een belangrijk punt: hoe zit dat eigenlijk in Nederland? Gevoelige informatie lekt uit maar wordt kennelijk niet misbruikt. Kun je dan alsnog schade claimen???

  16. @Wim, helaas is de situatie in Nederland niet anders… Tenzij de lekker uit “coulance” je een schadevergoeding geeft, zul je voor de rechter de schade moeten kunnen aantonen.

    Het voorstel van Arnoud spreekt me wel aan: een forfaitair bedrag per “lek”, tenzij je aan kunt tonen dat de schade die je geleden hebt hoger is dan het forfait, dan wordt de totale schade vergoed. (De hoogte van het bedrag mag best afhankelijk zijn van welke data gelekt is: alleen NAW telt minder dan NAW plus creditkaartnummer en geboortedatum.

  17. @MathFox een forfaitair bedrag als minimum per lek spreekt mij ook aan, maar ik voorspel er ook problemen mee. Want een datalek kan ook gebeuren indien iemand een laptop verliest met daarop gevoelige informatie. Het kan zijn dat de dief vervolgens de data probeert uit te lezen maar het is waarschijnlijker dat de dief de data negeert en gewoon de hardware doorverkoopt, waarbij de schijven eigenlijk meteen geformatteerd worden om de sporen naar de vorige eigenaar uit te wissen. Sowieso wordt er best veel data gelekt zonder dat er direct misbruik van wordt gemaakt. Maar stel dat dit een betrekkelijk klein bedrijf overkomt en gegevens van 10.000 klanten wordt gejat. Dan moet dit bedrijf dus drie miljoen aan schade gaan uitbetalen, zelfs als er niets wordt misbruikt! Een bedrag van 300 Euro klinkt laag, maar met grote aantallen wordt het al snel enorm prijzig. Een bedrijf als Sony kan het nog veroorloven om 10 miljoen klanten te vergoeden, hoewel dit de winst enorm zal drukken. Maar zou een bedrijfje als ICTRecht wel de schade kunnen vergoeden indien ze data van maar 1.000 klanten verliezen? Of maar 500 klanten?

    Het bedrag dat minimaal toegekend zal worden zal dus laag genoeg moeten zijn om bedrijven van een faillisement te kunnen behoeden. Daarom is het misschien redelijker om geen forfaitair bedrag toe te kennen indien er geen daadwerkelijke schade is maar bijvoorbeeld een bepaald boete-bedrag die dan maar de schatkist in gaat. Een boete van EUR 50.000 per datalek (niet per persoon) zou ook afschikwekkend kunnen werken, zeker voor kleinere spelers.

  18. Om even een voorbeeld te geven, op security.nl staat een artikel over een ziekenhuis-medewerker die een laptop verloor met gegevens van 6.000 patienten. Het voorstel van Arnoud betekent dat dit ziekenhuis dus EUR 300 x 6.000 mag gaan betalen. Dat is 1.8 miljoen Euro! Maar de gestolen laptop is zeer waarschijnlijk door de dief geformatteerd en dus is de data verloren gegaan, in plaats van dat deze wordt misbruikt. In dat geval is de schade maar beperkt tot de waarde van de laptop zelf. De gegevens werden toch gesynchroniseerd met een grotere server, dus geen data-verlies.

    Ik vind het dus wel belangrijk dat schade eerst wordt aangetoond voordat je een claim kunt indienen. En in geval van schade zou je inderdaad een minimum compensatie-bedrag kunnen instellen. Geen schade, dan ook geen geld!

  19. Wim, het idee is dat de dreiging van die 1.8 miljoen euro inspireert tot beveiligingsmaatregelen op die laptop zodat de diefstal geen schade meer kán berokkenen. (Uiteraard komt er dan in de wet bij te staan dat als de laptop beveiligd is, er geen 300 euro betaald hoeft te worden.)

  20. Snap ik, maar een dreiging moet je ook waar kunnen maken. In dit geval zou het ziekenhuis dus 1.8 miljoen Euro moeten uitbetalen wegens een gestolen laptop met gevoelige data die misschien wel of niet misbruikt zal worden. In dit geval was er wel sprake van een beveiliging via een wachtwoord, maar is een dergelijke bescherming wel voldoende? De Sony site was ook door wachtwoorden beschermd maar kennelijk waren er de nodige zwakke plekken in het geheel. Plekken die wel bekend waren maar waar men nog niet aan toe was gekomen om te repareren.

    De dreiging heeft geen effect als je al met een zwakke beveiliging er onder uit kunt komen. De dreiging is daarentegen weer te zwaar indien je enorm hoge beveiligings-eisen gaat stellen. De balans ligt daar ergens tussen maar de preciese grens is meer de mening van experts dan een duidelijk aan te wijzen grens. Wat de een meer dan voldoende vindt, vind een ander nog steeds veel te zwak. Zelfs het bedrag van 300 Euro is maar een mening van een expert. Anderen willen misschien een ondergrens van maar 100 Euro. Of 1.000 Euro. Kortom, het is een maatregel waar veel discussies over los zullen barsten…

    Waar ik verder bang voor ben is de mogelijkheid dat mensen dit zullen misbruiken. Immers, als een diefstal van mijn gegevens mij al zowat 300 Euro kan opleveren, waarom dan niet mijn gegevens onderbrengen in zwak-beschermde locaties om deze te laten stelen? Medewerkers van bedrijven kunnen dan zelf de nodige data lekken zodat hackers binnen kunnen komen zodat familie van die medewerkers lekker ieder 300 Euro per persoon kunnen claimen. En er zullen vast anderen zijn die een dergelijke maatregel nog creatiever kunnen misbruiken…

    Het mooie van Nederland is dat als je schade veroorzaakt dan hoef je in principe alleen het schadebedrag te vergoeden. En niet meer dan dat. Daardoor blijven veel rechtzaken nog in het redelijke wanneer het om schadeclaims gaat. Dus geen mensen die een half miljard Euro claimen als ze in een restaurant hun tong branden aan een kop te hete koffie, zoals in de USA wel eens geprobeerd wordt.

    Een minimum schadebedrag klinkt mij gewoon als een soort boete. Noem het dan ook een boete, geen schadevergoeding!

  21. Ik vind het prima het een boete te noemen, maar “boete” betekent meestal “bedrag dat aan de overheid wordt betaald”. En ik wil juist dat de slachtoffers het krijgen. Het is dan het makkelijkst in de wet te hacken door het een gefixeerde schadevergoeding te noemen. #define SCHADE 300\ euro is makkelijker dan een boetesysteem invoeren. 🙂

  22. Op zich is nalatigheid in het geval van Sony al bekend. Niet patchen en nadat je gewezen bent op je zwakheden niet fiksen is gewoon nalatig. Gezien de hoeveelheid gevoelige data, is “grove nalatigheid” naar mijn mening ook prima aantoonbaar. Het lijkt me dat de gebruikers en de CC-maarschappijen in deze gewoon alle schade op Sony zouden moeten kunnen verhalen.

  23. @Arnoud, maar waarom een schadebedrag toekennen indien er geen schade is? Zoals Alex al zegt, noem het dan een dwangsom of geef het een andere naam, maar schadevergoeding klinkt alsof er schade heeft plaatsgevonden.

    Overigens denk ik niet dat een dergelijke regelgeving mensen zal afschrikken omdat de inbouwen uiteindelijk door programmeurs gebeurt die zelf verder geen verantwoording hebben. Ik zie het op mijn eigen werkplek, waarbij we software produceren die vrij gevoelige klant-informatie moet bijhouden. Maar qua beveiliging is er nauwelijks iets te vinden in de software en gebruikers stellen een dergelijke bescherming niet eens op prijs!

    Ik zie het ook op mijn werkplek nu mijn werkgever besloten heeft om producten onder te brengen in “the Cloud” waardoor we straks geeneens meer controle hebben over de hardware waar alles op komt te draaien! En we moeten wel, want de concurrentie is al met hetzelfde bezig. Nu is de cloud-omgeving van Amazon laatst een tijdje plat gegaan maar gelukkig zitten wij niet onder Amazon. Toch moet ik er niet aan denken hoeveel schade er kan ontstaan indien een hacker de Google/Amazon/Azure/RackSpace cloud weet te hacken en zo alle databases in die cloud te jatten. Met die duizenden bedrijven die nu al gevoelige informatie bewaren in de Cloud zou dat een enorme schade kunnen opleveren! Dat het Sony Datacenter nu is aangevallen is vervelend voor vooral Sony. Maar als b.v. RackSpace een vergelijkbare aanval krijgt op hun Cloud-omgeving dan is niet allen RackSpace het haasje, maar ook honderden, zo niet duizenden andere bedrijven en bedrijfjes.

    Gelukkig hou ik mijzelf goed op de hoogte van de mogelijkheden van beveiliging en ik volg dit blog ook vooral om kennis op te doen over legale kwesties die ik in mijn werk tegen kan komen. Ook al ben ik als programmeur niet degene die straks 300 Euro per persoon mag gaan betalen, toch wil ik mijn werkgever dergelijke onkosten wel besparen! Maar als je merkt hoeveel collega’s en gebruikers van de software al deze beveiliging maar overbodig gezeur vinden en als je ook merkt dat beveiliging vaak een der eerste zaken is waarop bespaard wordt binnen een project… Tja, ik denk niet dat een dergelijke boete of schadeclaims bedrijven zal afschrikken…

    Probleem is dat gebruikers snel resultaat worden. Beveiliging toevoegen doet niets om het eindresultaat te versnellen.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.