image

Erasmus MC lekt patiëntgegevens door e-mailblunder

dinsdag 20 maart 2018, 09:29 door Redactie, 19 reacties

Het Erasmus Medisch Centrum heeft gegevens van 46 jonge patiënten door een e-mailblunder gelekt, zo laat de organisatie op de eigen website weten. Het gaat om een nieuwsbrief van de afdeling Kinderinfectieziekten / Immunologie, die is verspreid in een besloten groep van ouders van patiënten en patiënten van 18 jaar en jonger. De mailadressen van de patiënten waren per abuis in de To-adressering terecht gekomen, in plaats van in het BCC-veld.

Het gaat in totaal om 58 e-mailadressen. "Er is sprake van een menselijke vergissing, waar de afdeling zich zeer bezwaard over voelt. Ze weten immers hoe gevoelig de privacy ligt. Dit had niet mogen gebeuren. Met de patiënten is dan ook direct nadat de fout aan het licht kwam, contact opgenomen met excuses", aldus het Erasmus MC. De organisatie stelt verder dat het draaiboek voor het verzenden van nieuwsbrieven is aangepast en er wordt overwogen om bij de lancering van de nieuwe website geen nieuwsbrieven meer van de afdeling per e-mail te versturen.

Reacties (19)
20-03-2018, 09:47 door Anoniem
Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...
20-03-2018, 10:04 door Anoniem
Als de adressen in het verkeerde veld terecht gekomen zijn dan zijn toch alleen de e-mail adressen gelekt?

Nieuwsbrieven zijn sowieso riskant omdat mensen ze geleidelijk gaan vertrouwen en een phishing exemplaar voldoende is om de ontvangens alles open te laten klikken.

Ziekenhuizen moeten gewoon alle e-mail ondertekenen en gevoelige informatie versleutelen en ze moeten een foldertje aan patiënten geven waarin ze uitleggen hoe patiënten hetzelfde kunnen doen.
20-03-2018, 10:57 door Anoniem
Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...

Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?
20-03-2018, 11:05 door Anoniem
Daar heb je speciale software voor waar je expleciet moet aangeven wat waar naar toe moet en hoe. Geloof dat die dingen standaard op BCC ingesteld staan.

Wat dat EMC nu doet naar ik mag aannemen is het prinicpe van All in one omarmen met hun outlook.. maar als er dus wat fout gaat dan is het een schaap met vijf poten zoals nu.

De meeste online software boeren kunnen zo'n programmaatje wel leveren. Kost niet veel. Type maar ik: Nieuwsbrief software, Newsletter software en je vind er zo een hele hoop.
20-03-2018, 12:52 door Anoniem
Door Anoniem: Daar heb je speciale software voor waar je expleciet moet aangeven wat waar naar toe moet en hoe. Geloof dat die dingen standaard op BCC ingesteld staan.

Wat dat EMC nu doet naar ik mag aannemen is het prinicpe van All in one omarmen met hun outlook.. maar als er dus wat fout gaat dan is het een schaap met vijf poten zoals nu.

De meeste online software boeren kunnen zo'n programmaatje wel leveren. Kost niet veel. Type maar ik: Nieuwsbrief software, Newsletter software en je vind er zo een hele hoop.

En hoe reageren die online software boeren als je de woorden 'medisch' , 'jong' en 'patient' in je offerte aanvraag erbij zet ?

Wedden dat we binnen het jaar we hier kunnen betweten dat een ziekenhuis natuurlijk never nooit patienten adressen aan een cloud based mailbrieven boer moet geven, wegens net even een ander foutje dan Cc vc BCC.
20-03-2018, 13:09 door Anoniem
Door Anoniem: Als de adressen in het verkeerde veld terecht gekomen zijn dan zijn toch alleen de e-mail adressen gelekt?

Afhankelijk van het e-mailadres kun je al een hoop gegevens via internet achterhalen. Als het mailadres frank@familierademakers.nl is, dan kom je via WHOIS een aardig eind wie dit is. Dat mag natuurlijk niet gebeuren. Eenzelfde fout werd ooit gemaakt bij Wikileaks, waarbij de e-mailadressen niet in de BCC waren opgenomen, en mensen zagen dat bepaalde mailadressen van Wikileajs mails kregen. Niet handig.

Door Anoniem:Ziekenhuizen moeten gewoon alle e-mail ondertekenen en gevoelige informatie versleutelen en ze moeten een foldertje aan patiënten geven waarin ze uitleggen hoe patiënten hetzelfde kunnen doen.

Het ondertekenen van deze mail had dit probleem niet voorkomen. Ook versleutelen klinkt makkelijker dan het is. Denk aan sleutelbeheer, certificaatbeheer e.d. Het handigst is misschien nog wel een persoonlijke omgeving op een website, waar je via gebruikersnaam en wachtwoord (of nog beter: 2FA) inlogt. Dan voorkom je al het e-mailverkeer. Het enige dat er dan, in hoge nood, uit zou hoeven gaan is "Er staat een 'bericht in uw persoonlijke berichtenbox", vergelijkbaar met de opzet zoals gehanteerd door de Belastingdienst. Maar dat kost een paar duiten aan inrichting, onderhoud etc.
20-03-2018, 13:17 door karma4
Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...
De vraag is wat er hier speelt. Met zo'n kleine groep denk ik aan een bijzondere behandeling.
De naam van de afdeling en de leeftijd doet zoiets vermoeden.
In dat soort gevallen heb je ook praatgroepen en verenigingen van patiënten met het zelfde.
20-03-2018, 13:19 door Anoniem
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Ben je als IT-er dan erg bang voor complexe uitdagingen ? Het is een logische security control, en het is goed te implementeren. Ook kan je via een policy bijvoorbeeld zorgen dat gebruikers helemaal geen CC veld hebben, alleen TO en BCC. De complexiteit vind ik een non-argument.
20-03-2018, 13:21 door Anoniem
De meeste online software boeren kunnen zo'n programmaatje wel leveren. Kost niet veel.

Enige wat zo'n programmatje moet doen is bijvoorbeeld wat registry entries aanpassen/toevoegen, voor de meeste email programma's. Zelf dit uitzoeken, en implementeren, kost waarschijnlijk nog veel minder. Zo ingewikkeld is dit niet, voor een ervaren beheerder.
20-03-2018, 13:22 door Anoniem
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Is dat nou het niveau van ICT vandaag de dag, klagen over dat werk complex is ? Natuurlijk is ICT werk soms complex. Kan je dat niet aan; zoek ander werk.
20-03-2018, 13:59 door Anoniem
Door karma4:
Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...
De vraag is wat er hier speelt. Met zo'n kleine groep denk ik aan een bijzondere behandeling.
De naam van de afdeling en de leeftijd doet zoiets vermoeden.
In dat soort gevallen heb je ook praatgroepen en verenigingen van patiënten met het zelfde.

HIV patiënten. Wellicht via de moeder gekregen. Weet je ook meteen dat die geïnfecteerd is. Al met al niet handig.
20-03-2018, 15:10 door Anoniem
Door Anoniem:
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Is dat nou het niveau van ICT vandaag de dag, klagen over dat werk complex is ? Natuurlijk is ICT werk soms complex. Kan je dat niet aan; zoek ander werk.

Gut, in plaats van thuisnerds opeeens wannabe managers hier .
Geen benul, wel grote bek dat iets maar even moet. Natuurlijk tussendoor.

In verhouding tot de use case (incidentele nieuwsbrief naar enkele tientallen mensen) is de feature erg veel werk.
En _natuurlijk_ kun je het niet globaal maken, want het is op de afdeling wel heel normaal om Cc te gebruiken als je een paar mensen in de loop wilt houden.
Dus moet de 'geen Cc' feature alleen werken voor de nieuwsbrief. Altijd goed herkenbaar dat het 'de' nieuwsbrief is.

Maar jij als manager gaat voor deze vraag natuurlijk zonder problemen een vrij seniore IT engineer een week of twee aan het werk zetten . Er zijn vast geen andere prioriteiten, en je hebt vast genoeg budget .

Tenminste - als het te bouwen is de algemene mailomgeving van het ziekenhuis - daar moet je echt geen storing maken met een of andere hack rule check.

(het zou me weinig verbazen als de vraag voor een 'algemene nieuwsbrieven server' al bij IT in de bak ligt, en tussendoor de afdeling maar gewoon is gaan Bcc'en omdat die server er maar niet komt. Of omdat het IT aanvraag proces voor een nieuwsbrief onvindbaar/onmogelijk is.)

Er _kan_ heel veel met IT. Genoeg mensen/budget/tijd om het te doen is het meestal het probleem.
En vanzelfsprekend gaat degene die iets wil niet eindeloos lang wachten maar regelt dan zelf wel iets - webservertje met een hostertje (of bij amazon), iedereen blij totdat het mis gaat, en dan weten we hier natuurlijk precies dat ze het anders hadden moeten doen.
20-03-2018, 15:11 door Briolet
Door Anoniem: Als de adressen in het verkeerde veld terecht gekomen zijn dan zijn toch alleen de e-mail adressen gelekt?

Ja, maar de inhoud van de mail koppelt wel een medisch feit aan deze e-mail adressen. Er zijn 12 e-mail adressen meer dan patiënten. Dat zijn waarschijnlijk de ouders. Zij worden ook gekoppeld aan die brief.

Enkele van de ontvangers zullen elkaar ook al in de wachtkamer tegen gekomen zijn. Dat is ook een 'datalek'. (:-
20-03-2018, 16:43 door Anoniem
Door Anoniem:
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Is dat nou het niveau van ICT vandaag de dag, klagen over dat werk complex is ? Natuurlijk is ICT werk soms complex. Kan je dat niet aan; zoek ander werk.

Je heb ook enige idee wat de impact hiervan is voor gebruikers? Technisch is alles werkend te krijgen. Dat is het probleem niet. Alleen gebruikers snappen het dan meestal niet meer. Daar zit de complexiteit in. Sommige gebruikers schieten al in de straks als het icoontje van een applicatie er anders uit ziet.
20-03-2018, 17:26 door karma4
Door Anoniem: HIV patiënten. Wellicht via de moeder gekregen. Weet je ook meteen dat die geïnfecteerd is. Al met al niet handig.
Ik dacht meer aan de hele lang reeks van zeldzame aandoeningen https://encyclopedie.medicinfo.nl/autoimmuunziekten--algemeen Wat jij noemt als al lang niet meer zo buzzing als toen het nieuw en dodelijk was.
Je zult maar met een zeldzame aandoening zitten.
20-03-2018, 19:14 door Anoniem
Door Anoniem:
Het handigst is misschien nog wel een persoonlijke omgeving op een website, waar je via gebruikersnaam en wachtwoord (of nog beter: 2FA) inlogt. Dan voorkom je al het e-mailverkeer. Het enige dat er dan, in hoge nood, uit zou hoeven gaan is "Er staat een 'bericht in uw persoonlijke berichtenbox", vergelijkbaar met de opzet zoals gehanteerd door de Belastingdienst. Maar dat kost een paar duiten aan inrichting, onderhoud etc.

https://www.security.nl/posting/554311/Patientendata+versturen+via+gewone+email

Post van 23:41 op 19-03-2018 legt helder uit waarom dat een (behoorlijk) slecht idee is.
21-03-2018, 08:02 door Anoniem
Door Anoniem:
Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...

Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?
Echt niet ingewikkelder dan spam- en malwarefilters.

Een mogelijkheid die ik ooit bij Postfix heb toegepast was om Postfix te configureren alle inkomende e-mail via SMTP door te sluizen naar een filter-daemon, die zijn ding doet en een e-mail op een alternatieve poort weer teruggeeft aan de Postfix-daemon, die vervolgens doorgaat met het bezorgen van de e-mail. Die opzet was geen eigen bedenksel, die werd gewoon in de documentatie van Postfix beschreven.

Die filter-daemon is verrassend simpel. Die ontvangt zoals gezegd een e-mail over SMTP, maar laat als de complete e-mail binnen is nog even na in de SMTP-dialoog de goede ontvangst te bevestigen. Eerst doet hij zijn controles, aanpassingen, wat de filtertaak ook inhoudt, en als de e-mail doorgaat levert hij hem als SMTP-client via de alternatieve poort terug aan Postfix. Die eindigt de interactie met een goed- of foutmelding. De SMTP-dialoog waarmee de e-mail werd aangeleverd aan het filterproces staat nog open, en pas wanneer het teruggeven aan Postfix goed is gegaan meldt die dat de ontvangst goed is gegaan. Als je dat goed doet dan hoeft de filter-daemon verder geen maatregelen te nemen om zeker te stellen dat e-mails niet verloren gaan, die lift volledig mee op de robuuste faciliteiten van de eigenlijke SMTP-daemon en daarmee is de belangrijkste bron van complexiteit in het filterproces geëlimineerd.

In dit geval zoekt die simpelweg de To-header op, telt het aantal e-mailadressen daarin en als die over een ingestelde grens gaan wordt óf de e-mail niet terugbezorgd aan Postfix en een foutcode aan de aanleverende dialoog afgegeven, óf wordt simpelweg de To-header uit de e-mail geknipt waardoor het effectief een Bcc wordt, om hem daarna verder te verwerken zoals ik al beschreven heb. Ik zou voor de foutcode gaan, dat is lastiger voor de verzender maar die wordt wel scherp gehouden door met zijn fout geconfronteerd te worden, wat helpt de kans laag te houden dat die elders dezelfde fout maakt.

Dat vond ik al niet moeilijk, er zijn libraries beschikbaar waarmee zowel de SMTP-server als -client een fluitje van een cent zijn om op te zetten. Daarbij moet ik wel moet aantekenen dat het niet om hoge volumes ging en ik niet met schaalbaarheidsproblemen geconfronteerd werd. Bedenk wel dat dit een aanzienlijk lichtere controle is dan een spam- of malwarescan, dus de schaalbaarheidsproblemen zullen eerder op andere plaatsen optreden dan bij deze bewerking. Postfix heeft meen ik tegenwoordig een andere manier toegevoegd om dit soort dingen te doen die (nog) eenvoudiger is. Hoe het met andere SMTP-servers gaat weet ik niet, maar als dit overdreven moeilijk is dan kan je je afvragen of je met de juiste SMTP-server werkt. Maar je kan sowieso elke SMTP-server configureren om alle uitgaande e-mail bij een andere server af te leveren, en zo kan je het beschreven proces altijd tussen twee "echte" SMTP-servers inhangen.

Ik vind overigens dat dit soort constructies niet eens nodig zouden moeten zijn. To gebruiken in plaats van Bcc is een vergissing die zo makkelijk en zo vaak gemaakt wordt dat ik eigenlijk vind dat in elke e-mailserver én elke e-mailclient het maximum toegestane aantal e-mailadressen geconfigureerd moet kunnen worden. Misschien zijn er produkten waarbij dat ook kan, dat overzie ik niet (ik ben nu ook niet meer met dat soort dingen bezig). Als je ermee te maken hebt en die mogelijkheid niet beschikbaar hebt wordt het misschien tijd om een feature-request bij je leverancier in te dienen.
21-03-2018, 09:56 door Anoniem
Door Anoniem:
Door Anoniem: Ik vind het eigenlijk geen menselijke fout meer dat na herhaaldelijk zo'n voorval de mailserver niet ingesteld is om te controleren dat het to-veld maar één ontvanger of gewhiteliste ontvangers bevat...

Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Wil je stellen dat het oplossen van het ontstane datalek achteraf mínder complex is?
21-03-2018, 10:01 door Anoniem
Door Anoniem:
Door Anoniem:
Je hebt ook enige idee, hoe complex dit is om in te richten vanuit de techniek?

Is dat nou het niveau van ICT vandaag de dag, klagen over dat werk complex is ? Natuurlijk is ICT werk soms complex. Kan je dat niet aan; zoek ander werk.

Je heb ook enige idee wat de impact hiervan is voor gebruikers? Technisch is alles werkend te krijgen. Dat is het probleem niet. Alleen gebruikers snappen het dan meestal niet meer. Daar zit de complexiteit in. Sommige gebruikers schieten al in de straks als het icoontje van een applicatie er anders uit ziet.

Dat hoeft niet, ookal is het wel (m.i.) de daadwerkelijke oplossing om de gebruikers zo ver te krijgen dat ze hiermee bewuster omgaan. Makkelijker is wss een relatief simpele instelling om bij mails met vele afzenders in de to-lijst dat automatisch om te laten zetten naar bcc-contacten...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.