Hoe weerbaar is uw digitale identiteit?

Gepost op: 4-10-2016 13:29:09 door Maarten Albregts
Tags: datalekken, DNS, meldplicht, NCSC, privacy, regelgeving, SMTP
Maarten Albregts

Hoe afhankelijk is een organisatie van e-mail? Dat is een retorische vraag… De afhankelijkheid van een ruim dertig jaar oud protocol benadert bijna het bedrijfskritische. 

In 1983 is RFC 876 gepubliceerd voor het Simple Mail Transfer Protocol om efficiënt en betrouwbaar transport van e-mailberichten mogelijk te maken. Encryptie en beveiliging maakten destijds geen deel uit van de RFC, laat staan dat er was nagedacht over risico’s als spam en phishing. Inmiddels zijn we 35 jaar verder en is de hele digitale wereld alleen maar afhankelijker geworden van e-mail en zijn de genoemde risico’s alleen maar toegenomen. Dat geldt trouwens voor alle internetprotocollen (TCP/IP, DNS, SMTP, et cetera) 

Hoe kan een organisatie met een digitale identiteit en reputatie zich zo goed mogelijk blijven aansluiten bij de uitbreidingen op oorspronkelijke technologieën om maximaal weerbaar te blijven? Bij gebruik van clouddiensten zoals Office 365 moet die ‘cloud’ namens een bedrijf e-mail kunnen versturen. Maar ook (marketing-) partijen die mailings verzorgen namens een bedrijf of onderzoeksbureaus die klanttevredenheidsonderzoeken uitvoeren. De digitale identiteit en bedrijfsdomeinnaam moet verantwoord en vertrouwd kunnen worden gebruikt zonder op een blacklist terecht te komen of in een phishingcampagne te belanden.

Protocollen 
In de loop van de tijd is er een groot aantal uitbreidingen en wijzigingen op de oorspronkelijke RFC van het mailprotocol geïntroduceerd. Enkele belangrijke mechanismen om bijvoorbeeld risico’s op spam en phishing bij mailuitwisseling te beperken, zijn het Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) en Domain-based Message Authentication, Reporting & Conformance (DMARC). Er zit een afhankelijkheid en samenhang in deze mechanismen die een mailserver weer gebruikt om bijvoorbeeld een afzender zo goed mogelijk te kunnen identificeren. En hoe beter de mogelijkheden tot identificatie en controle des te beter de bescherming tegen spam en phishing.

Nou maken deze mechanismen weer gebruik van een ander gedateerd protocol: DNS. U raadt het al… de oorspronkelijke RFC dateert uit 1983 en beveiliging maakt hier niet of nauwelijks deel van uit. Daar is in de loop van de tijd toch ook weer wat op gevonden met het DNSSEC-mechanisme en aanvullende extensies om met digitale sleutels DNS-informatie te signen zodat er een controle op authenticiteit plaats kan vinden. Kortom, er wordt op oude technologieën voortgeborduurd om enerzijds compatibel te blijven met onderliggende protocollen en anderzijds die benodigde verbetering te brengen.

Regelgeving 
Ondertussen zijn er regelgevende (Logius, Nationaal Beraad) en adviserende instanties (bijvoorbeeld NCSC) die adviseren of (in het geval van overheidsinstanties) verplichten om de nieuwe standaarden en mechanismen te implementeren: SPFDKIMDMARCDNSSECSTARTTLS, DANE. De lijst groeit en de uitdaging om overzicht te houden bij deze zaken ook. Een goede implementatie van uitbreidingen op mailtechnologieën beperkt de risico’s op spam, phishing en misbruik of blacklisting van een digitale bedrijfs-/domeinnaam.

Een gedegen aanpak bij deze technologieën is vereist en er kan vaak een soort PDCA-cyclus worden toegepast:

  1. Inventariseer en registreer: welke organisaties mogen communiceren namens uw domeinnaam en welke randvoorwaarden zijn hieraan gesteld? Heeft de partij die namens uw bedrijf mag e-mailen de informatiebeveiliging wel op orde?
  2. Definieer en activeer een basispolicy. Voor SPF bijvoorbeeld: neem hierin enkel geautoriseerde e-mailsystemen op. Activeer DKIM en distribueer de sleutel naar partijen die namens uw domein mogen e-mailen en voldoen aan beveiligingseisen. Activeer DMARC, dwing nog geen policy af maar bewaak wie er namens uw domein e-mail verstuurt en of dat overeenkomt met de inventarisatie uit stap 1.
  3. Monitor het gebruik uit stap 2 en rapporteer wie er namens uw domein e-mail verstuurt.
  4. Scherp de policy en mailserverconfiguratie verder aan.
  5. Nu schermen de bekende (overheids)baselines met het ‘pas toe of leg uit’-principe en zou men al kunnen stoppen bij implementatie van stap 2 met een monitoring only en loose policy. Maar om het maximale resultaat te halen, is het aan te raden om ook de vervolgstappen te zetten en toe te werken naar een gecontroleerd policy.

Conclusies
Wat zijn eigenlijk de conclusies na het lezen van al deze afkortingen? Ja, het internet is gebaseerd op verouderde netwerk- en applicatieprotocollen die worden ‘gepatcht’ met een groeiende lijst lapmiddelen. Het is trouwens bewonderenswaardig dat het TCP/IP-protocol nog gewoon standhoudt (eerste TCP-specificatie al gepubliceerd in 1974). Oh ja, hoeveel organisaties zijn al voorbereid op de IPv6-‘upgrade’?

In een aantal stappen is de weerbaarheid van de digitale identiteit van een organisatie te verbeteren. Belangrijk hierbij is de plaats die DNS inneemt. De verschillende technologieën (SPF, DMARC, DKIM) gebruiken DNS-records om e-mail beter tegen phishing en spam te beveiligen. DNSSEC, DANE en TLSA gebruiken DNS voor verbeterde authenticatie en verificatie van domeinnamen. Al deze verbeteringen vragen een goede inventarisatie, administratie en controles bij ingebruikname en policybeheer.

Blog postsRSS