Hoe afhankelijk is een organisatie van e-mail? Dat is een retorische vraag… De afhankelijkheid van een in 1982 opgesteld protocol benadert bijna het bedrijfskritische. In 1982 is RFC876 opgesteld voor het 'Simple Mail Transfer Protocol' om efficiënt en betrouwbaar transport van e-mail berichten mogelijk te maken. Encryptie en beveiliging maakten destijds geen onderdeel 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 en de genoemde risico’s alleen maar toegenomen. Dat geldt trouwens voor alle internet protocollen (TCPIP, DNS, SMTP, etc.), maar 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 cloud diensten zoals Office365 moet die ‘cloud’ namens een bedrijf 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 phishing campagne te belanden.
Protocollen
In de loop van de tijd zijn er een groot aantal uitbreidingen en wijzigingen op de oorspronkelijke RFC van het mail protocol 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 onderdeel 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 (bijv. NCSC) die adviseren of (in het geval van overheidsinstanties) verplichten om de nieuwe standaarden en mechanismen te implementeren: SPF, DKIM, DMARC, DNSSEC, STARTTLS en DANE. De lijst groeit en de uitdaging om overzicht te houden bij deze zaken ook. Een goede implementatie van uitbreidingen op mail technologieë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 mailen de informatiebeveiliging wel op orde?
2) Definieer en activeer een basis policy. Voor SPF bijvoorbeeld: neem hierin enkel geautoriseerde mailsystemen op. Activeer DKIM en distribueer de sleutel naar partijen die namens uw domein mogen mailen en voldoen aan beveiligingseisen. Activeer DMARC, dwing nog geen policy af maar bewaak wie er namens uw domein mail verstuurt en of dat overeenkomt met de inventarisatie uit stap 1.
3) Monitor het gebruik uit stap twee en rapporteer wie er namens uw domein mail verstuurt.
4) Scherp de policy en mailserver configuratie verder aan.
Nu schermen de bekende (overheid)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 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 TCPIP protocol nog gewoon stand houdt (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 en DKIM gebruiken DNS records om e-mail tegen phishing en spam beter 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 in gebruik name en policy beheer.
Maarten Albregts, securityspecialist bij Motiv
