Op weg naar p=Verworpen, Mimecasts Interne DMARC Project: Deel 2

In mijn eerste blog over het interne DMARC-project van Mimecast, legde ik de basis voor waarom we ervoor kozen om aan het project te beginnen. In het kort komt het erop neer dat de eigen online merken en e-maildomeinen van Mimecast regelmatig de ongewenste aandacht trekken van kwaadwillende actoren die ze proberen te gebruiken als onderdeel van phishing-campagnes. Het is duidelijk dat wij daar een einde aan willen maken!

Wie moet er betrokken zijn bij het bereiken van P=Verwerpen?

Aangezien een DMARC project raakvlakken zal hebben met verschillende andere gebieden dan alleen DNS administratie - wat het makkelijke gedeelte is - is het zeer belangrijk dat de juiste interne functies vertegenwoordigd en actief zijn in het DMARC implementatie team voor de duur van het project.

Voor Mimecast bestaat het samengestelde team uit een senior beveiligingsarchitect en projectmanager van ons interne beveiligingsteam; onze interne SOC-manager die zich bezighoudt met het monitoren, opsporen en reageren op bedreigingen; een vertegenwoordiger van het engineeringteam van Mimecast (we zijn tenslotte een e-mailbeveiligingsleverancier met diepgaande expertise en zijn altijd op zoek om onze producten te verbeteren); een lid van het interne IT-team die zich bezighoudt met IT-toepassingsserviceproviders van derden; en een DMARC-specialist van het DMARC Analyzer professional services team, dat diepgaande expertise toevoegt van succesvolle DMARC-implementatieprojecten voor klanten. Het DMARC Analyzer product dient als de applicatie ruggengraat van het project.

Een gelijkaardige projectteamopstelling wordt aanbevolen voor andere organisaties die p=Verwerpen willen bereiken, misschien met uitzondering van Mimecast engineering, om ervoor te zorgen dat geen enkel onderdeel van het project over het hoofd wordt gezien, verkeerd wordt begrepen, of problemen veroorzaakt bij de aflevering van e-mail in de toekomst.

Interne organisatie voor P=Verwerpen

En zoals bij elk project met vele facetten en mogelijke gevolgen voor het bedrijf, is de sleutel tot succes een juiste fasering en risicobeheer. Er zijn bijvoorbeeld een aantal legitieme diensten die e-mail verzenden namens Mimecast, waaronder Salesforce.com, Netsuite en Marketo, waardoor het van cruciaal belang is om de levering van legitieme e-mails aan onze verschillende doelgroepen niet te verstoren tijdens het proces van DMARC-verbeteringsmaatregelen.

Een van de hoofddoelen van het project is het blokkeren van illegaal gebruik van ons primaire domein, mimecast.com, maar het is heel belangrijk om niet alle andere domeinen over het hoofd te zien die onze organisatie bezit, maar misschien niet voor e-mail gebruikt; het feit dat uw organisatie ze niet voor e-mail gebruikt, betekent niet dat cybercriminelen die u proberen te spoofen, dat ook niet doen!

Domeinen en Categorisaties

Met dit in gedachten was een vroege stap in ons DMARC-project het verzamelen van een lijst van alle domeinen die Mimecast bezit, wat ons leidde tot de ontdekking van meer dan 350 domeinen in eigendom. Deze domeinen werden onderverdeeld in de volgende drie categorieën:

• Cybersquattedomeinen - Dit zijn domeinen die wij in de loop der jaren hebben geregistreerd om kwaadwillenden te verhinderen ze te registreren en te gebruiken voor websites of het verzenden van e-mail. Wij hebben niet de intentie om ze voor onze zaken te gebruiken. Voorbeelden hiervan zijn: store, mimecastt.com, mimecast.ai, mimecsat.co.uk. Merk op dat met een toename van TLD's en de oneindige combinatie van gelijksoortige domeinen door slechts hier of daar een letter te veranderen, het proactief registreren van uw weg naar domeinbescherming een aanpak is die alleen registrars leuk zouden kunnen vinden!
• Geparkeerde of omleidingsdomeinen - Dit zijn domeinen die wij in de toekomst misschien zullen gebruiken of op een lichte manier gebruiken, bijvoorbeeld om webverkeer om te leiden naar specifieke delen van de mimecast.com-website. Wij gebruiken ze niet als domeinen voor het verzenden van e-mail. Domeinen die samen met overnames kwamen, werden over het algemeen ook hier ondergebracht. Voorbeelden hiervan zijn com, mimecast.com.au, en mimecastercentral.com.
• Actieve e-mail verzenddomeinen - Dit zijn de e-mail "kroonjuwelen" voor Mimecast waar dit project grotendeels op gericht is om te beschermen. Deze categorie omvat domeinen waarvan wij - inclusief die van overgenomen bedrijven - actief e-mail versturen of dat in het recente verleden hebben gedaan. Voorbeelden hiervan zijn mimecast.com, ataata.com en solebitlabs.com.

Hoewel er niets echt magisch is aan de bovenstaande categoriseringen, verwacht ik dat u, de slimme lezer, de beweegredenen hebt opgepikt. Gezien de impact die de overgang naar p=reject kan hebben als het niet correct gebeurt, wil je het niet aanzetten en er maar het beste van hopen. Het DMARC-projectteam van Mimecast doorloopt de meer dan 350 domeinen die het in eigendom heeft in precies dezelfde volgorde als hierboven vermeld en pauzeert tussen elke fase om de eventuele zakelijke impact te beoordelen. En natuurlijk controleren we de DMARC-rapporten die naar DMARC Analyzer zijn teruggestuurd door e-mailontvangers met DMARC-rapportage.

De kern van de zaak

Fase 1 omvatte het configureren van de DNS van alle cybersquattedomeinen op p=reject. Aangezien deze domeinen nooit zijn en nooit zullen worden gebruikt om legitiem e-mail te verzenden, hebben we deze onmiddellijk op p=afwijzen gezet, en we verwachten geen nadelen van het blokkeren van e-mail die van deze domeinen afkomstig zou zijn. In fase 2 zijn ook onze geparkeerde en redirect domeinen op p=reject gezet, en de DMARC rapporten hiervan worden nauwlettend in de gaten gehouden om er zeker van te zijn dat er geen problemen ontstaan.

Fase 3, die betrekking heeft op onze domeinen die actief e-mail verzenden, waaronder mimecast.com, zal een complexere stap van het project zijn. Zoals verwacht, hebben we door dit proces e-mail afzenders ontdekt die dit domein gebruiken en er legitiem uitzien (geen phishers of spammers), maar die niet correct geconfigureerd waren met SPF of DKIM en dus DMARC niet haalden. Dit is waar het interne speurwerk begint. Wie is de interne eigenaar van deze dienstverleners? Moeten ze nog steeds actief e-mail verzenden namens ons? Hoe kunnen we ze het best in overeenstemming brengen met DMARC? Dit is de veiligheids opruim functie die deel uitmaakt van elk DMARC project.

In mijn volgende en laatste blog over dit onderwerp zal ik een project wrap-up en retrospectieve geven over wat onze belangrijkste leerpunten en takeaways waren. Tot dan, blijf DMARCen!