NIS2 vereist dat uw organisatie beveiligde communicatie implementeert. Bestaande oplossingen zoals S/MIME en OpenPGP zijn hiervoor niet geschikt, omdat ze weliswaar voldoen aan de eis van beveiligde communicatie, maar uw klanten onvoldoende beschermen tegen beveiligingsproblemen binnen uw organisatie, zoals virussen, malware en het delen van vertrouwelijke informatie.

“Voldoet end-to-end versleutelde e-mail [ ] aan de NIS2-vereisten? Helaas niet!”

Is het implementeren van end-to-end versleutelde e-mail niet in het belang van uw klanten en voldoet u bovendien aan de NIS2-regelgeving? Helaas niet, en om die bewering te onderbouwen, moeten we de interne werking van end-to-end versleutelde e-mailoplossingen nader bekijken.

Wat is end-to-end-encryptie?

Laten we eerst het concept van end-to-end-beveiliging definiëren, een term die vaak verkeerd wordt geïnterpreteerd en door leveranciers te pas en te onpas wordt gebruikt. Bij een echte end-to-end-encryptie worden de gegevens versleuteld op het systeem of apparaat van de afzender, en kan alleen de beoogde ontvanger ze decoderen. Er zijn twee gestandaardiseerde methoden voor end-to-end-versleutelde e-mail: S/MIME en OpenPGP. Beide standaarden bestaan ​​al tientallen jaren en worden op grote schaal gebruikt.

Uitdagingen van S/MIME en OpenPGP

Bij beide benaderingen beschikt de afzender over een publieke sleutel van de ontvanger en gebruikt deze om de inhoud te versleutelen. De ontvanger beschikt over een privésleutel en gebruikt deze om de inhoud te ontsleutelen. Alleen de ontvanger heeft deze privésleutel; hij of zij is de enige partij in het gesprek die de e-mailinhoud kan ontsleutelen. Aanbieders die een webportaal gebruiken voor beveiligde e-mail en beweren end-to-end e-mailversleuteling te leveren, voldoen niet aan de bovengenoemde, algemeen aanvaarde definitie van end-to-end versleuteling. Hun oplossing is wellicht (voldoende) veilig, maar zeker geen end-to-end versleuteling.

Wat is er dan mis met een volwaardige en breed geïmplementeerde standaard voor end-to-end e-mailbeveiliging? Er zijn echter wel degelijk uitdagingen verbonden aan S/MIME en OpenPGP, zoals het feit dat je over de publieke sleutel van elke ontvanger moet beschikken waarmee je veilig wilt communiceren. Dit betekent dat elke ontvanger waarmee je communiceert een privésleutel en een certificaat op zijn of haar apparaat moet hebben geregistreerd. Bovendien moet de ontvanger zijn of haar publieke sleutel voorafgaand aan de daadwerkelijke communicatie aan jou hebben verstrekt. En diezelfde ontvanger moet elk jaar zijn of haar sleutelset vervangen, omdat deze sleutels een vervaldatum hebben. Oh, en diezelfde ontvanger moet alle eerder uitgegeven sleutels op een veilige plek bewaren, want als ze die kwijtraken, kunnen ze de e-mails die met hun oude publieke sleutel zijn versleuteld niet meer lezen. Had ik al gezegd dat de ontvanger in kwestie een gewoon persoon is, geen IT-expert?

Je ziet de problemen zich opstapelen, nietwaar? Interessant genoeg is dit niet het belangrijkste argument waarom deze oplossingen niet geschikt zijn voor jouw organisatie. Dat komt eigenlijk door het kerngedrag van klassieke end-to-end versleutelde oplossingen. Wat gebeurt er als je een end-to-end versleutelde e-mail verstuurt? Je moet de publieke sleutel van de ontvanger hebben, zoals we eerder al hebben vastgesteld. Laten we ervan uitgaan dat je die hebt en je begint met het schrijven van je e-mail. Aan het einde van de e-mail versleutel je deze met de publieke sleutel van de ontvanger. Dit werkt feilloos, aangezien zowel S/MIME als OpenPGP al lang bestaan ​​en het proces soepel verloopt. Je hebt nu een e-mailbericht dat volledig is versleuteld met de publieke sleutel van de ontvanger en je verzendt het naar de ontvanger. De ontvanger ontvangt de e-mail, decodeert deze met de bijbehorende privésleutel en het bericht is vervolgens in leesbare vorm beschikbaar.

Iedereen is blij, toch?

Niet dus. Je vergeet je bezorgd kijkende beveiligingsmedewerker die, hoewel enthousiast over het gebruik van end-to-end versleutelde e-mail, nu ontdekt dat deze versleutelde e-mail alle beveiligingsmechanismen omzeilt, zoals je antivirus-/malwaregateway en je software voor datalekkenpreventie. Dat betekent dat je (nog steeds) niet voldoet aan NIS2.

“De oplossing waarvan je dacht dat die je klanten zou beschermen, keert zich uiteindelijk tegen je.”

Met een klassieke end-to-end versleutelde e-mailoplossing creëert u in feite berichten die niet kunnen worden gecontroleerd, geïnspecteerd of geblokkeerd door uw gateways. Omdat de inhoud volledig versleuteld is, kan geen enkel controleproces de inhoud van het bericht inspecteren. Elk virus, malware of communicatie met inhoud die in strijd is met het beveiligingsbeleid van uw organisatie, zal onopgemerkt door uw beveiligingsmechanismen heen gaan. Dit is waar uw NIS2-verplichting tekortschiet: u beschermt uw klanten niet tegen interne beveiligingsproblemen die zich kunnen voordoen; deze verspreiden zich gewoon naar uw ontvanger zonder dat u ze kunt tegenhouden. De oplossing waarvan u dacht dat die uw klanten zou beschermen, keert zich tegen u. Een tweesnijdend zwaard, inderdaad!

Er zijn oplossingen beschikbaar waarbij u de end-to-end versleuteling op uw gateway uitvoert, nadat u uw antivirus-/malware- en datalekpreventiescans hebt uitgevoerd. Dat is zeker mogelijk, maar dan is het geen end-to-end versleuteling meer. En u blijft zitten met alle andere problemen met sleutelbeheer die eerder zijn genoemd. Een vicieuze cirkel, nietwaar? Je zit hoe dan ook in de problemen.

Hoe voldoe je aan NIS2 zonder andere mechanismen te blokkeren?

Hoe los je het probleem op dat je wilt voldoen aan NIS2 en e-mailversleuteling wilt gebruiken, maar tegelijkertijd ook controlemechanismen wilt toepassen op (malafide) e-mailinhoud, zoals vereist door NIS2? Een hybride oplossing is de beste optie. Deze oplossing levert versleutelde e-mail aan je klanten en stelt je tegelijkertijd in staat om antivirus-/malware- en datalekpreventiemaatregelen af ​​te dwingen. Met een dergelijke aanpak moet je de e-mail vanuit je IT-omgeving via een versleutelde verbinding naar de beveiligde e-mailoplossing transporteren, in plaats van de versleuteling op clientniveau toe te passen. Door de verbinding met de beveiligde e-mailoplossing te versleutelen, kun je nog steeds de inhoud controleren, ofwel door de inhoud te inspecteren voordat deze je gateway bereikt, ofwel door de transportversleuteling bij de gateway te beëindigen en een nieuwe versleutelde verbinding met de beveiligde e-mailoplossing tot stand te brengen. Zodra de e-mail bij de beveiligde e-mailoplossing aankomt, wordt de versleuteling op berichtniveau toegepast en wordt de e-mail aan de ontvanger geleverd met een geschikt mechanisme om de inhoud in de client van de ontvanger te decoderen.

Dat klinkt perfect, maar is dit wel een haalbare oplossing?

De bovengenoemde aanpak vormt de basis van SecuCypher, een hybride beveiligde e-mailoplossing van SecuMailer die een combinatie van versleutelde verbindingen en versleuteling op berichtniveau gebruikt om het beste van beide werelden te bieden.

“De ontvanger heeft nu met minimale inspanning toegang tot de onversleutelde inhoud van de e-mail; alle versleutelings-/ontsleutelingsprocessen vinden automatisch plaats, zonder dat de afzender of de ontvanger hiervoor kennis of expertise nodig heeft.”

Ons SaaS-platform ontvangt e-mails van uw organisatie via een versleutelde TLS-verbinding. Hierdoor kunt u beveiligingsmaatregelen zoals antivirus, malwarebescherming of datalekpreventie toepassen op uw uitgaande e-mails. Zodra we de e-mail op ons platform ontvangen, genereren we een sterke (symmetrische) sleutel op basis van een hoofdsleutel die u beheert. De inhoud van uw e-mail, inclusief eventuele bijlagen, wordt versleuteld met deze afgeleide sleutel. Uw versleutelde e-mail wordt ingevoegd in een bijlage die de inhoud van uw e-mail in een webpagina bevat, samen met alle benodigde versleutelings-/ontsleutelingslogica om de ingesloten e-mail aan de beoogde ontvanger te tonen. De ontvanger ontvangt de e-mail, opent de bijlage in de browser en wordt gevraagd om authenticatie. Als onderdeel van de 2FA-authenticatie genereert de browser een publieke/private sleutelpaar, stuurt de publieke sleutel samen met het authenticatietoken naar het SecuCypher SaaS-platform en, indien de authenticatie succesvol is, haalt het platform de sleutel op die is gebruikt om uw bericht te versleutelen. Deze sleutel wordt versleuteld met de unieke publieke sleutel die u van de browser hebt ontvangen en wordt teruggestuurd naar de browser van de ontvanger. In de browser van de ontvanger wordt de versleutelde sleutel ontsleuteld met de privésleutel die in het geheugen van de browser is opgeslagen. De ontvanger heeft nu met minimale inspanning toegang tot de ontsleutelde inhoud van de e-mail; alle versleutelings- en ontsleutelingsprocessen vinden automatisch plaats, zonder dat de afzender of ontvanger hiervoor enige kennis of expertise nodig heeft. Er is een optie om het originele bericht in onversleutelde vorm te downloaden, dat u vervolgens in uw e-mailprogramma kunt openen om op de gebruikelijke manier te reageren. Een extra voordeel is dat u als afzender de berichtsleutel kunt intrekken en zo de toegang tot de versleutelde e-mail kunt blokkeren als u deze naar de verkeerde ontvanger hebt verzonden, waardoor een datalek wordt voorkomen.

“Buiten deze scenario’s is het onwaarschijnlijk dat de specifieke omstandigheden waarin u een end-to-end versleutelde e-mailoplossing gebruikt, opwegen tegen uw fiduciaire verantwoordelijkheden.”

Is end-to-end e-mailversleuteling dan helemaal niet nuttig?

Natuurlijk zijn er situaties waarin deze aanpak een geschikte oplossing is. Deze situaties spelen zich echter meestal af in de privésfeer, wanneer u veilig wilt mailen met vrienden of collega’s (die doorgaans technisch onderlegd zijn), of in een vakgebied waar de waarde van end-to-end versleuteling zwaarder weegt dan uw fiduciaire verplichtingen, bijvoorbeeld journalisten die communiceren met bronnen of activisten. Buiten deze scenario’s is het onwaarschijnlijk dat de specifieke omstandigheden waarin u een end-to-end versleutelde e-mailoplossing gebruikt, zwaarder wegen dan uw fiduciaire verantwoordelijkheden.

De ultieme oplossing: veilig en gebruiksvriendelijk

Kortom, de NIS2-richtlijn vereist dat u als organisatie veilige communicatie implementeert. Een klassieke end-to-end versleutelde e-mailoplossing zoals S/MIME of OpenPGP staat geen antivirus-/malwarebescherming of datalekpreventie toe, waardoor deze oplossingen niet voldoen aan de NIS2-richtlijn. Als u wilt voldoen aan de NIS2-richtlijn én een goede gebruikerservaring voor uw klanten wilt bieden, kunt u het beste een hybride oplossing zoals SecuCypher gebruiken.