Duitse BSI publiceert uitgebreide technische richtlijn e-mailauthenticatie

Eerste aanvalsvector

"Mensen vertrouwen steeds meer op digitale communicatie en zijn steeds afhankelijker daarvan," aldus Florian Bierhoff, werkzaam bij de BSI en een van de auteurs van de richtlijn. "Daarbij is e-mail een van de meest gebruikte vormen van digitale communicatie. Tegelijkertijd is e-mail nog steeds kwetsbaar voor 'Man-in-the-Middle'-aanvallen zoals afluisteren en manipulatie van berichten, en voor impersonatie-aanvallen zoals spoofing en phishing. Dit type aanvallen fungeert bovendien vaak als eerste ingang naar grotere aanvallen waarbij complete netwerken worden gecompromitteerd [1, 2]."

"Deze richtlijn is gericht op organisaties met eigen mailvoorzieningen en -infrastructuur en op mailaanbieders. De beveiligingstechnieken die onder deze richtlijn vallen, zijn onzichtbaar voor de eindgebruiker. Aan de positieve kant betekent dat dat gebruikers niets fout kunnen doen. Aan de negatieve kant vinden managers het moeilijk om budget vrij te maken voor onzichtbare features. Deze richtlijn biedt een handvat om een behoorlijk veiligheidsniveau op te bouwen en geeft je ook een manier om dat zichtbaar te maken middels een label en certificering."

State-of-the-art

De auteurs van de TR-03182-richtlijn kwalificeren het drietal SPF, DKIM en DMARC als state-of-the-art in e-mail authenticatie. Daarnaast adviseren zij de toepassing van 'TR-03108 Secure Email Transport', dat een vergelijkbare richtlijn met bijbehorende toetsing geeft voor de beveiliging van mailtransport. Dat gebeurt dan op basis van (START)TLS, DANE, MTA-STS en TLS-RPT.

Zoals je in de mailkolom van ons maturitymodel voor de toepassing van moderne internetstandaarden kunt zien, bouwen wij de stack voor de beveiliging van e-mail op vergelijkbare wijze op: Eerst de implementatie van SPF en DKIM, gevolgd door DMARC. Daarmee is de authenticiteit van het bericht, de verzender (een systeem) en de afzender (een persoon) geregeld. Daarna implementeer je (START)TLS en DANE, waarmee ook het transport van de mailberichten beveiligd is.

Merk op dat de end-to-endversleuteling van mailberichten hier nog ontbreekt. Daarvoor zet je typisch OpenPGP en S/MIME op individuele basis in. Voordeel van bovengenoemde authenticatie- en encryptie-oplossingen is dat ze volledig transparant zijn voor de eindgebruiker.

Eisen TR-03182

In de TR-03182-richtlijn zijn de eisen aan e-mailauthenticatie tot in redelijk detail uitgewerkt. Voor de techniek en achtergrond van de betreffende standaarden verwijzen we je graag naar onze FAQ betreffende e-mailbeveiliging. Op diezelfde pagina vind je ook links naar de hands-on artikelen voor de implementatie van deze beveiligingsmiddelen op Exim en Postfix.

Ondanks dat de BSI in zijn richtlijn regelmatig refereert naar de Duitse situatie en wetgeving, vinden we hun aanbevelingen ook heel waardevol voor Nederlandse organisaties. Hieronder zetten we daarom de eisen die niet op deze manier in bovenstaande documenten worden besproken op een rijtje:

SPF

Geen aanvullingen voor SPF-specificatie en validatie.

DKIM

DKIM-ondertekening:

• De DKIM-selector moet bij voorkeur uniek zijn. (Vanuit puur technisch perspectief is het geen probleem om hetzelfde sleutelpaar voor meerdere domeinen tegelijk te gebruiken, of zelfs voor alle domeinen op de verzendende mailserver.)

• We zitten op dit moment in een overgangsperiode van cryptografische methode RSA naar Ed25519, dus nu onderteken je met zowel RSA-SHA256 als ED25519-SHA256 (RFC 8463); Voor RSA-SHA256 gebruik je een sleutellengte tussen de 1024 en 2048 bits; De methode RSA-SHA1 mag helemaal niet meer gebruikt worden (per RFC 8301).

• Het DKIM-sleutelpaar kun je het beste elke 3 maanden vernieuwen (middels een kleine rollover), maar doe dat in ieder geval elk half jaar.

• Er moet een DKIM-monitor opgezet worden: deze ontvangt een kopie van alle uitgaande berichten en controleert of de ondertekening in orde is; is dat niet het geval, dan moet de monitor een waarschuwing geven. Het doel is om te voorkomen dat problemen met één of een beperkt aantal afzenderadressen de reputatie en daarmee de "deliverability" voor een heel domein (i.e. een hele organisatie) aantasten.

• De uitgaande mailserver moet (strikte) DKIM Oversigning toepassen: daarbij worden ook niet aanwezige (lege) mail-headers in de ondertekening meegenomen; Zo worden 'DKIM Replay'-aanvallen (waarbij ontbrekende headers door een aanvaller worden toegevoegd) geblokkeerd.

DKIM-validatie:

• De ontvangende mailserver moet (naast de RSA-gebaseerde handtekeningen) ook moderne Ed25519-SHA256-gebaseerde handtekeningen kunnen valideren.

• De inmiddels verouderde RSA-SHA1-gebaseerde handtekeningen mogen niet meer geaccepteerd worden.

DMARC

DMARC-publicatie:

• Indien mogelijk moet alleen 'strict alignment' tussen de From-header enerzijds en de envelope (SPF) en het 'signing domain' (DKIM) anderzijds toegestaan worden; Externe dienstverleners mogen alleen een apart (naar hen gedelegeerd) subdomein gebruiken om berichten (namens de betreffende organisatie) te versturen.

• Alleen de policy’s 'reject' en 'quarantine' zijn toegestaan; op termijn alleen nog de policy 'reject'

• Het DMARC-record moet minstens één RUA-adres bevatten, en geen enkel RUF-adres.

• De data in de DMARC-rapportages betreffen persoonsgegeven en mogen dus alleen binnen de EU (volgens de GDPR) verwerkt worden. Bovendien mag de verwerker van de rapportages niet door een ander land gedwongen kunnen worden om deze data af te staan (e.g. onder de Amerikaanse Cloud Act en Freedom Act, de opvolger van de Patriot Act).

DMARC-validatie:

• Binnenkomende berichten moeten volgens de DMARC-policy van het afzenderdomein verwerkt worden; 'Local-overrides' voor problematische afzenderdomeinen zijn alleen een noodoplossing maar houden op termijn problemen alleen maar in stand; Afwijkingen in de vorm van ‘local-overrides’ moeten verantwoord en gedocumenteerd worden.

DMARC-rapportages:

• Ongeacht de DMARC-policy van het afzenderdomein mag het ontvangende mailsysteem nooit RUF-rapportages sturen; deze bevatten persoonsgegevens en het versturen daarvan is tegen de GDPR.

• De afzender van de DMARC-rapportages moet een geldig mailadres bevatten, zodat de ontvanger navraag kan doen in geval van problemen.

• Binnenkomende rapportages moeten periodiek (automatisch) worden verwerkt.

Null MX

Domeinen zonder mailingang:

• Moeten zijn voorzien van een Null MX-record: domeinnaam.nl IN MX 0 .

• Bovendien moet een SPF-record worden gepubliceerd waarin geen enkele server is geautoriseerd om namens dit domein berichten te verzenden: domeinnaam.nl IN TXT "v=spf1 -all"

• en een DMARC-record ingesteld worden op 'reject' en voorzien van een RUA-adres: _dmarc.domeinnaam.nl IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@dmarc-processor.nl;" Let op dat de ontvanger van de DMARC-rapportages op zijn domein wel eerst middels een DMARC authorization-record toestemming moet geven voor de aflevering van deze berichten: domeinnaam.nl._report._dmarc.example.nl IN TXT "v=DMARC1;"

DNSSEC

Voor alle 3 de mailbeveiligingsstandaarden geldt dat de betreffende DNS-records (ingesteld aan verzendende zijde) het liefst wel maar niet per se met DNSSEC beveiligd moeten zijn. Dit is een gevolg van de RFC-standaarden waarin de verplichting tot DNSSEC niet hard opgenomen is (SHOULD), omdat men destijds bang was dat een harde verplichting (MUST) de adoptie van deze beveiligingsstandaarden zou hinderen.

Aan ontvangende zijde is de toepassing van een DNSSEC-validerende resolver wel verplicht. Dat betekent dat DNS-records die door de verzendende zijde ondertekend zijn, aan ontvangende zijde ook altijd gevalideerd moeten worden.

Niet-functionele eisen

• Mailverwerkers moeten een veiligheidsplan opstellen volgens de nationale telecommunicatie-wetgeving, en dat plan regelmatig bijwerken.

• Alle verwerking moet voldoen aan de GDPR.

• Gebruikers moeten volgens de nationale wetgeving op de hoogte gesteld worden van veiligheidsproblemen.

• Mail-verwerkers moeten hun gebruikers infomeren over andere verwerkers waarmee zij mail uitwisselen en die ook aan de eisen van deze technische richtlijn voldoen

• Mailverwerkers kunnen hun eigen compliance aan deze richtlijn aantonen middels een 'IT Security Label' van de BSI of een 'Certification to Technical Guidelines' van een BSI-geaccrediteerd onderzoeksbureau.

• Daarvoor zijn conformiteitseisen en -tests opgesteld in een apart document: 'Conformance Tests for Email Authentication in compliance with BSI TR-03182'

Druk op adoptie

"Iets als het Nederlandse 'pas toe of leg uit’-principe kennen we in Duitsland niet," vertelt Bierhoff. "Deze richtlijnen zijn slechts aanbevelingen. Hier staat wel op andere manieren druk op de adoptie van TR-03182: door deze richtlijnen op te nemen in aanbestedingseisen, via de marktpositionering van degenen die het label gebruiken of gecertificeerd zijn, en door Data Protection Officers die de implementatie van deze richtlijn eisen zoals zij dat eerder ook al voor TR-03108 deden [1]."

Nederlandse organisaties kunnen als zij willen ook in aanmerking komen voor de 'IT Security Labels' of de 'Certifications to Technical Guidelines' van de BSI, zij het met een paar kanttekeningen: Het label is alleen van toepassing op producten en diensten voor klanten in Duitsland en op dit moment alleen beschikbaar voor TR-03108 (v1). De certificering is wel al beschikbaar voor TR-03108 (v2). Aan de certificering voor TR-03182 wordt nog gewerkt, maar organisaties kunnen zich al aanmelden bij de BSI.

Publicaties Nederlandse NCSC

Onze eigen Nederlandse NCSC publiceerde in 2021 de laatste 'ICT-beveiligingsrichtlijnen voor Transport Layer Security v2.1 (TLS)'. Dat document behandelt TLS en DANE in algemene zin, met de nadruk op de instelling van de cryptografische algoritmen [Exim, Postfix]. Daarnaast is er de 'Factsheet Beveilig verbindingen van mailservers', maar die is veel beknopter en dateert nog uit 2017. Op de website van de NCSC kunnen we lezen dat op dit moment aan een nieuwe versies van deze 2 documenten gewerkt wordt, maar wat de huidige status daarvan is kon men niet zeggen.

SPF, DKIM en DMARC worden behandeld in de wel recente 'Handreiking Bescherm domeinen tegen phishing', zij het weer heel beperkt.

Shoppen

Vooralsnog bieden de Duitse richtlijnen een stevige en actuele basis voor de implementatie van e-mailauthenticatie (en beveiligd mailtransport). Voor de details omtrent de cryptografische algoritmen voor TLS zijn de beveiligingsrichtlijnen van de NCSC nog steeds een goede bron.

Zodra de NCSC nieuwe versies van zijn documenten heeft gepubliceerd, besteden we daar weer aandacht aan op deze website.