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...

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.

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

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.

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.


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.

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.

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.

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.

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.

HIV patiënten. Wellicht via de moeder gekregen. Weet je ook meteen dat die geïnfecteerd is. Al met al niet handig.

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.

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'. (:-

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.

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.

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.

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.

Wil je stellen dat het oplossen van het ontstane datalek achteraf mínder complex is?

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...