Nieuw datalek Utrechtse Jeugdzorg door online zetten testsite
De Utrechtse Jeugdzorg heeft opnieuw met een datalek te maken gekregen, nadat een testwebsite met niet geanonimiseerde beslissingen in tuchtzaken online werd gezet. Dat heeft minister De Jonge van Volksgezondheid laten weten op Kamervragen van D66.
Het datalek deed zich voor bij Stichting Kwaliteitsregister Jeugd (SKJ). Dit is het beroepsregister voor professionals in de jeugdsector, dat zich bezighoudt met (her)registratie, tuchtrecht en scholing. De stichting is een kennisbank aan het ontwikkelen die toegang tot alle geanonimiseerde beslissingen in SKJ-tuchtzaken geeft. De testwebsite die hiervoor wordt gemaakt is per ongeluk online gezet. Op deze testwebsite stonden niet geanonimiseerde beslissingen in SKJ-tuchtzaken.
Volgens de stichting hebben enkele bezoekers niet geanonimiseerde beslissingen ingezien. In totaal waren 34 niet geanonimiseerde beslissingen online toegankelijk. Onlangs kreeg Bureau Jeugdzorg Utrecht met een datalek te maken waardoor vertrouwelijke dossiers van duizenden kinderen in handen van onbevoegden kwamen. Het datalek ontstond omdat Jeugdzorg een domeinnaam had laten verlopen waar nog steeds allerlei vertrouwelijke dossiers naar toe werden gestuurd. Deze domeinnaam werd door klokkenluiders geregistreerd, die zo de documenten ontvingen.
Minister De Jonge heeft Jeugdzorg Nederland gevraagd om dringend het belang van goede gegevensbescherming bij hun leden onder de aandacht te brengen en hen te adviseren om hun eigen gegevensbescherming te evalueren, risico’s in kaart te brengen - en op basis van gevonden risico's - aanvullende maatregelen te nemen. Volgens de minister onderzoekt Jeugdzorg Nederland welke extra maatregelen nodig zijn om het informatiebeveiligingsniveau in de sector te verbeteren.
Daarnaast voert de Inspectie Gezondheidszorg en Jeugd dit jaar bij aanbieders in het jeugddomein een onderzoek uit dat bestaat uit een quick scan, gevolgd door verdiepend toezicht bij enkele instellingen. Verder laat De Jonge bij een aantal jeugdzorginstellingen pentesten uitvoeren om inzicht te krijgen in de risico's en kwetsbaarheden van de systemen van de jeugdzorginstellingen om hiermee de informatiebeveiliging binnen de jeugdzorg naar een hoger niveau te tillen.
Ze hebben aanvankelijk zelfs niet eens contact opgenomen met Google hieromtrent, waardoor de beslissingen nog gewoon met Google opzoekbaar waren (in hun cache).
Degenen die de site bouwen beschikken óf alleen over testdata, die volledig fictief zijn met als namen alleen "persoon a", "instelling b" e.d. of over de netjes geschoonde bestanden, zoals die uiteindelijk gebruikt worden.
Dus moet deze stichting nou zichzelf gaan berispen wegens laakbaar onprofessioneel gedrag?
Exact mijn gedachte. Hoe kan het in vredesnaam dat er uberhaupt niet geanoniemiseerde data gebruikt is bij een omgeving, zeker bij een "test" omgeving, terwijl het nooit de bedoeling is geweest dat die online ging. Ze zijn dus gaan developpen met live data. Dat is al een doodzonde. Tijdens een development proces gaat er van alles mis, dat is waarom je aam het ontwikkelen bent, omdat het nog vol zit met (ontwerp-)fouten, bugs, en je nog moet testen of je systeem aan alle voorwaarden voldoet. Dat ze daar niet geanonimiseerde gegevens gebruiken is redelijk incompetent.
De ene groep die zich wel degelijk bewust is van de risico's wordt ondergraven door een andere groep dat omdat het test het toch allemaal niets uitmaakt.
Hier lijkt er nog iets bij te spelen. Om snel iets te leveren agile scrum is er voor echte uitspraken gegaan. Het moeten wachten als bij een waterval dat de anonimisatie rond is kost tijd. Dat een eerdere afhankelijkheid eerst ingelost moet zijn hoort bij de planning, dan duurt het maar langer (hogere kosten).
Het is niet enkel code wat een leefcyclus doorloopt maar ook data. Voor velen is dat onderscheid te hoog gegrepen
Een achterliggend punt, belangrijk bij gegevensbescherming en andere kwesties. Alleen maar de argumentatie dat en bepaalde instelling/bevoegdheid nodig zou zijn wegens een ander kwaad is niet genoeg. De organisatie heeft ook nog 24x7x365 te bewijzen dat de macht bij hen in goede handen is. Anders raak je van de regen in de drup, of in mooi Engels, out of the frying pan, into the fire.
Een grote verbetering van de GDPR ten aanzien van de eerdere 95/46/EC is dat het veel meer nadruk legt op de verantwoordingsplicht. Houd je je aan goed beheer van de toevertrouwde gegevens? Mooi, laat maar zien.
Dit is inderdaad wel een goed moment om te gaan handhaven. Het is niet de eerste keer en lijkt een cultuurprobleem te zijn. De Autoriteit Persoonsgegevens heeft een aantal mogelijkheden om hier in te grijpen. Onder anderen:
1. Een order om de gegevensbescherming op orde te brengen met een specifieke deadline (artikel 58 lid 2d GDPR).
2 Een order om de datalekken bij de data subjects te melden (artikel 58 lid 2d GDPR).
3. Een tijdelijke beperking van verwerking van de gegevens (artikel 58 lid 2f GDPR). Een dergelijke beperking zou bijvoorbeeld de vorm aan kunnen nemen dat men toestemming van de AP moet vragen voor veranderingen in de wijze van verwerking.
4. Diverse mogelijkheden voor onderzoek / verscherpt toezicht (artikel 58 lid 1).
Onderschat niet hoeveel mensen pas weten te beoordelen of een voor hun gebouwde applicatie goed werkt als de gegevens die ze voor zich zien herkenbaar zijn. Het soort abstractievermogen dat automatiseerders in staat stelt om hun werk te doen ontbreekt bij flinke groepen mensen, die hangen hun begrip en overzicht aan concrete, echte situaties op. Die kunnen niet goed uit de voeten met dossiers met teksten als "Lorem ipsum dolor sit amet..." of "Rabarber rabarber rabarber...".
Of dit hier de verklaring is weet ik niet, maar het is een mogelijkheid. Hoe dan ook is de projectleiding in gebreke gebleven bij het voorkomen van deze situatie.
De ene groep die zich wel degelijk bewust is van de risico's wordt ondergraven door een andere groep dat omdat het test het toch allemaal niets uitmaakt.
Hier lijkt er nog iets bij te spelen. Om snel iets te leveren agile scrum is er voor echte uitspraken gegaan. Het moeten wachten als bij een waterval dat de anonimisatie rond is kost tijd. Dat een eerdere afhankelijkheid eerst ingelost moet zijn hoort bij de planning, dan duurt het maar langer (hogere kosten).
Het is niet enkel code wat een leefcyclus doorloopt maar ook data. Voor velen is dat onderscheid te hoog gegrepen
Wat is je onderbouwing daarbij?
De mijne is vrij eenvoudig. De benodigde en gevraagde rappotages waarbij persoonsgegevens betrokken zijn kunnen pas gemaakt worden NADAT er zinnige ofwel echre productiegegevens beschikbaar zijn. Voor die tijd weet de opdrachtgever niet welke vragen hij zou moeten of kunnen stellen. Het beruchte kip en ei verhaal. Met een leggende kip heb je snel eieren.
Ga je naar ML AI dan moet je met productiedata in ontwikkeling werken. Alleen wel de ongewenste features niet beschikbaar stellen bij modelling terwijl die wel in de api bij exploitatie mee mogen.
Let wel ik heb aangetekend dat de anonimisatie van de dossiers eerst afgerond had moeten zijn. Zoals hierboven anoniem 09:21 zinvolle data is vaak nodig.
Dan moet je voor de beveiliging dezelfde eisen instellen en inrichten als voor productie data. Dat is nog een horde die genomen moet worden.
Nog genoeg problemen met data lakes dwh's op dit vlak. Dat is wat anders dan hoe het zou moeten gaan.
Ik ben benieuwd naar je uitleg.
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
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.
