In de zorgsector wordt veelvuldig gebruik gemaakt van e-mail voor interne en externe communicatie.
Het elektronisch cliëntdossier faciliteert over het algemeen interne overdracht en communicatie rondom de cliënt. Andere systemen kunnen in het door de zorgorganisatie beheerde applicatielandschap relatief eenvoudig en op een veilige manier worden gekoppeld.
Voor de digitale overdracht van gegevens naar andere partijen in de zorgketen, zoals het ziekenhuis, de huisarts of een behandelaar zijn er minder vaak eenvoudige en veilige oplossingen voorhanden.
E-mail niet veilig
Hoewel er vroeger nog veel gebruik werd gemaakt van post en fax, is e-mail en de mogelijkheid om bijlagen aan berichten toe te voegen voor veel eindgebruikers een vertrouwde, laagdrempelige manier geworden om gegevens naar externe partijen te verzenden.
Verbindingen tussen mailservers zijn van oudsher zwak beveiligd en het is daarom niet uit te sluiten dat derden inzage verkrijgen in de inhoud van het bericht. Voor e-mail geldt daarom een verhoogd risico op datalekken. Organisaties die voor 25 mei, wanneer de Algemene verordening gegevensbescherming (AVG) intreedt, geen maatregelen hebben getroffen om hun e-mailverkeer te beveiligen lopen daarmee een risico.
Meerdere oplossingen
Veel organisaties zijn daarom de afgelopen tijd op zoek gegaan naar toepassingen op het gebied van veilig mailen. Er zijn veel commerciële partijen op deze behoefte ingesprongen. Bekende namen zijn o.a. KPN Secure Mail (E-Zorg), ZorgMail, Zorgring en Zivver.
"Het fijne van standaarden is dat er zoveel zijn om uit te kiezen." - Andrew S. Tanenbaum
Hoewel deze oplossingen het e-mail verkeer beveiligen, dit (al dan niet) transparant maken voor de eindgebruikers en additionele functionaliteit kunnen bieden, zijn er ook een aantal nadelen:
- Een aantal van deze oplossingen zit op applicatie-niveau. Dat wil zeggen dat het een aparte (web)app en/of een plug-in voor Outlook betreft. Het is daarom raadzaam om te onderzoeken of de oplossing past in de langetermijnvisie van het applicatielandschap en het gekozen platform (on-premises of cloud/mobile).
- Samenwerkende ketenpartners moeten voor dezelfde oplossing kiezen, anders worden eindgebruikers geconfronteerd met meerdere apps of meerdere Verzend-knoppen in hun e-mail cliënt. De eindgebruiker moet, afhankelijk van de beoogde ontvanger, zelf de juiste route kiezen voor het bericht. Hier wordt het proces niet transparanter of eenvoudiger van. Het is onrealistisch om aan te nemen dat er tussen alle samenwerkende partijen overeenstemming bereikt kan worden over de keuze voor één third-party, zeker voor organisaties die in meerdere regio’s actief zijn.
- Minister Plasterk schreef in een brief in 2016 aan de gemeenten dat zij uiterlijk eind 2017 hun e-mail beter moeten beveiligen. En dat zij dit moeten doen volgens standaarden op de pas-toe-of-leg-uit lijst van het Forum Standaardisatie. Dit advies is overgenomen door het Nationaal Cyber Security Centrum (NCSC). Daarmee is het voor overheden verplicht om deze standaarden toe te passen bij het investeren in e-mailsystemen.
Kies voor standaarden
Veilig mailen kan mogelijk worden gemaakt door toepassing van een aantal standaard protocollen:
Transport Layer Security (TLS) is een beveiligingsprotocol waarmee een versleutelde verbinding tot stand wordt gebracht tussen twee (mail)servers.
DomainKeys Identified Mail (DKIM) is een authenticatietechnologie waarmee mede kan worden bepaald of een bericht daadwerkelijk van een bepaalde domeinnaam afkomstig is.
Sender Policy Framework (SPF) is een protocol waarmee kan worden vastgesteld of een verzender gemachtigd is om uit naam van een bepaalde domeinnaam berichten te verzenden.
Domain Name System Security Extensions (DNSSEC) is een protocol om te voorkomen dat er vervalsing plaatsvind bij het omzetten van domeinnamen naar IP-adressen, waardoor berichten mogelijk op een verkeerde (mail)server uitkomen.
Vrijwel alle moderne Exchange-omgevingen en ook Gmail van Google, waarvan veel huisartsen gebruik maken ondersteunen de TLS beveiligingsstandaard.
Bij het tot stand brengen van een verbinding onderhandelen mailservers onderling over het te hanteren beveiligingsprotocol. Wanneer een versleutelde verbinding niet mogelijk is, bijvoorbeeld omdat één van de deelnemers het beveiligingsprotocol niet ondersteund, zal een niet-versleutelde verbinding tot stand worden gebracht.
Is het dan zo dat alle deelnemers in de keten moderne beveiligingsprotocollen moeten ondersteunen om veilig mailverkeer te garanderen? Nee, om ervoor te zorgen dat de verbinding tussen twee mailservers altijd versleuteld plaatsvindt, hoeft slechts één van de deelnemers versleuteling te vereisen. Als niet aan de eis kan worden voldaan, dan wordt de verbinding niet tot stand gebracht, het bericht niet verzonden en ontvangt de verzender een Non-Delivery Report (NDR).
In Exchange kan per "partner organization" (lees: ketenpartner) een aparte Send/Receive connector worden geconfigureerd waarin TLS verplicht wordt gesteld. Hoewel niet noodzakelijk is het wel aan te raden om deze configuratie tweezijdig af te stemmen en het berichtenverkeer vooraf te testen.
Bij toepassing van bovengenoemde standaarden werkt de technologie volledig op de achtergrond. Voor de eindgebruiker verandert er functioneel niets. Zij blijven op dezelfde manier gebruik maken van hun e-mail client waardoor adoptieproblemen achterwege blijven. De bestaande Verzend-knop wordt hiermee een Veilig-mailen-knop, onafhankelijk van naar welke ketenpartner je berichten verstuurd en welke e-mail client je gebruikt, in lijn met bescherming tegen spam en het automatisch scannen van hyperlinks op malafide websites.
Dit is ook een valkuil. Omdat het merendeel van datalekken een gevolg is van menselijk handelen, blijft een bewustwordingsprogramma met betrekking tot het veilig omgaan met persoonsgegevens een onderwerp van aandacht.
Het via regels automatisch toevoegen van een e-mail footer waarmee wordt aangegeven dat het bericht via een beveiligde verbinding is verstuurd is een mogelijkheid om de zichtbaarheid van de versleutelde verbinding te vergroten.
Data Loss Protection (DLP) maakt het mogelijk om op basis van patroonherkenning gebruikers, wanneer zij op het punt staan om berichten te verzenden die mogelijk gevoelige gegevens bevatten (bijvoorbeeld creditcardgegevens of een BSN) te waarschuwen of blokkeren.
Voor alle partijen waarmee het niet mogelijk is om afspraken te maken en waarmee wel (incidenteel) persoonsgegevens worden gemaild is het mogelijk om apart van de verbinding, het bericht zelf te versleutelen, bijvoorbeeld met S/MIME of Office 365 Message Encryption (OME).
