Op weg naar p=Verworpen, Mimecast's Interne DMARC Project: Deel 3. Klaar?

In mijn eerste blog over het interne DMARC-project van Mimecast, legde ik de basis over wat DMARC is en waarom we ervoor kozen om dit project op te starten. Mimecast, zoals elk bedrijf met een online aanwezigheid, is het doelwit van phishers die specifiek proberen misbruik te maken van de bekendheid en het vertrouwen in ons merk en onze klanten, partners en anderen aan te vallen. DMARC is een uitstekende manier om dit soort op e-mail gebaseerde merkuitbuiting aan te pakken door het gebruik van domeinen voor e-mail doeltreffender te vergrendelen. Het doel van deze blog serie is om inzichten te verschaffen die kunnen helpen bij het begeleiden van het DMARC project van uw eigen organisatie.

In mijn tweede blog , verdiepte ik me in het "wie" en het "hoe" van ons DMARC project. Ja, het is een project dat, naast een goed DMARC product , een cross-functioneel team vereist dat bestaat uit IT, beveiliging, een DMARC specialist en zelfs marketing om het beste en snelste resultaat te krijgen. Voor Mimecast ontdekten we, net als de meeste andere organisaties, dat we veel meer domeinen bezitten dan we aanvankelijk dachten - meer dan 300. Veel van deze domeinen zijn gewoon geparkeerd om te voorkomen dat anderen ze registreren, terwijl andere domeinen in het verleden in M&A-transacties terecht zijn gekomen, en weer andere zijn geregistreerd voor speciale projecten zonder de actieve deelname van de IT- of beveiligingsteams.

Domeinen registreren is toch zo gemakkelijk. Gelukkig worden maar heel weinig van de 300 domeinen die Mimecast bezit, gebruikt om legitieme e-mail te versturen. Voor Mimecast is mimecast.com ons nummer één domein dat we willen beschermen. Wij gebruiken het zowel als ons hoofdwebsite-domein als het domein van waaruit wij het grootste deel van onze e-mail versturen.

Mimecast.com instellen op p=weigeren

Eens we onze lijst van domeinen verzameld hadden, ontdekten we dat sommige domeinen speurwerk vereisten om het interne eigendom te achterhalen. Voor die meestal ongebruikte domeinen, stelden we ze heel snel in op p=reject voor DMARC - aangezien we ze toch niet gebruiken om e-mail te versturen, is er geen kans dat de aflevering van legitieme e-mail zou worden verstoord. Houd in gedachten dat alleen omdat u geen e-mail verstuurt vanaf de meeste van uw domeinen, niet betekent dat aanvallers dat ook niet doen! Daarom is DMARC relevant voor al je domeinen en zou p=reject deel moeten uitmaken van je standaard DNS entry, zelfs voor geparkeerde domeinen. Door dit in de eerste fase van het project te doen, konden we onze energie richten op onze primaire e-mailaanwezigheid, die is opgebouwd rond het mimecast.com domein. Dit is het domein van waaruit wij en onze legitieme dienstverleners (Marketo en anderen) e-mail verzenden. Hier moesten we voorzichtiger zijn met onze overstap naar p=reject.

Na ongeveer een maand DMARC-rapporten te hebben bekeken, voortdurend te hebben gecontroleerd en DKIM en SPF configuratiewijzigingen te hebben aangebracht in de weinige overblijvende legitiem verzendende toepassingen, hebben we de overstap gemaakt naar p=reject voor mimecast.com. Ik ben blij te kunnen zeggen dat mimecast.com van p=quarantaine naar p=reject is overgegaan zonder noemenswaardige negatieve gevolgen. Sterker nog, het heeft geholpen om nog een paal in het hart te drijven van de phishers die ons merk proberen te misbruiken!

Heeft deze overstap naar p=reject spammers en phishers ervan weerhouden te proberen om het mimecast.com domein te gebruiken om het Mimecast merk te spoofen? Nog niet, maar het heeft zeker invloed gehad op hun e-mail bezorgpercentage! En met een drastisch verminderde e-mailafleveringssnelheid verwachten we dat ze verder zullen gaan met het aanvallen van minder goed verdedigde domeinen. Laat me u een voorbeeld van een e-mail geven - afbeelding 2 hieronder - om u een voorbeeld te geven van wat we hebben verzameld in onze ruf en rua DMARC-rapporten.

En waar probeerden deze e-mails hun beoogde slachtoffers naartoe te leiden? Grote verrassing - een pagina voor het verzamelen van referenties die werd gehost op verschillende, nu geblokkeerde of uit de lucht gehaald, webpagina's. Merk op dat ze niet eens de moeite namen om "Mimecast" correct te spellen in de URL's.

Wat nu?

Wel, dat was het. DMARC project gedaan. Op naar het volgende beveiligingsproject? Niet echt. De realiteit is dat niets statisch is in de wereld van IT en beveiliging. Het is belangrijk om uw DMARC rapporten te blijven controleren om te zien of er nieuwe, legitieme maar onjuist geconfigureerde diensten zijn uitgerold (hallo, marketing). Zonder voortdurende controle zal het afleveringspercentage van deze nieuwe legitieme e-mailverzendservices vrij laag zijn. Bovendien moet de informatie in uw DMARC-rapporten over de phishers die uw domeinen proberen te misbruiken, worden verstrekt aan uw SOC-team of iemand anders die uw bedreigingsdetectie- en reactieprogramma beheert, aangezien deze belangrijke inzichten kan verschaffen in wie en hoe uw organisatie via e-mail wordt gespoofed. De hierboven beschreven aanvallen zijn niet uniek voor Mimecast.

Volgende, BIMI

Nu mimecast.com op p=reject staat voor DMARC, opent dit ook een andere mogelijkheid om het vertrouwen in het merk Mimecast via e-mail te verbeteren. Een nieuwe standaard, Brand Indicators for Message Identification (BIMI) , is in opkomst die de cryptografische vergrendeling van een handelsmerk-logo, in ons geval de Mimecast "M" (hierboven te zien) aan het mimecast.com domein mogelijk maakt. Op deze manier kunnen alleen geverifieerde BIMI-afzenders die het mimecast.com-domein gebruiken de levering van de Mimecast "M" inschakelen en deze laten weergeven in BIMI-ondersteunende e-mailclients, zoals Gmail en Yahoo mail. Blijf op de hoogte, aangezien het DMARC-team bij Mimecast bezig is met een omslag om BIMI voor mimecast.com te implementeren. In een volgende blog zal ik verslag uitbrengen over de BIMI uitbreiding van ons DMARC project.