Helft overheidsdomeinen kwetsbaar voor e-mailspoofing
De helft van de overheidsdomeinen is kwetsbaar voor e-mailspoofing waardoor de derde overheidsbrede streefbeeldafspraak waarschijnlijk niet wordt gehaald, zo blijkt uit een meting van het Forum Standaardisatie onder 548 domeinnamen van de overheid (pdf).
Voor de meting werd er gekeken naar het toepassen van web- en mailbeveiligingsstandaarden op overheidsdomeinen. De webstandaarden worden gemiddeld beter toegepast dan de mailstandaarden (92 procent versus 77 procent). Het gaat dan om gebruik van standaarden zoals https en hsts die voor een versleutelde verbinding zorgen.
Bij mailstandaarden is dat een ander verhaal. Het gebruik van DNSSEC op mailservers neemt juist af en de anti-spoofing e-mailstandaard DMARC is op slechts 49 procent van de overheidsdomeinen voldoende strikt geconfigureerd. DMARC helpt, in combinatie met e-mailstandaarden DKIM en SPF, om e-mailspoofing te voorkomen.
"E-mailspoofing is dat een aanvaller zich in een e-mail voordoet als een ander door het afzendadres te vervalsen. Zo bleek het in 2017 mogelijk om namens Mark Rutte en de AIVD te mailen, en hebben de Tweede Kamer en de AIVD sindsdien hun e-mailbeveiliging op orde gebracht", zo legt het Forum uit.
Ook het gebruik van DANE is met 45 procent nog onvoldoende. Het DANE-protocol zorgt ervoor dat STARTTLS wordt afgedwongen. Dit is een uitbreiding voor smtp die een beveiligde verbinding tussen de verzendende en ontvangende mailserver opzet.
Afspraken
Binnen de overheid zijn afspraken gemaakt om de eerder genoemde standaarden uit te rollen, de zogeheten streefbeeldafspraken. Alle overheden moeten eind dit jaar in ieder geval STARTTLS en DANE voor encryptie van mailverkeer en SPF en DMARC juist hebben ingesteld. "Zonder aanvullende inspanningen zal zo goed als volledige adoptie van de mailstandaarden uit de derde streefbeeldafspraak eind 2019 lastig te realiseren zijn", zo stelt het Forum Standaardisatie.
Met name de waterschappen lopen achter als het om mailstandaarden gaat, terwijl die samen met gemeenten op het gebied van webstandaarden juist weer voorop lopen. Volgens het Forum is het van belang dat overheidsorganisaties hun verantwoordelijkheid nemen en domeinen, websites en e-mail adequaat beveiligen en daarin de informatieveiligheidstandaarden meenemen. Om de uitrol van e-mailstandaarden te versnellen wordt er gekeken naar het in beweging krijgen van grotere mailleveranciers en een wettelijke verplichting.
Forum Standaardisatie bestaat uit deskundigen afkomstig uit diverse overheidsorganisaties, het bedrijfsleven en de wetenschap. Het stimuleert het gebruik van open standaarden voor digitale gegevensuitwisseling in de publieke sector. Het Forum onderhoudt ook de lijst met verplichte open standaarden voor de publieke sector en monitort de adoptie en naleving van het open standaardenbeleid.
Een groot security drama bij onze overheid.
Helaas is dat zo. Maar het is feitelijk nog veel erger. Microsoft heeft volledige toegang tot al die emails. Ze vervangen bijvoorbeeld links in emails en ze zien dus ook of er op geklikt wordt.
Ik kan er niet bij dat men een buitenlandse partij vertrouwd met interne overheids- en bedrijfsdocumenten. Zijn ze vergeten dat de VS graag aan bedrijfsspionage doet?
Dat klopt niet, je kunt best met je mail naar MS toe en DMARC gebruiken als je maar niet je DNS hosting naar MS verhuist.
Je kunt icm MS cloud oplossingen gewoon elders je DNS servers onderbrengen. En dan support MS gewoon DKIM, SPF
en DMARC. Of je DANE kunt doen hangt er vanaf hoe je je certificaten regelt maar meestal kan dat ook wel.
Terzijde, het nut van al die protocollen is zeer beperkt omdat ontvangers vaak het afzenderdomein niet zien in hun mail client, en als ze het wel zien er niet op letten, en als ze er wel op letten niet weten of het getoonde afzenderdomein NIET van de kennelijke organisatie is c.q. NIET IS GEAUTHORISEERD om namens de kennelijke organisatie e-mails te verzenden.
En als een organisatie het risico dat e-mails niet aankomen (bijv. door problemen met forwarding) groter vindt dan dat ontvangers ietsje eenvoudiger te foppen zijn (met gespoofde afzendermails), dan gaan zij deze protocollen wellicht wel implementeren (zoals sommige spammers ook doen), maar niet maximaal veilig configureren.
Verder zie ik als overheid wel dat deze mechanismen pas waarde hebben als de andere kant ze gebruikt, maar moet je in ieder geval de kans bieden om iets van verificatie toe te passen. Dan is het aan de ontvangende kant of zij de zaak blokkeren als deze niet matcht met spf en dkim. Overigens kan je als ontvanger leuke plugins krijgen om dkim te checken.
Terzijde, het nut van al die protocollen is zeer beperkt omdat ontvangers vaak het afzenderdomein niet zien in hun mail client, en als ze het wel zien er niet op letten, en als ze er wel op letten niet weten of het getoonde afzenderdomein NIET van de kennelijke organisatie is c.q. NIET IS GEAUTHORISEERD om namens de kennelijke organisatie e-mails te verzenden.
Dus niemand kijkt meer op van communicatie door dezelfde organisatie onder 10 verschillende namen, en een scammer kan gewoon een 11e aanmaken zonder dat dit opvalt.
Dat ook ja. En je komt ook nergens met van die "check uw veiligheid" organisaties die gewoon de site of domein langs de waan van de dag leggen en er een score aan koppelen zonder te overwegen of deze maatregelen proportioneel zijn voor de situatie. Kijk bijvoorbeeld eens op internet.nl die hebben ook voor zichzelf bepaald wat naar hun idee de ideale situatie is en zetten rode kruisjes bij alles wat daar niet aan voldoet, met vaak in de uitleg er al bij dat dit alleen om 1 onwaarschijnlijk scenario gaat wat wellicht in het geval van die site helemaal niet van toepassing is.
Zie ook de recente blog "Better mail security with DANE for SMTP": https://blog.apnic.net/2019/11/20/better-mail-security-with-dane-for-smtp/. Daarin ook verwijzingen naar wereldwijde adoptiecijfers en informatie over de ondersteuning door mailhosters.
Ook voor DNSSEC op Azure is er een request met heel veel stemmen: https://feedback.azure.com/forums/217313-networking/suggestions/13284393-azure-dns-needs-dnssec-support.
Hopelijk neemt Microsoft deze duidelijk klantwens spoedig ter harte...
Overigens heeft Google wel een eerste stap gezet. Zij bieden namelijk MX-domeinen voor Gsuite aan die DNSSEC-ondertekend zijn: https://twitter.com/danielverlaan/status/1189461302449790977
Partijen die wel DNSSEC en DANE doen zijn bijvoorbeeld Protonmail, Freedom Internet, Soverin, en XS4ALL.
Voor DMARC (en ook voor DKIM en SPF) is DNSSEC geen must maar wel sterk aanbevolen: https://tools.ietf.org/html/rfc7489#section-12.3
Mailclient tonen inderdaad niet altijd duidelijk het afzenderdomein. Dat is zeker voor verbetering vatbaar. Tegelijkertijd leert de ervaring dat er nu al heel veel niet-legitieme mail wordt tegengehouden door DMARC (icm DKIM en SPF). Deze standaarden hebben nu dus zonder meer al veel nut in de praktijk. Tegelijkertijd kan door (1) verbetering mailclients, (2) training van ontvangers en (3) eenduidig domeinnaamgebruik door verzenders het nut nog verder toenemen. There's no silver bullet ;-)
Daarnaast, dan gebruik je toch gewoon een On-Prem SMPT Relay icm Hosted Exchange. Gewoon een hybride omgeving neer zetten. Probleem opgelost.
Een trieste bijkomstigheid is dat OpenDMARC nauwelijks tot niet onderhouden wordt (zie (Duits) https://www.golem.de/news/opendmarc-aktiv-ausgenutzte-dmarc-sicherheitsluecke-ohne-fix-1909-143798.html, (Engels) https://www.openwall.com/lists/oss-security/2019/09/11/8 en https://github.com/trusteddomainproject/OpenDMARC/issues/). Naar verluidt zijn de maintainers ervan te druk met de opvolger "ARC".
M.b.t. ARC: ik ben de tel kwijt bij al dit soort protocollen die beloofden het spoofing-probleem op te lossen, en zodra marketing zich ermee bemoeide, ook het spamprobleem. Voorbeelden: Sender Permitted From (ontworpen om Joe-jobs te bestrijden), werd Sender Policy Framework (zie https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden), en zie ook https://news.microsoft.com/2004/02/24/bill-gates-outlines-technology-vision-to-help-stop-spam/. Helaas blijken we telkens weer te zijn blijgemaakt met een dode mus. Bizar is dat we ons gek laten maken bij elk volgend protocol (ook ik ben met DMARC aanvankelijk in die val getrapt), want telkens beloven de bedenkers dat met dat nieuwste protocol wel al uw problemen als sneeuw voor de zon verdwijnen, zonder bijwerkingen natuurlijk (eh, te benoemen). Ik ben er klaar mee.
Wij scoren voor onze website 100% en voor de e-mail 87%.
Een hoop private instellingen, zie ik dit nog niet zomaar nadoen.
Dus ja het kan.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
