'Overgrote deel Nederlandse gemeentes beveiligt e-mail slecht'

Uit een onderzoek van het tijdschrift Binnenlands Bestuur blijkt dat Nederlandse gemeentes hun e-mail slecht beveiligen. Slechts drie van de vijftig onderzochte gemeentes zou standaarden als dkim, dmarc en spf toepassen.

De enige gemeentes die op het gebied van e-mailbeveiliging aan deze standaarden zouden voldoen zijn Den Haag, 's-Hertogenbosch en Woerden. Daarmee zijn grote gemeentes als Utrecht, Amsterdam en Rotterdam onvoldoende beveiligd, aldus Binnenlands Bestuur. Tijdens het onderzoek werd ook gekeken naar de beveiliging door middel van tls, waaruit bleek dat maar dertien gemeentes gebruikmaken van starttls om een onbeveiligde verbinding via tls te laten verlopen. Dit gaat bij veertien gemeentes mis.

Dkim is een authenticatiemethode waarmee een ontvanger van een e-mail kan nagaan of een bericht van het domein van de verzender inderdaad daarvandaan verzonden mocht worden. Met spf kan daarnaast worden nagegaan welke servers binnen een domein berichten mogen verzenden. Dmarc bouwt voort op deze technieken en kan bijvoorbeeld ingezet worden om te verifiëren of de inhoud van een e-mail is veranderd na het verzenden daarvan.

Door deze standaarden niet te implementeren, kunnen kwaadwillenden bijvoorbeeld e-mails versturen namens de gemeente, zo stelt Binnenlands Bestuur. Dit kunnen zij inzetten om phishing- of spam-e-mails te verzenden. Zo konden de onderzoekers bijvoorbeeld een e-mail versturen en zich daarbij voordoen als de Rotterdamse burgemeester Ahmed Aboutaleb, zo schrijft de NOS.

Dmarc is een vrij nieuwe standaard uit 2012, die door steeds meer organisaties geïmplementeerd wordt. Zo kondigde de ABN Amro in 2014 aan de standaard te gaan gebruiken. Uit een eerder onderzoek bleek dat ongeveer twintig procent van de Nederlandse gemeentes slecht beveiligd is door sslv2 te ondersteunen. Daarmee zijn de desbetreffende gemeentes vatbaar voor een zogenaamde Drown-aanval.

Reacties (63)

[mashell]

Zou email als het niet versleuteld is niet gewoon per defintiie als onveilig beschouwd moeten worden? En daarmee als ongeschikt om berichten met de andere bedrijven, met klanten, om facturen en dergelijke over uit te wisselen?

[[Roland]]

Email is per definitie onveilig. Komt terecht op mobiele telefoons, slecht beveiligde pc's en gaat over het algemeen nog altijd onversleuteld over het internet. Net als met echte post heb je na het verzenden niet meer controle over wat er met je mail gebeurt.

Gewoon email dus niet gebruiken voor gevoelige zaken buiten je eigen (gecontroleerde) organisatie.

[Armin]

Gewoon email dus niet gebruiken voor gevoelige zaken buiten je eigen (gecontroleerde) organisatie

Email kan overigens best in combinatie met andere technieken. SMIME is in de bedrijfskringen geen onbekende en ik gebruik het zelf ook regelmatig. PGP kan ook, maar is doorgaans minder makkelijk op te zetten qua sleuteluitwisseling voor minder technisch aangelegde mensen.

Maar bij het afsluiten van een financieel contract van mij onlangs werd TLS-versleutelde email gebruikt door het juristenkantoor, waarna ik dan in een Office365 site moest inloggen om de email op hun servers te kijken met aparte authenticatie. Office365 heeft daar schijnbaar ondersteuning voor, dat bij het verzenden van emails naar buiten de eigen organisatie gaat zo'n link verstuurd wordt ipv het bericht zelf.

Andersom kon ik kiezen via die portal te antwoorden of via gewone TLS-versleutelde email.
Zo is bij falende of ontbrekende STARTTLS de data nooit in plain-text in de lucht. Uiteraard als mijn email-account gecomprimeerd wordt of ik zelf onzorgvuldig ben, heeft dit weinig nut. Maar ik heb het in ieder geval dan in eigen hand.

Bij datzelfde contract moest ik later bij een bank ook gegevens zenden/ontvangen. Dat ging dan ook via zo'n systeem, maar dan niet gebaseerd op Office 365 maar een eigen systeem. Dus kennelijk is het geen ongebruikelijke methodiek.

[i-chat]

post is niet veilig, je hebt maar een paar uur nodig om de brieven te onderscheppen, deze te openen nieuwe te maken en digitale truuks toe te passen om handtekeningen te vervalsen vervolgens een nieuwe envelope (want verzegeling wordt al jaren (zo niet eeuwen) al niet meer gebruikt....

ik zou willen zeggen dat, zodra je pgp gebruikt, er niets mis is met email. het probleem is alleen dat de overheid nog steeds niet inziet wat de voordelen ervan zijn, en hoe ze deze (liefst voor alle burgers), mogelijk zou kunnen maken.

stel je eens voor: een pgp- private key, in plaast van je BSN.

[beerendlauwers]

In België heb je op je eID een persoonlijk private-public keypair waarmee je exact dit kunt doen.

[ollie1965]

stel je eens voor: een pgp- private key, in plaast van je BSN.

We gaan er wel naartoe (eID)
Leesvoer?
Google: X-road+estland, Idensys en eIDAS

[Virtlink]

Waarom geen cryptografische hash van de e-mail (afzender, ontvanger, inhoud) encrypten met het certificaat van de afzender en dat in de header van de mail doen? Je pc kan zulke signatures al verifiëren, en je weet dan zeker dat de mail van de afzender is en onveranderd. Zeg maar PGP maar dan met de certificaten en trusted roots die we al hebben, en zonder de inhoud van de mail zelf te veranderen. Wie gaat dit maken?

[Aurora]

Onder andere Google, Microsoft, Yahoo, LinkedIn en Comcast: Zie mijn post hierboven over SMTP STS.

Wat makkelijker te lezen is misschien dit artikel: http://thehackernews.com/2016/03/smtp-sts-email-security.html

[Reactie gewijzigd door Aurora op 23 juli 2024 14:24]

[mxcreep]

Smime maakt al gebruik van de huidige CA infrastructuur...

[Armin]

Zoals mxcreep aangeeft bestaat zoiets al en het heet S/MIME.

O.a. iPhone en elke Outlook van de laatste 10 jaar ondersteunen het. Oude particuliere email clients zoals Windows (Live) Mail ook. In de Microsoft Windows 8.x clients was het helaas afwezig, maar in Windows Phone 8.1 en Windows 10 (Mobile) is het weer terug maar helaas wel enkel in combinatie met Exchange.

Je kunt het overigens ook met self-signed certifciaten gebruiken (mits je een Outlook of Windows Live Mail gebruikt), maar dan vereist dat uiteraard eenmalig een handmatige certifciaat installatie op de ontvangende PC's net zoals bij (de meeste varianten van) PGP.

[teek2]

Ja eigenlijk wel maar email is erg oud. En alle veiligheid is er later opgeplakt. Toen ik twee jaar geleden mijn eigen mailserver aan het opzetten was kwam ik er met http://www.checktls.com/ achter dat mijn MS live.com email niet eens TLS bood, evenals Apple's email toen ter tijd. Dat betekend dat je email als plain text over het web ging! Dat is allemaal nu gelukkig niet meer zo, ik denk mede door Google's awareness campagne: https://www.google.com/transparencyreport/saferemail/

[Aurora]

SMTP is inderdaad verouderd, vandaar dat men op dit moment bezig is met de opvolger van het SMTP protocol: SMTP STS

'SMTP STS is a mechanism enabling mail service providers to declare their ability to receive TLS-secured connections, to declare particular methods for certificate validation, and to request sending SMTP servers to report upon and/or refuse to deliver messages that cannot be delivered securely.'

EDIT:
Hier een artikel die het wat makkelijker uitlegt:
http://thehackernews.com/...p-sts-email-security.html

[Reactie gewijzigd door Aurora op 23 juli 2024 14:24]

[Blokker_1999]

STS veranderd niets aan encryptie op zich. Je kan een SMTP verbinding al lang beveiligen met encryptie. Met STS wil je in de eerste plaats een manier voorzien om aan andere systemen aan te geven dat ze vanaf de opbouw van de initiële communicatie reeds encryptie moeten gebruiken en zo mitm aanvallen en downgrade attacks een stuk moeilijker worden.

Met SMTP STS hebben ze imho trouwens onmiddelijk ook een grote kans gemist. Ook bij de ontwikkeling van deze RFC is er opnieuw gekozen om data toe te vertrouwen aan een externe partij. SMTP STS werkt namelijk niet zonder een CA. Dit terwijl de RFC zelfs vergelijkt met DANE waar je wel kan werken zonder centrale CA maar men het gebruik van die CA verantwoord omdat er anders DNSSEC moet opgezet worden.

[jozuf]

Mee eens. En trek het dan gelijk door in spamfilters, extra dwangmiddel voor dergelijke organisaties er wat aan te doen als al hun mail direct in de junk folder beland bij iedereen.

[Aurora]

Ik ben blij dat Google als 1 van grotere providers duidelijke waarschuwingen laat tonen in zijn web client wanneer inkomende e-mail niet via TLS is verzonden.

Op de MAAWG conferenties kwam het begrip "no auth / no entry" steeds meer naar voren en gaat dus steeds belangrijker worden bij ISP's.

[Johan9711]

Daar past maar één antwoord op: Ja. Ik werk bij 1 van de 3 gemeenten waar het wél goed is geregeld, en hier beschouwen we al het mailverkeer als onveilig als het over privacy/gevoelige gegevens gaat. De standaardemail is daar gewoon niet voldoende voor als je kijkt naar wat voor kaliber gegevens er worden uitgewisseld.
Gevoelige gegevens gewoon niet over de mail, tenzij het apart is geencrypt. (bijvoorbeeld door middel van een wachtwoordbeveiligd zip bestand, of een encryptietool)

[XeNoN62]

Misschien een stomme vraag maar is het protocol email niet te oud geworden? Ik bedoel, we hebben al https maar nog geen beveiligd email? b.v. pops, imaps en smtps

[Benedykt]

Ik snap jouw vraag niet helemaal, want je geeft er zelf al antwoord op. We hebben HTTPS, maar inderdaad ook beveiligd mailen in de vorm van POP3S, IMAPS en SMTP met TLS encryptie.

Het probleem is dat lang niet iedereen STARTTLS heeft (of het niet goed ingericht heeft) waardoor een groot deel van al het verkeer gewoon nog onversleuteld over de lijn gaat. Wat ik zo gauw van SMTP STS heb vernomen (moet me er nog even verder in verdiepen) is dat hierin de encryptie veel strenger afgedwongen wordt, waardoor het mail verkeer in ieder geval versleuteld over het internet gaat. En wat er dan mee gebeurt, tsja...

[XeNoN62]

Kijk daar zit het probleem

"Het probleem is dat lang niet iedereen STARTTLS heeft"

Dit zal standaard gemeengoed moeten worden en niet apart een vinkje ergens aanzetten. Daarom is mijn vraag ook waarom niet pops, imaps en smtps standaard maken?

@Aurora, Ik heb je linkje gevolgd over SMTP STS, Top!

[Reactie gewijzigd door XeNoN62 op 23 juli 2024 14:24]

[MPAnnihilator]

Allicht omdat je voor alle beveiligde verbindingen certificaten moet instellen/kopen/vernieuwen enz...

(Luiheid en € / $ - redenen dus als antwoord op je vraag).

Iedere moderne MTA anno 2016 kan TLS , technisch is er dus geen probleem.
Bij overheden zal het hier in BE stilaan gaan verplicht worden heb ik opgevangen , net zoals DNSSEC.

[Armin]

Daarom is mijn vraag ook waarom niet pops, imaps en smtps standaard maken?

Bij de meeste provdiers is dit al standaard. O.a. GMail en Hotmail bij mijn weten weigeren gewoon non-TLS of STARTTLS verkeer. Er zijn providers zoals KPN die dat niet doen, maar dat zijn echt wel de uitzonderingen aan het worden.

Maar inter-SMTP verkeer (dus tussen email servers onderling) is lastig. Immers wat moet je doen als een van jouw gebruikers een email krijgt over een niet versleutelde verbinding? Dan maar weggooien/weigeren zonder de gebruiker te vragen? Dat kan evident niet. Wat GMail nu bijvoorbeeld doet is gebruikers achteraf te verwittigen.

[hackerhater]

Daarom hebben de meeste mail-hosts de instelling op "prefer encryption"
cq versleuteling als de andere partij (mailserver) het ondersteund, anders terug vallen op onversleuteld.

[Verwijderd]

Helemaal waar. Dit nieuwtje is natuurlijk weer een aanleiding om goedkoop gemeentes te bashen, maar een onderliggende oorzaak is dat email een naief protocol is waar halfzachte maatregelen zijn opgeplakt naderhand, die ook nog eens verschillend geinterpreteerd worden door de tig email clients. Daarbij is het een moving target.

Probeer zelf maar eens met je bedrijfje betrouwbaar emails uit te sturen die veilig zijn en door alle spam filters komen, en correct renderen. Dat is een veel grotere klus dan menigeen denkt.

[Aurora]

Geen stomme vraag. Het SMTP protocol is zeker verouderd. Om deze reden zijn een aantal reuzen bezig met een opvolger, SMTP STS. Zijn mijn posts hierboven.

[Blokker_1999]

SMTP STS is geen opvolger van SMTP maar een uitbreiding op SMTP+STARTTLS waarbij de andere partij op voorhand weet wat er van encryptie verwacht moet worden bij het opzetten van de communicatie.

[Aurora]

Incorrect. SMTP heeft een lappendeken van extensies meegekregen, dus niet alleen STARTTLS. Deze werden door verschillende initiatoren opgezet. Hierdoor liet bijvoorbeeld de samenhang te wensen over. SMTP STS wordt neergezet als een volledig nieuw standaard.

[RoofTurkey]

In ander nieuws blijkt het dat water nat is. Natuurlijk is het onvoldoende geregeld, dit blijkt keer op keer, maar zolang de gemeentes niet willen investeren in kennis op het gebied van ICT blijven dit soort problemen zich herhalen. En als het dan ging om wat kleine dingetjes dan prima, maar het gaat hier om privacy gevoelige informatie die men verplicht is af te staan aan deze instanties en juist dat is wat mij (en ik denk veel mensen met mij) zo pislink kan maken telkens als ik dit soort berichten lees.

[geerttttt]

Als je ziet hoeveel pakketten binnen een gemeente draaiend gehouden moeten worden met het aantal ICT-ers dat er zijn dan kan ik me voorstellen dat iets als SPF en helemaal Dmarc in hun geval geen prio heeft.

De reden hiervoor is denk ik ook dat het bestuur hier geen reden toe ziet. Die hebben geen idee wat er bedoeld wordt met dit artikel en zolang er geen grote phishing problemen zijn komen ze dat ook niet te weten. Daarom zijn zulke onderzoeken heel goed, dit brengt het aan het licht. Grote kans dat in menig gemeente de komende tijd in de vergaderingen dit besproken wordt. Dan kan men hier een verzoek voor doen en hier tijd in investeren.

[mxcreep]

Er wordt ook veel teveel individueel geregeld per gemeente, niet efficient.

[Niemand_Anders]

Maar de gemeente zal niet zelf zijn mailserver beheren. Dit zullen zij hebben uitbesteed. Het bedrijf dat de server beheerd namens de gemeente dient ervoor te zorgen dat de mailserver veilig is en dient ook te controleren dat alle juiste records aanwezig zijn in de DNS..

Net zoals de gemeente een schoonmaak bedrijf inhuurt om ervoor te zorgen dat het gemeentehuis schoon is en men zich niet bezig zal houden welke technieken de schoonmaakster gebruikt, hoeft de gemeente zich ook niet bezig te houden hoe je een mailserver beveiligd..

Half Amerika viel over Clinton heen, toen bekend dat ze een prive mailserver gebruikte in plaats van de officiele mailserver van de overheid. Anders dan dat de server niet alle laatste updates had, was deze verder wel goed ingesteld..

Als je zaken uitbesteed, mag je er vanuit gaan dat degene welke de opdracht aanneemt dat correct doet. Omdat ik zelf niet voldoende weet van auto techniek, laat ik het onderhoud van mijn auto uitvoeren bij de garage..

[hackerhater]

Inderdaad, wij zijn zelf een hoster.
We vragen onze klanten altijd of ze nog via andere systemen mail versturen?
Zo nee gaat het SPF-record op onze mail-server en onze mail-server controleerd daar ook hard op bij inkomende email.
SPF-fail? => reject

Onze eigen site staat op v=spf1 mx -all

[Reactie gewijzigd door hackerhater op 23 juli 2024 14:24]

[geerttttt]

Ik denk dat de meeste gemeenten gewoon een Exchange servertje ergens in het domein hebben hangen hoor. Wellicht in DMZ, maar goed.

[djexplo]

maar zolang de gemeentes niet willen investeren ... ICT

Zelf snap ik ook niet dat dit niet meer landelijk word geregeld.
B.v. website als https://www.amsterdam.nl/ en https://www.arnhem.nl/ , zijn totaal verschillend ook in CMS.
Je zou verwachten dat dit veel kost effectiever, betrouwbaarder en veiliger zou kunnen, als dit door een landelijk ICT team zou worden gehost en onderhouden.

[gabba25]

Je patient gegevens van de tandarts lopen ook via de mail. En hou je vast, zelfs gmail en hotmail accounts worden er gebruikt. Dus als dit al zou zijn opgelost bij de gemeente, dan lekt het aan de andere kant wel weer.

[GrooV]

Gmail -> Gmail of Hotmail -> hotmail is dan wel weer secure

[Verwijderd]

mitst je niet je wachtwoorden op een flash drive opslaat of je telefoon op auto login zet. en dan deze 2 voorwerpen in een random taxi of auto laat liggen..

[GrooV]

Ja en je briefpost kan ook door de postbode opengemaakt worden, en je veilige website SSL verbinding kan gewoon door een malafide chrome extensie uitgelezen worden.

Het internet is niet veilig en zal het ook nooit worden, maar je kan de risico's wel beperken

[Verwijderd]

'Ja en je briefpost kan ook door de postbode opengemaakt worden.'

als dat gebeurd sta je sterker als op internet waar een random iemand die je nooit zal zien iets opent.. tevens zou ik ook nooit geld/waardevolle spullen versturen via de post.. maargoed

'je veilige website SSL verbinding kan gewoon door een malafide chrome extensie uitgelezen worden.'

chrome extensie's in mijn overtuiging.. zo WEINIG mogelijk hebben draaien.
een lek in flash.. dat kan.. maar alle extra bende die altijd word mee geïnstalleerd met van alles en nog wat.. per direct uitzetten nog VOOR het geïnstalleerd wordt

problem solved..

[Armin]

En Gmail <--> Hotmail in principe ook, aangezien beide goed geconfigureerde STARTTLS hebben.

Ik weet niet wat er gebeurd als je als MITM aanvaller probeert de STARTTLS te verstoren, maar dikke kans dat ze het op zijn minst merken. Plus het vereist doorgaans dan al een Nation State hacker en die kunnen die emails ook "gewoon" opvragen bij de provider of afhankelijk van details bij de medische instelling zelf.

[hackerhater]

Veel mail-servers vereisen encryptie op de client-verbindingen.
Als iemand starttls verstoord zal de verbinding simpelweg geweigerd worden.

[Armin]

Veel mail-servers vereisen encryptie op de client-verbindingen

Klopt geheel, maar deze discusie over slecht beveiligde email gaat vooral over inter-SMTP verkeer.

Zowel GMail and Hotmail laten inderdaad geen non-TLS/STARTTLS toe, maar beiden wel op inter-SMTP verkeer. Ze moeten immers wel.

Maar de aanvallers die dat kunnen/willen, kunnen vaak ook 'gewoon' bij de provider terrecht om jouw email op te vragen.

[hackerhater]

In mijn geval niet, maar inderdaad bij iedereen die niet zelf zijn email host klopt dat inderdaad.
Mochten ze bij mij wat willen is het standaard antwoord : kom maar terug met een gerechtelijk bevel.
Komen ze daarmee, tjah...

[Wasabi!]

Pfff, net zoals dat er nog steeds veel systemen op XP draaien en dat onderling uitwisselen van gegevens tussen gemeentes een drama is. De overheid waarschuwt de bevolking tegen fishing, fraude, hacken etc., terwijl het binnen hun eigen structuur een zooitje is. Waar gaan al die budgetten naar toe? Oh ja, ze willen 80.000 ICTers uit het buitenland halen.

http://www.telegraaf.nl/t...gen_ict_ers_niet____.html

[Verwijderd]

I.M.O zou een cursus 'computer 101' wonderen doen bij een boel mensen in ambtelijke functies EN ook in het bedrijfsleven.

aangezien de gemiddeld cyber crimineel tegenwoordig zo vernuftig is dat je zowaar moet kunnen LEZEN voordat je een mail bericht opent (ookal komt het van een vreemde, met een .PL email adres die vraagt om je bank gegevens)
daar zou eens wat van het 'bonus' geld aan moeten worden besteeds, gewoon een 'how does the computer work' cursus voor gerrit-jan van havelstein de VVD ambtenaar EN voor hoog blonde sabine tieteloos van de loon administratie bij firma 'verkopen doe je zo!'

kort samengevat:

waarom zou je iets nieuws gaan ontwikkelen al er met het oude nog niet eens normaal kan worden omgegaan?
de verwarring bij menig niet ITer, achter een computerscherm is nu al te groot om te verwoorden.
laat de mensen eerst eens leren dat je niet zomaar op elke mail zou moeten klikken of dingen moet openen die 'toevallig' lijken op het order registratie nr. van je klant.
dat zou zoveel van de onaangename problemen kunnen verhelpen, in mijn optiek is het gewoon schandalig dat mensen met een HBO cursus en papiertje.. die een best salaris hebben!

simpelweg niet goed snappen waar de digitale wereld over gaat en dus vaker wel dan niet in de problemen komen.. zijn het niet de mensen ZELF dan zijn het wel de bedrijven waarvoor ze werken.

op mijn opleiding krijgen we eigenlijk ook niet echt 'security' lessen, omdat er gezegt wordt:
vertrouw je het niet? OPEN het NIET is regel 1
goed lezen, wat er staat is regel 2
heb je na deze 2 regels nogsteeds twijfel? verwijder het bericht! regel 3
als na deze 3 regels er nog geen bellen gaan rinkelen? bel iemand die het wel snapt (of beter) regel 4

[Rob Coops]

Waarom...
Waarom niet een centrale mail server voor de overheids diensten die simpel weg beheerd word door een team van wel competente beheerders.
Waarom niet eindelijk eens een einde maken aan al die gemeente die de zoon van lekker laten aan klooien met een servertje en totaal geen idee wat hij aan het doen is.
Waarom niet eindelijk eens de ambtenaren die weer eens veel te veel geld over de balk smijten om een faal project te laten falen verantwoordelijk houden voor hun falen en ze de laan uit sturen.

Het is onbegrijpelijk dat er zo geklooid kan worden tot je eens op een gemeente huis komt en om je heen kijkt de meeste plantsoen diensten hebben mensen met meer verstand en sociale vaardigheden in dienst...

[Verwijderd]

Dat is het probleem inderdaad, dat elke gemeente zijn eigen infrastructuur heeft.

[MPAnnihilator]

"Dkim is een authenticatiemethode waarmee een ontvanger van een e-mail kan nagaan of een bericht van het domein van de verzender inderdaad daarvandaan verzonden mocht worden".

...zo staat het ook min of meer op Wikipedia maar het is niet correct omschreven of slecht overgenomen.

Met een valide DKIM check weet je of de ontvangen email van domeinn X is aangepast sinds hij de versturende mail server is vertrokken.
Dit doordat de mail headers en/of de body van de mail bij DKIM hashed zijn bij het versturen , en deze hashes gecontroleerd kunnen worden door middel van DKIM records in de zone file van het domein vermeld in de DKIM signature ( d=... )( = meestal het mail-from domein van de ontvangen email ).
Hierdoor weet je dus bijkomend ineens ook dat de ontvangen email niet gespoofed werd, en dus "toegelaten" moet zijn. Authorisatie dus eerder dan authenticatie.

( of de private key is gelekt natuurlijk , dan kan ieder systeem valide DKIM mail sturen voor dat domein )

DKIM heeft dus weinig met authenticatie te maken , maar eerder met integriteit van een email.

SPF aan de andere kant heeft dan weer met autorisatie te maken , daarin bepaalt een eigenaar van een domein welke servers ( IP adressen ) email met zijn domeinnaam als afzender ( envelope-sender ) mogen versturen op Internet.

( correcties aangebracht op basis van feedback Aurora i.v.m. mail-from / envelope sender , thx.)

[Reactie gewijzigd door MPAnnihilator op 23 juli 2024 14:24]

[Aurora]

Een aantal beweringen zijn niet helemaal correct.

DKIM gaat niet uit van de mail-from header (5322.From). Daar hoef je dus niet je publieke sleutel op te plaatsten. DKIM wordt ondertekend met het d= domein. Dat staat los van alle andere headers. In de praktijk wordt echter vaak het mail from header domein gebruikt als het signing domein. Maar dat is meer voor het gemak en belangrijker, voor je domein alignment.

Het SPF wordt ook niet op het mail-from domein geplaatst. SPF wordt geplaatst op het envelope sender domein, ook wel het return-path of bounce domein genoemd. In termen van de RFC, de 5321.From.

[Aurora]

Correctie: mail-from is niet hetzelfde als de From header. MPAnnihilator gebruikte de juiste termen voor het envelope sender domein, dat dus ook mail-from genoemd mag worden.

mail-from = envelope sender, return-path oftwel de 5321.From
from header = 5322.From

[CAPSLOCK2000]

Het probleem met DMARC/DKIM/SPF is dat je wel volledige controle over je e-mail-infrastructuur moet hebben. Alle uitgaande mail moet via je eigen mailservers lopen (of via de servers van een bekende partij). Als je medewerkers hebt die de hele wereld over reizen, overal verwachten BYOD te kunnen doen en ook nog eens zelfstandig IT-diensten inkopen zoals reclamecampagnes dan is DMARC eigenlijk niet te doen. Mailinglijsten en remailers zijn ook nog altijd vervelend.

Je kan zeggen dat je dan maar niet zo'n infrastructuur moet hebben maar kom er maar eens van af.

[Aurora]

Maar al die BYOD's zijn toch geen uitgaande mailservers? Alle werkstations, tablets en smartphones zullen toch gewoon een connectie maken met een (vertrouwde) mailserver?

Dat een grotere organisatie met een vaak complexe infrastructuur het moeilijk zal hebben met de implementatie van DMARC. Daar heb je gelijk in. Maar onmogelijk? Een DMARC implementatie moet altijd gezien worden als een project. Als je als grote organisatie het goed wilt doen, ben je een paar maanden bezig.

Je begint altijd met een DMARC policy op None. Hiermee inventariseer je de mailsystemen die gebruik maken van je From header domein, zonder dat er acties toegepast worden op DMARC door een ontvangende mailserver.

[CAPSLOCK2000]

Maar al die BYOD's zijn toch geen uitgaande mailservers? Alle werkstations, tablets en smartphones zullen toch gewoon een connectie maken met een (vertrouwde) mailserver?

Dat moet je maar hopen, het is BYOD, dus het kan net zo goed via gmail lopen of via een lokale provider. Je hebt er geen controle over.

Je begint altijd met een DMARC policy op None. Hiermee inventariseer je de mailsystemen die gebruik maken van je From header domein, zonder dat er acties toegepast worden op DMARC door een ontvangende mailserver.

Je gaat nooit een policy schrijven waarmee de directeur vanuit zijn hotel in China kan mailen. Als beheerder zou ik dat graag verbieden maar dat zit er realistisch gezien niet in.

[Aurora]

Dat moet je maar hopen, het is BYOD, dus het kan net zo goed via gmail lopen of via een lokale provider. Je hebt er geen controle over.

Hoe wil jouw werknemer via Gmail met jouw organisatie domein mailen? Dat iemand zijn privé adres gebruikt om bedrijfsmail te versturen, dat is een heel ander verhaal en daar zijn SPF/DKIM etc helemaal niet voor bedoeld natuurlijk. Jouw organisatie domein wordt niet gebruikt als afzender, dus het nut van DMARC komt hier niet ter sprake. Daar had je het namelijk over

Je gaat nooit een policy schrijven waarmee de directeur vanuit zijn hotel in China kan mailen. Als beheerder zou ik dat graag verbieden maar dat zit er realistisch gezien niet in.

Ik heb het over de DMARC record policy in je DNS. Deze kun je op None, Quarantine of Reject zetten. Ter bescherming van je mail-from header domein.

Nogmaals, als iemand, de directeur in dit geval, vanuit een hotel in China gaat mailen, dan doet hij dat met een ander adres dan zijn zakelijk adres. Dus je domein beschermen is niet relevant, want hij gebruikt zijn Gmail of Outlook adres. Als hij wel zijn zakelijk adres gebruikt, dan heeft hij verbinding gemaakt met de mailservers van de organisatie, die natuurlijk vertrouwd zijn en waarbij de authenticatie technieken correct valideren.

[Armin]

Dat moet je maar hopen, het is BYOD, dus het kan net zo goed via gmail lopen of via een lokale provider. Je hebt er geen controle over.

Als jouw personeelsleden tegen de bedrijfspolicies of igv gemeenten wet GMail gebriuken, moet je ze daar op wijzen. Als die persoon Kamp heet en je een dikke vinger geeft is er niet veel aan te doen , maar bij de meeste andere personen heeft dat wel degelijk effect.

En heel on-Nederlands sancties laten volgen bij herhaaldelijke overtredingen. Maar dat vinden we dat "streng" en durven we niet. Het gaat echter om informatie van derden en daar moet je nu eenmaal netjes mee omgaan.

Je gaat nooit een policy schrijven waarmee de directeur vanuit zijn hotel in China kan mailen. Als beheerder zou ik dat graag verbieden maar dat zit er realistisch gezien niet in.

Inderdaad als het de directeur is, of minister en die expliciet niet wilt, heb je pech. Maar een iPhone met exchange account werkt ook gewoon veilig vanuit China en is ook voor de directeur makkelijk.

[kristofv]

Toch wel hoor, je kan als bedrijf perfect een publiek bereikbare maar enkel via domein authenticatie bruikbare relay server voorzien. Onze infrastructuur is vanop gans de wereld bruikbaar .

[AlphaWierie]

Ik werk zelf bij de gemeente. In de praktijk zie ik vaak dat de oude generatie het nog netjes volgens de protocollen doet. Mailt netjes via de gegeven werk mail, apps en logt bijvoorbeeld netjes uit het systeem.
De nieuwe generatie is echter zeer slordig.
Deze koppelen vaak hun mail aan hun persoonlijke Gmail/livemail omdat dit makkelijker is en zodat ze hun privé telefoon kunnen gebruiken (geen logger die alles bijhoud) Daarnaast zitten ze meer op de (zelfgemaakte) afdelingsgroepsapp waar ook belangrijke zaken worden besproken en dus niet wordt vast gelegd in het mail verkeer.

Een logische en niet te voorkomen ontwikkeling wat mij betreft.

[Armin]

Een logische en niet te voorkomen ontwikkeling wat mij betreft.

Best te voorkomen, indien men gaat - in Nederland vies woord - handhaven. Ofwel als blijkt dat iemand zijn prive-email gebruikt - waarschuwing. En bij herthaalde overtredingen schorsing, demotie of ontslag. Zover zal het echter vrijwel nooit komen, want die eerste waarchuwing werkt waarschijnlijk al.

Het is meer een gedoogcultuur omdat de leiding het niet zo belangrijk vindt. En daar zit hem meer het probleem, het personeel inclusief de leiding vind security en privacy van de data van burgers niet een prioriteit.

Maar ook de ICT kan helpen. Bijvoorbeeld door policies op de Exchange or Sharepoint te zetten, zodat een PIN-vereist is, verplichte disk encryptie, een korte screensaver timeout. Zo zijn diverse zaken al op tevangen, en is als bonus de kans groot dat de meeste lakse personeelsleden het zo lastig vinden dat ze toch maar niet die prive telefoon gebruiken.