Overheid loopt achter bij uitrol van e-mailbeveiliging
De overheid loopt achter bij de uitrol van standaarden voor het beveiligen van e-mail en lijkt een afgesproken deadline zonder aanvullende inspanningen niet te halen. Dat blijkt uit een meting van Forum Standaardisatie. Voor de meting werd er naar 563 domeinnamen van overheidsorganisaties gekeken.
Webstandaarden worden gemiddeld vaker gebruikt dan e-mailstandaarden (89 procent tegenover 74 procent). De implementatie van e-mailstandaarden laat echter een sterkere groei zien. Gemiddeld is het gebruik in het afgelopen halfjaar met 7 procent toegenomen. Met name e-mailstandaarden DMARC en DANE worden veel meer gebruikt.
Toch vragen de relatief lage adoptiegraden van deze standaarden bijzondere aandacht, aldus Forum Standaardisatie. Via DMARC kan worden ingesteld wat de mailserver moet doen als die een verdachte e-mail ontvangt. 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.
Alle overheden moeten eind 2019 in ieder geval STARTTLS en DANE voor encryptie van mailverkeer en SPF en DMARC hebben ingesteld. Via het Sender Policy Framework (SPF) kunnen providers controleren of een e-mail van een specifiek domein ook daadwerkelijk van dit domein afkomstig is. Als er wordt gekeken naar de implementatie van e-mailstandaarden doen met name het Rijk (80 procent) en gemeenten (79 procent) het goed.
De waterschappen lopen het verst achter. Iets meer dan de helft (56 procent) heeft de standaarden uitgerold. Forum Standaardisatie concludeert dat de gemiddelde adoptie van veiligheidsstandaarden in de afgelopen 3 jaar sterk is gegroeid, maar de overheid er nog niet is. "Zonder aanvullende inspanningen zal zo goed als volledige adoptie van de mailstandaarden uit de derde streefbeeldafspraak eind 2019 lastig te realiseren zijn."
Om de adoptie van mailstandaarden te versnellen is het volgens de organisatie een mogelijkheid om de grotere mailleveranciers in beweging te krijgen. "Daarnaast kan een wettelijke verplichting helpen om de achterblijvers zo ver te krijgen dat ze de standaarden ondersteunen." Het ministerie van Binnenlandse Zaken is van plan de standaard voor HTTPS te verplichten door middel van een algemene maatregel van bestuur op basis van het wetsvoorstel Wet digitale overheid. Het ministerie zal gaan kijken of dit ook voor andere standaarden een optie is.
Vooralsnog zie ik dat niet gebeuren. Tegen de tijd dat mail end-to-end encrytie doet, en dan ook nog op een manier die als 'secure' wordt geaccepteerd in beveiligingsland, dan praten we verder.
Op zich wel grappig: Microsoft zal heel veel resources en eigen technieken toepassen om te voorkomen dat hun DNS gekaapt wordt. Dus voor zichzelf hebben ze geen DNSSEC nodig. Echter klanten hebben het wel nodig omdat het een basis is voor andere standaarden, en daar lijkt Microsoft aan voorbij te gaan...
Eens met anoniem 16:55
En ook hier is er een extra uitdaging. Dichtgeplakte brieven geven een mogelijkheid voor poederbrieven. Bewust bekwame slechteriken weten hier gebruik van te maken. Om tal van redenen.
Zo kan een digitaal versleuteld bericht gemakkelijker mallware in het IT systeem van de ontvanger injecteren. De bewust bekwame slechterik zal ook hiervan gebruik kunnen maken (elk voordeel heeft zijn nadeel)
Ook hier zijn additionele maatregelen te bedenken
Zomaar uit de losse pols
- een mailscanner in de keten (dan heb je de private sleutels nodig; kan je zien als veilig-functionele man-in-the-middel)
- verplichte digitale ondertekening met gekwalificeerd certificaat (daarmee wordt opsporing mogelijk; helpt ook tegen spam)
En ook hier weer: elk voordeel heeft zijn nadeel
Bijv anonimiteit voor het geval verzender onderdeel is van gevoelig journaille, klokkenluider, politiek activist, etc
Eens met anoniem 17:04
In samenwerkverbanden ook met Microsoft samengewerkt (goede mensen overigens)
In de tijd dat Office 365 in ontwikkeling was wilde MS geen knopje in de mailserver of cliënt inbouwen om eenmaal gelezen e-mail voortaan als onversleuteld te kunnen laten voortbestaan. Reden van dit verzoek waren voldoen aan archiefwetten en beschikbaarheid zakelijke e-mails nadat het personeelslid vertrokken is.
MS wilde traineerde omdat de mogelijkheid verstorend zou werken op de uitrol (imago) van Office 365.
Dit toont dat de keuzes van MS nog wel eens vanuit alleen maar eigen belang wordt gestuurd.
Erg?
Is maar hoe je kijkt
Waarom zou je HTTPS gebruiken voor publieke data? Dat is net zoiets als reclamefolders huis aan huis verspreiden in gesloten enveloppen "omdat er anders iemand je reclamefolder kan lezen"
Q
Vooralsnog zie ik dat niet gebeuren. Tegen de tijd dat mail end-to-end encrytie doet, en dan ook nog op een manier die als 'secure' wordt geaccepteerd in beveiligingsland, dan praten we verder.
Of bedoel van bedrijf naar bedrijf? Dat laatste wordt afgedwongen door STARTTLS. Daarmee vergelijkbaar met hoe fysieke post verwerkt wordt: komt binnen op de postkamer, wordt geopend, eventueel gearchiveerd, en doorgestuurd naar de betreffende medewerker. Waarom moet ineens alles anders als het digitaal is.
Wat is nu je punt?
Niet helemaal juist. Ze kunnen alleen controleren of het van dat domein afkomstig is. Als Pietje of Jantje een ander e-mail adres spoofen met dezelfde domeinnaam als hun eigen, dan ziet SPF of DMARC dat niet.
Waarom zou je HTTPS gebruiken voor publieke data? Dat is net zoiets als reclamefolders huis aan huis verspreiden in gesloten enveloppen "omdat er anders iemand je reclamefolder kan lezen"
Q
Ook publieke websites moeten beveiligd zijn met https. Een bezoeker van een openbare, publieke website met informatie over bijvoorbeeld mishandeling, geslachtsziekten en dergelijke heeft ook gewoon het recht om deze veilig (lees encrypted) te kunnen bezoeken, dus https everywhere.
Niemand die daar bij stilstaat. Het is nieuwe afkorting dit, nieuwe techniek dat, nieuw buzzword zus, nieuwe "push" om het allemaal maar weer in te voeren zo. Oftewel, een hoop technogefap van inepte knutselaars. Allemaal piepkleine "oplossingen" voor onderdeeltjes van het probleem, zonder echt na te denken. De enige reden dat het aanslaat is dat de roedels technofappers zich verenigd hebben in "internetreuzen" (inepte softwareknutselaars, advertentiebedrijven, "eyeball"-herders, dat soort zut) en daarmee enorme marktmacht hebben. Maar de wijsheid in pacht, dat nemen ze dan wel aan maar hebben ze niet.
Niet helemaal juist. Ze kunnen alleen controleren of het van dat domein afkomstig is. Als Pietje of Jantje een ander e-mail adres spoofen met dezelfde domeinnaam als hun eigen, dan ziet SPF of DMARC dat niet.
SPF checks controleren of de verbindende mailserver IP voorkomt in de (SPF) lijst met toegestane servers, afhankelijk van het MAIL FROM: adres wat is opgegeven (te vinden als ReturnPath/Envelope adres etc.).
DMARC controleert of SPF en DKIM falen én of de FROM (wat pas na DATA komt) adresdomein overeenkomt met de MAIL FROM adres. Dit voorkomt dingen als displayname spoofing etc.
DKIM signeert alle uitgaande mail met een private key en voegt een hash toe in de headers die door ontvangende servers gecontroleerd kan worden door gebruik te maken van een public key wat via DNS is gepubliceerd. Hiermee heeft de ontvanger ook meer zekerheid dat de mail ook daadwerkelijk van de versturende organisatie (domein) is.
DANE staat ook op de lijst "pas toe/leg uit", maar idd O365 DNS records zijn niet beschermd met DNSSEC en ook hun MTA (Exchange Online Protection) heeft deze ondersteuning niet.
Dan heb je ook nog SMTP STS of MTA STS, die iets minder veilig is (vanwege trust on first connection, zoals SSH dat ook kan), maar geen DNSSEC nodig heeft. Denk daardoor ook dat deze een wat snellere adoptie zal krijgen, al kan je prima DANE en MTA STS naast elkaar gebruiken.
Je kan natuurlijk ook op al je Inbound en Outbound Connectors RequireTLS aanzetten, maar dan kan het dus voorkomen dat je naar dat domein geen mail kan versturen/ontvangen als de andere partij dat niet op orde heeft. Verbazingwekkend hoe vaak SMTP TLS slecht is ingericht...
En zelfs dan moet je goed op blijven letten. Als namelijk een org die dit alles heeft ingericht, gehackt word oid., dan heeft dit hierboven weinig nut. Helaas zie ik ook steeds vaker phishing mails die gewoon door SPF, DKIM en DMARC geauthenticeerd zijn...
Geen reden om het toch in te stellen en ontvangende mail op te controleren, ik meen dat 80%-90% van mail die geen SPF, DKIM en DMARC hebben/falen malafide mail is.
Waar haal je dat vandaan? HTTPS staat al sinds heel lang op als verplicht protocol
Bron: https://www.forumstandaardisatie.nl/standaard/https-en-hsts
"omdat er anders iemand je reclamefolder kan lezen"
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.
