Waarom TLS Mogelijk Niet Voldoende Is Voor Uw E-mail Encryptiestrategie
Het digitale tijdperk heeft niet alleen ons dagelijks leven veranderd, maar ook de manier waarop bedrijven opereren. Bedrijven hebben tegenwoordig veel meer interactie met hun klanten en cliënten. Ze beschikken ook over veel meer data om hun bedrijf en het koopgedrag van hun klanten beter te begrijpen. Deze data stelt bedrijven in staat om efficiëntiegaten te dichten, groeikansen te identificeren en hun klanten beter te bedienen.
Deze data is, niet verrassend, ontzettend waardevol. Het beschermen ervan is daarom cruciaal voor het voortbestaan van een bedrijf in een zeer competitieve markt. Wanneer organisaties hun persoonlijk identificeerbare informatie (PII), beschermde gezondheidsinformatie (PHI), intellectueel eigendom (IP) of andere vertrouwelijke informatie beschermen, waarborgen ze de continuïteit van hun bedrijf, tonen ze naleving van wetgeving op het gebied van gegevensbescherming aan en behouden ze hun reputatie.
Bedrijven moeten hun gevoelige informatie beschermen, of deze nu is opgeslagen op servers of wordt gedeeld via e-mail of een ander communicatiekanaal. Transportlaagbeveiliging (TLS) is een belangrijk onderdeel geworden van de e-mailbeveiligingsstrategie van elke organisatie, zeker nu ze moeten voldoen aan regelgeving zoals de Payment Card Industry Data Security Standard (PCI DSS), de Health Insurance Portability and Accountability Act (HIPAA) en de Algemene Verordening Gegevensbescherming (GDPR) van de Europese Unie.
Het inschakelen van TLS garandeert echter niet dat uw e-mails veilig zijn voor nieuwsgierige ogen. Sterker nog, veel organisaties gebruiken TLS nog steeds op de verkeerde manier, waardoor hun e-mails kwetsbaar blijven voor ongeautoriseerde toegang en datalekken.
Hoe Werkt TLS?
Om een website of applicatie TLS te laten gebruiken, moet er een TLS-certificaat zijn geïnstalleerd. Een TLS-certificaat wordt uitgegeven aan de persoon of het bedrijf dat eigenaar is van een domein. Het certificaat bevat belangrijke informatie over wie het domein bezit en de publieke sleutel van de server, die beide essentieel zijn voor het valideren van de identiteit van de server.
Een TLS-verbinding wordt gestart via een proces dat bekendstaat als de TLS-handshake. Wanneer iemand een website bezoekt die TLS gebruikt, begint de TLS-handshake tussen het apparaat van de gebruiker (ook wel het clientapparaat genoemd) en de webserver.
Tijdens de TLS-handshake doen het apparaat van de gebruiker en de webserver het volgende:
- Specifiëren welke versie van TLS (TLS 1.0, 1.2, 1.3, enz.) wordt gebruikt,
- Bepalen welke cipher suites worden gebruikt,
- De identiteit van de server authenticeren met behulp van het TLS-certificaat van de server, en
- Sessiesleutels genereren voor het versleutelen van berichten tussen het apparaat van de gebruiker en de webserver nadat de handshake is voltooid.
Wat Is een Certificate Authority (CA)?
Een certificate authority (CA) is een organisatie die de identiteit van entiteiten (zoals websites, e-mailadressen, bedrijven of individuen) valideert en deze koppelt aan cryptografische sleutels door het uitgeven van elektronische documenten die bekendstaan als digitale certificaten.
Een digitaal certificaat biedt het volgende:
- Authenticatie—dient als bewijs om de identiteit van de entiteit waarvoor het is uitgegeven te valideren
- Encryptie—voor veilige communicatie over onveilige netwerken
- De integriteit van documenten die met het certificaat zijn ondertekend, zodat een derde partij deze onderweg niet kan wijzigen
Wat Is het Verschil Tussen TLS en SSL?
TLS is voortgekomen uit een eerder encryptieprotocol genaamd secure sockets layer (SSL), ontwikkeld door Netscape. TLS versie 1.0 begon als SSL versie 3.1, maar de naam van het protocol werd vóór publicatie gewijzigd om aan te geven dat het niet langer aan Netscape was verbonden. Hierdoor worden TLS en SSL soms door elkaar gebruikt.
Mogelijke Kwetsbaarheden van TLS
Hoewel TLS en SSL ongetwijfeld een essentiële basis vormen voor de aanpak van gegevensbeveiliging door bedrijven, bevatten ze nog steeds kwetsbaarheden.
De belangrijkste zwakte ontstaat door het gebrek aan kennis van bedrijven over e-mailencryptie, waarbij velen denken dat het transportkanaal—en dus de e-mail—volledig beveiligd is zodra TLS wordt gebruikt.
Bedrijven moeten zich echter realiseren dat e-mailberichten reizen tussen de e-mailservers van de verzender en ontvanger, een kanaal dat ook buiten hun eigen netwerken loopt. Een e-mail is slechts beschermd tot de volgende mail-hop, en er is geen controle over wat er gebeurt zodra deze bij de volgende Simple Mail Transfer Protocol (SMTP) hop aankomt.
Een vertrouwelijk bericht kan dus binnen het netwerk van het bedrijf worden blootgesteld, omdat TLS geen end-to-end encryptie biedt. TLS beveiligt alleen het kanaal van het apparaat van de verzender tot de zakelijke mailserver. Maar e-mails worden vaak via extra servers doorgestuurd, waar encryptie niet kan worden gegarandeerd.
Bijvoorbeeld, bij antiviruscontroles en inhoudsscans kan data onderweg worden blootgesteld aan nieuwsgierige beheerders of andere medewerkers.
Een ander beveiligingsrisico ligt bij het gebruik van X.509-certificaten. Veel bedrijven valideren hun certificaten niet, waardoor al hun gevoelige data wordt blootgesteld.
Bedrijven moeten ervoor zorgen dat certificaten zijn uitgegeven door een betrouwbare en gerenommeerde certificate authority (CA). Dit is allesbehalve triviaal, want veel bedrijven ondertekenen hun certificaten zelf.
Organisaties moeten ook controleren of certificaten geldig zijn en of encryptie-algoritmen en sleutellengtes up-to-date zijn (lees: state-of-the-art).
Veel bedrijven, vooral die gebruikmaken van OpenSSL, maken hun eigen certificaten aan omdat dit gemakkelijk en goedkoper is dan certificaten van een officiële CA. Ja, certificaten kosten geld. Ze moeten worden aangeschaft en vernieuwd. Als bedrijven vergeten te vernieuwen, wordt het certificaat uiteindelijk ingetrokken en moeten ze opnieuw betalen aan de CA voor een nieuw certificaat.
Bedrijven zijn zich er vaak niet van bewust dat als ze een verkeerde TLS-versie gebruiken die geen “perfect forward secrecy” biedt, berichten kunnen worden ontsleuteld door onbevoegde gebruikers die de sleutels weten te achterhalen.
Een andere bekende beperking van TLS is de “optionele TLS”-systeemconfiguratie. Met “verplichte TLS” zal het oorspronkelijke systeem een e-mailbericht alleen verzenden als het volgende systeem in de keten TLS ondersteunt; het bericht wordt niet verzonden als dat systeem geen TLS ondersteunt. Als een systeem echter “optionele TLS” gebruikt, wordt het bericht toch verzonden, waardoor het kanaal niet versleuteld is en het bericht wordt blootgesteld.
Hier zijn nog enkele aanvullende redenen waarom TLS mogelijk niet voldoende is om uw e-mailcommunicatie te beveiligen.
TLS beschermt e-mails tegen sommige, maar niet alle, soorten aanvallen
TLS alleen is niet voldoende voor e-mailbeveiliging, omdat het slechts tegen bepaalde vormen van e-mailaanvallen beschermt. TLS is vooral effectief tegen man-in-the-middle en afluisteraanvallen die plaatsvinden terwijl data onderweg is. Als u gevoelige informatie op uw servers of databases opslaat, moet u een extra encryptieprotocol gebruiken zoals Pretty Good Privacy (PGP) of Secure/Multipurpose Internet Mail Extensions (S/MIME).
Deze encryptieprotocollen zorgen ervoor dat als een hacker toegang krijgt tot de server, hij de versleutelde data niet kan lezen. En omdat deze protocollen niet vertrouwen op het verzenden van platte tekst over het netwerk, zijn ze minder vatbaar voor verkeersanalyse en andere side-channel aanvallen die versleutelde communicatie monitoren.
TLS kan kwetsbaar zijn voor downgrade-aanvallen
TLS wordt meestal gebruikt om verbindingen tussen uw computer en een server te beveiligen, bijvoorbeeld wanneer u via een browser inlogt op uw e-mail. Maar het kan ook worden gebruikt voor andere verbindingen, zoals het verzenden van e-mails van de ene server naar de andere.
Het probleem met deze aanpak is dat de volledige verbinding niet versleuteld is. Alleen de data tussen de verzendende en ontvangende servers is versleuteld—en die servers hebben mogelijk geen sterke beveiliging. Een downgrade-aanval kan verkeer op een niet-versleutelde verbinding onderscheppen en berichten lezen terwijl ze worden verzonden. Tenzij u end-to-end encryptie gebruikt, loopt u het risico dat uw data en uw organisatie gevaar lopen.
TLS heeft een sterkere handshake nodig
TLS is het meest gebruikte encryptieprotocol van dit moment, maar het kent nog steeds beperkingen. Om te garanderen dat de e-mail van uw bedrijf vanaf het begin veilig en versleuteld is, gebruikt u STARTTLS met encryptie-algoritmen zoals PGP of S/MIME.
Op deze manier kunnen zelfs als iemand uw e-mails onderweg onderschept, deze niet worden gelezen zonder uw privésleutel. Het maakt het ook moeilijker voor een man-in-the-middle aanval om plaats te vinden, doordat er een extra laag encryptie bovenop de initiële TLS-handshake komt.
Als u vertrouwelijke informatie veilig wilt verzenden, overweeg dan een extra beschermingslaag toe te voegen door uw e-mail te versleutelen via een externe dienstverlener.
Kiteworks voor End-to-End Beveiliging en Encryptie
Kiteworks is meer dan alleen een beveiligde e-mailprovider. Het fungeert als een private content network (PCN) voor governance, naleving en beveiliging met betrekking tot het verzenden en ontvangen van gevoelige inhoud binnen, door en buiten een organisatie.
Kiteworks biedt encryptie op ondernemingsniveau en uniforme beveiligingscontroles via een e-mail encryptiegateway en een Microsoft Outlook-plugin, webapplicatie, enterprise applicatieplugin of mobiele applicatie. Daarnaast levert het geautomatiseerde beleidsregels op basis van rollen om de beveiliging en naleving van de meest gevoelige informatie van een organisatie te waarborgen.
Plan een persoonlijke demo om te ontdekken hoe Kiteworks het verzenden en ontvangen van e-mails met vertrouwelijke informatie automatiseert, ongeacht de gebruikte encryptiestandaard.