Der Weg zu p=Reject, dem internen DMARC-Projekt von Mimecast: Teil 2

In meinem ersten Blog über das interne DMARC-Projekt von Mimecast habe ich die Grundlagen dafür gelegt, warum wir uns für dieses Projekt entschieden haben. Kurz gesagt, Mimecasts eigene Online-Marken und E-Mail-Domänen ziehen regelmäßig die unerwünschte Aufmerksamkeit von böswilligen Akteuren auf sich, die versuchen, sie als Teil von Phishing-Kampagnen zu nutzen. Dem wollen wir natürlich einen Riegel vorschieben!

Wer sollte an der Erreichung von P=Ablehnung beteiligt sein?

Da ein DMARC-Projekt nicht nur die DNS-Verwaltung betrifft - was der einfache Teil ist -, ist es sehr wichtig, dass die richtigen internen Funktionen im DMARC-Implementierungsteam vertreten und für die Dauer des Projekts aktiv sind.

Für Mimecast umfasst das Team einen Senior Security Architect und Projektmanager aus unserem internen Sicherheitsteam, unseren internen SOC-Manager, der sich um die Überwachung, Erkennung und Reaktion auf Bedrohungen kümmert, einen Vertreter des Mimecast-Technikteams (schließlich sind wir ein E-Mail-Sicherheitsanbieter mit tiefgreifendem Fachwissen, der stets bestrebt ist, seine Produkte zu verbessern), ein Mitglied des internen IT-Teams, das sich um IT-Anwendungsdienstleister von Drittanbietern kümmert, und einen DMARC-Spezialisten aus dem professionellen Serviceteam von DMARC Analyzer , der sein Fachwissen aus erfolgreichen DMARC-Implementierungsprojekten für Kunden einbringt. Das Produkt DMARC Analyzer dient als Anwendungsbackbone des Projekts.

Eine ähnliche Zusammensetzung des Projektteams wird für andere Organisationen empfohlen, die p=Reject erreichen wollen, vielleicht mit Ausnahme der Mimecast-Techniker, um sicherzustellen, dass kein Teil des Projekts übersehen oder missverstanden wird oder Probleme bei der E-Mail-Zustellung verursacht.

Interne Organisation für P=Ablehnen

Und wie bei jedem facettenreichen und potenziell geschäftsbeeinflussenden Projekt ist ein Schlüssel zum Erfolg eine angemessene Phaseneinteilung und Risikomanagement. Zum Beispiel gibt es eine Reihe von legitimen Diensten, die E-Mails im Namen von Mimecast versenden, darunter Salesforce.com, Netsuite und Marketo. Daher ist es wichtig, die Zustellung legitimer E-Mails an unsere verschiedenen Zielgruppen während des Prozesses der DMARC-Härtung nicht zu unterbrechen.

Während ein Hauptziel des Projekts darin besteht, die unrechtmäßige Nutzung unserer Hauptdomain mimecast.com zu blockieren, ist es sehr wichtig, all die anderen Domains nicht zu übersehen, die unsere Organisation zwar besitzt, aber möglicherweise nicht für E-Mails nutzt; denn nur weil Ihre Organisation sie nicht für E-Mails nutzt, bedeutet das nicht, dass Cyberkriminelle, die versuchen, Sie zu fälschen, dies nicht tun!

Domains und Kategorisierungen

Vor diesem Hintergrund bestand ein erster Schritt in unserem DMARC-Projekt darin, eine Liste aller Domains zu erstellen, die Mimecast besitzt. Dabei entdeckten wir mehr als 350 eigene Domains. Diese Domains wurden in die folgenden drei Kategorien eingeteilt:

• Cybersquatted Domains - Dies sind Domains, die wir im Laufe der Jahre registriert haben, um zu verhindern, dass böswillige Akteure sie registrieren und für Websites oder den Versand von E-Mails verwenden. Wir haben nicht die Absicht, sie für unser Geschäft zu nutzen. Beispiele hierfür sind: store, mimecastt.com, mimecast.ai, mimecsat.co.uk. Beachten Sie, dass angesichts der Zunahme von TLDs und der unendlichen Kombination ähnlicher Domains durch den Austausch eines Buchstabens hier oder dort, die proaktive Registrierung Ihres Weges zum Domainschutz ein Ansatz ist, den nur Registrierstellen lieben können!
• Geparkte oder umgeleitete Domains - Dies sind Domains, die wir in der Zukunft verwenden könnten oder die wir auf eine leichte Art und Weise verwenden, z. B. um den Webverkehr zu bestimmten Bereichen der mimecast.com-Website umzuleiten. Wir verwenden sie nicht als E-Mail-Versanddomains. Domains, die im Rahmen von Akquisitionen erworben wurden, wurden ebenfalls in der Regel hier eingeordnet. Beispiele hierfür sind com, mimecast.com.au und mimecastercentral.com.
• Active Email Sending Domains - Dies sind die E-Mail-"Kronjuwelen" von Mimecast, auf deren Schutz sich dieses Projekt weitgehend konzentriert. Diese Kategorie umfasst Domains, von denen wir - auch von übernommenen Unternehmen - aktiv E-Mails versenden oder in der jüngsten Vergangenheit versendet haben. Beispiele hierfür sind mimecast.com, ataata.com und solebitlabs.com.

Auch wenn die obigen Kategorisierungen nichts wirklich Magisches an sich haben, gehe ich davon aus, dass Sie, der versierte Leser, den Grundgedanken verstanden haben. In Anbetracht der Auswirkungen, die die Umstellung auf p=reject haben kann, wenn sie nicht korrekt durchgeführt wird, möchte man sie nicht einfach einschalten und auf das Beste hoffen. In Anbetracht dessen durchläuft das Mimecast DMARC-Projektteam unsere mehr als 350 eigenen Domains in genau der oben genannten Reihenfolge, wobei zwischen den einzelnen Phasen eine Pause eingelegt wird, um die Auswirkungen auf das Geschäft zu bewerten, falls überhaupt. Und natürlich überwachen wir die DMARC-Berichte, die von den DMARC-Reporting-Empfängern an DMARC Analyzer zurückgeschickt wurden.

Die Quintessenz

In Phase 1 wurden die DNS aller cybersquatted Domains auf p=reject konfiguriert. Da diese Domänen nie für den rechtmäßigen Versand von E-Mails verwendet wurden und werden, haben wir sie sofort auf p=reject gesetzt, und wir erwarten keine Nachteile durch das Blockieren von E-Mails, die angeblich von diesen Domänen gesendet wurden. In Phase 2 haben wir auch unsere geparkten und umgeleiteten Domänen auf p=reject gesetzt, und die DMARC-Berichte dieser Domänen werden genau überwacht, um sicherzustellen, dass keine Probleme auftreten.

Phase 3, die unsere aktiven E-Mail-Versanddomänen einschließlich mimecast.com umfasst, wird ein komplexerer Schritt des Projekts sein. Wie erwartet, haben wir durch diesen Prozess E-Mail-Absender entdeckt, die diese Domäne nutzen und legitim zu sein schienen (keine Phisher oder Spammer), aber nicht richtig mit SPF oder DKIM konfiguriert waren und somit DMARC nicht erfüllten. An dieser Stelle beginnt die interne Nachforschung. Wem gehören diese Dienstanbieter intern? Sollten sie noch aktiv E-Mails in unserem Namen versenden? Wie kann man sie am besten mit DMARC in Einklang bringen? Dies ist die Sicherheitsbereinigungsfunktion, die Teil jedes DMARC-Projekts ist.

In meinem nächsten und letzten Blog zu diesem Thema werde ich ein Projekt-Fazit ziehen und einen Rückblick auf die wichtigsten Lehren und Erkenntnisse geben, die wir daraus gezogen haben. Bis dahin: Bleiben Sie DMARC-fähig!