GGZ-instellingen laten gegevens patiënten uitlekken

Twee GGZ-instellingen hebben de gegevens van circa 8500 patiënten laten uitlekken. De gegevens stonden op een slecht beveiligde ontwikkelingsserver. Het ging onder meer om namen, adressen, geboortedata en burgerservicenummers.

Het beveiligingslek werd ontdekt door een groep die zichzelf het Genootschap van Hackende Huisvrouwen noemt en die het aan NU.nl rapporteerde.

Van circa 8500 patiënten waren onder meer naam, adres, geboortedatum, het zeer fraudegevoelige burgerservicenummer en niet nader toegelichte gegevens voor uitwisseling via het Elektronisch Patiëntendossier toegankelijk. Alle getroffenen waren patiënten in de geestelijke gezondheidszorg.

De gegevens stonden op een slecht beveiligde ontwikkelingsserver, waarop ook gegevens van een aantal andere instellingen te zien waren. Daarbij ging het om logingegevens van medewerkers, maar niet om patiëntgegevens. Van één zorginstelling waren voorgeschreven recepten in te zien, maar die waren niet te herleiden naar een persoon. De verantwoordelijke automatiseerder, FarMedvisie, heeft het beveiligingsprobleem inmiddels verholpen.

Reacties (47)

[mrfreeze12345]

Het gaat trouwens o.a. om GGZ Noord-Holland-Noord:
http://www.ggz-nhn.nl/Nie...ke-gezondheidszorg-gelekt

[Verwijderd]

Ik ben benieuwd naar welke 2 GGZ-instellingen gegevens hebben laten uitlekken.

[E-Rick]

Hier staan de klanten van FarMedvisie: http://www.farmedvisie.nl/index.php?content_id=19
en daar staan niet zo veel GGZ-instellingen bij.

[Verwijderd]

Waarom zou je echte gegevens gebruiken op een ontwikkelingsserver? Kleine moeite om een database met dummy data te maken lijkt me.

[Verwijderd]

Een kleine moeite om dummy data van 8500 personen te generen? Dat is een verdomd groot karwei!

NB: Je dummy data wil je niet met een computer genereren. Want dan weet je dat alles perfect is ingevuld. Je wilt juist tegen met handmatig ingevulde data, omdat er dan allerlei rare bugs naar boven komen, die je anders nooit was tegengekomen.

Helemaal niet zo raar dat ze dus echte data gebruiken, want dat is de ultieme test omgeving. Maar wel fout natuurlijk dat het dan zo slecht beveiligd is. Verder hadden ze natuurlijk even de namen en service nummers kunnen anonymiseren.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:22]

[jwarmer]

dat het moeite kost is geen reden om geen dummy data te gebruiken. Alle beveiliging en privacy kost moeite. Privacy gevoelige data hoort per definitie niet op ontwikkelservers te staan.

[Verwijderd]

Lees de laatste zin eens...

[stresstak]

Een kleine moeite om dummy data van 8500 personen te generen? Dat is een verdomd groot karwei!

NB: Je dummy data wil je niet met een computer genereren. Want dan weet je dat alles perfect is ingevuld.

Een deel van een database shuffle-en. Her en der wat data verminken of veranderen, en het resultaat als dummy gebruiken. Gaat heel goed.

[Wim-Bart]

In principe mag je gewoon geen echte data gebruiken bij test en ontwikkeling, echte data wordt pas valide wanneer je functionele testen gaat doen met gebruikers waarbij het systeem al onderdeel uit maakt van de omgeving van de klant.

Ten eerste wil ik niet dat een niet gecertificeerd persoon welke de waarde van de data kan inschatten inzage heeft in mijn persoonlijke gegevens. Het zou toch van de zotte zijn dat alle medische en overige informatie over jou bij een conculega bedrijf ligt en dat mensen daar inzage in hebben.

Daarnaast voldoen de eigenlijke gebruikers aan een aantal verplichtingen met betrekking tot geheimhouding etc. en een ontwikkelaar/tester per definitie niet.

Daarnaast is er ook nog zo iets als gebruik van je persoonlijke gegevens. Een software bedrijf gebruikt jouw gegevens voor ontwikkeling/testen van een product waar ze geld aan verdienen. Persoonlijk ben ik van mening dat ik dan ook recht heb op een gedeelte van de opbrengst. Stel je zit in een testset van 10.000 records. Het bedrijf verdiend 1.000.000 euro met verkoop van het product, dat wil zeggen dat ik recht heb op 100 euro, want dat zijn die gegevens waard binnen de testset. Argumenten dat het minder moet zijn zijn voor mij niet valide want dan hadden ze me maar uit de testset moeten gooien.

Overigens is het annonimiseren van een database met zinnige data totaal geen probleem, het is vrij intensief en kan geautomatiseerd plaatsvinden. Het enige wat moeilijk te anonimiseren is zijn adressen. Telefoonnummers (met behoud van kengetal), namen, sofi nummers, bankrekeningnummers, etc. etc. zijn binnen een database te shuffelen. Zolang er maar geen directe koppeling is tussen adres - telefoon - sofinummer - bankrekeningnummer is het goed. Geboorteplaatsen en -datum's zijn ook makkelijk te annonimiseren. dus ik zie het probleem niet.

[WhiteDog]

Je hebt gewoon gelijk, Bedrijf X gebruikt hier gevoelige data van een zorginstelling om een product mee te ontwikkelen. Dat lijkt me gewoon een schending van je privacy en het overtreden van een aantal wetten.

[Alcmaria]

Als wij het hier op het werk in ons hoofd krijgen (een bank!) om produktiedata op een Test of Ontwikkelserver te zetten, kunnen we net zo goed direct de boel sluiten en zijn we zo onze banklicentie kwijt.

Je gebruikt NOOIT proddata op een ontwikkelomgeving... en al helemaal niet als het om gevoelige info gaat.

Dan kan je zeggen "ja maar soms is het nodig voor testen"... dan blijft het antwoord NEE.. dan verzin je maar een list.

[Verwijderd]

Je wilt zeggen dat je handmatig een dummyset gaat aanmaken?

Bij een bank heb je vaak klanten, rekeningen, rekeningsoorten, medewerkers, transacties, leningen en zo nog een aantal tabellen. Dat is zo enorm veel data dat het amper te vullen is.

Wat wel een optie is, is om de productie data te gebruiken, de foreign keys ongemoeid te laten en alle gegevens die tot personen kunnen herleiden (NAW-gegevens) te vervangen door dummy-data.

[__fred__]

Euh, wij hebben op onze ontwikkelomgevingen ook dummy data, en de staging omgeving zit in dezelfde beveiligingszone als de productieomgeving. De staging omgeving wordt alleen maar opgebouwd vanuit productie, op de dag voor de migratie van productie, voor het testen van de conversiescripts en de geconverteerde kopie van productie en daarna weer afgebouwd. Test- en development draaien op de dummy data.

En dan hebben we niet eens medische gegevens in de DB. Lijkt me standaard practice imho.

[Jasper Janssen]

Dev/staging/production is een omgeving die lang niet ieder bedrijf heeft. Daarvoor moet je een zekere minimum grootte hebben.

[Batje4]

Als opdrachtgever zou je dat als eis mee moeten nemen in je leveranciersselectie, zeker bij privacy gevoelige data volgens Wet Bescherming Persoonsgegevens II. De wet is hier ook van toepassing: medische gegevens zijn hoogste categorie.

Dus elke leverancier die niet in staat is tot OTAP / Dev-staging/prod valt imho af.

Ik heb zelf jarenlang conversies gedraaid. Opties die we hadden:
- op een virtual, lokaal, zonder internetverbinding.
- via een subnet van het LAN, zonder toegang van buitenaf.
- sommige omgevingen zijn complex en niet eenvoudig na te bouwen: dan via een remote sessie (RDT, Citrix) op een in een DMZ geplaatste ontwikkeldesktop met toegang tot de omgeving, inclusief token.

Nogmaals, elke leverancier die niet in staat is te voldoen aan passende beveiligingsmaatregelen, ook voor OTAP, valt af. Wat passend is, is aan de opdrachtgever om te bepalen in de requirements. De opdrachtgever kan de oplossing altijd laten valideren door een ingehuurde expert. Ook daarvoor zou een opdrachtgever capaciteit moeten inhuren.

[sjongenelen]

tjsah, alhoewel dit niet direct opgaat voor de GGZ, had een -door experts- centraal beheerd systeem dit kunnen voorkomen. Ik heb het dan natuurlijk over het EPD.

Dit zal zeker niet de laatste schandelijke fout zijn in de zorgsector, helaas.

@wnoise92 dit heeft natuurlijk niets te maken met overheid, maar met een private instelling / bedrijf

[Reactie gewijzigd door sjongenelen op 23 juli 2024 04:22]

[Verwijderd]

Het EPD waar jij het over had was een koppeling van lokale EPDs en zou dit probleem dus niet verhelpen. Iedereen blijft dan het eigen systeem houden maar die communiceren via een landelijk schakelpunt. Dit zou het risico juist vergroten omdat de systemen aangesloten moeten worden op de buitenwereld.

[Batje4]

Tja, als je ervan uitgaat dat er geen toelatingseisen zijn.
Gelukkig zijn die er, en worden ze gehandhaafd. Zie hier het commentaar van het Servicecentrum Zorgcommunicatie:

Servicecentrum Zorgcommunicatie 1 juni 2012 om 16:58

In de pers wordt gesteld dat EPD gegevens van een tweetal GGZ instellingen gelekt zijn door een hack op de applicatie van het bedrijf FarMedvisie. De link wordt gelegd met de doorstart van het LSP in gewijzigde vorm. Deze link is onterecht. FarMedvisie is momenteel niet gekoppeld aan het LSP en heeft nooit daadwerkelijke patiëntgegevens uitgewisseld over het LSP. Wel is FarMedvisie in voorbereiding daarop.

Daartoe worden testen en kwalificatietrajecten doorlopen, waarbij testgegevens worden uitgewisseld. In 2007 is FarMedvisie gekwalificeerd tegen de toen geldende kwailiteits-eisen. Momenteel worden zij geherkwalificeerd tegen de huidige kwaliteits-eisen, maar dit traject is niet afgerond. Voordat aan deze zware eisen is voldaan, is het klanten van FarMedvisie niet toegestaan gegevens uit te wisselen via het LSP.

Bron: http://www.hpdetijd.nl/20...overheid-laat-ons-hacken/

[Stoney3K]

Omdat de betrokkenen nog niet zijn geïnformeerd en het een kwetsbare groep mensen betreft met een hulpvraag in de geestelijke gezondheidszorg, heeft NU.nl ervoor gekozen de namen van de zorginstellingen nog niet naar buiten te brengen.

Leuk is dat. Ik sta zelf nog ergens bij een aantal GGZ-instellingen in het dossier en kan dus nu ook niet uitvissen of ik (misschien) tot één van de gedupeerden behoor.

Mijn NAW-gegevens en BSN maak ik me niet zo'n zorgen om, die moet ik als eigen ondernemer toch al publiceren, maar mijn medische achtergrondgegevens hou ik toch liever privé.

[ArcticWolf]

idem
liever niet dat m'n dossiers gewoon rondzwerven op het internet wat doen die dossiers op een ontwikkelingsserver? echt kansloos dit

dankje E-Rick, mijn instelling zit er iig niet bij

[Reactie gewijzigd door ArcticWolf op 23 juli 2024 04:22]

[E-Rick]

zie mijn reply hier boven

[gekkie]

Het meest verontrustende vind ik nog dat er nogal wat waarde aan een burgerservicenummer wordt gehangen, wat in principe niet geheim zou moeten hoeven worden gehouden (het staat immers ook open en bloot op je rijbewijs en paspoort).

Maar kennelijk is alleen dit nummer vaak afdoende omdat bedrijven cq de overheid het de burger "makkelijk" wil maken om zaken te regelen.

[Verwijderd]

Misschien is het al geroepen, maar wat doet een ontwikkelserver dan aan een blijkbaar publiekelijk toegankelijk netwerk?

Misschien simplistisch gedacht, maar als je dan om welke reden dan ook met prod-data moet gaan testen, zorg er dan voor dat het op een geisoleerde infra draait.

Of zie ik iets over het hoofd ?

[casper956]

Weer zo'n ICT blunder m.b.t. lekken. Door goed te testen met de instellingen/configuratie had men dit eventueel kunnen voorkomen.
Een ontwikkel server zou ik persoonlijk niet aan de publieke netwerk hangen.

[Ongepast]

Genootschap van Hackende Huisvrouwen.
Klinkt beter dan Anonymous; Internet Hate Machine.
En wie zei nou dat persoonsgegevens altijd veilig zijn bij de overheid? Lang leve het EPD.

[Verwijderd]

Mét een EPD was dit waarschijnlijk niet voorgekomen.... Daar was namelijk bij voorbaat zoveel heibel over, dat alles driedubbel gecontroleerd wordt op de veiligheid.
Het probleem is nú juist dat zorginstellingen zelf individueel allerlei kleine bedrijfjes gaan inschakelen om de software te schrijven, i.p.v. dat dit integraal in een groot process wordt gedaan. En bij die kleinschalige projectjes, zal juist de veiligheid makkelijker vergeten worden.