Authentification des messages basée sur le domaine
Au début de cette année, dans le cadre de notre démarche à l'échelle de l'entreprise visant à nous conformer aux 20 contrôles de sécurité essentiels du Center for Internet Security (CIS) (s'ouvre dans un nouvel onglet), Tanium a mis en place une configuration plus restrictive utilisant le protocole DMARC (Domain Based Message Authentication, Reporting, and Conformance) pour les e-mails de l'entreprise. Comme prévu, cela a permis de réduire considérablement le nombre de spams et d'e-mails de hameçonnage de type « ». Mais nous avons également rencontré plusieurs difficultés imprévues lors du déploiement. Compte tenu du nombre d'entreprises qui choisissent de ne pas configurer DMARC, nous avons pensé qu'il pourrait être utile de partager notre expérience en vous présentant une vue d'ensemble de DMARC, les difficultés courantes liées à sa mise en œuvre, ainsi que quelques conseils pratiques que nous avons pu tirer de notre expérience.
DMARC utilise deux technologies, le Sender Policy Framework (SPF) et le DomainKeys Identified Mail (DKIM), pour déterminer si un e-mail a été usurpé (c'est-à-dire falsifié pour donner l'impression qu'il provient de votre organisation) ou s'il a bien été envoyé par votre entreprise. Le SPF et le DKIM sont tous deux publiés sous forme d'enregistrements DNS publics auxquels il est possible d'accéder depuis n'importe où. Ces contrôles permettent aux serveurs SMTP destinataires d'examiner les en-têtes entrants, de comparer leurs clés de source et d'intégrité à celles publiées par votre organisation, puis de décider s'il convient de transmettre le message ou de prendre une mesure, telle que la mise en quarantaine d'un message. Ces informations sont ensuite transmises à une adresse e-mail spécifique, où elles peuvent être analysées et triées afin de détecter d'éventuelles anomalies ou problèmes.
La liste SPF est simplement une liste de noms de domaine complets (FQDN) ou d'adresses IP qu'une entreprise a désignés comme expéditeurs SMTP autorisés. Les serveurs SMTP récepteurs peuvent analyser les en-têtes d'un message entrant afin de déterminer le serveur SMTP d'origine. Le DKIM est un mécanisme de contrôle bien plus précis qui repose sur le chiffrement asymétrique. Tanium publie une clé publique via le DNS et conserve en toute sécurité la clé privée correspondante, qui n'est pas publiée. Tout tiers souhaitant envoyer des e-mails au nom de l'entreprise doit également générer une paire de clés publique/privée et inclure ainsi que sa clé publique dans le DNS.
Lorsqu'un e-mail arrive, le serveur destinataire extrait la clé DKIM jointe des en-têtes du message et interroge le serveur d'origine afin de vérifier sa légitimité. Si la clé DKIM fournie ne correspond pas à la clé privée du serveur d'origine, le message est falsifié. En cas de correspondance, le serveur distant sait que l'e-mail provient bien de l'expéditeur et peut donc être remis en toute sécurité.
Difficultés liées à la mise en œuvre
Bien que les protocoles SPF et DKIM soient tous deux assez simples à mettre en œuvre, ils nécessitent toutefois que d'autres organisations y participent et configurent correctement leurs enregistrements DNS. Lorsque vous envisagez d'utiliser un logiciel tiers qui enverra des e-mails en votre nom, vous devez vérifier si le fournisseur prend pleinement en charge les protocoles SPF et DKIM. Si le fournisseur ne met pas correctement en œuvre les protocoles SPF et DKIM, cela pourrait rendre difficile, voire impossible, l'application intégrale de ces mesures.
Cela dit, même si d'autres organisations configurent correctement les protocoles SPF et DKIM, vous devez être conscient de difficultés supplémentaires :
Évolutivité de SPF
SPF ne peut effectuer que dix requêtes DNS, limitées à plusieurs types d'enregistrements différents (notamment les enregistrements A, MX, PTR, EXISTS, INCLUDE et REDIRECT). Cette limite a pour but d'empêcher les recherches infinies d'enregistrements, mais elle restreint également l'évolutivité du SPF. Les redirections et autres mécanismes DNS nécessitant plusieurs requêtes peuvent rapidement épuiser la limite et semer la confusion lors du dépannage. C'est pourquoi il est extrêmement important d'examiner attentivement la manière dont les enregistrements DNS sont utilisés pour mettre en œuvre le protocole SPF. Les adresses IP et les plages d'adresses IP ne sont pas concernées par cette restriction ; toutefois, la gestion des changements d'adresses IP peut s'avérer très gourmande en ressources par rapport à l'utilisation d'un nom de domaine complet (FQDN).
Sous-domaines non inclus :
SPF prend uniquement en compte le nom de domaine exact indiqué dans l'enregistrement : les sous-domaines tels que et sont pris en compte, mais paset . Par exemple, si vous spécifiez une adresse IP dans un enregistrement SPF pour @company.com, et que cette adresse IP envoie des e-mails depuis @_subdomain.company.com, _la vérification SPF échouera. Chaque sous-domaine doit disposer de son propre enregistrement SPF.
Utilisation de clés DKIM provenant d'autres domaines
Les clés DKIM permettent à d'autres organisations d'être pleinement authentifiées par rapport à votre domaine (et donc d'envoyer des e-mails vérifiés en votre nom). Des tiers correctement configurés peuvent vous fournir une clé de sélection (cette clé revient en substance à ce qu’ prêtent leur clé publique tout en conservant le contrôle de la clé privée). Même si vous ne disposez pas de la clé privée, une configuration correcte de la clé de sélection dans le DNS vous permettra de rediriger les demandes de déchiffrement vers le tiers et de mener à bien la validation.
Les organisations peuvent définir le niveau de contrôle des échecs liés au SPF ou au DKIM à l'aide des options suivantes :
-Aucune : les messages sont résumés et consignés dans un journal à des fins de vérification, tout en permettant la livraison du message incriminé
-Mise en quarantaine : chaque fournisseur de messagerie détermine la nature de cette action, mais pour la plupart, cela signifie le transfert direct des messages dans le dossier « Spam » de l’utilisateur
-Rejet : les messages sont purement et simplement rejetés lorsqu’ils ne sont pas conformes aux normes SPF ou DKIM
N'oubliez pas : les résultats DMARC ne sont pas faciles à interpréter. Les résultats sont fournis dans un fichier XML et envoyés à l'adresse e-mail indiquée dans la politique DMARC par chaque serveur SMTP qui reçoit des messages. En fonction du volume de trafic de messagerie, des milliers de messages pourraient être envoyés chaque jour, ce qui rendrait difficile l'identification et la résolution des problèmes potentiels.
Afin de bien comprendre votre environnement, il existe plusieurs outils permettant à la fois d'identifier les problèmes au sein même des enregistrements DMARC/SPF/DKIM et de mettre en évidence les problèmes cachés dans les rapports XML DMARC renvoyés lorsqu'un serveur SMTP a déterminé qu'un message enfreignait la politique. Tanium utilise un service appelé Dmarcian (s'ouvre dans un nouvel onglet) pour faciliter l'analyse de nos paramètres et le regroupement des résultats.
Même si elle n'est pas parfaite, la mise en œuvre du protocole DMARC contribue grandement à offrir aux organisations à la fois une visibilité et un contrôle sur les expéditeurs d'e-mails utilisant leur nom de domaine. En utilisant efficacement ces outils, les entreprises peuvent réduire considérablement le nombre d'e-mails malveillants qui leur parviennent et empêcher des utilisateurs malveillants d'usurper l'identité de leur domaine. DMARC permet aux organisations de contrôler la manière dont les serveurs SMTP destinataires peuvent à la fois vérifier les e-mails légitimes et non légitimes prétendant provenir de l'adresse d'origine « @votredomaine.com » et prendre les mesures qui s'imposent.
En mettant en place une implémentation DMARC adéquate, Tanium a pu renforcer la couverture des contrôles dans 3 domaines CIS différents :
- CSC 7 : Protection des messageries électroniques et des navigateurs Web
- CSC 8 : Mesures de protection contre les logiciels malveillants
- CSC 9 : Limitation et contrôle des ports réseau, des protocoles et des services
Conclusion
Si vous gérez des domaines utilisés pour la messagerie électronique, nous vous recommandons vivement de mettre en place le protocole DMARC. Non seulement cela est dans l'intérêt de chaque entreprise prise individuellement, mais l'écosystème de la messagerie électronique dans son ensemble en tirera également profit, car le nombre de domaines susceptibles d'être usurpés diminuera de plus en plus. Réduire le risque d'usurpation de votre nom de domaine signifie réduire le risque que vos utilisateurs soient victimes d'abus, ainsi que le risque de devoir engager des dépenses pour faire face à des incidents ou gérer d'autres problèmes de responsabilité. Il s'agit d'un élément modeste mais important de la mise en œuvre complète de mesures de sécurité proactives, telles que les 20 contrôles du CIS, et cela contribue à satisfaire aux exigences nécessaires à l'obtention d'une certification dans le cadre de référentiels de conformité tels que la norme ISO 27002. C'est tout simplement une évidence pour la santé et le bien-être des entreprises, quelle que soit leur taille.
À propos de l'auteur : Eric Fisher est analyste en sécurité de l'information et expert en conception des opérations d'entreprise chez Tanium, à Raleigh, en Caroline du Nord. Eric est titulaire d'un master en sécurité de l'information et en criminalistique numérique. Il a auparavant travaillé comme consultant en sécurité, où il a mis en place des centres d'opérations de sécurité (SOC) et des programmes de gestion des incidents pour plusieurs banques, enseignes de distribution et entreprises technologiques figurant au classement Fortune 500 . Il a également conçu et mis en place des architectures informatiques et des réseaux à grande échelle pour plusieurs organismes gouvernementaux et pour l'armée, en tant que collaborateur du Laboratoire de recherche appliquée de Penn State et de Raytheon.
