Juridische vraag: Hoe voorkom je aansprakelijkheid wanneer een klant productiedata met persoonsgegevens als testdata aanlevert?
woensdag 24 januari 2018, 15:27 door Arnoud Engelfriet, 30 reacties
Ict-jurist Arnoud Engelfriet geeft elke week antwoord op een interessante vraag over beveiliging, recht en privacy. Heb jij een vraag? Stuur hem naar juridischevraag@security.nl.
Vraag: Wij ontwikkelen enterprisesoftware voor klanten, en testen deze uiteraard ook. Meestal ontvangen we daarvoor de testdata van de klant en soms zit daar ineens productiedata tussen inclusief persoonsgegevens. Zijn wij daarvoor aansprakelijk onder de GDPR?
Antwoord: Het is uiteraard een goed idee om software te testen alvorens je deze gebruikt, zeker wanneer die software persoonsgegevens gaat verwerken. Dergelijke software moet immers veilig zijn en voldoen aan de beginselen van privacy by design en privacy by default.
Goede testdata is daarbij van belang, maar is vaak moeilijk te krijgen. Daarom zie je regelmatig dat er toch met productiedata wordt getest, dat is dan de enige bron van een grote hoeveelheid uiteenlopende data waarmee genoeg aspecten getest kunnen worden.
Handig, maar erg problematisch: je weet immers per definitie nog niet of de software veilig is en wel privacytechnisch dichtgetimmerd is. Daarmee neem je als bedrijf (de klant dus van de vraagsteller) een serieus risico op datalekken. Bovendien moet je met je wederpartij (zoals de vraagsteller dus) een verwerkersovereenkomst sluiten waarin je de omgang met deze data expliciet reguleert, en dat wordt vaak vergeten want "het is maar om te testen".
Het ontwikkelbedrijf zou ik adviseren om expliciet in de overeenkomsten op te nemen dat er géén productiedata wordt geleverd en al helemaal niets waar persoonsgegevens in zit. Een anti-verwerkersovereenkomst, zeg maar. Stuurt de klant die dan toch, dan heb je in ieder geval een sterk argument dat dit niet de bedoeling was. Uiteraard moet je dat bij ontdekking wel melden en die data vervolgens meteen wissen.
Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.
Reacties (30)
24-01-2018, 18:08 door
karma4
Het niet leveren van productiedata en tevens geem productiedumps (tenzij en dan ook zeer beperkt) lijkt me een standaard.
Ik maak nog heel vaak mee dat externe softleveranciers er van overtuigd zijn dat alle data van de klant hun toebehoort omdat zij de tools leveren. Te triest voor woorden.
Ik maak nog heel vaak mee dat externe softleveranciers er van overtuigd zijn dat alle data van de klant hun toebehoort omdat zij de tools leveren. Te triest voor woorden.
Door karma4: ....Ik maak nog heel vaak mee dat externe softleveranciers er van overtuigd zijn dat alle data van de klant hun toebehoort omdat zij de tools leveren. Te triest voor woorden.
Ja, of dat artsen denken dat de inhoud van jouw medisch dossier van hen is omdat zij de testen hebben laten uitvoeren :-)
Maar terug naar de vraagsteller: er zijn bedrijven die productiedata kunnen pseudonimiseren waarna ze als testdata gebruikt kunnen worden: je zou dat als leverancier aan de klanten kunnen aanbieden. Dat beperkt risicos voor zowel klant als leverancier.
Hier zitten overigens wel beperkingen aan bij gebruik van ongestructureerde datasets die met big-data software doorzocht moeten worden: omdat het ongestructureerd is kan er geen automatisch algoritme overheen...
Q
Als de klant je productiegegevens levert, dan zo snel mogelijk weggooien (hot potato) en vragen om synthetische data of om het datamodel en genoeg info over aantallen, variantie, verscheidenheid etc om zelf goede testdata te kunnen genereren.
Als je persoonsgegevens in huis hebt die je niet mag hebben dan ben je verkeerd bezig (geen doelbinding), je klant heeft zojuist zichzelf een datalek bezorgd en jij bent ineens verantwoordelijk om alle voorwaarden van de AVG in te vullen voor die productiedata of je mag ook een datalek gaan melden...
We hebben die ervaring onlangs ook gehad (kregen een volledige dump van de productieomgeving) en hebben volgens bovenstaande gehandeld. Het was even schrikken.
Het is toch net of de buurman binnenkomt, een peperdure Mingvaas in je kamer zet en weg loopt onder de woorden "daar paste ik op voor de buurman verderop, ik stuur hem even een smsje dat jij er nu op past".
Als je persoonsgegevens in huis hebt die je niet mag hebben dan ben je verkeerd bezig (geen doelbinding), je klant heeft zojuist zichzelf een datalek bezorgd en jij bent ineens verantwoordelijk om alle voorwaarden van de AVG in te vullen voor die productiedata of je mag ook een datalek gaan melden...
We hebben die ervaring onlangs ook gehad (kregen een volledige dump van de productieomgeving) en hebben volgens bovenstaande gehandeld. Het was even schrikken.
Het is toch net of de buurman binnenkomt, een peperdure Mingvaas in je kamer zet en weg loopt onder de woorden "daar paste ik op voor de buurman verderop, ik stuur hem even een smsje dat jij er nu op past".
25-01-2018, 07:31 door
5ec5ec
Wij hebben dat hier, tevens een softwarebedrijf, opgelost door dergelijke data d.m.v. een script te anonimiseren. Mocht er dan toch data onveilig verwerkt worden in testomgevingen, dan zijn dit geen persoonsgegevens en heeft dit voor niemand gevolgen.
Door Anoniem:
Ja, of dat artsen denken dat de inhoud van jouw medisch dossier van hen is omdat zij de testen hebben laten uitvoeren :-)
Maar terug naar de vraagsteller: er zijn bedrijven die productiedata kunnen pseudonimiseren waarna ze als testdata gebruikt kunnen worden: je zou dat als leverancier aan de klanten kunnen aanbieden. Dat beperkt risicos voor zowel klant als leverancier.
Hier zitten overigens wel beperkingen aan bij gebruik van ongestructureerde datasets die met big-data software doorzocht moeten worden: omdat het ongestructureerd is kan er geen automatisch algoritme overheen...
Q
Door karma4: ....Ik maak nog heel vaak mee dat externe softleveranciers er van overtuigd zijn dat alle data van de klant hun toebehoort omdat zij de tools leveren. Te triest voor woorden.
Ja, of dat artsen denken dat de inhoud van jouw medisch dossier van hen is omdat zij de testen hebben laten uitvoeren :-)
Maar terug naar de vraagsteller: er zijn bedrijven die productiedata kunnen pseudonimiseren waarna ze als testdata gebruikt kunnen worden: je zou dat als leverancier aan de klanten kunnen aanbieden. Dat beperkt risicos voor zowel klant als leverancier.
Hier zitten overigens wel beperkingen aan bij gebruik van ongestructureerde datasets die met big-data software doorzocht moeten worden: omdat het ongestructureerd is kan er geen automatisch algoritme overheen...
Q
Pseudonimiseren is niet afdoende.... laat staan wanneer je hier weer een ander bedrijf voor inschakelt en je in eerste instantie daar ook productiedata naar toe moet sturen.....
Door Anoniem:Als je persoonsgegevens in huis hebt die je niet mag hebben dan ben je verkeerd bezig (geen doelbinding), je klant heeft zojuist zichzelf een datalek bezorgd en jij bent ineens verantwoordelijk om alle voorwaarden van de AVG in te vullen voor die productiedata of je mag ook een datalek gaan melden...
Hoe zit dat precies met de AVG?
Bij de Wbp is iets pas een datalek na een security incident. Is het moedwillen, conform procedures, verstrekken van persoonsgegevens een datalek. Wij hebben iets dergelijks meegemaakt, met een procedure die al sinds vorige eeuw draaide, waarbij persoonsgegevens naar een derde werden verstuurd. De conclusie van de juristen was toen dat het geen datalek was.
Peter
Door Anoniem:
Ja, of dat artsen denken dat de inhoud van jouw medisch dossier van hen is omdat zij de testen hebben laten uitvoeren :-)
Maar terug naar de vraagsteller: er zijn bedrijven die productiedata kunnen pseudonimiseren waarna ze als testdata gebruikt kunnen worden ...
Ook gepseudonimiseerde persoonsgegevens vallen onder de AVG, daarom is dit een slecht idee. Slechts als de gegevens worden geanonimiseerd is de AVG niet meer van toepassing.Door karma4: ....Ik maak nog heel vaak mee dat externe softleveranciers er van overtuigd zijn dat alle data van de klant hun toebehoort omdat zij de tools leveren. Te triest voor woorden.
Ja, of dat artsen denken dat de inhoud van jouw medisch dossier van hen is omdat zij de testen hebben laten uitvoeren :-)
Maar terug naar de vraagsteller: er zijn bedrijven die productiedata kunnen pseudonimiseren waarna ze als testdata gebruikt kunnen worden ...
Als je als softwareleverancier echter de gegevens anonimiseert, moet je nog steeds een verwerkersovereenkomst sluiten en geldt, totdat de gegevens geanonimiseerd zijn, ook de AVG.
Daarom zal de oplossing van Arnoud meestal de beste zijn: contractueel de klant verbieden productiedata en persoonsgegevens te leveren, als ze dat toch doen de klant informeren en de gegevens direct verwijderen.
25-01-2018, 14:43 door
karma4
Door Anoniem:
Pseudonimiseren is niet afdoende.... laat staan wanneer je hier weer een ander bedrijf voor inschakelt en je in eerste instantie daar ook productiedata naar toe moet sturen.....
Dank je. Het strategisch letterlijk zo in de gdpr bij de begrippen. Pseudonimiseren is geen oplossing om niet aan alle gdpr eisen te ontkomen, integendeel. Het helpt enkel om de impact bij een lek kleiner te maken. Anonimiseren kan alleen goed gaan met een aggregatie waarbij een totaal ander iets ontstaat. Dan nog blijft het oppassen.Pseudonimiseren is niet afdoende.... laat staan wanneer je hier weer een ander bedrijf voor inschakelt en je in eerste instantie daar ook productiedata naar toe moet sturen.....
Door karma4:
Door Anoniem:
Pseudonimiseren is niet afdoende.... laat staan wanneer je hier weer een ander bedrijf voor inschakelt en je in eerste instantie daar ook productiedata naar toe moet sturen.....
Dank je. Het strategisch letterlijk zo in de gdpr bij de begrippen. Pseudonimiseren is geen oplossing om niet aan alle gdpr eisen te ontkomen, integendeel. Het helpt enkel om de impact bij een lek kleiner te maken. Anonimiseren kan alleen goed gaan met een aggregatie waarbij een totaal ander iets ontstaat. Dan nog blijft het oppassen.Pseudonimiseren is niet afdoende.... laat staan wanneer je hier weer een ander bedrijf voor inschakelt en je in eerste instantie daar ook productiedata naar toe moet sturen.....
De omkeerbaarheid van het proces is de sleutel of het wel of niet onder GDPR valt.
Als ik als gegevenseigenaar de gegevens pseudonimiseer kan ik de gegevens via een vertaaltabel weer terugvertalen tot de originele data, en betekent het dat de gegevens dus nog steeds gebruikt kunnen worden om een persoon te identificeren. En dus onder de GDPR vallen.
Als ik diezelfde gegevens zonder de vertaaltabel overhandig aan een verwerker (hier een bedrijf dat software test), en die verwerker (of enig andere persoon buiten degene die gepseudonimiseerd heeft!) is op geen enkele manier in staat de gegevens tot een individu te herleiden, dan zijn voor de verwerker de gegevens geanonimiseerd.
Dit stelt wel eisen aan de oorspronkelijke gegevens houder: die moet zorgen dat de "vertaaltabel" wel veilig is en op geen enkele manier kan uitlekken.
Waarom dan in sommige gevallen pseudonimiseren ipv. anonymiseren? Een voorbeeld is analyse van medische gegevens: de nieuw te testen software kan uit gegevens een ziekte detecteren, maar de partij die de test draait heeft geen enkel idee om wie het gaat en kan de betreffende persoon niet waarschuwen. De houder van de gegevens (die de gegevens gepseudonimiseerd heeft) kan dan geinformeerd worden, en die kan dan wel kontakt zoeken met de betreffende persoon.
(uit artikel 12 De verwerkingsverantwoordelijke faciliteert de uitoefening van de rechten van de betrokkene uit hoofde van de artikelen 15 tot en met 22. In de in artikel 11, lid 2, bedoelde gevallen mag de verwerkingsverantwoordelijke niet weigeren gevolg te geven aan het verzoek van de betrokkene(n) om diens rechten uit hoofde van de artikelen 15 tot en met 22 uit te oefenen, tenzij de verwerkingsverantwoordelijke aantoont dat hij niet in staat is de betrokkene te identificeren. )
Door Anoniem:
en die verwerker (of enig andere persoon buiten degene die gepseudonimiseerd heeft!) is op geen enkele manier in staat de gegevens tot een individu te herleiden, dan zijn voor de verwerker de gegevens geanonimiseerd.
Lastige voorwaarde, te vaak is gebleken dat aan de unieke gegevens de persoon is te achterhalen. en die verwerker (of enig andere persoon buiten degene die gepseudonimiseerd heeft!) is op geen enkele manier in staat de gegevens tot een individu te herleiden, dan zijn voor de verwerker de gegevens geanonimiseerd.
Een voorbeeld is analyse van medische gegevens: de nieuw te testen software kan uit gegevens een ziekte detecteren, maar de partij die de test draait heeft geen enkel idee om wie het gaat en kan de betreffende persoon niet waarschuwen. De houder van de gegevens (die de gegevens gepseudonimiseerd heeft) kan dan geinformeerd worden, en die kan dan wel kontakt zoeken met de betreffende persoon.
Daarmee is het medisch dossier van een persoon niet enkel persoonlijk maar heeft een overstijgend algemeen belang.
De privacy voorvechters die anders beweren zitten fout. Degenen die beweren door een technisch trucje alles te anonimiseren zitten net zo goed verkeerd.
Nu kan het nog om meerdere zaken gaan, zoals:
- andere behandelwijze vaak gepaard aan een nieuw gepatenteerd medicijn (korte termijn)
Doel bewijs succes nieuw medicijn (commercieel interessant)
- langlopend diagnostisch onderzoek waarmee schadelijkheid of niet van blootstelling aan stoffen bekeken wordt (lange termijn commercieel niet interessant meer de sociale insteek).
In beide gevallen heb je de onderzoeksfase (training-test groep en een validatie groep) en de uiteindelijke uitrol (productie - scoring). Voor de onderzoeksfase heb je met dataminimalisatie een gerichte modellering - profilering een andere eis aan de dataverwerking dan het toepassen. Met dat laatste kun je de naam van de patiënt object of wat dan ook niet vermijden. Het is een onbegrip van analyses waar menigeen ook de bof niets van begrijpt.
Door Anoniem:
Waarom dan in sommige gevallen pseudonimiseren ipv. anonymiseren? Een voorbeeld is analyse van medische gegevens: de nieuw te testen software kan uit gegevens een ziekte detecteren, maar de partij die de test draait heeft geen enkel idee om wie het gaat en kan de betreffende persoon niet waarschuwen. De houder van de gegevens (die de gegevens gepseudonimiseerd heeft) kan dan geinformeerd worden, en die kan dan wel kontakt zoeken met de betreffende persoon.
Waarom dan in sommige gevallen pseudonimiseren ipv. anonymiseren? Een voorbeeld is analyse van medische gegevens: de nieuw te testen software kan uit gegevens een ziekte detecteren, maar de partij die de test draait heeft geen enkel idee om wie het gaat en kan de betreffende persoon niet waarschuwen. De houder van de gegevens (die de gegevens gepseudonimiseerd heeft) kan dan geinformeerd worden, en die kan dan wel kontakt zoeken met de betreffende persoon.
Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Even terug naar de vraag. Als software bedrijf kunt je volgens mij twee dingen doen.
Altijd zorgen dat je voor de zekerheid een verwerkersovereenkomst af laat sluiten door je opdrachtgever. Dan heb je in ieder geval kaders met elkaar afgesproken voor het moment dat er onverhoops persoonsgegevens in de dataset zitten.
Daarnaast moet je volgens mij gewoon een aantal acceptatie criteria voor datasets hebben, waarin je stelt dat je in principe alleen geanonimiseerde data accepteert. Mocht het voor het doeleinde nodig zijn om met gepseudonimiseerde data te werken omdat je anders geen representatieve dataset hebt, dan is dit vanuit de AVG een prima maatregel. Ik zou de sleutel dan wel bij de controller laten.
Altijd zorgen dat je voor de zekerheid een verwerkersovereenkomst af laat sluiten door je opdrachtgever. Dan heb je in ieder geval kaders met elkaar afgesproken voor het moment dat er onverhoops persoonsgegevens in de dataset zitten.
Daarnaast moet je volgens mij gewoon een aantal acceptatie criteria voor datasets hebben, waarin je stelt dat je in principe alleen geanonimiseerde data accepteert. Mocht het voor het doeleinde nodig zijn om met gepseudonimiseerde data te werken omdat je anders geen representatieve dataset hebt, dan is dit vanuit de AVG een prima maatregel. Ik zou de sleutel dan wel bij de controller laten.
Door Anoniem:Als ik diezelfde gegevens zonder de vertaaltabel overhandig aan een verwerker (hier een bedrijf dat software test), en die verwerker (of enig andere persoon buiten degene die gepseudonimiseerd heeft!) is op geen enkele manier in staat de gegevens tot een individu te herleiden, dan zijn voor de verwerker de gegevens geanonimiseerd.
Dit is niet waar. Heel simpel tegenvoorbeeld: voor een IP-adres heeft over het algemeen alleen de internetprovider de "vertaaltabel" (eventueel is voor de vertaling ook tijd + port nodig). Echter is een IP-adres wel degelijk een persoonsgegeven, daarbij maakt het niet uit of het IP-adres door de internetprovider of een andere partij wordt verwerkt.Gepseudonimiseerde persoonsgegevens zijn altijd persoonsgegevens. Dus ook voor gepseudonimiseerde gegevens is altijd een verwerkersovereenkomst met alle eventuele verwerkers nodig. En om terug te komen op de vraag is er in dit geval wel degelijk ook een aansprakelijkheid voor de vraagsteller, als hier niets duidelijk geregeld is. Ook als het alleen maar gepseudonimiseerde productiedata zijn.
OT: Dat neemt niet weg dat het pseudonimiseren van persoonsgegevens één van de passende technische of organisatorische maatregelen kan zijn om het gebruik van productiedata in een testomgeving mogelijk te maken, zoals hierboven geopperd.
26-01-2018, 09:56 door
karma4
Door Anoniem:
Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Ik loop rond in de analytische wereld en dan zie je dat dit geen hypothetische geval is. Die verwevenheid is nogal gangbaar en zekere niet altijd correct als hoor je er weinig van. Wat er staat is het ethische probleem als je tijdens het onderzoek niet een marginaal verschil maar een zeer beduidend effect positief of negatief bemerkt. Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Het onderzoek gebeurt dubbel blind. Ga je het hele voorgenomen traject door en grijp je voortijdig in. Denk even aan de gevolgen bij niet ingrijpen.
Door karma4:
Door Anoniem:
Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Ik loop rond in de analytische wereld en dan zie je dat dit geen hypothetische geval is.Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Ja ja, en ik ben de paus... hypothetisch dan.
Ik mis in deze discussie het volgende:
Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Door karma4:
Ik bedoel ook: is dit een aanvulling op het gestelde in de vraag?Door Anoniem:
Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Ik loop rond in de analytische wereld en dan zie je dat dit geen hypothetische geval is.Is dit van toepassing op de gestelde vraag, of is dit een hypothetisch geval wat verder niks met de vraag te maken heeft?
Ik vind het eerlijk gezegd nogal vreemd dat als je software aan het testen bent en daar komt iets uit (wat het ook is),
je daarop dan in actie zou (willen) komen.
Als die software een bepaald doel dient dan zal dat doel bereikt worden tijdens gebruik in productie.
Waar ik me veel meer zorgen om maak is het representatief zijn van testdata als dit geen live data is.
Om maar een simpel voorbeeldje te noemen: je kunt wel verhaspelde namen of willekeurige tekens gebruiken als testdata
maar dan kom je ook nooit de bug tegen die we een aantal jaren geleden in het personeelssysteem hadden, waarbij
de hele boel op zijn bek ging van de naam 't Hart.
(programmeurs snappen wel hoe dat kan gebeuren)
26-01-2018, 12:10 door
karma4
Door Anoniem: Ik mis in deze discussie het volgende:
Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Je moet even verder denken dan dat een mens alles wel weet. De omslag is dan dat in de data de kennis zit waar je naar op zoek bent. Als je van een machine kan voorspellen wanneer hij stuk gaat dan kan je dat voor zijn. Meten is weten.Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Met gegevens uit bedrijven inclusief persoonsgegevens zie je dat het op C-level normaal gevonden worden de analyse uit te besteden. Dan gooi je alle productie data naar de verwerker. Bij nieuwe/opties aanbesteding komt die handeling ook voor.
Door Anoniem:
Ik bedoel ook: is dit een aanvulling op het gestelde in de vraag?
Ik vind het eerlijk gezegd nogal vreemd dat als je software aan het testen bent en daar komt iets uit (wat het ook is),
je daarop dan in actie zou (willen) komen.
Als die software een bepaald doel dient dan zal dat doel bereikt worden tijdens gebruik in productie.
In de klassieke aanpak dat de kennis van de beslissingen in requirements via een waterval gaan heb je gelijk.Ik bedoel ook: is dit een aanvulling op het gestelde in de vraag?
Ik vind het eerlijk gezegd nogal vreemd dat als je software aan het testen bent en daar komt iets uit (wat het ook is),
je daarop dan in actie zou (willen) komen.
Als die software een bepaald doel dient dan zal dat doel bereikt worden tijdens gebruik in productie.
Als de data zelf door nieuwe wiskundige analyses heen moet gaan, gaat dat niet meer op.
Ik pleit er dan ook voor om geen bijzondere persoonsgegevens bij het modeleren te gebruiken (anoniem in beperkte mate).
Je moet het modelleren (met begeleiding materiedeskundige) dan ook zien als het programmeren. De omschakeling is dat de data de rol van coderen en opstellen logische requirements vervangt. Je moet die data zien in versioning te gooien.
Je voorbeeld van de naam 't Hart is een leuke, dat gaat fout als er "slimme" algoritmes over heen gaan wat de bedoeling zou zijn. Meneer de Hond ken ik als een ander voorbeeld (afkorting handelsonderneming).
Door Anoniem: Ik mis in deze discussie het volgende:
Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Natuurlijk heeft de klant in dit geval een veel groter probleem met de Wbp / AVG. Wat echter niet weg neemt dat de ontvanger, zodra deze zoiets merkt, ook moet handelen, anders kan de ontvanger ook een boete krijgen (die natuurlijk veel lager zal zijn dan die van de klant).Hoe haalt deze klant het in z'n botte hoofd om doodleuk produktiedata met persoonsgegevens over de schutting te gooien?
Is dat niet een veel grotere overtreding van deze wet en/of de geest daarvan dan welke actie van de ontvanger dan ook?
Door Anoniem:Waar ik me veel meer zorgen om maak is het representatief zijn van testdata als dit geen live data is.
Om maar een simpel voorbeeldje te noemen: je kunt wel verhaspelde namen of willekeurige tekens gebruiken als testdata
maar dan kom je ook nooit de bug tegen die we een aantal jaren geleden in het personeelssysteem hadden, waarbij
de hele boel op zijn bek ging van de naam 't Hart.
(programmeurs snappen wel hoe dat kan gebeuren)
In de ideale wereld is van te voren duidelijk hoe alle input en output precies gestructureerd is. Als dat zo is, kunnen ook gemakkelijk anonieme testcases gemaakt worden, zodat ook alle randgevallen worden getest.Om maar een simpel voorbeeldje te noemen: je kunt wel verhaspelde namen of willekeurige tekens gebruiken als testdata
maar dan kom je ook nooit de bug tegen die we een aantal jaren geleden in het personeelssysteem hadden, waarbij
de hele boel op zijn bek ging van de naam 't Hart.
(programmeurs snappen wel hoe dat kan gebeuren)
In de praktijk is dit vaak niet mogelijk (tijd/geld/...) en worden dus andere methodes gebruikt (zoals productiedata in een testomgeving). Wettelijk gezien natuurlijk niet toegestaan (als het persoonsgegevens zijn), maar gebeurt toch. Alhoewel ook dat geen garantie dat het systeem dan goed functioneert. Als in dit voorbeeld de naam 't Hart niet in de huidige productiedata zit, maar pas later wordt toegevoegd als het systeem al live is, heeft ook de test met "echte" data voor geen meter geholpen.
26-01-2018, 14:06 door
karma4
Door Anoniem: ... In de ideale wereld is van te voren duidelijk hoe alle input en output precies gestructureerd is. Als dat zo is, kunnen ook gemakkelijk anonieme testcases gemaakt worden, zodat ook alle randgevallen worden getest. ...
Nope dat dogma is te beperkt, niet de echte wereld. Dat vasthouden aan de beperkte eigen wereld is een bron van problemen ofwel misvattingen met desinformatie. Om je een voorbeeld te geven:
https://www.paloaltonetworks.com/content/dam/pan/en_US/assets/pdf/datasheets/logging-service-privacy.pdf
Dat gaat om echt productie data met echte persoonsgegevens. Allemaal gestructureerd gegevens, nog beperkt er ontbreekt de middleware met applicaties. Geef eens aan hoe je zoiets van te voren voorspelbaar maakt. Het gaat er juist om dat je datgene wat voorspelbaar normaal en acceptabel is er uit te halen zodat je op een behapbare hoeveelheid abnormaliteiten komt die niet acceptabel zijn. Dit heeft niet eens met tijd/geld te maken het is de aard van de problematiek.
26-01-2018, 15:11 door
Krakatau
Door Anoniem: waarbij de hele boel op zijn bek ging van de naam 't Hart.
(programmeurs snappen wel hoe dat kan gebeuren)
(programmeurs snappen wel hoe dat kan gebeuren)
Je moet je afvragen wat de kwaliteit van je programmeertaal is, als je met een niet escaped single quote de hele zaak kan laten crashen. Ik kan me eigenlijk geen programmeertaal voorstellen waarbij dat zou kunnen gebeuren. Of wacht, natuurlijk wel! We hebben het over PHP! Niet?
26-01-2018, 15:17 door
Krakatau
Door Arnoud Engelfriet: Goede testdata is daarbij van belang, maar is vaak moeilijk te krijgen. Daarom zie je regelmatig dat er toch met productiedata wordt getest, dat is dan de enige bron van een grote hoeveelheid uiteenlopende data waarmee genoeg aspecten getest kunnen worden.
Mocht dat echt niet anders kunnen dan zou men die productiedata voor gebruik kunnen anonimiseren? Toch? Met behoud van de uiteenlopendheid van die data, zodat er voldoende aspecten getest kunnen worden. Beter nog is om generative testing tools te gebruiken, waarmee automatisch zeer veel en (zeer) uiteenlopende testdata worden gegenereerd.
26-01-2018, 18:06 door
karma4
Door Krakatau:
..
. Beter nog is om generative testing tools te gebruiken, waarmee automatisch zeer veel en (zeer) uiteenlopende testdata worden gegenereerd.
Dat laatste idee van automatisch blackbox testen is onhaalbaar denk aan de ! functie !...
. Beter nog is om generative testing tools te gebruiken, waarmee automatisch zeer veel en (zeer) uiteenlopende testdata worden gegenereerd.
Een beetje omgeving met wat variabele mogelijkheden vliegt wat mogelijkheden ontzettend snel uit de bocht. Dat was in de IT oudheid een basis als kennis waarom dat zo is. Die basis lijkt verloren te gaan, geen wonder al die ICT project faals.
Zeer schokkend is dat projectmanagers de open productieverbindingen externe koppelingen zo inzetten bij eigen testen.
Het gaat gewoonlijk niet meer om het standalone single machine gebeuren. Je koppelt hele netwerken waarover de informatie gaat.
26-01-2018, 20:09 door
Krakatau
Door karma4:
Door Krakatau:
..
. Beter nog is om generative testing tools te gebruiken, waarmee automatisch zeer veel en (zeer) uiteenlopende testdata worden gegenereerd.
Dat laatste idee van automatisch blackbox testen is onhaalbaar denk aan de ! functie !...
. Beter nog is om generative testing tools te gebruiken, waarmee automatisch zeer veel en (zeer) uiteenlopende testdata worden gegenereerd.
Natuurlijk is dat met productiedata wel haalbaar... NOT...
Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
27-01-2018, 13:15 door
Krakatau
Door Krakatau: Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
En omdat het gratis is zal in de praktijk dat aantal groot zijn.
28-01-2018, 08:46 door
karma4
Door Krakatau:
Natuurlijk is dat met productiedata wel haalbaar... NOT...
Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
Natuurlijk is dat met productiedata wel haalbaar... NOT...
Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
Zomaar wat willekeurige gevallen opvoeren en dat als het bewijs hanteren dat de software goed is?
Het gaat om onderlinge afhankelijkheden met grenzen/kantelpunten. Met zoiets willekeurig opvoeren is het prutswerk.
Dan weet je zekere dat je een onwerkbare situatie aflevert. Ik zie de faal met het feest projectteam want productie.
Genoeg van dat soort praktijkervaringen meegemaakt.
Een van de recentere was inderdaad de houding wij weten alles beter en onze verzonnen testen geven de werkelijkheid oor de gebruikers. De koppeling uitgerold en na een maandje uitgezet om alles opnieuw te bouwen waarbij regelmatig invoer uit prod gevraagd werd die we wel onherkenbaar maakten. Uiteindelijk na 6 maanden iets wat acceptabel was (nog veel te verbeteren). Gelukkkig bleef de data intern al was het met de nodige externen.
Wil je testen goed doen, verdiep je dan in : https://www.istqb.org/
Let op het model base testen gaat over het testproces zelf niet over het testen met big data risicomodellen. Dat zijn compleet andere werelden als is het gebruikte woord model het zelfde.
28-01-2018, 13:47 door
Krakatau
Door karma4:
Zomaar wat willekeurige gevallen opvoeren en dat als het bewijs hanteren dat de software goed is?
Door Krakatau:
Natuurlijk is dat met productiedata wel haalbaar... NOT...
Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
Natuurlijk is dat met productiedata wel haalbaar... NOT...
Het doel van generatieve testing is niet om alle mogelijke invoeren af te werken. Een aantal random waarden uit het hele bereik van de invoer is al prima. En wie heeft gezegd dat het (alleen) om black box testen gaat?
Zomaar wat willekeurige gevallen opvoeren en dat als het bewijs hanteren dat de software goed is?
Nee, natuurlijk niet zomaar, met (waar nodig) op maat geschreven generators. Je weet er echt helemaal niets van, nietwaar?
https://en.wikipedia.org/wiki/QuickCheck
Door Krakatau: ....
Nee, natuurlijk niet zomaar, met (waar nodig) op maat geschreven generators. Je weet er echt helemaal niets van, nietwaar?
Ik geef je de praktijkvoorbeelden waar het faalt omdat er te veel rond lopen die er niets van snappen. Dan kom jij met te kort schietend vinkenlijstje. Duidelijk niet bij istqb gekeken.Nee, natuurlijk niet zomaar, met (waar nodig) op maat geschreven generators. Je weet er echt helemaal niets van, nietwaar?
Even kort naar dat vinkenlijstje gekeken. De programmeur kan wat cases ofwel testgevallen opvoeren waarvan hij geloofd dat ze goed en belangrijk zijn. Dat is de faal vanaf bouw.
Door karma4:
Door Krakatau: ....
Nee, natuurlijk niet zomaar, met (waar nodig) op maat geschreven generators. Je weet er echt helemaal niets van, nietwaar?
Ik geef je de praktijkvoorbeelden waar het faalt omdat er te veel rond lopen die er niets van snappen. Dan kom jij met te kort schietend vinkenlijstje. Duidelijk niet bij istqb gekeken.Nee, natuurlijk niet zomaar, met (waar nodig) op maat geschreven generators. Je weet er echt helemaal niets van, nietwaar?
Nee dank je. Verhaaltjes over het 'certificeren' van software testers vind ik eigenlijk alleen maar lachwekkend. Dat soort dingen zijn vooral bedoeld om managers het idee te geven dat ze er een vinger achter hebben gekregen en het proces in de hand hebben. Natuurlijk is dat niet het geval, omdat ze gewoon te gierig zijn om goede mensen aan te nemen. Zonder goede mensen kan je je helemaal suf certificeren, het zal niet helpen.
Door karma4: Even kort naar dat vinkenlijstje gekeken. De programmeur kan wat cases ofwel testgevallen opvoeren waarvan hij geloofd dat ze goed en belangrijk zijn. Dat is de faal vanaf bouw.
Nee, de programmeur gaat uit van wat een programma moet doen en laat voor de logische eigenschappen van de software automatisch testen genereren. Mits je een goede programmeur hebt, resulteert dit in een foutloos programma. Maar wat wijd ik uit, dat snap jij toch niet, als papieren tijger.
01-02-2018, 09:36 door
Krakatau
Door Krakatau: Maar wat wijd ik uit, dat snap jij toch niet, als papieren tijger.
Excuseer: wat weid ik uit...
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
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?