E-mail encryptie exchange 2013

15-02-2016, 09:57 door Anoniem

https://technet.microsoft.com/en-us/library/dn626158%28v=exchg.150%29.aspx

15-02-2016, 10:10 door sjonniev

Door Dell: Beste Security.nl Lezers,

Wij zijn van plan om binnen onze bedrijf email encryptie te gaan implementeren door de nieuwe wet "data lek" die per 1 januari is ingegaan. Wij maken gebruik van een exchange 2013 omgeving. Mijn vraag bij deze is, wat zijn de mogelijkheden hiervoor?. Graag zie ik jullie reacties tegemoet.

Makkelijk: zet een apparaat tussen je mailserver(s) en internet en laat deze berichten versleutelen op basis van eigenschappen van de uitgaande mail
Moeilijker: geef iedereen een smart card met sleutelpaar en certificaat en ga lekker aan de S/Mime.

15-02-2016, 11:16 door Hobbyist

@ sjonniev
Bedankt voor je reactie, kan je iets specifieker zijn d.m.v. een voorbeeld en de beschikbare producten/leveranciers die dat kunnen?. Ik ben nieuw op dit gebied, alle hulp en reacties zijn welkom.

15-02-2016, 12:54 door sjonniev

Voorbeeld: je laat de uitgaande mail van je mail server richting gateway sturen. Je voorziet je mail van een header Sensitivity:Company Confidential. De gateway snapt dat de mail versleuteld moet worden.

Ander voorbeeld:je laat de uitgaande mail van je mail server richting gateway sturen. Je stelt die gateway zo in dat er DLP-regels op de inhoud van de mail kan worden losgelaten (RegEx, Classificatietags, etc). Zodra zo´n dlp-regel getriggerd worden: emailversleuteling toepassen.

Emailversleutelingsgateway met diverse mogelijkheden: https://www.compumatica.com/producten/compumail-gateway

Mailsecurity gateways met versleutelingsmogelijkheden: https://www.sophos.com/en-us/products/secure-email-gateway.aspx

Security gateway met mail security en versleutelingsmogelijkheden: https://www.sophos.com/en-us/lp/utm-upgrades.aspx.

Er zijn er ongetwijfeld meer, maar dit is waar ik ervaring mee heb.

15-02-2016, 13:18 door Hobbyist

@ 09:57 door Anoniem
Deze was ik inderdaad wel tegengekomen.. Wij zoeken eigenlijk een derde partij oplossing die eventueel ook spamfiltering kan verzorgen..

15-02-2016, 13:19 door Hobbyist

@ Sjonniev

Dank voor je reactie, doen deze producten ook aan spamfiltering?.

15-02-2016, 14:18 door Rolfieo

Door Hobbyist: Beste Security.nl Lezers,

Wij zijn van plan om binnen onze bedrijf email encryptie te gaan implementeren door de nieuwe wet "data lek" die per 1 januari is ingegaan. Wij maken gebruik van een exchange 2013 omgeving. Mijn vraag bij deze is, wat zijn de mogelijkheden hiervoor?. Graag zie ik jullie reacties tegemoet.

Encryptie is mooi, maar wat wil je er exact mee bereiken? Het is namelijk momenteel een kreet waar je eigenlijk alle kanten op kan.
Als je iets wilt encrypteren, zal de andere kant dit moeten snappen. Dus hoe wil je dat gaan regelen?

Je bent nu al technisch aan het denken, maar wat wil je eigenlijk functioneel bereiken? Dus eerst even een stapje terug, wat je exact wilt bereiken met je oplossing.

15-02-2016, 19:58 door sjonniev

Door Hobbyist: @ Sjonniev

Dank voor je reactie, doen deze producten ook aan spamfiltering?.

De compumail gateway niet, de anderen wel.

15-02-2016, 21:27 door Anoniem

er zijn 3 methoden gebruikelijk:
- bescherm transport van mail over internet: SMTP met TLS. Je kan bijvoorbeeld TLS verplicht stellen voor versturen naar bepaalde domeinnamen, waarmee je afspraken hebt.
- bescherm inhoud van mail: SMIME. de mail client versleuteld mail met certificaat. Ontvanger moet ook SMIME ondersteunen. Gebruikt 3rd party root voor praktische implementatie
- gebruik een gateway, die de mail encrypted beschikbaar maakt in een browservenster; mail naar buiten laat je afslag naar deze gateway nemen; ontvanger krijgt mailtje dat er een bericht gereed staat.

Paul

16-02-2016, 09:31 door Hobbyist

@sjonniev, dankje wel voor je antwoorden!

@Rolfieo

Het gaat erom dat wanneer gevoelige email de deur uitgaat deze wordt versleutelt, en deze enkel door ontvanger gelezen kan worden.. Dit moet eigenlijk het liefst zonder dat de gebruiker die de email verzendt dit merkt..
Als ik niet duidelijk genoeg ben dan hoor ik dat graag.. Het liefst heb ik dus een oplossing die ook aan spamfiltering doet..

16-02-2016, 09:42 door Hobbyist

Door Anoniem: er zijn 3 methoden gebruikelijk:
- bescherm transport van mail over internet: SMTP met TLS. Je kan bijvoorbeeld TLS verplicht stellen voor versturen naar bepaalde domeinnamen, waarmee je afspraken hebt.
- bescherm inhoud van mail: SMIME. de mail client versleuteld mail met certificaat. Ontvanger moet ook SMIME ondersteunen. Gebruikt 3rd party root voor praktische implementatie
- gebruik een gateway, die de mail encrypted beschikbaar maakt in een browservenster; mail naar buiten laat je afslag naar deze gateway nemen; ontvanger krijgt mailtje dat er een bericht gereed staat.

Paul

Bedankt voor je antwoord: kan je iets meer uitleggen over de eerste methode?. Kan dat standard in exchange 2013?.

16-02-2016, 13:32 door Rolfieo

Door Hobbyist: @sjonniev, dankje wel voor je antwoorden!

@Rolfieo

Het gaat erom dat wanneer gevoelige email de deur uitgaat deze wordt versleutelt, en deze enkel door ontvanger gelezen kan worden.. Dit moet eigenlijk het liefst zonder dat de gebruiker die de email verzendt dit merkt..
Als ik niet duidelijk genoeg ben dan hoor ik dat graag.. Het liefst heb ik dus een oplossing die ook aan spamfiltering doet..

Dit betekend dus dat de andere kant ook het certificaat moet ondersteunen, anders kan die de Email niet lezen. Maar als je iedere Email gaat encrypten, zal IEDEREEN jouw certificaat moeten weten. Iets wat weer erg lastig is in beheer. Want wat als je morgen iets wilt versturen naar een nieuw iemand, met wie jullie nog nooit gecommuniceerd hebben? Die kan dan je Email weer niet lezen.
En wat als je per ongelijk een Email naar een verkeerd iemand stuurt. Die kan indien het certificaat heeft, ook de Email gewoon lezen.Immers die heeft het certificaat al.

Je moet eerst hiervoor oplossingen gaan bedenken , voordat je in de techniek iets wilt gaan doen. Beide zijn namelijk zeer lastig op te lossen punten en waar je eerst over nagedacht hebt.

Je bent eigenlijk al met dingen bezig, zonder dat je eigenlijk weet hoe en of wat je werkelijk wilt hebben. Techniek / welk producten zijn nog helemaal niet van belang. Eerst een paar stappen terug.
TLS bijvoorbeeld gaat helemaal niets oplossen voor je. De Email wordt dan een beetje encrypted verstuurd, maar certificaten worden niet gecontroleerd, en als je iets per ongelijk verstuurd naar pietje@mijnhotmail zal deze gewoon aankomen.

Je wilt eigenlijk dus dat de niet zomaar vertrouwelijke Emails naar verkeerde Email adres kunt sturen. Daar heb je hele andere producten voor welke dit juist bewaken.
Je zou je daar eigenlijk op moeten focusen.
Wat je eigenlijk wilt hebben is Data Loss Prevention (DLP) als dan niet icm met Encryptie.

Maar ga eerst eens een paar stappen terug, en denk Functioneel wat je wilt hebben. Welke techniek je hiervoor gaat gebruiken is nog helemaal niet van belang.

16-02-2016, 13:32 door sjonniev - Bijgewerkt: 16-02-2016, 14:04

SMTP over TLS is alleen maar een tunnel tussen MTA´s. De berichten zelf zijn nog net zo onbeschermd wanneer ze de tunnel weer verlaten. TLS is niet geschikt om de inhoud van berichten te beschermen. Deze fout wordt vaker gemaakt.

17-02-2016, 10:16 door Hobbyist

@Rolfieo
Bedankt voor de uitleg, voor wat betreft de functionaliteit eerst in kaart brengen maakt het inderdaad makkelijker om daarna naar de techniek te kijken. Aan de hand van jou verhaal heb ik de volgende vragen aan mijn manager voorgelegd:

- Is het de bedoeling dat bepaalde data niet per mail verstuurd mag worden?
- Is het de bedoeling dat de inhoud van de email wordt beschermt of het transport ervan?
- Indien de inhoud van de email beschermt moet worden, Is het dan de bedoeling dat bepaalde gebruikers of iedereen gevoelige data mag verzenden?
- Is het de bedoeling dat de vertrouwelijke e-mails niet zomaar/per ongeluk naar verkeerder email adres kunt sturen?

Zijn deze vragen voldoende, welke vragen zou je nog meer kunnen stellen om dit nog beter in beeld te krijgen.

Nogmaals bedankt..

17-02-2016, 10:47 door Anoniem

"Je moet eerst hiervoor oplossingen gaan bedenken , voordat je in de techniek iets wilt gaan doen. Beide zijn namelijk zeer lastig op te lossen punten en waar je eerst over nagedacht hebt."

Je moet bedenken dat degenen die nu met dit probleem te maken hebben, helemaal niet willen encrypten maar dit
moeten doen omdat er nou eenmaal een nieuwe wet is. Die wet zegt niet dat je moet encrypten, maar als er een
probleem optreedt en je hebt ge-encrypt dan sta je er gewoon veel beter voor. Dus encrypten.

Of het nou allemaal zo veel beter daar van wordt dat is verder niet zo belangrijk. Zie het als die idioterie rond het omzetten
van alle sites naar https, dat dient ook geen enkel echt doel rond encryptie maar is puur belangrijkdoenerij.

Als je een datalek hebt en de instanties gaan kijken naar of jij encrypted mailt dan gaan ze echt niet uitzoeken wie er
allemaal wiens key hebben en wie niet. Er komt een vinkje bij "encrypted" en klaar.
Vergelijk het met de cookiewet, allemaal een layer of popup die waarschuwt dat er cookies zijn en klaar zijn we, het
eigenlijke probleem is niet opgelost en het werken is weer moeilijker gemaakt, maar bepaalde zichzelf belangrijk
vindende mensen zijn blij en hebben het beeld geschetst dat ze de wereld gered hebben en daar gaat het toch allemaal
om.

17-02-2016, 11:52 door Rolfieo

Door Hobbyist: @Rolfieo
Bedankt voor de uitleg, voor wat betreft de functionaliteit eerst in kaart brengen maakt het inderdaad makkelijker om daarna naar de techniek te kijken. Aan de hand van jou verhaal heb ik de volgende vragen aan mijn manager voorgelegd:

- Is het de bedoeling dat bepaalde data niet per mail verstuurd mag worden?
- Is het de bedoeling dat de inhoud van de email wordt beschermt of het transport ervan?
- Indien de inhoud van de email beschermt moet worden, Is het dan de bedoeling dat bepaalde gebruikers of iedereen gevoelige data mag verzenden?
- Is het de bedoeling dat de vertrouwelijke e-mails niet zomaar/per ongeluk naar verkeerder email adres kunt sturen?

Zijn deze vragen voldoende, welke vragen zou je nog meer kunnen stellen om dit nog beter in beeld te krijgen.

Nogmaals bedankt..

Moet het automatisch of niet?
Wat mag het kosten?
Wat mag de gebruikers impact zijn?
Server afhankelijkheid? Client afhankelijkheid?

Er zullen vast veel mee vragen zijn, maar dit zijn belangrijke vragen waar je over na moet denken voordat je iets in de techniek kan bedenken

17-02-2016, 11:59 door Rolfieo

Door Anoniem: "Je moet eerst hiervoor oplossingen gaan bedenken , voordat je in de techniek iets wilt gaan doen. Beide zijn namelijk zeer lastig op te lossen punten en waar je eerst over nagedacht hebt."

Je moet bedenken dat degenen die nu met dit probleem te maken hebben, helemaal niet willen encrypten maar dit
moeten doen omdat er nou eenmaal een nieuwe wet is. Die wet zegt niet dat je moet encrypten, maar als er een
probleem optreedt en je hebt ge-encrypt dan sta je er gewoon veel beter voor. Dus encrypten.

Als echter iedereen de key heeft om de encryptie ongedaan te maken, heeft encryptie niet zoveel nut. Het heeft geen nut om iedere email te encrypten, omdat dan of niemand je Email meer kan lezen, of iedereen moet de encryptie key hebben. Waarna Encryptie eigenlijk geen nut meer heeft.

Encryptie, hoeft dus helemaal niet de oplossing te zijn.

Als je een datalek hebt en de instanties gaan kijken naar of jij encrypted mailt dan gaan ze echt niet uitzoeken wie er
allemaal wiens key hebben en wie niet. Er komt een vinkje bij "encrypted" en klaar.

Nadeel is, dat als je iedere Email ecrypted verstuurd, iemand je Email meer kan lezen zonder de keys. Je bedrijf kan dan niet meer communiceren, en dus niet meer werken.

Daarom moet je eerst eens kijken wat je wilt bereiken, en daarna hoe je dit wilt bereiken. even ecryptie noemen heeft geen nut.

Je wilt eigenlijk Data Loss Prevention hebben, als dan niet met encryptie.

17-02-2016, 13:38 door Hobbyist

@ Anoniem Vandaag, 10:47
Bedankt voor je reactie. Als encryptie ervoor zorgt dat iedere nieuwe organisatie mijn encryptie key moet hebben om email te kunnen lezen, is dat voor ons niet de oplossing. Het zijn veel te veel organisaties en gebruikers waarmee gecommuniceerd wordt.

@Rolfieo
in het geval DLP met encryptie, moeten de organisaties/gebruikers waarmee gecommuniceerd wordt ook de encryptie key hebben of gaat dat anders?.

Alvast bedankt..

17-02-2016, 13:52 door Rolfieo - Bijgewerkt: 17-02-2016, 13:52

Door Hobbyist: @ Anoniem Vandaag, 10:47
Bedankt voor je reactie. Als encryptie ervoor zorgt dat iedere nieuwe organisatie mijn encryptie key moet hebben om email te kunnen lezen, is dat voor ons niet de oplossing. Het zijn veel te veel organisaties en gebruikers waarmee gecommuniceerd wordt.

Dit is inderdaad juist de redenen waarom je eerst functioneel moet denken, en niet meteen de techniek in.

@Rolfieo
in het geval DLP met encryptie, moeten de organisaties/gebruikers waarmee gecommuniceerd wordt ook de encryptie key hebben of gaat dat anders?.

Alvast bedankt..

Ik zou zeggen google eens. Niet verkeerd bedoelt.....
Als ik even snel mij Mcafee kijk naar hun DLP product:

The McAfee DLP Prevent appliance allows you to take a variety of remediation actions, including encrypting, redirecting, quarantining, and blocking—so you can ensure compliance with regulations governing the privacy of sensitive information and reduce the data risk to your business.[/i]

Zo zijn er nog meer producten die dit kunnen.

17-02-2016, 13:55 door Anoniem

Door Rolfieo:

Door Anoniem: "Je moet eerst hiervoor oplossingen gaan bedenken , voordat je in de techniek iets wilt gaan doen. Beide zijn namelijk zeer lastig op te lossen punten en waar je eerst over nagedacht hebt."

Je moet bedenken dat degenen die nu met dit probleem te maken hebben, helemaal niet willen encrypten maar dit
moeten doen omdat er nou eenmaal een nieuwe wet is. Die wet zegt niet dat je moet encrypten, maar als er een
probleem optreedt en je hebt ge-encrypt dan sta je er gewoon veel beter voor. Dus encrypten.

Als echter iedereen de key heeft om de encryptie ongedaan te maken, heeft encryptie niet zoveel nut.

Nogmaals: dat doet er niet toe.
Net als dat het geen nut heeft om alle websites te encrypten, net als dat het geen nut heeft om iedere site te
voorzien van een waarschuwing over cookies.
Het doel is niet het onmogelijk maken dat iemand de data ziet, het doel is het kunnen zetten van een checkmark.

Als je een datalek hebt en de instanties gaan kijken naar of jij encrypted mailt dan gaan ze echt niet uitzoeken wie er
allemaal wiens key hebben en wie niet. Er komt een vinkje bij "encrypted" en klaar.

Nadeel is, dat als je iedere Email ecrypted verstuurd, iemand je Email meer kan lezen zonder de keys. Je bedrijf kan dan niet meer communiceren, en dus niet meer werken.

Het gaat in dit geval uiteraard alleen om mails met persoonsgegevens er in (of in de bijlagen).
Die je stuurt naar iemand waar je al keys mee hebt uitgewisseld.
Tuurlijk gaat dit niks helpen. Dat is duidelijk. Maar er is een wet dus zul je er aan mee moeten werken.

17-02-2016, 14:01 door Anoniem

Door Rolfieo:
Dit betekend dus dat de andere kant ook het certificaat moet ondersteunen, anders kan die de Email niet lezen. Maar als je iedere Email gaat encrypten, zal IEDEREEN jouw certificaat moeten weten. Iets wat weer erg lastig is in beheer. Want wat als je morgen iets wilt versturen naar een nieuw iemand, met wie jullie nog nooit gecommuniceerd hebben? Die kan dan je Email weer niet lezen.
En wat als je per ongelijk een Email naar een verkeerd iemand stuurt. Die kan indien het certificaat heeft, ook de Email gewoon lezen.Immers die heeft het certificaat al.

Het is tegenwoordig gebruikelijk om asymmetrische encryptie te gebruiken. Als je een mail naar iemand wilt sturen
die encrypted moet zijn, vraag je aan die iemand zijn publieke key, je encrypt het onder die key, en die iemand heeft
de bijbehorende secret key en kan het decrypten. Het is dus niet zo dat je allerlei mensen jouw key geeft en dat die
mensen dan al jouw mails kunnen decrypten ook degenen die naar anderen gestuurd zijn.

Dit houdt uiteraard niet tegen dat mails verkeerd gestuurd worden want de mailprogramma's (zoals Outlook 2013 waar
dit over gaat) hebben allemaal een handige opbergplaats voor die keys die ze keurig koppelt aan de gebruiker, dus
als je regelmatig met allerlei mensen encrypted communiceert en je maakt een vergissing bij het selecteren van een
adres uit je adresboek dan zoekt het programma daar feilloos de juiste key bij en kan de ontvanger het gewoon lezen.

Dat is echter geen gevolg van het werkingsprincipe van de encryptie maar van het te ver doorgeschoten gebruikersgemak
van de programma's, dat heb je wel met meer dingen.

17-02-2016, 15:51 door Rolfieo

Door Anoniem:

Door Rolfieo:
Dit betekend dus dat de andere kant ook het certificaat moet ondersteunen, anders kan die de Email niet lezen. Maar als je iedere Email gaat encrypten, zal IEDEREEN jouw certificaat moeten weten. Iets wat weer erg lastig is in beheer. Want wat als je morgen iets wilt versturen naar een nieuw iemand, met wie jullie nog nooit gecommuniceerd hebben? Die kan dan je Email weer niet lezen.
En wat als je per ongelijk een Email naar een verkeerd iemand stuurt. Die kan indien het certificaat heeft, ook de Email gewoon lezen.Immers die heeft het certificaat al.

Het is tegenwoordig gebruikelijk om asymmetrische encryptie te gebruiken. Als je een mail naar iemand wilt sturen
die encrypted moet zijn, vraag je aan die iemand zijn publieke key, je encrypt het onder die key, en die iemand heeft
de bijbehorende secret key en kan het decrypten. Het is dus niet zo dat je allerlei mensen jouw key geeft en dat die
mensen dan al jouw mails kunnen decrypten ook degenen die naar anderen gestuurd zijn.

Dit houdt uiteraard niet tegen dat mails verkeerd gestuurd worden want de mailprogramma's (zoals Outlook 2013 waar
dit over gaat) hebben allemaal een handige opbergplaats voor die keys die ze keurig koppelt aan de gebruiker, dus
als je regelmatig met allerlei mensen encrypted communiceert en je maakt een vergissing bij het selecteren van een
adres uit je adresboek dan zoekt het programma daar feilloos de juiste key bij en kan de ontvanger het gewoon lezen.

Dat is echter geen gevolg van het werkingsprincipe van de encryptie maar van het te ver doorgeschoten gebruikersgemak
van de programma's, dat heb je wel met meer dingen.

Correct maar dit lost het probleem eigenlijk niet op waar TS zich tegen wilt beschermen.
Of het gebeurt automatisch voor iedere Email, of het is een handmatige actie.
Indien het automatisch gebeurt zal iedere Email encrypted moeten zijn. Met het probleem dat de andere kant een key moet hebben om de Email te lezen.
Bij een handmatige actie, wil wordt het juist vergeten of niet gedaan. En lost menselijk falen, wat bijna altijd het issue is bij Email, niet op.

Daarom is DLP juist uitgevonden is. Dit pakt het probleem intelligent op en neemt voorgedefinieerde acties.

17-02-2016, 19:48 door Anoniem

Door Rolfieo:
Correct maar dit lost het probleem eigenlijk niet op waar TS zich tegen wilt beschermen.
Of het gebeurt automatisch voor iedere Email, of het is een handmatige actie.
Indien het automatisch gebeurt zal iedere Email encrypted moeten zijn. Met het probleem dat de andere kant een key moet hebben om de Email te lezen.
Bij een handmatige actie, wil wordt het juist vergeten of niet gedaan. En lost menselijk falen, wat bijna altijd het issue is bij Email, niet op.

Neen dit probleem is er niet!
Niet de ontvanger moet zorgen dat hij de beschikking krijgt over de key om het te lezen, nee, de verzender moet zorgen
dat hij de key van de ontvanger krijgt om mail mee te versturen. Heeft hij die niet dan kan hij alleen plaintext sturen met
een verzoek om te replyen met een ondertekend mailtje met die key.
Heeft hij die (nog) niet dan zal het mail programma weigeren om mail te sturen met de encryptie optie aan, en krijg
je dus de mogelijkheid de mail zonder encryptie te sturen.

En nogmaals: het gaat helemaal niet om de encryptie, het is alleen een formaliteit voor de wet.

18-02-2016, 02:13 door Anoniem

Neen dit probleem is er niet!
Niet de ontvanger moet zorgen dat hij de beschikking krijgt over de key om het te lezen, nee, de verzender moet zorgen
dat hij de key van de ontvanger krijgt om mail mee te versturen. Heeft hij die niet dan kan hij alleen plaintext sturen met
een verzoek om te replyen met een ondertekend mailtje met die key.
Heeft hij die (nog) niet dan zal het mail programma weigeren om mail te sturen met de encryptie optie aan, en krijg
je dus de mogelijkheid de mail zonder encryptie te sturen.

Helemaal correct! In ieder geval voor wat betreft GnuPG methode. Andere methoden weet ik niet precies.
Alleen je kan als bedrijf natuurlijk ook het initiatief nemen, en een bulkmail rondsturen met je eigen publieke sleutel:
"Blablabla hierbij onze publieke sleutel, zodat je ons voortaan beveiligde e-mail kan sturen.
En als je voortaan ook je e-mail beveiligd van ons wil ontvangen stuur dan een mail terug met jouw publieke sleutel."
Vervolgens zullen de "fingerprints" van de sleutels van iedereen die reageert moeten worden geverifieerd
(niet per e-mail, maar bijv. telefonisch;
tenminste... als je 100% zeker wil zijn van de afkomst van de e-mail (Authenticatie)... Lijkt mij minstens zo belangrijk!)
en dient alles uiteraard te worden ingevoerd in het systeem.

Vanaf dat moment kan je veilig e-mailen met iedereen die daartoe in staat is.
Je kan ook besluiten om te weigeren bepaalde gevoelige informatie per onbeveiligde e-mail uit te wisselen:
("Blablabla wegens wet datalekken etc...)
Neem het heft maar in handen. Het is er belangrijk genoeg voor.

En nogmaals: het gaat helemaal niet om de encryptie, het is alleen een formaliteit voor de wet.

Dit snap ik niet zo goed. Het is volgens mij niet "alleen maar een formaliteit". Dit vond ik wel een verhelderende link:
https://www.linkedin.com/pulse/de-wet-datalekken-normale-mensentaal-jochen-den-ouden

Het gaat dus om alle ernstige datalekken waar het persoonlijke gegevens betreft.
Ben je dus zorginstelling of zorgverzekeraar of zo, en zit je stapels met BSN-nummers en andere persoonsgegevens
heen en weer te mailen, dan kan je volgens mij maar beter e-mail-encryptie gebruiken,
want anders ben je veel te gemakkelijk een keer het haasje!

Met de nieuwe wet is namelijk de inspanningsplicht om persoonlijke data goed te beveiligen verzwaard,
en kun je een fikse boete tegemoet zien als je een ernstig lek niet meteen meldt, of als je je inspanningsplicht
om persoonlijke data goed te beveiligen hebt verzuimd.

Aan de topicstarter: misschien is GnuPG iets voor je.
Hier een website om Exchange hiervoor geschikt te maken: https://www.giepa.de/products/gpg4o/?lang=en
Daar kan je vast ook meer informatie inwinnen over GnuPG op Exchange servers.

Voordeel van GnuPG is dat bijna elke computer (linux, windows, Mac) er mee kan werken,
dankzij Thunderbird met GnuPG- en Enigmail plugins.

De vele handleidingen die op internet te vinden zijn, helpen bovendien goed op weg om de zaken werkend te krijgen.
Bijv. https://enigmail.wiki/Quick_start.
Zo kan dus ieder E-mailontvanger in principe prima beveiligde e-mail ontvangen en versturen.

Goeroehoedjes

18-02-2016, 11:11 door sjonniev

Door Hobbyist: @ Anoniem Vandaag, 10:47
Bedankt voor je reactie. Als encryptie ervoor zorgt dat iedere nieuwe organisatie mijn encryptie key moet hebben om email te kunnen lezen, is dat voor ons niet de oplossing. Het zijn veel te veel organisaties en gebruikers waarmee gecommuniceerd wordt.

Nee hoor, zo werkt e-mailversleuteling niet (per se).

Zie bijvoorbeeld https://vimeo.com/97463770. Je kunt het ook zo instellen dat de ontvanger zelf zijn sleutel bepaalt.
Uiteraard zou het fijn zijn als de organisaties waar je mee communiceert zelf als PGP of S/Mime zouden gebruiken, maar helaas.

18-02-2016, 16:20 door Anoniem

Door Anoniem:
Helemaal correct! In ieder geval voor wat betreft GnuPG methode. Andere methoden weet ik niet precies.

Dit gaat over Outlook dus neem maar aan dat het over S/MIME gaat en niet over PGP of GPG ofzo.
Dat zijn oplossingen voor nerds. De zakenwereld gebruikt Outlook en S/MIME.

Vervolgens zullen de "fingerprints" van de sleutels van iedereen die reageert moeten worden geverifieerd
(niet per e-mail, maar bijv. telefonisch;
tenminste... als je 100% zeker wil zijn van de afkomst van de e-mail (Authenticatie)... Lijkt mij minstens zo belangrijk!)
en dient alles uiteraard te worden ingevoerd in het systeem.

Ach welnee, dat is in de praktijk helemaal niet nodig. Als iemand mail kan sturen vanaf een bepaalde afzender en
de mail kan lezen die naar die afzender gestuurd wordt dan is dat in de normale wereld voldoende authenticatie.
Gedoe over fingerprints dat is, wederom, voor nerds.
Het is jammer dat ze er steeds weer over beginnen want daardoor houden ze normale gebruikers er vanaf omdat
het allemaal te moeilijk wordt.

En nogmaals: het gaat helemaal niet om de encryptie, het is alleen een formaliteit voor de wet.

Dit snap ik niet zo goed. Het is volgens mij niet "alleen maar een formaliteit". Dit vond ik wel een verhelderende link:
https://www.linkedin.com/pulse/de-wet-datalekken-normale-mensentaal-jochen-den-ouden

Het gaat dus om alle ernstige datalekken waar het persoonlijke gegevens betreft.
Ben je dus zorginstelling of zorgverzekeraar of zo, en zit je stapels met BSN-nummers en andere persoonsgegevens
heen en weer te mailen, dan kan je volgens mij maar beter e-mail-encryptie gebruiken,
want anders ben je veel te gemakkelijk een keer het haasje!

Wat ik bedoel is dat al die mitsen en maren rond authenticatie en sleutelbeheer helemaal niet tellen.
Als je een datalek hebt dan is alleen van belang "heb je encrypted gemaild", niet wie allemaal de sleutel hebben en
wie er allemaal man-in-the-middle spelen etc. Dat is de verantwoordelijkheid van anderen, niet van jezelf.

18-02-2016, 20:58 door Anoniem

Door Anoniem:

Neen dit probleem is er niet!
Niet de ontvanger moet zorgen dat hij de beschikking krijgt over de key om het te lezen, nee, de verzender moet zorgen
dat hij de key van de ontvanger krijgt om mail mee te versturen. Heeft hij die niet dan kan hij alleen plaintext sturen met
een verzoek om te replyen met een ondertekend mailtje met die key.
Heeft hij die (nog) niet dan zal het mail programma weigeren om mail te sturen met de encryptie optie aan, en krijg
je dus de mogelijkheid de mail zonder encryptie te sturen.

Helemaal correct! In ieder geval voor wat betreft GnuPG methode. Andere methoden weet ik niet precies.
Alleen je kan als bedrijf natuurlijk ook het initiatief nemen, en een bulkmail rondsturen met je eigen publieke sleutel:
"Blablabla hierbij onze publieke sleutel, zodat je ons voortaan beveiligde e-mail kan sturen.
En als je voortaan ook je e-mail beveiligd van ons wil ontvangen stuur dan een mail terug met jouw publieke sleutel."
Vervolgens zullen de "fingerprints" van de sleutels van iedereen die reageert moeten worden geverifieerd
(niet per e-mail, maar bijv. telefonisch;
tenminste... als je 100% zeker wil zijn van de afkomst van de e-mail (Authenticatie)... Lijkt mij minstens zo belangrijk!)
en dient alles uiteraard te worden ingevoerd in het systeem.

Vanaf dat moment kan je veilig e-mailen met iedereen die daartoe in staat is.
Je kan ook besluiten om te weigeren bepaalde gevoelige informatie per onbeveiligde e-mail uit te wisselen:
("Blablabla wegens wet datalekken etc...)
Neem het heft maar in handen. Het is er belangrijk genoeg voor.

En nogmaals: het gaat helemaal niet om de encryptie, het is alleen een formaliteit voor de wet.

Dit snap ik niet zo goed. Het is volgens mij niet "alleen maar een formaliteit". Dit vond ik wel een verhelderende link:
https://www.linkedin.com/pulse/de-wet-datalekken-normale-mensentaal-jochen-den-ouden

Het gaat dus om alle ernstige datalekken waar het persoonlijke gegevens betreft.
Ben je dus zorginstelling of zorgverzekeraar of zo, en zit je stapels met BSN-nummers en andere persoonsgegevens
heen en weer te mailen, dan kan je volgens mij maar beter e-mail-encryptie gebruiken,
want anders ben je veel te gemakkelijk een keer het haasje!

Met de nieuwe wet is namelijk de inspanningsplicht om persoonlijke data goed te beveiligen verzwaard,
en kun je een fikse boete tegemoet zien als je een ernstig lek niet meteen meldt, of als je je inspanningsplicht
om persoonlijke data goed te beveiligen hebt verzuimd.

Aan de topicstarter: misschien is GnuPG iets voor je.
Hier een website om Exchange hiervoor geschikt te maken: https://www.giepa.de/products/gpg4o/?lang=en
Daar kan je vast ook meer informatie inwinnen over GnuPG op Exchange servers.

Voordeel van GnuPG is dat bijna elke computer (linux, windows, Mac) er mee kan werken,
dankzij Thunderbird met GnuPG- en Enigmail plugins.

De vele handleidingen die op internet te vinden zijn, helpen bovendien goed op weg om de zaken werkend te krijgen.
Bijv. https://enigmail.wiki/Quick_start.
Zo kan dus ieder E-mailontvanger in principe prima beveiligde e-mail ontvangen en versturen.

Goeroehoedjes

Das mooi, maar veel te complex. Als je daarna ooit je keys moet vernieuwen, gaat het 1 groot drama worden en deze key weer overal bij iedereen te krijgen.
Misschien is er juist ook een redenen waarom men eigenlijk in de zaken wereld bijna alleen maar s/mime gebruikt en nooit PGP?

Ik heb nog nooit zo'n verzoek gekregen, of via de servicedesk hierover vragen kregen hoe ze hier mee moeten handelen als gebruikers hierover vragen stellen.
Ik krijg wel regelmatig s/mime emails binnen van externe organisaties of intern. En wij draaien van alles als clients.

Misschien heeft dit ook een redenen?

18-02-2016, 21:06 door Anoniem

Door sjonniev:

Door Hobbyist: @ Anoniem Vandaag, 10:47
Bedankt voor je reactie. Als encryptie ervoor zorgt dat iedere nieuwe organisatie mijn encryptie key moet hebben om email te kunnen lezen, is dat voor ons niet de oplossing. Het zijn veel te veel organisaties en gebruikers waarmee gecommuniceerd wordt.

Nee hoor, zo werkt e-mailversleuteling niet (per se).

Zie bijvoorbeeld https://vimeo.com/97463770. Je kunt het ook zo instellen dat de ontvanger zelf zijn sleutel bepaalt.
Uiteraard zou het fijn zijn als de organisaties waar je mee communiceert zelf als PGP of S/Mime zouden gebruiken, maar helaas.

Dit lost alleen niet het probleem op van TS, als je met deze encryptie de mail verstuurd. De andere "verkeerde" partij krijgt dan gewoon een code om als nog de email te lezen. (En helaas ondersteund dit product ook geen PGP, met als veel andere producten. Het wordt bijna niet gebruikt in een Enterprise. Soms in de Linux wereld, maar bijna overal is het gewoon S/Mime als standaard)

Maar dit toont inderdaad wel aan wat DLP doet. Het neemt actie op bepaalde kenmerken in de Email en dat kan versleutelen zijn.

19-02-2016, 09:15 door sjonniev

Door Anoniem:

Door sjonniev:

Door Hobbyist: @ Anoniem Vandaag, 10:47
Bedankt voor je reactie. Als encryptie ervoor zorgt dat iedere nieuwe organisatie mijn encryptie key moet hebben om email te kunnen lezen, is dat voor ons niet de oplossing. Het zijn veel te veel organisaties en gebruikers waarmee gecommuniceerd wordt.

Nee hoor, zo werkt e-mailversleuteling niet (per se).

Zie bijvoorbeeld https://vimeo.com/97463770. Je kunt het ook zo instellen dat de ontvanger zelf zijn sleutel bepaalt.
Uiteraard zou het fijn zijn als de organisaties waar je mee communiceert zelf als PGP of S/Mime zouden gebruiken, maar helaas.

Dit lost alleen niet het probleem op van TS, als je met deze encryptie de mail verstuurd. De andere "verkeerde" partij krijgt dan gewoon een code om als nog de email te lezen. (En helaas ondersteund dit product ook geen PGP, met als veel andere producten. Het wordt bijna niet gebruikt in een Enterprise. Soms in de Linux wereld, maar bijna overal is het gewoon S/Mime als standaard)

Maar dit toont inderdaad wel aan wat DLP doet. Het neemt actie op bepaalde kenmerken in de Email en dat kan versleutelen zijn.

Dit lost het probleem van TS wel op wanneer je de code door het apparaat or verzender laat genereren, en deze op een andere manier naar de ontvanger stuurt, SMS, telefoongesprek, face to face. Een mail naar een verkeerd mail adres sturen, en dan de code ook nog naar het verkeerde telefoonnummer communiceren is dan nodig om te lekken.

PGP en S/Mime worden wel degelijk ondersteund.

19-02-2016, 20:23 door Anoniem

17-02-2016 door Anoniem:
Das mooi, maar veel te complex. Als je daarna ooit je keys moet vernieuwen, gaat het 1 groot drama worden en deze key weer overal bij iedereen te krijgen.
Misschien is er juist ook een redenen waarom men eigenlijk in de zaken wereld bijna alleen maar s/mime gebruikt en nooit PGP?

Waarom zou s/mime beter, minder complex en daarbij minstens zo veilig zijn?

20-02-2016, 09:17 door CakeDelivery

Online Cake Delivery @ http://www.cakengift.in/ ,
Cake Delivery in Delhi @ http://www.cakengift.in/by-city/cake-delivery-in-delhi-333.html
Cake Delivery in Noida @ http://www.cakengift.in/by-city/cake-delivery-in-noida-335.html

20-02-2016, 09:17 door CakeDelivery

Cake Delivery in Gurgaon @ http://www.cakengift.in/by-city/cake-delivery-in-gurgaon-334.html
Cake Delivery in Ghaziabad @ http://www.cakengift.in/by-city/cake-delivery-in-ghaziabad-336.html
Cake Delivery in Faridabad @ http://www.cakengift.in/by-city/cake-delivery-in-faridabad-337.html
Online Birthday Cake @ http://www.cakengift.in/by-occasion/birthday-cakes-339.html

20-02-2016, 09:17 door CakeDelivery

Order Cake in Delhi @ http://www.cakengift.in/by-city/cake-delivery-in-delhi-333.html
Order Cake in Noida @ http://www.cakengift.in/by-city/cake-delivery-in-noida-335.html
Order Cake in Gurgaon @ http://www.cakengift.in/by-city/cake-delivery-in-gurgaon-334.html
Order Cake in Ghaziabad @ http://www.cakengift.in/by-city/cake-delivery-in-ghaziabad-336.html
Order Cake in Faridabad @ http://www.cakengift.in/by-city/cake-delivery-in-faridabad-337.html

20-02-2016, 15:30 door Anoniem

Grapjurk... jajaja S/Mime helpt om spam tegen te gaan, maar dat doet PGP net zo goed.
Bovendien laat topicstarter weten dat datalekken de belangrijkste motivatie is voor encrypted mail.

Dus nogmaals:
Waarom zou s/mime beter, minder complex en daarbij minstens zo veilig zijn vergeleken bij PGP?
Het zal toch niet voor niets zijn dat dit bedrijf https://www.giepa.de/products/gpg4o/?lang=en PGP voor Exchange
verkoopt?

(techniek van gisteren was gisteren; nu is vandaag)

23-02-2016, 17:03 door Hobbyist

Allen bedankt voor jullie input.. Ik heb een aantal vragen bij mijn manager neergelegd; tot die tijd kan ik niet heel specifiek zijn over wat we nu precies willen.. Als ik meer weet zal ik hier specifiek plaatsen wat de bedoeling is..

voor nu nogmaals bedankt..

E-mail encryptie exchange 2013

Bitcoin:

Wachtwoord Vergeten

Password Reset

Registreren