Bijlage 5 Factsheet-emailauthenticatie

Factsheet

E-mailauthenticatie: Voorkom dat anderen e-mailberichten versturen namens uw gemeentelijke e-maildomein Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)

Colofon Naam document E-mailauthenticatie: Voorkom dat anderen e-mailberichten versturen namens uw gemeentelijke emaildomein (uitgebreide versie) Versienummer 1.1 Versiedatum 05 - 2020 Versiebeheer Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).

Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten (IBD) Tenzij anders vermeld, is dit werk verstrekt onder een Creative Commons Naamsvermelding-Niet Commercieel-Gelijk Delen 4.0 Internationaal licentie. Dit houdt in dat het materiaal gebruikt en gedeeld mag worden onder de volgende voorwaarden: Alle rechten voorbehouden. Verveelvoudiging, verspreiding en gebruik van deze uitgave voor het doel zoals vermeld in deze uitgave is met bronvermelding toegestaan voor alle gemeenten en overheidsorganisaties. Voor commerciële organisaties wordt hierbij toestemming verleend om dit document te bekijken, af te drukken, te verspreiden en te gebruiken onder de hiernavolgende voorwaarden: 1. De IBD wordt als bron vermeld. 2. Het document en de inhoud mogen commercieel niet geëxploiteerd worden. 3. Publicaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker berusten, blijven onderworpen aan de beperkingen opgelegd door de IBD en / of de Vereniging van Nederlandse Gemeenten. 4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze paragraaf vermelde mededeling. Wanneer dit werk wordt gebruikt, hanteer dan de volgende methode van naamsvermelding: “Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten”, licentie onder: CC BY-NC-SA 4.0.

Bezoek http://creativecommons.org/licenses/by-nc-sa/4.0 voor meer informatie over de licentie.

2

Rechten en vrijwaring De IBD is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan de IBD geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave voorkomende onjuistheden, onvolledigheden of nalatigheden. De IBD aanvaardt ook geen aansprakelijkheid voor enig gebruik van voorliggende uitgave of schade ontstaan door de inhoud van de uitgave of door de toepassing ervan. Met dank aan De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product. Wijzigingshistorie Versie

Datum

Wijziging / Actie

1.0

02-06-2016

1ste versie

1.1

27-05-2020

BIO update en actualisatie wet en regelgeving

Over de IBD De IBD is een gezamenlijk initiatief van alle Nederlandse Gemeenten. De IBD is de sectorale CERT / CSIRT voor alle Nederlandse gemeenten en richt zich op (incident)ondersteuning op het gebied van informatiebeveiliging. De IBD is voor gemeenten het schakelpunt met het Nationaal Cyber Security Centrum (NCSC). De IBD ondersteunt gemeenten bij hun inspanningen op het gebied van informatiebeveiliging en privacy / gegevensbescherming en geeft regelmatig kennisproducten uit. Daarnaast faciliteert de IBD kennisdeling tussen gemeenten onderling, met andere overheidslagen, met vitale sectoren en met leveranciers. Alle Nederlandse gemeenten kunnen gebruikmaken van de producten en de generieke dienstverlening van de IBD. De IBD is ondergebracht bij VNG Realisatie.

3

Leeswijzer Dit product is een nadere uitwerking voor gemeenten van de Baseline Informatiebeveiliging Overheid (BIO). De BIO is eind 2018 bestuurlijk vastgesteld als gezamenlijke norm voor informatiebeveiliging voor alle Nederlandse overheden. Doel Het doel van dit document is informatie geven over de mogelijkheden om ‘e-mail spoofing’ tegen te gaan, door het valideren van de identiteit van de afzender door gebruik te maken van de emailauthenticatiestandaarden SPF, DKIM en DMARC. Doelgroep Dit document is van belang voor informatiebeveiligers van de gemeente, de CISO, het management van de gemeente, de systeemeigenaren, applicatiebeheerders en de ICT-afdeling. Relatie met overige producten • Baseline Informatiebeveiliging Overheid (BIO) • Informatiebeveiligingsbeleid van de gemeente Verwijzingen naar de Baseline Informatiebeveiliging voor de Overheid (BIO) 13.2.3 Elektronische berichten Informatie die is opgenomen in elektronische berichten behoord passend te zijn beschermd. 13.2.3.1 Voor de beveiliging van elektronische (e-mail)berichten gelden de vastgestelde open standaarden tegen phishing en afluisteren op de ‘pas toe of leg uit’-lijst van het Forum. Voor beveiliging van websiteverkeer gelden de open standaarden tegen afluisteren op de ‘pas toe of leg uit’-lijst van het Forum.

4

Inhoudsopgave 1.

Inleiding ......................................................................................................................................6

2.

Achtergrond...............................................................................................................................6

3.

Wat levert e-mailauthenticatie mijn gemeente op?.....................................................7

3.1. Voldoen aan wet- en regelgeving ....................................................................................................7

4.

Wat zijn de standaarden SPF, DKIM en DMARC?...........................................................7

4.1. SPF ...................................................................................................................................................9 4.2. DKIM ..............................................................................................................................................13 4.3. DMARC...........................................................................................................................................15

5.

Hoe maakt u uw e-mailberichten betrouwbaarder?.................................................17

5.1. Pas DNSSEC toe..............................................................................................................................17 5.2. Blokkeer niet gebruikte domeinnamen .........................................................................................17 5.3. Volg stappenplan ...........................................................................................................................18 5.4. Maak bij DKIM-sleutelrotatie gebruik van CNAME-records ..........................................................19 5.5. Hulpmiddelen ................................................................................................................................19

6.

5

Adviezen IBD met betrekking tot SPF, DKIM en DMARC..........................................20

1.

Inleiding

Volgens het Dreigingsbeeld Informatiebeveiliging Nederlandse Gemeenten 2019/2020 hebben aanvallers vaak niet meer nodig dan een niet bijgewerkt stukje software of een klik op een phishingmail om toegang te krijgen tot systemen. Ook het Cybersecuritybeeld Nederland 2019 van het Nationaal Cyber Security Centrum (NCSC) maakt melding van een groei aan fraude-incidenten. Dit zit vooral in een toename van gemelde phishingcampagnes, waarbij het label ‘fraude’ betrekking heeft op het onrechtmatig gebruik van organisatienamen bij het verzenden van phishingmails. Naast bewustzijn is ook de bredere invoering van emailauthenticatie noodzakelijk. Met e-mailauthenticatie kan een gemeente haar domeinnaam beschermen tegen betrouwbaar lijkende phishing e-mailberichten waarin bijvoorbeeld bijlagen of links naar malware of valse inlogpagina’s zitten. Het zorgt ervoor dat derden niet zomaar de gemeentelijke domeinnaam als afzenderadres kunnen misbruiken. Dit wordt ‘afzenderadres-vervalsing’ of ‘e-mail spoofing’ genoemd en is uit te voeren zonder diepgaande technische kennis. E-mailauthenticatie voorkomt dit en zorgt er bovendien voor dat spam nauwkeuriger wordt herkend. Het werkt op basis van de open standaarden SPF, DKIM en DMARC. Veel gemeenten passen deze standaarden al succesvol toe.1 Deze standaarden zijn ook relevant voor domeinnamen waarvan niet gemaild wordt.

Op de website internet.nl kunt u eenvoudig controleren of uw gemeentelijke e-maildomein gebruik maakt van de e-mailauthenticatiestandaarden SPF, DKIM en DMARC, zodat ontvangers echtheidskenmerken en bijbehorende aanwijzingen kunnen gebruiken om te controleren of een e-mailbericht vervalst is en hoe hiermee om te gaan. Deze factsheet legt uit hoe u phishing, spam en virussen die via e-mailberichten verspreid worden kunt terugdringen door gebruik te maken van e-mailauthenticatie. Voor de drie e-mailauthenticatiestandaarden SPF, DKIM en DMARC zal vooral ingegaan worden op de inrichting en de daarmee samenhangende consequenties. In deze factsheet wordt achtereenvolgens aandacht besteed aan de beveiligingsvoordelen van e-mailauthenticatie voor gemeenten, de achterliggende e-mailauthenticatiestandaarden SPF, DKIM en DMARC, hoe uw gemeente gebruik kan maken van e-mailauthenticatie en tenslotte het IBD advies. Voor meer uitgebreide en technische achtergrondinformatie wordt verwezen naar de uitgebreide versie van deze factsheet op de website van de IBD.

2.

Achtergrond

Voor het uitwisselen van e-mailberichten wordt gebruik gemaakt van het standaard (de facto) protocol Simple Mail Transport Protocol (SMTP). Dit SMTP-protocol is een relatief simpel, tekst gebaseerd protocol, dat geen betrouwbare voorzieningen bevat om na te gaan of de afzender echt is wie hij beweert te zijn. Deze beperking biedt derden de mogelijkheid om e-mailberichten te versturen namens andere emailadressen. Zonder extra maatregelen is er geen enkele zekerheid of een e-mailbericht wel echt afkomstig is van de organisatie namens welke het e-mailbericht verstuurd wordt. Een belangrijke manier om ‘e-mail spoofing’ tegen te gaan, is het valideren van de identiteit van de afzender door de ontvangende persoon of organisatie. Dit wordt e-mailauthenticatie genoemd. SPF, DKIM en DMARC zijn technieken voor e-mailauthenticatie en maken gebruik van het DNS-systeem (Domain Name

Forum Standaardisatie voert ieder halfjaar een meting uit op de implementatie van informatieveiligheidstandaarden bij overheidsorganisaties. De laatst uitgevoerde meting dateert van maart 2020, de resultaten vindt u in het rapport Meting Informatieveiligheidstandaarden overheid maart 2020. 1

6

System) om hun informatie te publiceren2. De verzendende organisatie zorgt voor echtheidskenmerken die de ontvangende organisatie geautomatiseerd kan controleren. Voor de eindgebruiker vindt dit allemaal transparant plaats en hij hoeft hier niets nieuws voor in te stellen of te valideren, maar is wel beter beschermd.

3.

Wat levert e-mailauthenticatie mijn gemeente op?

Veelal vervalsen of ‘spoofen’ aanvallers een domeinnaam, zodat de phishing en spam e-mailberichten afkomstig lijken van het e-mailadres van een betrouwbare organisatie. Met e-mailauthenticatie wordt een betrouwbare e-mailcommunicatie tussen gemeenten en burgers, bedrijven, (keten)partners en (semi)overheidsorganisaties bevorderd en beschermt de gemeente zichzelf tegen e-mailberichten van ongeauthentiseerde afzenders. Dit geldt voor alle domeinnamen, waarvan de gemeente de houder is. Concreet betekent dit dat e-mailauthenticatie ervoor zorgt dat uw gemeente: •

De kans vermindert dat derden uw e-mailadressen misbruiken voor het versturen van spam en/of phishing e-mailberichten.

•

De afleveringszekerheid van e-mailberichten vergroot, zodat de e-mailberichten in de inbox van de ontvanger worden afgeleverd in plaats van de spambox.

•

Minder vatbaar wordt voor oplichting en/of ransomware verspreid via vervalste e-mailadressen.

Het verhoogd het vertrouwen in de gemeentelijke domeinnaam.

3.1.

Voldoen aan wet- en regelgeving

De SPF en DKIM-standaarden zijn sinds 2013 opgenomen op de lijst met verplichte open standaarden voor de gehele publieke sector (‘pas-toe-of-leg-uit-lijst’) van het Forum Standaardisatie . Dit betekent dat overheden en semi-overheden SPF en DKIM dienen toe te passen en alleen in geval van zwaarwegende redenen daarvan mogen afwijken. DMARC is ook getoetst en sinds 2018 toegevoegd aan de ‘pas-toe-of-leguit’-lijst. Ook de Baseline Informatiebeveiliging Overheid (BIO) eist dat voor de beveiliging van elektronische (e-mail)berichten de vastgestelde open standaarden tegen phishing en afluisteren op de ‘pas toe of leg uit’lijst gelden van het Forum Standaardisatie. Tevens adviseert het NCSC e-mailauthenticatie met behulp van SPF, DKIM en DMARC in te zetten om spam en phishing namens uw domeinnamen tegen te gaan.

4.

Wat zijn de standaarden SPF, DKIM en DMARC?

SPF, DKIM en DMARC zijn open e-mailauthenticatie-standaarden en zorgen voor het terugdringen van phishing, spam en virussen die via een e-mailbericht bezorgd worden. Ze worden meestal gezamenlijk ingezet om te controleren dat de afzender, het e-mailadres en –server, van een e-mailbericht inderdaad kloppen, en dat de inhoud van het e-mailbericht onderweg niet is gewijzigd. Deze emailauthenticatiestandaarden maken gebruik van het DNS-systeem om hun informatie te publiceren. Voor alle drie de e-mailauthenticatiestandaarden geldt dat zowel de verzendende als ontvangende organisatie, van e-mailberichten, implementatie- en beheeractiviteiten dienen uit te voeren om volledig gebruik te kunnen maken van de geboden bescherming door deze e-mailauthenticatiestandaarden (zie figuur 1).

Er zijn drie soorten DNS-servers te weten, master (hoofdserver van een zone, waarop je wijzigingen publiceert), slave (repliceert van de master) en caching/forwarders. De master en slave servers zijn authoritatieve servers, deze stellen de bron DNS-data ter beschikking aan het wereldwijde DNS-systeem. De caching of forwarder servers zoeken in het wereldwijde DNS-systeem voor eindgebruikers. 2

7

De verzendende organisatie, gemeenten, dienen de basis te leggen voor de SPF-, DKIM- en/of DMARCstandaard door deze te implementeren (stap 1 in figuur 1). Voor gemeenten betekent dit concreet dat ze hun DNS-systeem dienen te voorzien van de correcte SPF, DKIM en/of DMARC DNS-records. De ontvangende organisaties dienen hun inkomende/ontvangende e-mailservers zo te configureren dat deze automatisch controleren of het ontvangen e-mailbericht legitiem is of niet (stap 2 in figuur 1). Uiteraard geldt dit ook voor gemeenten als ontvanger van e-mailberichten, maar dit wordt in deze factsheet buiten beschouwing gelaten. Hiervoor dient de inkomende/ontvangende e-mailserver te controleren of de gegevens van het ontvangen e-mailbericht overeenkomen met de instellingen van de SPF, DKIM en/of DMARC DNS-record die de verzendende organisatie heeft geconfigureerd. Voor de eindgebruiker vindt dit allemaal transparant plaats en hij hoeft hier niets nieuws voor in te stellen of te valideren, maar is wel beter beschermd.

Figuur 1 Eenmalige implementatieactiviteiten voor verzendende en ontvangende organisatie van emailberichten Opmerking: Het toevoegen van een SPF-, DKIM- en/of DMARC-record aan het DNS-systeem kent een korte doorlooptijd. Niet alle gemeenten beheren hun eigen DNS-systeem en dienen hiervoor een wijzigingsverzoek in te dienen bij hun provider die daar in een enkel geval een klein bedrag voor in rekening brengt. Als de verzendende en ontvangende organisatie, van e-mailberichten, de hierboven beschreven eenmalige implementatieactiviteiten hebben uitgevoerd vindt de bescherming van uw gemeentelijke e-maildomein automatisch en op de achtergrond plaats (zie figuur 2). Wellicht ten overvloede maar voor de eindgebruiker vindt dit allemaal transparant plaats en hij hoeft hier niets nieuws voor in te stellen of te valideren, maar is wel beter beschermd.

8

Figuur 2 Automatische handelingen verzendende en ontvangende organisatie in verband met SPF, DKIM en/of DMARC Op het moment dat nu e-mailberichten namens het e-maildomein worden verstuurd (stap 1 in figuur 2), waar SPF, DKIM en/of DMARC zijn geconfigureerd, worden de noodzakelijke handelingen automatisch en op de achtergrond uitgevoerd. De uitgaande/verzendende e-mailserver voegt (automatisch en op de achtergrond) een DKIM digitale handtekening toe aan het e-mailbericht (stap 2 in figuur 2). Als het emailbericht op de inkomende/ontvangende e-mailserver arriveert worden de SPF-, DKIM- en/of DMARCrecords behorende bij het e-maildomein uit de DNS opgehaald (stap 3 in figuur 2). Nu worden door de inkomende/ontvangende e-mailserver de bijbehorende controles uitgevoerd (stap 4 in figuur 2), zoals of de uitgaande/verzendende e-mailserver in het SPF-record van het e-maildomein voorkomt en of de DKIM digitale handtekening door de uitgaande/verzendende e-mailserver is geplaatst en of deze juist is. Na deze SPF- en DKIM-tests wordt op basis van de uitkomsten van deze tests het DMARC-beleid toegepast. Het DMARC-beleid kan de volgende resultaten opleveren (stap 5 in figuur 2): •

Als zowel de SPF- en DKIM-test succesvol zijn doorstaan, dan wordt het e-mailbericht afgeleverd in de inbox van de geadresseerde.

•

Als de SPF- en/of DKIM-test NIET succesvol wordt doorstaan wordt het e-mailbericht: o geaccepteerd, of o geaccepteerd maar als spam gemarkeerd, of o NIET geaccepteerd.

Als laatste stap (stap 6 in figuur 2) wordt door de inkomende/ontvangende e-mailserver een DMARCrapportage verstuurd naar de e-mailadressen die zijn gespecificeerd in het DMARC-record. Dit kan een periodiek geaggregeerd en/of forensics rapport zijn. De forensics rapporten kunnen privacygevoelige informatie bevatten, denk na waar u deze rapporten in uw gemeente laat binnenkomen en wie er allemaal toegang toe hebben.

4.1.

SPF

Sender Policy Framework (SPF) is een techniek waarmee een domeinnaamhouder kan aangeven welke emailserver(s) namens deze domeinnaam e-mailberichten mogen versturen (zie figuur 3)3,4. De domeinnaamhouder publiceert daarvoor een lijst van gerechtigde/geautoriseerde e-mailservers via het

3 4

Zie: http://tools.ietf.org/html/rfc7208 Zie de openspf-website voor achtergrondinformatie en verschillende implementaties voor e-mailservers.

9

DNS-systeem. SPF voorkomt hiermee dat inkomende/ontvangende e-mailservers e-mailberichten accepteren van niet gerechtigde/geautoriseerde e-mailservers. Hierdoor wordt ‘e-mail spoofing’ detecteerbaar gemaakt. Indien een e-mailserver niet in de lijst met gepubliceerde IP-adressen staat (SPF-record) maar toch emailberichten verstuurt met de betreffende domeinnaam als afzender, dan wordt het e-mailbericht als niet geauthenticeerd beschouwd. De inkomende/ontvangende e-mailserver bepaalt wat er met niet geauthentiseerde e-mailberichten dient te gebeuren, wel of niet accepteren. SPF controleert enkel het voor de gebruiker onzichtbare afzenderadres (envelope from) in de e-mailheader, niet het afzenderadres dat getoond wordt aan de gebruiker5. Een SPF-record is opgebouwd uit verschillende parameters, die aangeven welke e-mailservers als betrouwbaar worden beschouwd en namens de afzender e-mailberichten mogen versturen. Een inkomende/ontvangende e-mailserver zal, bij ontvangst van een e-mailbericht, het SPF-record van het emaildomein opvragen en de parameters controleren. Corresponderen die met de DNS-instellingen van het e-maildomein van de afzender, dan weet de inkomende/ontvangende e-mailserver dat het e-mailbericht legitiem is. Een SPF record begint altijd met een “v=” gedeelte.

Hiermee wordt aangegeven dat de inhoud van het TXT record een SPF record is en geeft tevens aan welke versie van het SPF-protocol wordt gebruikt. Dit gedeelte is essentieel voor de werking van het SPF-record, want anders wordt het gehele SPF-record genegeerd door de inkomende/ontvangende e-mailserver. Daarna wordt er aan de hand van mechanismen en qualifiers aangegeven wanneer een domein überhaupt e-mailberichten mag versturen. Met behulp van de mechanismen wordt aangegeven welke uitgaande/verzendende e-mailservers als betrouwbaar worden beschouwd. Met de qualifiers wordt aangegeven wat er met het betreffende e-mailbericht dient te gebeuren (wel of niet accepteren). Mechanismen kunnen worden gebruikt om de verzameling gerechtigde/geautoriseerde e-mailservers te beschrijven die e-mailberichten namens het e-maildomein mogen versturen. Domeinen kunnen nul of meerdere mechanismen definiëren. De mechanismen worden in volgorde geëvalueerd. Domeinen kunnen ook modifiers definiëren. Elke modifier kan slechts één keer voorkomen in een SPF-record. Als er geen mechanisme of modifier overeenkomt, is het standaard resultaat “Neutraal”. Elk mechanisme kan gecombineerd worden met een van de vier onderstaande qualifiers: •

“+”: geeft een PASS resultaat. Het e-mailbericht wordt altijd geaccepteerd.

•

“-”: voor een FAIL resultaat. Het e-mailbericht wordt dan NIET geaccepteerd door de ontvangende/inkomende e-mailserver.

•

“~”: voor een SOFTFAIL resultaat. Het e-mailbericht wordt dan wel toegelaten maar kan als spam beschouwd worden en in de spamfolder terecht komen.

•

“?”: geeft een NEUTRAAL resultaat. Het e-mailbericht wordt doorgelaten, omdat er geen mening gegeven wordt over het e-mailbericht (no policy).

De mechanismen die in een SPF-record gebruikt kunnen worden zijn: “all”, “a”, “ip4”, “ip6”,”mx”, “ptr”, “exists” en “include”: •

“all”: Dit mechanisme is altijd waar. Het staat meestal aan het eind van het SPF-record. o voorbeeld: “v=spf1 -all”. Het domein verstuurt helemaal geen e-mailberichten.

Een e-mailbericht dat door een e-mailprogramma wordt verstuurd, heeft twee verschillende afzenderadressen. Het zichtbare afzenderadres van het e-mailbericht kan per e-mailbericht afzonderlijk worden ingesteld. Dit is het adres dat mensen in hun emailprogramma te zien krijgen als ze het e-mailbericht ontvangen. Dit is ook het adres dat wordt gebruikt als de ontvanger op de ‘reply’ button klikt. Naast het afzenderadres, is er ook een ‘envelope from’ adres. Dit adres is voor gewone ontvangers niet zichtbaar en heeft vooral een technische betekenis. 5

1 0

•

“a”: Alle A-records van het domein worden gecontroleerd. Als het domein niet is gespecificeerd, wordt het huidige domein gebruikt. Wanneer het IP-adres waar de verzender vandaan mailt gelijk is aan het IP-adres (A-record in het DNS-systeem) van het domein, dan wordt het e-mailbericht toegelaten. o voorbeeld: “v=spf1 a -all”. Het huidige domein wordt gebruikt. o voorbeeld: “v=spf1 a:gemeente.nl -all”. Equivalent aan het vorige voorbeeld als het huidige domein gemeente.nl is.

•

“ipv4”: Wanneer de verzender zich in de IP versie 4 IP-range bevindt, wordt het e-mailbericht geaccepteerd. Voeg het IP-adres toe na “ip4’’ om het IP-adres te whitelisten.

•

“ipv6”: Wanneer de verzender zich in de IP versie 6 IP-range bevindt, wordt het e-mailbericht geaccepteerd. Voeg het IP-adres toe na “ip6’’ om het IP-adres te whitelisten.

•

“mx”: Wanneer het e-mailbericht verstuurd wordt vanuit het MX-record van het domein, dan wordt het e-mailbericht geaccepteerd.

•

“ptr”: (Pointer Record) is een record die wordt gebruikt voor omgekeerde DNS (DNS reverse), het zorgt voor de vertaling van een IP-adres naar hostnaam. Dit mechanisme controleert of de DNS reversemapping voor het gedefinieerde IP-adres bestaat en correct verwijst naar een domeinnaam binnen een bepaald domein. N.B. Het ptr afzender mechanisme wordt sterk afgeraden door RFC 7208.

•

“exists”: Wanneer het domein gekoppeld is aan een IP- adres, dan wordt het e-mailbericht geaccepteerd.

•

“include”: Als aan de voorwaarden in het record voldaan is, wordt het e- mailbericht geaccepteerd.

De modifiers die in een SPF-record gebruikt kunnen worden zijn: “redirect” en “exp”. Voor een beschrijving van de modifiers wordt verwezen naar de officiële beschrijving van de SPF-standaard. Wanneer tijdens de controle van het SPF-record een mechanisme een resultaat oplevert wordt de qualifier waarde gebruikt. De standaard qualifier is “+”, dat wil zeggen: “Pass”. Als een domeinnaam helemaal geen SPF-record heeft, is het resultaat “None”. Als er een (tijdelijke) fout optreedt tijdens de DNS-verwerking, dan is het resultaat “TempError”. Als er een syntax of evaluatie fout optreedt, bijvoorbeeld het domein specificeert een onbekend mechanisme, dan is het resultaat “PermError”. De evaluatie van een SPF-record kan een van de volgende resultaten opleveren: •

Pass: De uitgaande/verzendende e-mailserver is in het SPF-record aangeduid als gerechtigd/geautoriseerd om namens het domein e-mailberichten te versturen. Het beoogde resultaat van de controle is dat het e-mailbericht wordt geaccepteerd.

•

Fail: De uitgaande/verzendende e-mailserver is in het SPF-record aangeduid als NIET gerechtigd/geautoriseerd om namens het domein e-mailberichten te versturen. Het beoogde resultaat van de controle is dat het e-mailbericht wordt afgewezen.

•

SoftFail: De uitgaande/verzendende e-mailserver is in het SPF-record aangeduid als NIET gerechtigd/geautoriseerd om namens het domein e-mailberichten te versturen, maar zit in transitie. Het beoogde resultaat van de controle is dat het e-mailbericht wordt geaccepteerd, maar wordt gemarkeerd.

•

Neutraal: Het SPF-record geeft uitdrukkelijk aan dat er niets kan worden gezegd over de geldigheid. Het beoogde resultaat van de controle is dat het e-mailbericht wordt geaccepteerd.

•

None: Het domein beschikt niet over een SPF-record of de controle van het SPF-record levert geen resultaat op. Het beoogde resultaat van de controle is dat het e-mailbericht wordt geaccepteerd.

1 1

•

PermError: Er is een permanente fout opgetreden, bijvoorbeeld door een verkeerd geconfigureerd SPFrecord. Er is hiervoor GEEN beoogd resultaat gespecificeerd.

•

TempError: Er is een tijdelijke fout opgetreden. Het beoogde resultaat van de controle is dat het emailbericht is accepteren of NIET accepteren.

Hoe configureert u SPF voor de gemeente? Het (handmatig) samenstellen van een SPF-record dient zorgvuldig te gebeuren, zodat het SPF-record correct wordt ingesteld. Een fout SPF-record kan ervoor zorgen dat legitieme e-mailberichten niet worden afgeleverd en dat heeft een negatieve impact op uw reputatie. Er zijn op het internet verschillende tools/wizards beschikbaar die op basis van uw ingevulde gegevens het bijbehorende SPF-record genereren. Het resultaat van deze tools zou kunnen zijn dat te complexe of zelfs onjuiste SPF-records worden gegenereerd. Ook hiervoor geldt dat u over voldoende kennis dient te beschikken om de juiste input aan te kunnen leveren. Het advies is dan ook om, als uw gemeente niet over voldoende kennis beschikt, ondersteuning te vragen aan uw leverancier of hostingpartij of experts voor het configureren van het SPFrecord. Eventueel kan het Bureau Forum Standaardisatie (BFS)6 u adviseren over het gebruik van deze emailauthenticatiestandaarden.

Figuur 3 Sender Policy Framework (SPF)7 Voor het configureren van SPF dienen eenmalig de volgende stappen doorlopen te worden: 0. Identificeer welke e-mailservers er namens het gemeentelijke e-maildomein e-mailberichten mogen versturen. 1. Voeg het SPF-record toe aan bestaand DNS-record, zodat duidelijk is welke e-mailservers namens het e-maildomein e-mailberichten mogen verzenden. Bijvoorbeeld: “v=spf1 a:mail.ibdgemeenten.nl –all” •

“v=spf1”:Hiermee wordt aangegeven dat de inhoud in het TXT record een SPF-record is en geeft ook aan welke versie van het SPF-protocol (versie 1) wordt gebruikt.

•

“a:mail.ibdgemeenten.nl”: De server “mail.ibdgemeenten.nl” is gerechtigd/geautoriseerd om namens het e-maildomein “ibdgemeenten.nl” e-mailbericht te verzenden.

Het Bureau Forum Standaardisatie (BFS) is het secretariaat van het Forum Standaardisatie. Kort gezegd voert BFS de besluiten uit van het Forum Standaardisatie en bereidt ze voor. 7 In dit figuur is zowel de eenmalige gebeurtenis (nr. 1) als de herhalende gebeurtenissen (nr. 2 t/m 4) weergegeven. 6

1 2

•

“-all”: Alle andere servers zijn niet gerechtigd/geautoriseerd om namens het e-maildomein “ibdgemeenten.nl” e-mailberichten te verzenden en hiermee wordt aangegeven dat deze emailberichten als spam of phishing kunnen worden aangemerkt.

In stap 2 uit figuur 3 wordt een e-mailbericht samengesteld en verstuurd namens het e-maildomein naar de geadresseerde. Tijdens de SPF-controle worden de volgende stappen door de inkomende/ontvangende e-mailserver automatisch en op de achtergrond doorlopen: 3. De inkomende/ontvangende e-mailserver controleert in de DNS of de uitgaande/verzendende emailserver in het SPF-record van het e-maildomein voorkomt. 4. Bovenstaande controle kan de onderstaande uitkomsten opleveren: a. De uitgaande/verzendende e-mailserver komt voor in het SPF-record: Het e-mailbericht is afkomstig van een gerechtigde/geautoriseerde e-mailserver en het e-mailbericht wordt afgeleverd in de inbox van de geadresseerde. b. De uitgaande/verzendende e-mailserver komt NIET voor in het SPF-record: Het e-mailbericht is niet afkomstig van een gerechtigde/geautoriseerde e-mailserver, het e-mailbericht wordt als onrechtmatig beschouwd. Afhankelijk van het gedefinieerde SPF-beleid wordt de e-mail: •

altijd geaccepteerd, of

•

geaccepteerd maar als spam aangemerkt, of

•

NIET geaccepteerd.

Let op: Een SPF-record mag maar een beperkt aantal DNS-requests bevatten. Overschrijdt het tien (10) DNS-requests, dan zal het resulteren in een fout. Het is dus belangrijk het SPF-record correct te configureren.

4.2.

DKIM

Domain Keys Identified Mail (DKIM) is een techniek die met behulp van een digitale handtekening een emailbericht aan een domeinnaam koppelt (zie figuur 4)8,9,10. Hierbij ondertekent de uitgaande/verzendende e-mailserver alle uitgaande e-mailbericht namens dit e-maildomein. Zo wordt voorkomen dat kwaadwillenden een bericht namens een ander kunnen verzenden (spoofing) of de inhoud van een emailbericht onderweg kunnen veranderen.

Zie: https://tools.ietf.org/html/rfc6376 De volgende producten ondersteunen DKIM: Barracuda, IronPort, Postfix, Sendmail en SpamAssassin. Zie voor een uitgebreide maar niet onafhankelijk gevalideerd overzicht http://dkim.org/deploy/index.html. 10 Zie voor meer achtergrondinformatie: https://www.m3aawg.org/m3aawg-dkim-implementation-training-video. 8 9

1 3

Figuur 4 DomainKeys Identified Mail (DKIM)11 DKIM biedt inkomende/ontvangende e-mailservers de mogelijkheid te controleren welke domeinnaam (en daarmee welke achterliggende organisatie) verantwoordelijk is voor het verzenden van het e-mailbericht. DKIM blokkeert een e-mailbericht dat niet door een gerechtigde/geautoriseerde organisatie is verzonden niet zelf. Het markeert deze enkel als verdacht, waarna een (spam)filter op basis van deze markering spam en phishing e-mailberichten gericht kan filteren. Hoe configureert u DKIM voor uw gemeente? Voor het configureren van DKIM dienen eenmalig de volgende stappen doorlopen te worden: 1. Creëer een sleutelpaar Dit kan bijvoorbeeld met het programma openssl, via tools die door uw DNS-beheerder of een hosted DKIM leverancier worden aangeboden. 2. Voeg het DKIM-record (de publieke sleutel uit het sleutelpaar) toe aan bestaand DNS-record. Bijvoorbeeld: “v=DKIM1; k=rsa; Bijvoorbeeld: “v=DKIM1; k=rsa; p=[sleutel];” •

“v=DKIM1”: Hiermee wordt aangegeven dat de inhoud in het TXT record een DKIM-record is en geeft ook aan welke versie van het DKIM-protocol (versie 1) wordt gebruikt.

•

“k=rsa”: Hiermee wordt aangegeven welk sleuteltype (rsa) wordt gebruikt.

•

“p=[sleutel];”: Hiermee wordt de publieke sleutel weergegeven.

In stap 3 uit figuur 4 wordt een e-mailbericht samengesteld en verstuurd namens het e-maildomein naar de geadresseerde. Het e-mailbericht wordt (automatisch en op de achtergrond) digitaal ondertekend door de uitgaande/verzendende e-mailserver (stap 4 uit figuur 4). De standaard digitale handtekening is een RSA ondertekende SHA256 samenvatting (digest) van het e-mailbericht. Deze digitale handtekening wordt samen met extra informatie in de “DKIM-Signature header” opgenomen en toegevoegd aan de e-mailheader.

11

In dit figuur is zowel de eenmalige gebeurtenis (nr. 1 en 2) als de herhalende gebeurtenissen (nr. 3 t/m 6) weergegeven.

1 4

Om de DKIM-controle uit te voeren worden de volgende stappen door de inkomende/ontvangende emailserver automatisch en op de achtergrond doorlopen: 5. De inkomende/ontvangende e-mailserver verifieert de DKIM digitale handtekening. De DKIM digitale handtekening wordt geverifieerd door de inkomende/ontvangende e-mailserver. Dit verificatieproces maakt gebruik van informatie uit de “DKIM-Signature header” om de DNS-query voor DKIM samen te stellen. 6. Bovenstaande controle kan de onderstaande uitkomsten opleveren: a. Het e-mailbericht is daadwerkelijk afkomstig van het desbetreffende e-maildomein en het emailbericht is gedurende het transport niet aangepast. Het e-mailbericht wordt afgeleverd in de inbox van de geadresseerde. b. Het e-mailbericht is NIET afkomstig van het desbetreffende e-maildomein of het e-mailbericht is gedurende het transport aangepast, het e-mailbericht wordt als spam (ongeldig) gemarkeerd.

4.3.

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is een aanvullende techniek op de andere twee beveiligingsstandaarden voor e-mail, SPF en DKIM. De domeinnaamhouder stelt hiervoor een DMARC-record op en publiceert dit via het DNS-systeem (zie figuur 5). Dit DMARC-record bevat instructies hoe om te gaan met inkomende e-mailberichten die niet aan het gedefinieerde SPF- of DKIM-beleid voldoen. Mogelijke instructies zijn ‘reject’ (weggooien), ‘quarantine’ (markeren als spam) en ‘none’ (accepteren). Dit DMARC-record kan bovendien één of meerdere e-mailadres(sen) bevatten waarnaar inkomende/ontvangende e-mailservers een rapportage (XML-bestand) kunnen versturen. Zo kan de beheerder van het betreffende e-maildomein inzicht verkrijgen in de aflevering van zowel echte als vervalste e-mailberichten, die verzonden worden namens het e-maildomein. Dit inzicht kan gebruikt worden om e-mailstromen te identificeren en de werking van SPF en DKIM te verbeteren.

Figuur 5 Domain-based Message Authentication, Reporting, and Conformance (DMARC)12 Waar SPF enkel het voor de gebruiker onzichtbare afzenderadres controleert in de e-mailheader, controleert DMARC ook of het getoonde afzenderadres niet afwijkt. Dit is een belangrijke toevoeging ten opzichte van SPF voor het tegengaan van e-mail spoofing.

12

In dit figuur is zowel de eenmalige gebeurtenis (nr. 1) als de herhalende gebeurtenissen (nr. 2 t/m 6) weergegeven.

1 5

Hoe configureert u DMARC voor uw gemeente? Voor het configureren van DMARC dient eenmalig de volgende stap doorlopen te worden: 1. Voeg een DMARC-record toe aan bestaand DNS-record, zodat duidelijk is hoe omgegaan moet worden met inkomende e-mailberichten. Bijvoorbeeld: “v=DMARC1; p=none; rua=mailto: <adres@domeinnaam>; ruf=mailto: <adres@domeinnaam>” •

“v= DMARC1”: Hiermee wordt aangegeven dat de inhoud in het TXT record een DMARC-record is en geeft ook aan welke versie van het DMARC-protocol (versie 1) wordt gebruikt.

•

“p=none” Hier wordt het beleid aangegeven dat van toepassing is voor e-mailberichten die niet door de DMARC-test komt. De waarde kan ‘none’, ‘ quarantine’ of ‘reject’ zijn.

•

“rua=mailto: <adres@domeinnaam>”

•

“ruf=mailto: <adres@domeinnaam>” Lijst van Uniform Resource Identifiers (URI’s) waar de terugkoppeling (XML-rapport) naartoe gestuurd dient te worden. De URI dient te bestaan uit de volgende vorm ‘mailto: <adres@domeinnaam>’. rua: e-mailadres(sen) waar de ontvangende e-mailproviders de geaggregeerde rapportages naar toe sturen. ruf: e-mailadres(sen) waar de ontvangende e-mailproviders de forensics rapportages naar toe sturen.

In stap 2 uit figuur 5 wordt een e-mailbericht samengesteld en verstuurd namens het e-maildomein naar de geadresseerde. Als DKIM wordt ondersteund wordt het e-mailbericht (automatisch en op de achtergrond) voorzien van een DKIM digitale handtekening (stap 3 uit figuur 5) door de uitgaande/verzendende emailserver. Zie de uitleg over DKIM voor meer achtergrondinformatie. Om een e-mailbericht te versturen en de DMARC-controle uit te voeren worden de volgende stappen door de inkomende/ontvangende e-mailserver automatisch en op de achtergrond doorlopen: 4. Afhankelijk of een SPF- en/of DKIM-record is geconfigureerd worden onderstaande controles uitgevoerd: a. Als SPF wordt ondersteund wordt gecontroleerd of de e-mailserver in het SPF-record voorkomt of niet. De inkomende/ontvangende e-mailserver controleert dan in de DNS of de uitgaande/verzendende e-mailserver in het SPF-record van het e-maildomein voorkomt. b. Als DKIM wordt ondersteund wordt de DKIM digitale handtekening geverifieerd door de inkomende/ontvangende e-mailserver. Dit verificatieproces maakt dan gebruik van informatie uit de “DKIM-Signature header” om de DNS-query voor DKIM samen te stellen. 5. Pas het DMARC-beleid toe. Controleer de uitkomst van de SPF- en DKIM-test. 6.

Bovenstaande controle kan de onderstaande uitkomsten opleveren: • Als zowel de SPF- en DKIM-test succesvol wordt doorstaan, wordt het e-mailbericht afgeleverd in de inbox van de geadresseerde. • Als de SPF- en/of DKIM-test NIET succesvol wordt doorstaan dan past de inkomende/ontvangende e-mailserver het DMARC-beleid toe. Afhankelijk van het gedefinieerde DMARC-beleid wordt de email: 1 6

7.

5.

• geaccepteerd, of • geaccepteerd maar als spam gemarkeerd, of • NIET geaccepteerd. De inkomende/ontvangende e-mailserver verstuurt een DMARC-rapportage naar de URI’s die zijn gespecificeerd in het DMARC-record. Dit kan een periodiek geaggregeerd en/of forensics rapport zijn. De forensics rapporten kunnen privacygevoelige informatie bevatten, denk na waar u deze rapporten in uw gemeente laat binnenkomen en wie er allemaal toegang toe hebben.

Hoe maakt u uw e-mailberichten betrouwbaarder?

Hiervoor dient de gemeente gebruik te maken van alle drie de e-mailauthenticatiestandaarden. Zowel SPF, DKIM en DMARC zijn bepalend voor het te bereiken beveiligingsniveau. De factsheet ‘bescherm domeinnamen tegen phishing’ van het NCSC kan gebruikt worden bij het configureren van het SPF, DKIM en DMARC-protocol. Opmerking: Vraag voor configureren van de e-mail-authenticatiestandaarden, indien noodzakelijk, ondersteuning aan uw leverancier of hostingpartij. Het Bureau Forum Standaardisatie (BFS) kan u ook adviseren over het gebruik van deze e-mailauthenticatiestandaarden.

5.1.

Pas DNSSEC toe

Volgens de e-mailauthenticatiestandaarden is het niet noodzakelijk om daarbij ook DNSSEC te gebruiken maar dat willen we hier toch van harte aanraden. DNSSEC beschermd de integriteit van de DNS-informatie, dus ook de SPF-, DKIM- en DMARC-records, en zorgt ervoor dat het DNS-antwoord authentiek is en afkomstig van de juiste bron13.

5.2.

Blokkeer niet gebruikte domeinnamen

Als gebruik wordt gemaakt van e-mailauthenticatiestandaarden is het advies om onderstaande ‘soorten’ domeinnamen standaard te blokkeren: • Geparkeerde domeinnamen (parked domain) Een domeinnaam wordt vaak geparkeerd om de domeinnaam alvast te reserveren voor bijvoorbeeld een website die nog ontwikkeld dient te worden. Dit geeft zekerheid dat de domeinnaam is vastgelegd en niet door derden “weggekaapt” kan worden, aangeduid als cybersquatting. Een geparkeerde domeinnaam kan op verschillende manieren gebruikt worden en een bezoeker krijgt over het algemeen één van de volgende berichten te zien: o Een pagina met een kort bericht dat de domeinnaam gereserveerd is voor een klant of de mededeling dat de site nog in ontwikkeling is. o Een pagina met advertenties, op (veel) geparkeerde domeinen zie je een pagina met advertenties staan. Het exploiteren van geparkeerde domeinnamen wordt aangeduid als parked domain monetization. o Een pagina waarop de domeinnaam te koop wordt aangeboden. • Domeinnamen die niet worden gebruikt voor het versturen van e-mailberichten. Voor het blokkeren van deze domeinnamen kan gebruik gemaakt worden van zowel SPF, DKIM en DMARC14. 13 14

Zie ook de factsheet ‘DNSSEC: Voorkom domeinnaamfraude’ van de IBD. Zie voor meer achtergrondinformatie: https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf

1 7

• • •

SPF-record: “<domeinnaam>. TXT “v=spf1 -all” DKIM-record: “<domeinnaam>. TXT “v=DKIM1; p=” DMARC-record: “_dmarc.<domeinnaam> TXT “v=DMARC1; p=reject; rua=mailto:<e-mailadres>; ruf=mailto:<e-mailadres>”

5.3.

Volg stappenplan

Het volgende stappenplan kan gevolgd worden om tot het gewenste beveiligingsniveau te komen: 1. Configureer DMARC-record Gemeenten dienen een DMARC-record toe te voegen aan hun DNS-systeem met parameter ‘p=none’ om de uitgaande e-mailstromen per gemeentelijk domein te kunnen onderzoeken. Configureer het DMARC-record zodanig dat de terugkoppelingen (DMARC-rapportages) van de e-mailproviders verzameld wordt ten behoeve van de analyse. Opmerking: Voor het analyseren van de DMARC-rapportages van de e-mailproviders, bijvoorbeeld voor het identificeren van de e-mailstromen, is specifieke kennis en tooling nodig zodat deze (eenvoudig) geïnterpreteerd kunnen worden. Het is hierbij belangrijk, in verband met privacyaspecten, te zorgen dat deze DMARC-rapportages binnen de Europese Economische Ruimte (EER) worden opgeslagen en bewaard15. Kies daarom een leverancier die dit kan garanderen. Dit geldt met name voor de forensics rapportages. 2. Identificeer domeinnamen, e-mailstromen en soorten e-mail In deze stap dient een overzicht te worden gecreëerd van de domeinnamen, e-mailstromen en soorten e-mailberichten. Dit overzicht omvat zowel domeinnamen waarvandaan e-mailberichten worden verstuurd als domeinnamen waarvandaan nooit e-mailberichten worden verstuurd.

Om een zo compleet mogelijk beeld te vormen van de e-mailstromen dient de terugkoppeling van de emailproviders gedurende een periode van 6 tot 8 weken gelogd en geanalyseerd te worden. Veel van deze informatie zal binnen de gemeente aanwezig zijn. Denk hierbij aan de volgende e-mailstromen: Ketenpartners; Leveranciers; Kantoormail; Afsprakenmodules van klantcontactcentra (KCC) en Nieuwsbrieven. Opmerking: Als tijdens de inventarisatie van de e-mailstromen naar voren komt dat e-mailstromen buiten de EER worden gehost, dient u een risicoafweging te maken wat er met deze e-mailstromen dient te gebeuren. Vanwege de bescherming van persoonsgegevens. Opmerking: Vaak gebruiken leveranciers van klantcontactcentra en afsprakensoftware een externe hostingpartij waardoor het uitzoeken of een mailstroom legitiem is veel tijd kost. 3. Identificeer legitieme e-mailstromen Identificeer per domein welke e-mailstromen legitiem zijn ten behoeve van opname in het SPF-record. Deze configuratie zal goed gemonitord dienen te worden om mogelijke problemen snel te detecteren en op te lossen. 4. Inventariseer mailappliance Inventariseer welke mailappliance wordt gebruikt door de gemeente ten behoeve van het inschatten van de impact voor DKIM implementatie. De toepassing van DKIM vergt meer middelen dan de toepassing van SPF.

Om DKIM toe te passen dient er vaak aanvullende software geïnstalleerd worden op de e-mailserver. 5. Monitor e-mailautenticatiemiddelen

15

Zie: https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/internationaal-gegevensverkeer/doorgifte-binnen-en-buiten-de-eu

1 8

6.

7.

De implementatie, configuratie en gebruik van de e-mailauthenticatiemiddelen zal gemonitord moeten worden om effectief te zijn. Let onder andere op misbruik van een domeinnaam, problemen met geautoriseerde verzenders en aanpassingen aan e-mailservers. Test regelmatig de e-maildomeinen Voor het testen van de e-maildomeinen kan gebruik worden gemaakt van de verschillende hulpmiddelen die hieronder worden benoemd. Optioneel: Kies een kundige implementatiebegeleider of geef opdracht aan uw hostingpartij.

5.4.

Maak bij DKIM-sleutelrotatie gebruik van CNAME-records16

Sleutelparen hebben een levensduur/geldigheidsduur. Dit houdt in dat een sleutel na het verstrijken van deze periode niet meer kan worden gebruikt om berichten te versleutelen. Om de dienstverlening niet te verstoren dienen sleutelparen tijdig vervangen te worden15. Sleutelparen dienen direct te worden vervangen op het moment dat de privé sleutel is gecompromitteerd. Dit geldt ook voor de DKIM-sleutels en deze dienen tijdig gewijzigd te worden in de DNS, ook wel roteren van DKIM-sleutels16. Na voldoende replicatietijd in DNS , kan de nieuwe DKIM-sleutel in gebruik worden genomen voor het digitaal ondertekenen. Door een e-maildomein te voorzien van twee DKIM Canonical Name (CNAME)-records, kan de niet in gebruik zijnde DKIM-sleutel gewijzigd (geroteerd) worden zonder onderbreking van de dienstverlening. Hierdoor heeft de sleutelrotatie geen impact op het afnemend e-maildomein en is er geen downtime. Een ander voordeel is dat de DKIM-sleutels op één domein worden geadministreerd wat het beheer eenvoudiger maakt. Als sleutel #1 is verlopen wordt ondertekend met sleutel #2 en kan sleutel #1 zonder problemen worden vervangen.

• Het e-maildomein wordt uitgerust met 2 DKIM CNAME-records sel1_domainkey.<e-maildomein> CNAME sel1-<domein>._domainkey.<domein>.nl sel2_domainkey.<e-maildomein> CNAME sel2<domein>._domainkey.<domein>.nl • <domein>.nl bevat de DKIM TXT-records met de DKIM-sleutel. sel1<domein>._domainkey.<domein>.nl TXT “v=DKIM1; k=rsa; p=<publieke sleutel #1>” sel2<domein>._domainkey.<domein>.nl TXT “v=DKIM1; k=rsa; p=<publieke sleutel #2 >” Stel eisen aan uw leverancier Op het moment dat u gebruik maakt van een leverancier voor het afhandelen van e-mailberichten is het advies om onderstaande eisen aan uw leverancier te stellen: • De leverancier definieert en valideert de SPF-, DKIM- en DMARC-records van het gemeentelijke domein. • De leverancier zorgt ervoor dat de partijen, die e-mailberichten ontvangen van de gemeente, kunnen valideren dat deze e-mailberichten inderdaad van de gemeente afkomstig zijn. • Opmerking: Ontbrekende controles bij de ontvangende partij zorgen ervoor dat anti-spam maatregelen niet volledig worden benut.

5.5.

Hulpmiddelen

Hulpmiddelen waarmee de DMARC configuratie kan worden gecontroleerd zijn onder andere: • E-mail zelftest via Internet.nl • E-mail zelftest via phishingscorecard.com DANE voor SMTP-instructies CNAME-records worden gebruikt voor het doorverwijzen van domeinen en subdomeinen. Een voorbeeld van een CNAME-record is de doorverwijzing van www. ibdgemeenten.nl naar ibdgemeenten.nl, waardoor de website op twee manieren te bereiken is, namelijk met en zonder www ervoor. 16

1 9

Deze instructies (how-to) is gemaakt door het Platform Internetstandaarden (de organisatie achter Internet.nl) in samenwerking met experts uit de industrie (hostingbedrijven en leveranciers) en is bedoeld om praktische informatie en begeleiding te bieden bij het implementeren van SPF, DKIM en DMARC. Deze instructies maken deel uit de van ‘Internet.nl Toolbox - how-to's mail security standards’. Hier wordt naast de SPF, DKIM en DMARC standaarden ook nog informatie gegeven over de DANE-standaard.

6.

Adviezen IBD met betrekking tot SPF, DKIM en DMARC

De IBD geeft het advies om: • Ervoor te zorgen dat de gemeente beschikt over de benodigde kennis en tooling voor het identificeren van de e-mailstromen vanuit de terugkoppelingen van de e-mailproviders. Als de gemeente niet over de benodigde kennis en/of tooling beschikt, kan de gemeente kiezen voor een kundige externe implementatiebegeleider of opdracht geven aan uw hostingpartij. • Voor het configureren van SPF, DKIM en DMARC de factsheet ‘‘bescherm domeinnamen tegen phishing’ van het NCSC te volgen. • Voor zowel SPF als DMARC de eerste periode het beleid zo te configureren dat in eerste instantie de ontvangen e-mailberichten altijd worden geaccepteerd. Op het moment dat inzicht is in de legitieme emailstromen kan na verloop van tijd het beleid worden aangescherpt naar accepteren maar als spam markeren. Uiteindelijk kan het beleid nog verder worden aangescherpt naar NIET accepteren, door voor het betreffende domein het DMARC-beleid in te stellen op ‘p=reject’ op het moment dat er sprake is van afwijkingen. • DNSSEC te gebruiken en voor meer achtergrondinformatie van DNSSEC de factsheet ‘DNSSEC: Voorkom domeinnaamfraude’ van de IBD te lezen. • Bij het roteren van DKIM-sleutels gebruik te maken van twee CNAME-records, zodat de dienstverlening niet verstoord wordt.

• Geparkeerde domeinnamen en domeinnamen die niet worden gebruikt voor het versturen van emailberichten te blokkeren. Dit kan door voor het betreffende domein het SPF-record te voorzien van “-all”, het DKIM-record te voorzien van een lege sleutel “p=” en het DMARC-beleid in te stellen op ‘p=reject’. • Ervoor te zorgen dat de DMARC-rapportages, in verband met privacyaspecten, binnen de EER worden opgeslagen en bewaard. • Als tijdens de analyse van de terugkoppeling van de e-mailproviders blijkt dat er e-mailstromen worden geïdentificeerd die buiten de EER worden gehost, neem dan de huidige werkwijze onder de loep en neem mogelijke privacyrisico’s weg. • Als tijdens de analyse van de terugkoppeling (DMARC-rapportages) van de e-mailproviders blijkt dat misbruik heeft plaatsgevonden, bijvoorbeeld het versturen van spam of phishing e-mailberichten, meldt dan dit misbruik zowel bij de IBD als bij de politie.

2 0

Kijk voor meer informatie op: www.informatiebeveiligingsdienst.nl

Nassaulaan 12 2514 JS Den Haag CERT: 070 204 55 11 (9:00 – 17:00 ma – vr) CERT 24x7: Piketnummer (instructies via voicemail) info@IBDGemeenten.nl / incident@IBDGemeenten.nl