Gemeente Amersfoort: gegevens inwoners gelekt uit testomgeving
De gemeente Amersfoort heeft opnieuw te maken gekregen met een datalek waarbij gegevens van inwoners zijn gelekt. Het gaat om de persoonsgegevens van 24 huidige en voormalige inwoners, waaronder naam, geslacht, burgerservicenummer en geboortedatum. "Bij een voormalig softwareleverancier van ons belastingsysteem is sprake van een beveiligingsincident", zo laat het college van burgemeester en wethouders in een brief aan de gemeenteraad weten.
"Het gaat om gegevens uit een testomgeving van de voormalig leverancier, waarin naast voornamelijk fictieve persoonsgegevens ook bestaande persoonsgegevens staan. Dit was nodig om realistische tests uit te voeren voor de werking van het systeem", voegt het college toe (pdf). Aanvallers wisten door middel van een 'zwakke plek in de software' toegang tot de testomgeving en daarop aanwezige gegevens te krijgen.
De gemeente heeft de getroffen inwoners, waarvan er vier inmiddels zijn overleden, ingelicht. Tevens is er een voorlopige melding bij de Autoriteit Persoonsgegevens gedaan. Het contract met de betreffende leverancier was al beëindigd en loopt in februari af. "Op dat moment wordt alle data bij deze leverancier verwijderd. Er is nauw contact met de softwareleverancier over het vervolg van dit beveiligingsincident", aldus het college. Vorige maand werd bekend dat Amersfoort de gegevens van 100.000 inwoners had gelekt.
Oefendata (of gepseudonimseerde) data levert helaas niet altijd het gewenste resultaat bij het testen.
Werkelijke klantdata zal altijd onvoorspelbaarder en weerbarstiger zijn dat oefendata. En dus fouten in de software vinden die die oefendata niet zien.
Dat zou onderzocht kunnen worden, analoog, voor de veiligheid.
Oefendata (of gepseudonimseerde) data levert helaas niet altijd het gewenste resultaat bij het testen.
Werkelijke klantdata zal altijd onvoorspelbaarder en weerbarstiger zijn dat oefendata. En dus fouten in de software vinden die die oefendata niet zien.
Goed anonimiseren in een testomgeving zonder database connecties stuk te maken is inderdaad erg lastig, en als dit niet goed doordacht gebeurt levert het veel fase positives op met test werk. Vooral met veel gekoppelde applicaties .
Maar we zien dat het ondanks de uitdagingen een must is, want plenty it leveranciers zitten hier ook in te wroeten.
Ik ben geen jurist, maar schadeclaim lijkt me kansrijk
Dus wat maakt dat een test niet realistisch zou zijn als gegevens fictief of geanonimiseerd zijn? Toen ik in het verleden als ontwikkelaar werkte heb ik meerdere keren bij gebruikerstests mensen meegemaakt die erg slecht in staat bleken om voor hun bekende situaties nog te overzien als er met fictieve namen en andere identificerende gegevens werd gewerkt. Die kenden concrete gevallen die problematisch waren in het oude systeem op hun duimpje, wat de reden was om die gevallen in de testdata te verwerken, maar als je de identificerende gegevens veranderde waren ze los. Dan konden ze niet meer goed bij al die kennis erover die ze wel degelijk hadden, en dus niet goed testen en oordelen. De concrete identificerende gegevens waren voor hun kennelijk de ingang tot hun eigen kennis. Ik vermoed dat dat erop neerkomt dat die mensen vergaand concreet en nagenoeg niet abstract denken: alles moet aan echte, voor hun herkenbare situaties gekoppeld zijn. En dat zijn wel degenen die het systeem gaan gebruiken en die moeten beoordelen of het voor hun goed werkt.
Als je ze beperkt vindt overkomen: ja, die beperking hebben ze, en ik zelf zou weer bij lange na niet zo foutloos als zij kunnen werken in hun soort werk, want ik denk juist wel in abstracties en voor mij zijn die concrete gevallen voorbeelden van wat voor kan komen. Ik zou makkelijk gevallen door elkaar gaan halen, op een manier die in het bouwen van software niet erg is omdat al die varianten in de programmacode samenkomen, ze moeten tenslotte worden ondersteund, maar in klantcontacten en de bijbehorende administratie zou ik makkelijk fouten maken. Iedereen heeft talenten en beperkingen, en we mogen blij zijn dat we niet allemaal precies dezelfde hebben maar juist enorme divers zijn, daarom kunnen we als samenleving zoveel.
Ik weet niet of wat ik beschreef is wat hier bedoeld wordt, maar het lijkt me zeker een mogelijkheid. En ik weet er geen oplossing voor; wat ik hierboven beschrijf en het gebruik van fictieve of geanonimiseerde testdata zijn twee volkomen legitieme belangen die recht tegenover elkaar staan en waarvan ik niet inzie hoe ze met elkaar te verenigen zijn.
Te stom voor woorden..mogen de getroffenen nu hun bsn wijzigen? Ooh nee dat kan weer niet
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
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?