2014 P.E. van Gemeren Architectuur voorstel secure e-mail [Architectuur voorstel secure e-mail]
Documenthistorie Datum Versie Beschrijving Auteur 5-02-2014 0.1 Concept versie P.E. van Gemeren 5-02-2014 0.2 Concept versie P.E. van Gemeren 14-02-2014 0.3 Verduidelijking n.a.v. feedback P.E. van Gemeren 04-03-2014 0.4 Management samenvatting Dave Ormel 06-03-2014 0.5 Kosten Dave Ormel 10-03-2014 0.6 Aanleiding, bijlage bijgewerkt Dave Ormel 2
Inhoud Management samenvatting... 4 Aanleiding... 4 Introductie... 5 Doel... 5 Eisen NEN7510... 5 Begrippen... 5 Mogelijkheden... 7 Domein naar Domein communicatie... 7 Domein naar identiteit communicatie... 10 Voorstel... 11 Tekening 1: Domein naar Domein communicatie Huidige situatie... 12 Tekening2: Domein naar Domein communicatie Toekomstige situatie... 13 Kosten... 14 Bijlage... 15 Techniek... 15 Veiligheid van secure e-mail... 15 STARTTLS... 16 Smart host services... 16 Controleren TLS gebruik bij een ander domein... 17 Implementeren Opportunistic TLS (fase 2)... 20 Implementeren Mutual TLS (fase 3)... 21 Begrippenlijst... 22 3
Management samenvatting De doelstelling van RSO Haaglanden is het verbeteren van de kwaliteit en de doelmatigheid van de zorg door het organiseren van het berichtenverkeer tussen hulpverleners. Veilig mailen is daar een onderdeel van en betekent ook het ontwikkelen van een regionale koers (wat doen we samen en wat ieder voor zich), het opstellen van richtlijnen of voorstellen en beïnvloeding van leveranciers. Tevens is de RSO de plek om in de regio en met andere regio s kennis uit te wisselen. Dit document beschrijft de mogelijkheden in de techniek en de verschillende fasen om deze te implementeren. Door regionale, technische afspraken te maken, zijn de kosten zijn minimaal. Mede door geen (of zo min mogelijk) derde partijen (leveranciers) te betrekken, maar de huidige techniek beter te benutten. Het moge duidelijk zijn, hoe meer deelnemers deze richtlijn implementeren hoe veiliger de communicatie wordt. Aanleiding Om het veilig mailen tussen hulpverleners te organiseren heeft de RSO Haaglanden in januari 2014 een bijeenkomst met de betrokkenen uit de instellingen georganiseerd. In deze bijeenkomst is de noodzaak van veilig mailen in de regio expliciet bevestigd en zijn de verschillende mogelijkheden om dit te realiseren besproken. Gekozen is daar om een voorstel te ontwikkelen om vanuit regionale technische afspraken veilig mailen mogelijk te maken. Dit voorstel wordt besproken met de deelnemers aan de bijeenkomst: Sylvia Veereschild Rik Ernst Otto Jansen Roelof Bosch Pieter van Gemeren Hans Hupse Guido Kauer Kevin Berkhof Erik Kerkhove George Boukens Miranda de Gouw Rob Saathof Mia van Leeuwen Dave Ormel WZH Haga Ziekenhuis MC Haaglanden Apotheek Savalle Bronovo Ziekenhuis Sophia Revalidatie Bronovo Ziekenhuis Respect Zorggroep Haga Ziekenhuis Parnassia Florence Sleutelnet RSO Haaglanden RSO Haaglanden 4
Introductie In de tijd dat het Simple Mail Transport Protocol (SMTP) werd ontworpen kon men niet voorzien hoe het internet zich zou ontwikkelen en hoe dit protocol vele jaren later zou worden gebruikt en misbruikt. Tegenwoordig wordt het protocol als onveilig beschouwd o.a. doordat de e-mails in clear tekst over het netwerk getransporteerd worden. Er zijn vele voorstellen geweest ter verbetering of vervanging van het protocol waarvan de meeste nooit zijn geïmplementeerd vanwege het feit dat het protocol wereld wijd geïmplementeerd is in een onnoemelijke hoeveelheid applicaties en omdat backward compatibiliteit verlangt wordt. De verwachting is dan ook dat het protocol nooit zal worden vervangen voor iets veiligers waardoor men aangewezen is op beveiligingsmaatregelen die werken binnen de al bestaande kaders. Dit document gaat dieper in op de verschillende manieren die er zijn om communicatie via e-mail te beveiligen en er wordt een architectuur voorstel gedaan om secure e-mail te realiseren tussen de RSO deelnemers onderling en tussen RSO deelnemers en patiënten. In het hoofdstuk techniek zullen we o.a. dieper in gaan op de veiligheid van secure e-mail (100% veilige e-mail is niet realiseerbaar) en bespreken we hoe secure e-mail geconfigureerd en geverifieerd kan worden. Doel Het implementeren van secure e-mail tussen de deelnemers van de Regionale Samenwerkings Organisatie Haaglanden (RSO) onderling en tussen de deelnemers en patiënten. Eisen NEN7510 De ideeën over secure e-mail van de A12 Chief Information Security Officer (CISO) zijn: Het is zaak de actuele stand van de techniek te volgen (tekst uit de WBP). Toegang tot de e-mail: Authenticatie vanuit het domein: gebruikersnaam+wachtwoord Authenticatie van buiten het domein: gebruikersnaam+wachtwoord+bezit (token of telefoon) Encryptie: Encryptie (alleen buiten het domein): tenminste AES128 De CISO heeft aangegeven dat een veilig e-mail alternatief (secure e-mail) moet worden aangeboden voordat verzonden e-mails eventueel mogen worden gescand op content en personeel op hun gedrag (het niet secure verzenden van e-mail) mag worden aangesproken. Begrippen 5
Secure e-mail Secure e-mail is e-mail encrytpie, en vaak ook authenticatie, van e-mail berichten met als doel de inhoud van de e-mail te beschermen tegen ongeautoriseerd lezen door derden. Secure e-mail is gebaseerd op drie concepten: data encryptie, authenticatie, bericht integriteit en sleutel management (1). Secure e-mail gateway (SEG) Een secure e-mail gateway is de volgende stap in de evolutie van secure e-mail. Een secure e-mail gateway is een product dat naast secure e-mail (encryptie, authenticatie en sleutel management ) ook zaken regelt zoals: Bescherming tegen spam, phishing attacks, virussen en overige malware Data Leak Prevention (DLP): Het classificeren van data op basis van trefwoorden of regular expressions (denk aan BSN, namen van ziekten en andere patiënt gerelateerde informatie). Op bijvoorbeeld de classificatie vertrouwelijk kunnen vervolgens automatisch policy s worden toegepast (bijvoorbeeld blokkeren van de e-mail, waarschuwen van de gebruiker of automatische encryptie van de e-mail). 6
Mogelijkheden Op dit moment zijn er verschillende opties om secure e-mail te bewerkstelligen: Domein naar Domein communicatie Hiermee wordt de communicatie tussen de RSO deelnemers onderling bedoeld. - De data versleutelen in een versleuteld bestand in de bijlage (met bijvoorbeeld 7-zip). o Voordelen: Gratis Begrijpelijk (niet eenvoudig of complex) voor de eindgebruiker Veilig (AES-256 kan worden gebruikt) Te gebruiken naar iedereen (alle domeinen) Communicatie kan door beide partijen geïnitieerd worden o Nadelen: De e-mail zelf (header, subject en body) is niet encrypted maar alleen het versleutelde bestand uit de bijlage Het is een extra handeling voor de gebruiker en ontvanger Het uitwisselen van het wachtwoord via post, sms of telefonisch ect. Encryptie kan worden vergeten door gebruiker - Open standaarden (o.a. s/mime en PGP) gebruiken. o Voordelen: Gratis Veilig (AES-256 kan worden gebruikt) Complete e-mail is encrypted Te gebruiken naar iedereen (alle domeinen) Communicatie kan door beide partijen geïnitieerd worden o Nadelen: Complex voor eindgebruiker Encryptie kan worden vergeten door gebruiker Deze complexiteit zit in de volgende punten: Als een gebruiker een s/mime encrypted e-mail ontvangt maar zelf alleen PGP gebruikt kan de ontvanger de e-mail niet lezen. Een ander probleem is het uitwisselen van sleutels. Wil je encrypted e-mails ontvangen die alleen jij kan lezen dan moet jij sleutels genereren. De publieke sleutel moet je versturen aan contacten waarvan je wilt dat ze encrypted e-mails aan jou sturen. Deze contacten moeten die sleutel implementeren in hun e-mail client om e-mails te genereren die alleen jij kan ontsleutelen met je private sleutel. Wil jij een encrypted e-mail versturen aan een contactpersoon dan dient deze contactpersoon sleutels te genereren, de publieke sleutel naar jou te sturen, die jij weer dient te implementeren in je e-mail client. 7
- Commerciële producten gebruiken. Om de hiervoor besproken complexiteit te omzeilen zijn er commercieel producten ontwikkeld die met alle open standaarden voor e-mail encryptie overweg kunnen en het uitwisselen van encrypted e-mails en sleutels een stuk eenvoudiger maken voor de eindgebruikers. Hierbij valt te denken aan secure e-mail oplossingen van Cisco, Microsoft, Symantec, McAfee, Voltage ect. Gartner heeft hier onafhankelijk onderzoek naar gedaan: o o Voordelen: Veilig Eenvoudig voor de eindgebruiker (afhankelijk van product keuze) complete e-mail wordt encrypted in een kluis weggezet Te gebruiken naar iedereen (alle domeinen) Nadelen: Duur Extra handelingen voor de eindgebruikers Encryptie kan worden vergeten door gebruiker Communicatie kan alleen door beide partijen geïnitieerd worden indien beide partijen een commerciële oplossing hebben gekozen. Anders kan er alleen veilig gecommuniceerd worden via een reply op de verzender. Een ander nadeel is dat gebruikers mogelijk met twee verschillende produkten moeten werken indien RSO deelnemer A een andere oplossing heeft als deelnemer B. 8
- TLS gebruiken Deze mogelijkheid blijft vaak onderbelicht in de discussie over secure e-mail terwijl hij voor de domein naar domein communicatie wel erg interessant is. Transport Layer Security (TLS) is de opvolger van Secure Sockets Layer (SSL). Voor webservers is deze manier van communiceren al lange tijd zeer gebruikelijk. Waar het vroeger normaal was om gevoelige informatie over het http protocol te versturen is nu https niet meer weg te denken. Dezelfde mogelijkheid bestaat ook voor het SMTP protocol en wordt beschreven in rfc3207: STARTTLS. Hier wordt dieper op ingegaan in het hoofdstuk techniek. TLS/SSL enables server authentication, client authentication, data encryption, and data integrity over networks such as the World Wide Web. (2) o o Voordelen: Goedkoop (alleen kosten voor aanschaf certificaat en implementatie tijd) Veilig (zie de quote over TLS/SSL) Complete e-mail is encrypted Transparant voor de eindgebruiker (hoeft hier niks voor te doen en merkt er niets van op secure domein symbool in outlook na bij gebruik Exchange) Encryptie kan niet worden vergeten door gebruiker Nadelen: Niet ieder ontvangend domein ondersteunt dit automatisch: Het ontvangende domein moet dit inregelen door onder andere een certificaat op de mailserver te installeren. 9
Domein naar identiteit communicatie Hiermee wordt de communictie tussen de RSO deelnemers en patiënten/huisartsen e.d. bedoelt. - De data versleutelen in een versleuteld bestand in de bijlage (met bijvoorbeeld 7-zip). o Zie de domein naar domein communicatie voor de voor en nadelen - Open standaarden (o.a. s/mime en PGP) gebruiken. o Zie de domein naar domein communicatie voor de voor en nadelen - Commerciële producten gebruiken. o Zie de domein naar domein communicatie voor de voor en nadelen o Veilige communicatie is alleen mogelijk op initiatief van een RSO deelnemer in de vorm van een reply bericht - TLS gebruiken Een bijkomend voordeel is dat een aantal publieke e-mail diensten zoals gmail.com, yahoo.com en KPN.com ook het gebruik van TLS ondersteunen (ziggo.nl en hotmail.com ondersteunen dit niet) waardoor secure e-mail tussen de RSO domeinen en patiënten gerealiseerd wordt indien de patiënt gebruik maakt van één van deze veilige (een aantal publieke e-mail diensten staan er om bekend dat ze informatie uit de e-mails commercieel gebruiken) publieke e-mail diensten. De communicatie tussen de gebruiker van b.v. gmail.com en de mailserver van gmail is ook encrypted daar de gebruiker ingelogd is via de webbrowser over https waardoor end to end encryptie tussen een RSO e-mail gebruiker en gmail gebruiker mogelijk is. Een discussie punt hierbij is de praktische uitvoerbaarheid ervan: Er zouden lijsten bij gehouden moeten worden (en bekend moeten zijn bij medisch personeel dat vertrouwelijke informatie naar patiënten stuurt) van welke publieke e-mail dienst veilig gebruikt kan worden en welke niet. Een ander discussie punt hierbij is of de verantwoordelijkheid van het gebruik van publieke e- mail diensten bij de patiënt ligt, hoe groot de risico s zijn en of de RSO deelnemers hierin ook een verantwoordelijkheid dienen te nemen. De patiënt heeft immers de voorwaarden geaccepteerd bij het aanmaken van het e-mail account, dus deze behoort op de hoogte te zijn van het feit dat deze e-mail providers kunnen meelezen. Wij als RSO deelnemers kunnen patiënten hier echter tegen beschermen door gebruik te maken van een commerciële secure e-mail (kluis) oplossing. 10
Voorstel Voor de domein naar domein communicatie kan het beste gekozen worden voor het gebruik van TLS (de vierde mogelijkheid). Voor de domein naar identiteit communicatie kan het beste gekozen worden voor een commerciële oplossing (de derde mogelijkheid). De combinatie van TLS voor domein naar domein communicatie en een commercieel product voor de domein naar identiteit communicatie zal er waarschijnlijk ook voor zorgen dat er veel minder commerciële licenties nodig zijn (misschien 1 medewerker per afdeling en een aantal losse licenties voor de RSO deelnemer naar leverancier communicatie?) waardoor het financiële voordeel ook een interessante kan blijken te zijn. Dit voorstel wordt hieronder verder uiteengezet. domein naar domein communicatie Het grootste deel van de gevoelige communicatie verloopt tussen de medewerkers van de verschillende zorginstellingen aangesloten bij de RSO. Voor de medewerkers is deze oplossing transparant (ze kunnen blijven werken zoals ze gewend zijn zonder hinderlijke tussen stappen), veilig ( enables server authentication, client authentication, data encryption, and data integrity) en het vergeten van encryptie door de eindgebruikers is uitgesloten doordat de encryptie niet kan worden vergeten. Voor de RSO deelnemers is deze oplossing goedkoop. De stappen die hiervoor nodig zijn: Fase Wat te doen doorlooptijd resultaat Fase 1 Wijziging indienen en door CAB heen 1 maand Project gestart Fase 2 Bestellen en installeren van een certificaat op de mailserver 1 maand Secure e-mail is gerealiseerd (Opportunistic TLS) maar niet afgedwongen* Fase 3 TLS afdwingen naar RSO deelnemers 1 maand Secure e-mail afgedwongen (Mutual TLS/Domain security) tussen RSO deelnemers * Na stap 2 zullen de RSO mail servers altijd proberen een secure e-mail verbinding op te zetten over TLS. Echter indien dit niet mogelijk is (bijvoorbeeld omdat een exchange server gemigreerd is waarbij men vergeten is om het certificaat te installeren / TLS te activeren) zal worden terug gevallen op de standaard onveilige SMTP verbinding. Dit is niet meer mogelijk na stap 3 waarna de e-mail verbinding tussen de RSO deelnemers of veilig is of niet werkt. domein naar identiteit communicatie Het gebruik van TLS is hier praktisch niet uitvoerbaar en bovendien moeten wij de patiënt ook in bescherming nemen tegen het meelezen door de publieke e-mail aanbieders. De enige discussie die je hier zou kunnen voeren is die in de keuze tussen de eerste keuze, het versleutelen van data in een versleuteld bestand in de bijlage (m.b.v. bijvoorbeeld 7-zip), en de derde keuze, de commerciële oplossing waarbij de voordelen meer naar de commerciële mogelijkheid neigen vanwege de eenvoud in gebruik voor de patiënt en de eenvoud voor wat betreft sleutel uitwisseling. 11
Tekening 1: Domein naar Domein communicatie Huidige situatie Smart host services (zoals Messagelabs) Office365 Protocollen: SMTP on port 25: RFC 5321 SMTPS on port 465: revoked ESMTP on port 25 or 587: rfc 1869 en 6409 STARTTLS on port 25 or 587: rfc 3207 Gmail.com mogelijk Yahoo.com mogelijk Hotmail.com, outlook.com, live.com niet mogelijk MS Exchange RPC over HTTPS MS Exchange RPC over HTTPS Internet Domein Z SMTP SMTP of SMTP SMTP Outside FIREWALL Inside LAN DMZ POP3, IMAP, MS Exchange, Lotus Domino SMTP relay server SMTP Special client Outside Domein X Outside Domein Y FIREWALL Inside LAN DMZ POP3, IMAP, MS Exchange of Lotus Domino SMTP Email server FIREWALL Inside LAN DMZ MS Exchange RPC over HTTPS MS Exchange RPC over HTTPS MS Exchange server <=2007
Tekening2: Domein naar Domein communicatie Toekomstige situatie Smart host services (zoals Messagelabs) Office365 Protocollen: SMTP on port 25: RFC 5321 SMTPS on port 465: revoked ESMTP on port 25 or 587: rfc 1869 en 6409 STARTTLS on port 25 or 587: rfc 3207 Gmail.com Yahoo.com Hotmail.com, outlook.com, live.com niet mogelijk MS Exchange RPC over HTTPS MS Exchange RPC over HTTPS Internet Domein Z Outside FIREWALL Inside LAN DMZ POP3, IMAP, MS Exchange, Lotus Domino SMTP relay server Special client Outside Domein X Outside Domein Y FIREWALL Inside LAN DMZ POP3, IMAP, MS Exchange of Lotus Domino SMTP Email server FIREWALL Inside LAN DMZ MS Exchange RPC over HTTPS MS Exchange RPC over HTTPS MS Exchange server <=2007 13
Kosten Implementatie/configuratie: Tussen de 8 en 20 uur, afhankelijk van beschikbare kennis. Certificaten Geen self signed Reeds bestaande (web) SSL certificaten kunnen worden hergebruikt Indien nieuw: Certificaat lifespan: 3-5 jaar Kosten: 450-800 excl. btw
Bijlage Techniek Veiligheid van secure e-mail 100% veiligheid is niet realiseerbaar omdat er zaken zijn die IT beheer niet onder controle heeft: Gebruikers vormen altijd een risco (weggeven wachtwoorden aan college of via post-it) (Fysiek) toegang tot netwerk apparatuur bij ISP s niet onder controle Uitsluiten hardware matige keyloggers is niet mogelijk Verder zijn er zaken op secure e-mail van toepassing die IT beheer wel onder controle heeft maar die niet bij alle RSO deelnemers zullen zijn ingeregeld: Sender Policy Framework (SPF) DNSsec Hostfile security Server hardening (firewall, overbodige services uitschakelen, antivirus) Monitoring op aanvallen op de servers DMZ configuratie (Fysieke) toegang tot eigen netwerk beveiligen 15
STARTTLS STARTTLS is de vervanger van SMTPS. SMTPS had als nadeel dat het een aparte poort (465) nodig had (zoals http standaard poort 80 gebruikt en https poort 443) waardoor de backward compatibility in het gedrang kwam. STARTTLS is een mogelijkheid op de mailserver die je kunt inschakelen waardoor zowel beveiligde (TLS encrypted) als onveilige verbindingen kunnen worden ontvangen op dezelfde poort (SMTP poort 25). Belangrijk is dat hiervoor een officieel certificaat wordt aangevraagd omdat een self signed certificaat niet vertrouwd zal worden door de servers die een TLS verbinding willen opzetten met de ontvangende mail server waarna er zal worden terug geschakeld naar de onveilige vorm van SMTP. (Uiteraard kan ook dit opgelost worden door elkaars self signed certificaten te vertrouwen maar dit is, naast het feit dat organisaties buiten de RSO in dit geval niet veilig naar je domein kunnen mailen, beheerstechnisch niet wenselijk). Vanaf Exchange server 2007 probeert de verzendende exchange server standaard een STARTTLS verbinding op te zetten en zal er alleen een onveilige verbinding opgezet worden indien dit faalt. Smart host services Ook in geval van gebruik van smart host services in de cloud zijn er oplossingen mogelijk: Meestal is het mogelijk om een TLS verbinding op te zetten met de smart host service zodat zowel het verzenden als het ontvangen van e-mail encrypted kan plaats vinden. Indien dit niet mogelijk is kan er een aparte send connector worden aangemaakt om het uitgaande e-mail verkeer rechstreeks af te leveren bij de ontvangende SMTP server over TLS. 16
Controleren TLS gebruik bij een ander domein Als eerst de mail server(s) van het domein achterhalen op b.v.: http://mxlookup.online-domain-tools.com/ Onthoud degene met de laagste preference value. Vervolgens controleren of de server TLS ondersteund: Dit doe je door te telnetten naar de mailserver en vervolgens het EHLO (opvolger HELO) command in te geven. Indien STARTTLS er tussen staat betekent dit dat de server het STARTTLS commando kan ontvangen. Het kan zijn dat je in deze stap een foutmelding terug krijgt zoals: Server error: 501 5.0.0 helo requires domain address 501 Syntactically invalid EHLO argument(s) In dit geval dien je gedag (EHLO) te zeggen en waar je vandaan komt dus: EHLO jouwdomein.nl 17
Als je hebt vastgesteld dat de server STARTTLS ondersteunt kan je de openssl client gebruiken om het starttls commando uit te voeren. Dit commando zorgt er voor dat openssl eerst een normale verbinding maakt met de SMTP server, het STARTTLS commando stuurt en TLS encryptie onderhandeld. openssl s_client -starttls smtp -crlf -connect bronovo-nl.mail.protection.outlook.com:25 18
Om vervolgens te controleren of het certificaat gevalideerd is (en niet self signed zoals na een default Exchange server 2010 installatie) doe je het volgende: Kopieer het certificaat (inclusief -----BEGIN CERTIFICATE----- alles wat er tussen ligt en ----- END CERTIFICATE-----) uit de CMD output naar een.txt file. Verander de.txt naar.crt en Dubbelklik op dit bestand Klik op het tabje certification Path, onder Certificate status is aangegeven of het certificaat self signed is (The issuer of this certificate could not be found) of validated (This certificate is OK). Om het oude SMTPS (welke rfc niet meer bestaat omdat dit vervangen is door STARTLS) te testen op poort 465 (SSL), waarbij een SSL connective wordt opgezet voordat de SMTP conversatie start, kan je het volgende commando gebruiken (voor IP adres x.x.x.x): openssl s_client -crlf -connect x.x.x.x:465 19
Implementeren Opportunistic TLS (fase 2) We bespreken hier alleen de Exchange mail server. Deze mail server van Microsoft is de meest gebruikte mail server bij de RSO deelnemers. De TLS oplossing is een generieke oplossing die ook op andere mail servers (zoals Novell of apple s OS x server) gebruikt kan worden. Exchange server 2010: http://technet.microsoft.com/en-us/library/bb430753(v=exchg.141).aspx http://windowsitpro.com/exchange-server-2010/use-tls-smtp-secure-your-email Exchange server 2013: http://technet.microsoft.com/en-us/library/bb430753.aspx Exchange server 2007: http://technet.microsoft.com/en-us/library/bb430753(v=exchg.80).aspx 20
Implementeren Mutual TLS (fase 3) Exchange 2010: http://technet.microsoft.com/en-us/library/bb123543.aspx http://windowsitpro.com/exchange-server/securing-smtp-email-traffic Exchange 2013: http://social.technet.microsoft.com/wiki/contents/articles/17842.configuring-domain-security-onexchange-server-2013.aspx Exchange 2007: http://technet.microsoft.com/en-us/library/bb123543(exchg.80).aspx http://technet.microsoft.com/en-us/library/bb266978(v=exchg.80).aspx 21
Begrippenlijst Simple Mail Transport Protocol (SMTP) - Het protocol welke het mogelijk maakt om e-mails uit te wisselen tussen e-mail servers. Ook kan het gebruikt worden om e-mails vanuit een e-mail client te versturen aan een e-mail server. Het ophalen van e-mail door de e-mail client gebeurd met andere protocollen zoals bijvoorbeeld pop3. Secure e-mail - is e-mail encrytpie, en vaak ook authenticatie, van e-mail berichten met als doel de inhoud van de e-mail te beschermen tegen ongeautoriseerd lezen door derden Exchange - De mail server software van Microsoft. s/mime - Secure/Multipurpose Internet Mail Extensions. Een standaard voor het beveiligd verzenden van e-mail. PGP - Pretty Good Privacy. Een protocol dat gebruikt kan worden voor o.a. encryptie en decryptie van data, e-mails, disk partities e.d. http - Hypertext Transfer Protocol. Protocol voor de communicatie tussen een webbrowser en een webserver. https - Hypertext Transfer Protocol Secure: Http beveiligd door SSL/TLS 22
Transport Layer Security (TLS) - is de opvolger van Secure Sockets Layer (SSL). TLS en SSL zijn protocollen om applicatie onafhankelijke beveiligde verbindingen op te kunnen zetten over o.a. het internet. AES-256 Advanced Encryption Standard. Een encryptie standaard die o.a. gebruikt kan worden in TLS/SSL verbindingen. AES-256 wordt over het algemeen gezien als een van de veiligste vormen van encryptie. Deze veiligheid is echter ook afhankelijk van de versie van SSL of TLS. Zie onder: 23