Het blijft een vreemd fenomeen; je bent bezig in je erp-, zis- of facturatiesysteem en wilt een bestand met vertrouwelijke data veilig delen, want AVG-compliant. In veel gevallen moet je dan uit de business applicatie en Outlook of een andere mailclient openen om het bestand versleuteld te versturen. Behoorlijk omslachtig, niet?
Vanuit de voortschrijdende bewustwording als het gaat om veilige informatiedeling confirmeren veel mensen zich ongetwijfeld aan de noodzakelijke omweg van bestand opslaan, openen e-mailclient, bestand toevoegen, versleuteling toevoegen en versturen. Het is vergelijkbaar met de omweg die een document maakt wanneer het ondertekend retour gemaild moet worden en je het gescande en ondertekende stuk uit een mapje op de server moet vissen om het terug te mailen. Van harte gaat dat echter allemaal niet, in Nederland geldt nog steeds dat gebruiksgemak prevaleert boven veiligheid.
Outlook vaak centraal
Organisaties zoeken continu naar gebruiksgemak en automatiseren delen van processen door hun business applicaties te koppelen aan andere systemen. Een goed voorbeeld is het declaratiesysteem van een zorgverzekeraar. Voorheen moesten de medewerkers handmatig de gegevens over de behandelingen en de vergoedingen van de verschillende ziekenhuizen vanuit een spreadsheet in een e-mail kloppen en deze versturen naar de financiële afdeling van elk ziekenhuis. Dat betrof een aanzienlijk volume aan documenten met allemaal dezelfde structuur. Dankzij een koppeling tussen het declaratiesysteem en het e-mailsysteem is dit proces nu grotendeels geautomatiseerd en worden er vele uren werk bespaard.
In het bovenstaande voorbeeld was de winst evident; er waren minder fte nodig voor dezelfde taak. Dit leverde voldoende argumenten op om de koppeling te maken. Toch zijn dit soort efficiënte oplossingen lang niet altijd beschikbaar. Dat heeft ermee te maken dat mensen bij e-mailen vaak Outlook centraal stellen. Nu beveiliging steeds belangrijker wordt bij het versturen van e-mails en bestanden, wordt de procedure complexer en vermoeiender. Veiligheid kost tijd, is de heersende gedachte. Het vervelende is, dat veel business applicaties, die gebruikt worden voor dagelijkse taken, niet beschikken over een geïntegreerde mogelijkheid om veilig om te e-mailen.
Medewerkers op verkoopafdelingen, hr, in ziekenhuizen blijven dus maar zuchtend en steunend volharden in de ‘toeristenroute’. Tenzij de leverancier van de business applicatie óf die van de e-mailbeveiligingsoplossing een connector beschikbaar stelt die het mogelijk maakt om direct vanuit de applicatie beveiligd informatie te delen. Met de hulp van deze standaard verbinding kan afgedwongen worden dat bepaalde mails altijd beveiligd verstuurd worden zónder dat de gebruikers hiervoor uit het erp-systeem, document management- of zis hoeven te gaan en hun Outlook moeten openen. Dit zou bijvoorbeeld gelden voor e-mails met daarin de bloedwaarden van een patiënt. Voor artsen is het pure tijdswinst wanneer ze deze informatie direct vanuit hun werkscherm in het zis kunnen versturen, zonder naar Outlook te hoeven switchen. Het is dus zaak om veilige e-mail direct vanuit de bron te kunnen versturen. Dat is pas echt gebruiksvriendelijk in plaats van Outlook aan te passen.
Op dit moment zijn er slechts in beperkte mate connectoren beschikbaar om business applicaties te koppelen aan e-mailbeveiligingssoftware, terwijl het aantoonbaar veel voordelen oplevert qua productiviteit en het terugdringen van de kans op fouten. Het belang van deze slimme, korte lijntjes zal, vanwege de toenemende digitalisering van processen, toenemen. Toeleveranciers én klanten verwachten een geautomatiseerde orderverwerking, inclusief directe orderbevestiging, leveringsbevestiging én een factuur in de mailbox. Softwareleveranciers zullen daarom hun verantwoordelijkheid moeten pakken en het marktpotentieel moeten zien van de verdere integratie van business- en beveiligingsoplossingen. Op deze manier gaan veiligheid en gebruiksgemak hand in hand.
Lucien,
Ik snap dat je een toepassingsgebied voor Cryptshare zoekt maar misschien is het handig als je dan eerst even naar de markt kijkt. Je stelt dat problematiek van een gemakkelijke en veilige communicatie in het gebrek aan connectoren zit maar Zorgmail lijkt toch een groot aantal koppelingen te hebben met allerlei sectorgerichte applicaties. En betreffende het vraagstuk van een geautomatiseerde orderverwerking met juiste adresseringen en terugkoppeling is een EDI-systeem m.i. een betere optie dan e-mail. Tenslotte is één van de meest voorkomende redenen van een datalek binnen de sector een verkeerde adressering.
Ewout Dekkinga heeft een valide punt als het gaat om B2B berichtenverkeer. Er is geen enkele reden om inherent onveilige middelen als e-mail te gebruiken als daar een alternatief voor is die vanaf het begin ontworpen is om applicatie-onafhankelijk berichten uit te wisselen. EDI is al vanaf de jaren 90 van de vorige eeuw aanwezig en heeft, voor zover ik weet, in de afgelopen 30 jaren wel bewezen een snel en veilig medium te zijn.
Als het echter gaat om het versturen van berichten van bedrijven naar consumenten (B2C) of van consumenten naar bedrijven is EDI echter niet meer zo’n handig middel. De consument zal een EDI bericht niet zo makkelijk kunnen ontcijferen en is niet aangesloten op een EDI netwerk.
Dhr. Barink heeft een punt, maar focust zich tegelijkertijd teveel op één merk (Outlook) waar ook andere mailservers het probleem vormen. Maar zelfs als we dat voor het gemak even negeren, slaat Dhr. Barink de plank grotendeels mis.
Het is relatief eenvoudig om een applicatie automatisch mails te laten generen. SMTP is geen uitermate moeilijk of ingewikkeld protocol en de meeste programmeertalen hebben wel de beschikking over een template-generator of mail-merge framework.
Dat bedrijven daar geen geld in willen steken kan een aantal oorzaken hebben:
– Men gebruikt een applicatie die geen plug-in mogelijkheden biedt om mails te extraheren
– Men gebruikt een applicatie die wel een plug-in mogelijkheid biedt, maar de producent vraagt geld ervoor of het bedrijf moet zelf investeren om die plug-in te ontwikkelen
– Men gebruikt een applicatie die zelf ontwikkeld is, en die deze export mogelijkheid nog niet heeft
Feitlijk in alle gevallen zou het bedrijf zelf een plug-in of add-on applicatie kunnen ontwikkelen. Echter in de meeste gevallen zal er een manager ergens hebben besloten dat dat veel te veel geld kost en “zo werkt het toch ook?” hebben geroepen. Het zijn meestal het soort managers die zelf niet dagelijks met de applicatie hoeven te werken en niet ziet hoeveel uur er wordt verbrand door het personeel om die mails de deur uit te krijgen.
Maar zelfs al zou er een visionaire manager zijn die wel wil investeren in het ontwikkelen van een prettige werkomgeving voor het personeel (die managers zijn overigens erg zeldzaam), dan nog valt of staat de oplossing bij de juistheid van gegevens. Als een klant zijn/haar mailadres onjuist heeft ingevuld, komen de gegevens feitelijk op straat te liggen. AVG vereist dat de klant zijn/haar gegevens mag inzien, maar niets verplicht die klant om zijn/haar gegevens in te zien. Er worden aan de klanten geen boetes uitgedeeld als deze de gegevens niet bijwerkt.
En in het ideale geval dat de klant zijn/haar gegevens juist doorgeeft en blijft doorgeven, dan NOG hebben we een issue dat e-mail een inherent onveilig medium is: het SMPT (of POP3, of IMAP) protocol kent zelf geen encryptie mogelijkheid. Je zou over een beveiligde poort kunnen communiceren naar de mailbox, maar noch het bedrijf waar de gegevens vandaan komen noch de klant kunnen afdwingen dat de internet providers onderling ook encrypted werken. Om dat te omzeilen zullen het bedrijf en de klant moeten afspreken dat er een end-point encryptie wordt toegepast. En daar begint het gedoe: even er vanuitgaande dat er een public/private key encryptie wordt toegepast: de klant moet zijn public/private key paar genereren (en de private key bewaren), het bedrijf zal dit ook moeten doen (de meeste serieuze bedrijven doen dit overigens al) en dan zullen ze deze moeten uitwisselen (moeilijk voor veel klanten) EN de mailclient zal deze encryptie/decryptie moeten ondersteunen (moeilijk voor veel klanten).
Dit valt alleen maar op te lossen door de eindgebruikers (lees: consumenten) eerst allen op te leiden in het maken en veilig bewaren van de juiste private keys (met de juiste lengte, ook nog een leuke) en deze op te slaan in de juiste keyring of wallet. De bijbehorende public keys uit te wisselen met de juiste partijen en deze op te slaan in de juiste keyring of wallet. En dan moeten de bedrijven hetzelfde doen. En dan moeten alle maillcients ook nog eens op een eenvoudige manier (maar wel veilig) deze encryptie/decryptie gaan uitvoeren.
Er zal nog heel wat water door de Rijn stromen vooraleer die voorwaarden zijn ingevuld.
Kortom: hier gaat de AVG nog geen oplossing voor bieden, noch enige overheid en laat staan de vele, vele producenten van mailclients.
Voor bedrijven geldt echter dat een geautomatiseerde koppeling van uitgaande mails een minimaal begin is om problemen te verminderen.
Wat er bij mij niet ingaat is dat inmiddels het grote deel van het www, chat messaging verkeer allemaal via encryptie moet maar je smtp nog steeds via een antieke koppeling zou gebruiken. Ook daar zou encryptie verplicht afgedwongen moeten zijn. bijv. PGP bestaat al decennia lang maar nog steeds is dat geen gemeengoed. Dat hoort anders te zijn.