Nationaal Beraad verplicht e-mailbeveiligingsstandaarden voor overheden

Het Nationaal Beraad heeft besloten om de implementatie van twee beveiligingsstandaarden te verplichten bij nieuwe overheidsinvesteringen in e-mail. Daarbij gaat het om de standaarden dane en starttls, die vanaf nu onder de zogenaamde 'pas-toe-of-leg-uit'-regeling vallen.

Logius, een dienst van het ministerie van Binnenlanse Zaken, schrijft dat de noodzaak voor toepassing van de standaarden onder andere bleek uit het meest recente rapport van het NCSC. Daarnaast gebruiken grote Nederlandse e-mail-providers de technieken al voor hun diensten. Uit een onderzoek van het Forum Standaardisatie zou blijken dat 68 procent van de overheids-e-mailservers ondersteuning biedt voor starttls. Daarvan zijn er echter in totaal tien, of 0,85 procent, in staat om ook aanvullend dane te ondersteunen. De organisatie meldt dat implementatie van de standaarden belangrijk is, omdat overheden vaak met gevoelige informatie via e-mail te maken krijgen.

De opname op de pas-toe-of-leg-uit-lijst houdt in dat publieke organisaties de standaarden moeten implementeren bij het inkopen van nieuwe ict-systemen. Het Forum Standaardisatie beheert de lijst, waarop aanbevolen en verplichte standaarden zijn opgenomen. Zo is bijvoorbeeld tls genoemd voor het beveiligen van internetverbindingen en staat ook wpa2 op de lijst voor het aanbieden van veiligere wifi-netwerken. Bovendien is ook spf in de lijst opgenomen met het doel om phishing tegen te gaan.

Starttls is een manier om een gewone verbinding gebruik te laten maken van beveiliging door middel van tls of ssl. Dane zorgt daarbij voor aanvullende beveiliging en kan gebruikt worden om aan te geven dat een bepaald domein versleutelde verbindingen ondersteunt. Uit een recent onderzoek bleek dat een groot deel van de Nederlandse gemeenten zijn e-mail slecht beveiligt. Dat onderzoek richtte zich echter op andere standaarden.

Reacties (43)

[CAPSLOCK2000]

Geweldig, goed nieuws. Nouja, jammer dat het nodig is om het verplicht te stellen, ik vind dat je behoorlijk hebt gefaald als professionele IT'er als je nog geen SSL/StartTLS ondersteunt op je mailserver. Dat is meer dan een foutje, dat is een kwestie van ongeschikt zijn voor je werk. Verschuilen achter externe leveranciers hoeft niet, als ITer ben je verantwoordelijk voor welke producten en leveranciers je gebruikt.

DANE is een stuk ambitieuzer, ook al stelt DANE zelf niet zo veel voor. DANE is niet meer dan een regeltje toevoegen aan DNS. Wat DANE ambitieus maakt zijn de randvoorwaarden. Om DANE te kunnen gebruiken heb je namelijk DNSSEC nodig (voor SPF eigenlijk ook al, maar de gevolgen zijn minder groot als je SPF-records vervalst worden). DNSSEC is voor velen nog wat te veel gevraagd. Gelukkig zijn we in Nederland de absolute DNSSEC-kampioen van de wereld, 44% van de .NL domeinen ondersteunt het, dat is genoeg om impact te hebben.

Voor wie DANE nog niet kent, het is een alternatief voor het CA-systeem om SSL-certificaten te controleren. Het idee is dat je in DNS publiceert welke SSL-certificaten je in gebruik hebt. De client kan zo controleren of hij het juiste certificaat ontvangt van de mailserver en er dus geen sprake is van een Man-in-the-Middle-aanval en de verbinding niet wordt afgeluisterd.

Dat systeem heeft een paar grote voordelen. Ten eerste heb je geen CA's meer nodig, je kan het net zo goed doen met self-signed certificaten, en dat spaart geld. Omdat het toch gratis is kun je zoveel certificaten aanmaken en ze zo vaak vervangen als je wil. Het is over het algemeen ook een stuk sneller om een regeltje in DNS te publiceren dan om een nieuwe certificaat aan te vragen bij een CA.
Ten tweede wordt het probleem opgelost dat iedere CA certificaten kan uitgeven voor iedere domeinnaam. Via DANE kun je aangeven welke CA je gebruikt. Mocht een of andere aanvaller een CA zo gek krijgen om (ten onrechte) een certificaat uit te geven met jouw domeinnaam dan kun je daar via DANE tegen beschermen.

Specifiek voor e-mail heeft DANE heeft voordeel dat we het downgrade-probleem kunnen aanpakken. Momenteel ben je bijna gedwongen om niet-versleutelde verbindingen toe te staan op je mailserver. Er zijn nog te veel mailservers die helemaal geen SSL doen en de meeste mailservers schakelen automatische over naar onbeveiligde verbindigen als het niet lukt om een beveiligde verbinding te maken. Een aanvaller hoeft dus niet meer te doen dan SSL-pakketjes te blokkeren om een clear-text versie van mail te krijgen.
DANE maakt daar een einde aan. Via DANE weet je dat de server waar je meer verbindt geschikt is voor SSL en dat het niet nodig is (en zelfs onwenselijk) om een fallback te doen naar een onversleutelde verbinding.
In de e-mail wereld is het probleem nog groter dan op het web. Op het web heb je namelijk een gebruiker die toestemming kan geven om een ongeldig SSL-certificaat te accepteren of niet. Bij mailservers is er geen mens in de buurt en standaard worden dus maar alle certificaten geaccepteerd, of ze nu geldig zijn of niet.

[vanaalten]

Dat is meer dan een foutje, dat is een kwestie van ongeschikt zijn voor je werk.

... da's wel erg zwart-wit denken, lijkt mij. Tijddruk, bezuinigingen en lokaal gestelde prioriteiten door lokale managers kunnen je dwingen om andere dingen eerst te moeten doen.

[CAPSLOCK2000]

Jaren geleden had ik dat antwoord geaccepteerd, tegenwoordig niet meer. Als IT'er ben je mede verantwoordelijk voor het stellen van de juist prioriteiten. Als je niet in staat bent om je bazen te overtuigen van de juiste prioriteiten dan is dat ook een professionele mislukking. Dat is misschien geen technische mislukking maar een politieke/sociale mislukking, maar het blijft fout.

Ik snap best dat je het niet altijd voor het kiezen hebt en soms de prioriteiten anders moet leggen dan je wil, maar als dat jaren duurt dan vind ik het een mislukking.
We hebben het hier niet over raketwetenschap. Het configureren van SSL voor je mailserver hoeft niet meer dan een middagje te kosten. Als je jaar na jaar geen gaatje kan vinden om dat te regelen dan ben je niet geschikt voor je werk.

En ja, er zijn altijd uitzonderingen, maar gezien de percentages waar we het hier over hebben is dat geen excuus, dat zijn geen uitzonderingen meer, het is een structureel probleem.

[Verwijderd]

Ik ben het volledig met je eens maar klant is klant: ik wil het niet, ondoorzichtig risico, geen tijd, geen budget, blablablabla, nietszeggende managers woorden.....

Ik beschouw mezelf een proffesionele IT-er maar kruistochten houden bij overheden omdat ze niet willen meewerken met dit soort zaken staat echt niet op mijn takenlijst.
Laat staan dat dit soort acties werden opgenomen in een technisch ontwerp of RFC.

Wat ga je dan doen? In je vrije tijd aan de slag om Dane te implementeren? Net of je daar niemand binnen de organisatie voor nodig hebt.. en die andere mensen moeten dat ook maar even in hun vrije tijd doen? Heb je wel eens een ambtenaar gevraagd om over te werken? Echt een opmerking waar niet over na is gedacht....

Gelukkig wordt het nu afgedwongen en hebben ze geen keuze meer.

[CAPSLOCK2000]

Ik zal niet zeggen dat het allemaal jouw persoonlijke fout is, het is een fout van alle betrokken IT'ers samen. Wellicht is het echte probleem dat het hoofd IT van je opdrachtgever het niet snapt, maar uiteindelijk is het de taak van IT om te zorgen dat het goed en veilig werkt.

Dan ga ik het toch nog even persoonlijk maken: Blijkbaar accepteer jij opdrachten waarvan je van te voren weet dat je ze niet goed kan uitvoeren. Je zegt het zelf "klant is klant", dat is eigenlijk maar een heel slecht excuus. Je zou ook je tarief kunnen verhogen zodat je zelf de maatregelen kan nemen die nodig zijn. Misschien dat de klant dan naar een ander gaat maar dan is die ander de falende IT'er. Zolang je klanten accepteert tegen een tarief waarvan je weet dat je het werk niet goed kan doen dan acht ik je mede verantwoordelijk. De klant vertrouwt op jouw professionaliteit om kwaliteit te bieden.

Ik zal direct toegeven dat ik het hier allemaal lekker pittig opschrijf, de realiteit is weerbarstig, maar IT als geheel is maar een puinhoop. Zolang wij ons afstandelijk blijven opstellen ("klant is koning, kan me niet bommen wat de gevolgen zijn") blijft het een puinhoop en dat is onze schuld. Als het de industrie niet lukt om zelf een fatsoenlijk basisniveau te halen dan moet de overheid maar ingrijpen.

[itlee]

Een gemiddelde ICT'er weet niet zoveel van smtp(s), ssl, tls, dkim, dmarc, dane.SFP enz...en met de cloud wordt dit niet beter allemaal.

En als ik kijk dat het gemiddelde hosting bedrijf pop3/imap er bij rommelt (in je hosting pakketje van 2 eu per maand) is het daar ook niet veel beter.
Het is een utopie om te verwachten dat alle mensen tijd stoppen in smtp terwijl het 1 van de meest gebruikte (inmiddels papiervervangen/rechtsgeldende) mediums ter wereld is.

Dus leuk al die technische toepassingen, maar zolang het niet eenvoudig/toegankelijk wordt gemaakt zal de horde die genomen moet worden nog erg hoog blijven.

[CAPSLOCK2000]

Het is eenvoudig en toegankelijk, voor zover IT dat ooit is. Veel makkelijker gaat het niet meer worden. Als je een mailserver kan opzetten dan ben je ook prima in staat om SSL te configureren.

Het probleem is niet dat het te moeilijk is, het probleem is dat mensen niet beseffen dat er iets moet gebeuren.

Dat de gemiddelde IT'er niks weet van beveiliging is een enorm probleem. Beveiliging is juist een van de kerntaken van IT, als je daar niet goed in bent dan ben je gewoon niet goed in je vak. Ik weet dat er een hoop IT'ers zijn die denken dat hun werk bestaat uit op knopjes klikken en de problemen van mensen verhelpen maar die hebben het fout en zijn incompetent.
Een automonteur wordt ook geacht een veilige auto op te leveren, hij mag niet zeggen dat hij zich alleen bezig houdt met het uiterlijk van de auto omdat z'n klanten alleen daar om vragen. Hij moet nog steeds zorgen dat die auto veilig de weg op mag, dat is zijn professionele verantwoordelijkheid.

Natuurlijk zijn er wel specialisten die meer van een bepaald onderwerp weten dan een ander, niet iedere automonteur hoeft alles van kreukelzones en remtesten te weten, maar hij moet weten wat hij zelf veilig kan doen en wat hij moet overlaten aan de experts. Dat besef ontbreekt grotendeels binnen de IT.

Als we snackbars kunnen dwingen om gezond te frituren dan denk ik dat we IT-bedrijven ook wel zo ver kunnen krijgen dat ze SSL verzorgen.

[Sandor_Clegane]

Dit ^^

Vaak weten we wel hoe het moet en wat er aan de infra mankeert maar door allerlei, vaak valide redenen, blijft het erbij.

Neemt niet weg dat het voor het overgrote deel ook vaak complexe vraagstukken zijn en dat de software complex is etc. etc. etc.

[RobbieB]

Volledig mee eens. IT en informatiebeveiliging staan zelden boven aan de prioriteitenlijst tenzij het verplicht gesteld wordt.
Het levert geen direct financieel voordeel op, waar nieuwe productontwikkeling dit wel als doel heeft. En dat is helaas toch vaak de belangrijkste motivatie van prioriteitenbepaling.

[Verwijderd]

Dan verdien je ook niet het predikaat IT-professional....

[zenlord]

++
Ik ben geen informaticus, maar een hobby-sysadmin die zelf een mailserver heeft draaien en heb idd als eerste STARTTLS en SPF geconfigureerd. Het heeft mij heel wat trial-and-error gekost om hier te geraken (en soms heb ik nog problemen met emails van mezelf die bij de ontvanger als spam worden gecatalogeerd), maar het behoort wat mij betreft tot de basis van (veilig) mailverkeer, en zou dus al veel langer op 100% van alle overheidsservers moeten toegepast worden.
Thx ook voor je uitleg over DANE - ik ben het weliswaar tegengekomen toen ik hierover opzoekingen deed, maar het leek mij te ingewikkeld. Nu niet meer :-)

[VisionMaster]

De DANE+STARTTLS op MX servers spec zorgt niet voor het verplicht gebruik van het DANE record, maar geeft de far-side de instructie via DNS dat er STARTTLS gebruikt moet worden. Dit hoeft niet noodzakelijkerwijs te betekenen dat het DANE record op inhoud wordt gebruikt helaas. Wel dat STARTTLS voor deze connectie wordt gebruikt. Dit kan dus nog steeds met het self-signed certificaat gebeuren. Voordeel: sleepnet taps zijn niet meer mogelijk met alleen passieve componenten. Iedereen moet dus na deze invoering nog steeds goede certificaten gebruiken. Ook zegt deze spec nog niets over SPF, DKIM en DMARC, maar ik verwacht een logische evolutie naar die standaarden om ook spam zelf aan te pakken.

[CAPSLOCK2000]

De DANE+STARTTLS op MX servers spec zorgt niet voor het verplicht gebruik van het DANE record, maar geeft de far-side de instructie via DNS dat er STARTTLS gebruikt moet worden. Dit hoeft niet noodzakelijkerwijs te betekenen dat het DANE record op inhoud wordt gebruikt helaas.

Klopt, je bent nog steeds afhankelijk van de client om het goed te doen. Maar ik vind een onwillige client eigenlijk niet zo'n probleem. Althans, geen probleem waar een technische oplossing gaat helpen. Als de client wil kan hij z'n mails bestanden ook zo op straat gooien, daar is mijn mailserver niet voor nodig. Daarom vind ik het genoeg om me te richten op clients van goede wil. Clients van slechte wil kan ik toch niet tegenhouden.

Iedereen moet dus na deze invoering nog steeds goede certificaten gebruiken.

Wat bedoel je met een "goed" certificaat?

Ook zegt deze spec nog niets over SPF, DKIM en DMARC, maar ik verwacht een logische evolutie naar die standaarden om ook spam zelf aan te pakken.

Anti-spam is gewoon geen doel van deze standaard. Nou ja, het kan een heel klein beetje helpen, maar dat is dan vooral bonus, geen doel op zich.

SPF en DKIM staan overigens al op de pas-toe-of-leg-uit-lijst. Als je al SPF en DKIM hebt dan is DMARC nog maar een kleine stap. Helaas betekent het toevoegen aan die lijst nog niet dat er iets gebeurd. Het is niet zo'n harde verplichting en over de hele linie weten overheden zich er onder uit te werken. IPv6, DNSSEC en ODF staan al jaren op die lijst en die standaarden schieten ook niet erg op bij de overheid. Maar goed, iets is beter dan niets, het is wel een extra aftekenvakje op de checklist van iedere inkoper en iedere aanbesteding. Vroeg of laat heeft dat toch effect.

[VisionMaster]

Goede certificaten = verifieerbare certificaten vanuit een publiek trusted CA. PKI kent zijn grenzen, maar heeft meer voordelen bovenop self-signed certificaten voor iedere dienst die je wilt identificeren.

[CAPSLOCK2000]

Goede certificaten = verifieerbare certificaten vanuit een publiek trusted CA. PKI kent zijn grenzen, maar heeft meer voordelen bovenop self-signed certificaten voor iedere dienst die je wilt identificeren.

Ah ok, je doelt op EV/OV certificaten. Tot op zekere hoogte blijft dat nodig maar eigenlijk ben ik er niet zo dol op, het is voor 90% schijnveiligheid. Het probleem is namelijk dat bij zo'n certificaat wordt gecontroleerd of je inderdaad eigenaar bent van die naam, maar niet of die naam ook is wat het lijkt.

Wat is de juiste naam: ING Bank, Postbank, ING BV, De ING bank, ING, ING (NL), ING
NV? Ik durf te wedden dat 99% van NL het niet weet. Voor de allerbekendste bedrijven heeft het misschien zin, maar voor de grote meerderheid is het imho zinloos omdat de bezoeker niet weet wat de juiste bedrijfsnaam is.

Misschien dat CA's in de toekomst ook met dit soort aspecten rekening gaan houden, dat zou ze nieuwe waarde geven, maar op dit moment biedt een EV/OV certificaat van een "echte" CA maar weinig voordeel boven een via DANE gevalideerd certificaat. De voornaamste waarde van een EV-certificaat is dat het vrij duur is om er eentje te krijgen. Daarmee valt het buiten het bereik van veel kruimeldiefjes.

Wel met die aantekening dat DANE er nog lang niet is wat betreft ondersteuning. In praktijk is het echt nog geen vervanger voor een traditioneel CA-certificaat, ook al is het er technisch klaar voor.

[Reactie gewijzigd door CAPSLOCK2000 op 31 juli 2024 03:54]

[VisionMaster]

Nee, ik doelde zoals in RFC2818 en RFC6125, dus niet de verificatie op het oog (want dat gok ik dat je hier op doelt). Het onderwerp hier is MX naar MX, dus geautomatiseerde processen.

[CAPSLOCK2000]

Ik snap het echt niet, misschien praten we langs elkaar heen...

Het onderwerp hier is MX naar MX, dus geautomatiseerde processen.

Ok, dat is in ieder geval duidelijk.

Het ging mij om het zinnetje:

Iedereen moet dus na deze invoering nog steeds goede certificaten gebruiken.

Dat leg ik uit als dat je zegt dat je ook als je DANE gebruikt je nog steeds certificaten van een CA nodig hebt in plaats van self-signed certificaten.

Welke aspect van (machinale) verificatie wordt niet door DANE + self-signed-certs ondersteunt of vervangen? Oftewel wat is de meerwaarde van DANE met "goede" certificaten* **.

Of begrijp ik je gewoon helemaal verkeerd?

* Het certificaat zelf is eigenlijk niet goed of fout, dat is maar een getal, net zo min als dat het getal 12 of 17 "goed" of "fout" is.

** Een duidelijk nadeel van DANE is dat je een netwerkverbinding nodig hebt om er gebruik van te maken. Het traditionele systeem van CA's heeft dat minder nodig, daarbij neemt iedereen de benodigde informatie zo veel mogelijk zelf mee.

[Meg]

Betekent dit dat de email moeilijker te vinden is voor derden om te lezen? Wat wel in Amerika gebeurde bij Hillary Clinton.

[WienerBlut]

Deels ja... De verbinding van de client tot de email server van bijvoorbeeld de afzender bij de overheid zal de verbinding worden versleuteld. Maar wanneer de ontvangende server geen versleuteling ondersteunt, dan zal de mail alsnog plain worden verstuurd tussen deze servers.

[Meg]

Dus feitelijk moet het overal standaard en verplicht voorzien worden van versleuteling?

[WienerBlut]

Ja inderdaad, alleen dan zal je versleuteling in transit kunnen garanderen.

[ATS]

Tot er een man-in-the-middle aanval plaatsvindt die zorgt dat er een server tussen zit die zegt versleuteling niet te ondersteunen. Boom, einde veilig transport.

Kan je bij email niet in een header aangeven dat het bericht alleen via beveiligd transport verzonden mag worden, en anders terugkomt in plaats van onbeveiligd verstuurd wordt?

[CAPSLOCK2000]

Tot er een man-in-the-middle aanval plaatsvindt die zorgt dat er een server tussen zit die zegt versleuteling niet te ondersteunen. Boom, einde veilig transport.

Kan je bij email niet in een header aangeven dat het bericht alleen via beveiligd transport verzonden mag worden, en anders terugkomt in plaats van onbeveiligd verstuurd wordt?

Dat is de andere standaard die nu verplicht is, DANE. Met DANE kun je via DNS aangeven dat je inderdaad TLS ondersteunt zodat je clients weten dat ze per se TLS moeten gebruiken en niet minder mogen accepteren. Ze vernemen ook welk certificaat ze mogen verwachten, zo kun je voorkomen dat een hacker zelf een certificaat aanmaakt met jouw naam er op.

[WienerBlut]

Je hebt helemaal gelijk! Je vraag kan ik helaas niet beantwoorden, is best een goed idee!

[wizzkizz]

DANE zorgt er nu net voor dat de verzendende server weet dat er een beveiligde verbinding mogelijk is en welk certificaat daar bij hoort. Die hoeft zo een downgrade aanval dus niet te accepteren en kan ook controleren of het juiste certificaat aangeboden wordt om een mitm te detecteren.

[Dorank]

Geen idee waar de Clinton mail vandaan komt, maar hier gaat het puur over het transport van SMTP. Het grote probleem is dat encryptie tot nu toe volledig opportunistic (we proberen het en anders gewoon plain text). Je kan nauwelijks afdwingen dat er encryptie wordt gebruikt (omdat niet elke MTA dat ondersteund) en is/was geen zinnige manier om certificaten te controleren. Additioneel probleem is dat er officieeel geen support is voor smtps en dat met een simpele MitM het STARTTLS commando uit de plaintext handshakte te verwijderen is.

[joostdebruijn]

Klopt, maar er wordt wel aan gewerkt dit te verbeteren. Men is momenteel bezig met een RFC voor smtp-sts (zie de working draft https://github.com/mrisher/smtp-sts), waarbij je doormiddel van een policy kan aangeven dat smtp verbindingen altijd met STARTTLS opgebouwd moeten worden. Daarnaast kun je aangeven welke cetificaten de verzender kan verwachten met een certificate pinning mechanisme. Wel moeten zowel de ontvangende partij als de verzendende partij dit ondersteunen om er van te profiteren. Wellicht wordt dit ook ooit nog eens pas-toe-of-leg-uit!

[Reactie gewijzigd door joostdebruijn op 31 juli 2024 03:54]

[CAPSLOCK2000]

Klopt, maar er wordt wel aan gewerkt dit te verbeteren. Men is momenteel bezig met een RFC voor smtp-sts (zie de working draft https://github.com/mrisher/smtp-sts), waarbij je doormiddel van een policy kan aangeven dat smtp verbindingen altijd met STARTTLS opgebouwd moeten worden. Daarnaast kun je aangeven welke cetificaten de verzender kan verwachten met een certificate pinning mechanisme. Wel moeten zowel de ontvangende partij als de verzendende partij dit ondersteunen om er van te profiteren. Wellicht wordt dit ook ooit nog eens pas-toe-of-leg-uit!

Met DANE kun je effectief hetfzelfde bereiken. Beide systemen hebben voor- en nadelen maar beide bieden een mogelijkheid om aan te geven dat er gebruik moet worden gemaakt van SSL/TLS.

[kdekker]

Het enige waar geen kruid tegen gewassen is, is een gebruiker, die met alle beveiligde verbindingen, toch nog een wachtwoord als '1234' gebruikt. Maar goed, dan zit het niet in de infrastructuur/beheerder, maar in de eindgebruiker. En die overtuigen is (nagenoeg) onbegonnen werk.

Kortom: beheerders moeten er voor zorgen dat er geen onveilige protocollen openstaan (dat gaat verder dan mail alleen).

P.s. kortgeleden liep ik tegen een bijgewerkte SSL client aan (openSSL) die (zoals wij compileerden) oude protocollen overboord had gegooid. En dan valt plots de integratie om met een bank die het vertikt nieuwere/veiliger varianten te gebruiken. Dus verplichte overstap op SSL is niet het antwoord op alles, omdat binnen SSL ook legio mogelijkheden zijn voor meer en minder veilig werken.

[Jeoh]

Uh, password policies? Als je anno 2016 nog steeds 1234 als wachtwoord / PIN toestaat, dan doe je wat fout.

[kdekker]

Klopt, maar doe dat eens op UNIX bakken met NIS. We zijn bezig met een koppeling naar AD. Dan is dit probleem over.

[Verwijderd]

Beheerders moeten password policies introduceren als 1234 toegestaan wordt....

[Perkouw]

Begrijp me niet verkeerd, een goede zet, maar het heeft nog steeds weinig zin als ze te pas en onpas gebruik maken van privé mail voor gevoelige informatie. Ik zie toch liever dat ze eerst dat aan banden leggen, maar goed.

[ATS]

Hoe kom je er bij dat dat "te pas en te onpas" gebeurt? Niet iedereen heet Clinton en heeft een email server in zijn kelder staan...

[Perkouw]

De eerste Google hit: http://politiek.tpo.nl/20...l-voor-zakelijke-stukken/

Met name deze quote wil ik je niet onthouden, die je o.a. hier terug vind -> https://www.security.nl/p...il+voor+werk+verkeerd+was

"Ik ben de hele dag met allerlei dingen bezig en ik moet zorgen dat ik mijn werk zo goed mogelijk doe en soms is het voor mij gemakkelijk om het op deze manier te doen"

[Reactie gewijzigd door Perkouw op 31 juli 2024 03:54]

[ATS]

Dank voor het toevoegen van een bron.

[WienerBlut]

Ik denk dat Perkouw Minister Kamp bedoelde met z'n gmail account... En hij was destijds niet van plan het overheidsaccount voor overheidszaken te gebruiken.

[Verwijderd]

Allemaal leuk en aardig, maar een groot gedeelte van de gemeentes waar ik mee correspondeer, maakt helemaal geen gebruik meer van eigen mailservers.

Vrijwel zonder uitzondering maken ze gebruik van clouddiensten, sommigen via hun eigen provider en bijbehorend spamfilter, maar ook een heleboel van de Microsoft Cloud. Een paar gemeentes zijn zelfs nog niet zover dat hun mail zo geconfigureerd hebben dat ze vanaf hun eigen domein mailen, bij ons komt er dan te staan [e-mail] via xxx.onmicrosoft.com, waarbij ook nog direct te zien is welke gemeente de mail voor hun regelt.

Ongetwijfeld ondersteunen deze clouddiensten starttls en later dane, wat dan een veilige overdracht waarborgt. Wat er echter daarna gebeurt, daar heb ik wel mijn twijfels over. Als het je al niet lukt om een cloudproduct juist in te stellen, vrees ik dat het met achterliggende kennis ook niet al te best gesteld is.

[CAPSLOCK2000]

Ongetwijfeld ondersteunen deze clouddiensten starttls en later dane, wat dan een veilige overdracht waarborgt. Wat er echter daarna gebeurt, daar heb ik wel mijn twijfels over. Als het je al niet lukt om een cloudproduct juist in te stellen, vrees ik dat het met achterliggende kennis ook niet al te best gesteld is.

Het is allemaal dramatisch slecht gesteld met de veiligheid en vooral het gebrek aan besef hiervan. Dat is echter geen reden om met de handen in het haar te gaan zitten en niks te doen. Laten we doen wat we kunnen en beginnen met de makkelijkste aspecten waarmee we met de minste inspanning de grootste verbetering kunnen bereiken. De lat ligt nu ongelofelijk laag. Als daar iets aan gedaan is kunnen we verder gaan met de andere problemen aanpakken. Ik zou het ook liever vandaag dan morgen geregeld hebben maar dat zit er nu eenmaal niet in.

[WienerBlut]

Dit is een goede zaak!! Nog steeds is email vaak plain text... Maar helaas is niet al het dataverkeer, en in het bijzonder bij email, versleuteld tussen servers... Maar dit is een fantastische stap!

[Aragnut]

[off topic] moeten alle sleutels dan wel even gedeeld worden met de AIVD? [/off topic]

Het is heel goed om te zien dat de regering versleuteling en beveiliging op dit vlak beter wil gaan toepassen, wat hopelijk tot een beter ecosysteem zal leiden.

[Rudie_V]

Zou tijd worden dat het verplicht wordt. Er gaat genoeg persoonlijk informatie via de mail en net als websites zou dit ook beveiligd moeten zijn. Beveiliging behoort immers de standaard te zijn vandaag de dag.

[TWyk]

Ik zien wel veel overheden die een disclaimer in hun mail opnemen.
Staat in veel beveiligingshandboekjes.
Ultieme non-beveiliging!!!