fTLD DMARC : Meilleures pratiques en matière de sécurité du courrier électronique pour les institutions financières
par
Dernière mise à jour : 6 Temps de lecture : 2 min
Points clés à retenir
- fTLD DMARC assure une authentification stricte en combinant SPF, DKIM et l'alignement DMARC pour valider les expéditeurs légitimes.
- A p=reject policy est obligatoire pour tous les domaines .BANK et .INSURANCE, bloquant ainsi l'utilisation non autorisée du courrier électronique.
- DMARC améliore la délivrabilité en améliorant la réputation du domaine et en garantissant des communications fiables.
- La conformité soutient réglementations en matière de cybersécurité financière et réduit l'exposition aux pertes financières liées à la fraude.
- La surveillance continue des rapports et l'alignement des fournisseurs garantissent une protection et une conformité permanentes pour toutes les sources de courrier électronique.
Chaque jour, les organisations envoient et reçoivent d'innombrables courriels, mais tous ne sont pas sûrs. Pour les banques et les compagnies d'assurance, il est essentiel de sécuriser ces messages afin de protéger à la fois leurs clients et leur réputation. Reconnaissant ce besoin, en 2023, fTLD a introduit DMARC pour les domaines de suffixe public (PSD) pour les domaines de premier niveau (TLD) .BANK et .INSURANCE, fournissant une couche automatique de protection du courrier électronique au niveau du registre.
Qu'est-ce que PSD DMARC ?
Le DMARC pour les domaines à suffixe public (PSD DMARC) est une mesure de sécurité qui applique des règles d'authentification de base pour les courriels à tous les domaines enregistrés sous les TLD .BANK et .INSURANCE. Contrairement au DMARC traditionnel, que les propriétaires de domaines doivent mettre en œuvre individuellement, le PSD DMARC fonctionne au niveau du registre, ce qui garantit une protection cohérente dans tous les domaines.
Ce développement découle des normes établies par l'IETF (Internet Engineering Task Force). Internet Engineering Task Force (IETF) et est formellement documenté dans la RFC 9091Le domaine de premier niveau . fTLD a obtenu l'approbation de l'Internet Corporation for Assigned Names and Numbers (ICANN), ce qui a permis la mise en œuvre de cette mesure de protection automatique.
Qu'est-ce qu'un fTLD ?
Le registre des fTLD est l'autorité de domaine pour le .BANK et .INSURANCE. Il s'agit des extensions de domaine les plus fiables et les plus exclusives pour les banques, les assureurs et les producteurs. Le registre fTLD vise à fournir à ces domaines un bouclier solide contre les cyberattaques et les fraudes.
Liste de contrôle de conformité des domaines fTLD (.BANK / .INSURANCE)
Cette liste de contrôle aide les titulaires de noms de domaine à se conformer aux exigences en matière d'authentification et de cryptage du courrier électronique (TLS) pour les domaines de premier niveau. pour les domaines fTLD telles que spécifiées dans les documents officiels du fTLD.
1. Exigences en matière d'authentification du courrier électronique
Enregistrements DNS obligatoires
Publier un enregistrement enregistrement DMARC valide pour le domaine (obligatoire, que le domaine envoie ou non des courriels). Publier au moins un des éléments suivants :
- SPF (Sender Policy Framework)
- ENREGISTREMENT DKIM (DomainKeys Identified Mail)
Exigences de la politique DMARC
| Utilisation du domaine | Politique DMARC requise | Notes |
|---|---|---|
| Domaine non utilisé pour l'envoi de courrier électronique | p=rejeter | Empêche l'acceptation de courriers frauduleux ou non valides |
| Domaine utilisé pour l'envoi du courrier électronique | p=rejeter (obligatoire pour les opérations en cours) | Peut commencer avec p=none ou quarantine pendant la mise en œuvre, mais doit passer à p=reject dès que possible, et au plus tard dans les 90 jours. |
Configuration DMARC recommandée
Bien que ce ne soit pas une obligation, le fTLD recommande un alignement strict pour le SPF et DKIM en utilisant les balises adkim=s et aspf=s. Pour les domaines organisationnels publiant DMARC, définir une balise sp : appropriée pour définir la politique de sous-domaine.
Avantages de la configuration :
- L'authentification des courriels permet d'éviter les courriels frauduleux qui prétendent provenir de votre domaine.
- Il accroît la confiance et la fiabilité des courriels
2. Exigences en matière de cryptage et de sécurité de la couche transport (TLS)
Certificat numérique
- Obtenez un certificat TLS valide pour votre domaine et tous les sous-domaines.
- S'assurer qu'aucun composant de chiffrement interdit n'est utilisé (voir la liste ci-dessous).
Application du protocole HTTPS
- Forcer tout le trafic du domaine et du sous-domaine à passer par HTTPS (crypté).
- Toutes les URL HTTP doivent être automatiquement redirigées vers HTTPS.
- La redirection doit provenir de la version HTTPS du domaine fTLD.
- Le domaine doit être uniquement HTTPS (pas d'accès non crypté).
| Type de connexion | Exigence | Notes |
|---|---|---|
| Connexions web | Maintenir TLS v1.2 ou supérieur | Bien que les versions inférieures puissent être utilisées temporairement pour un contenu éducatif sur l'hygiène et les mises à jour des navigateurs, nous ne le recommandons pas. |
| Courrier électronique de serveur à serveur | Proposer TLS v1.1 ou supérieur en priorité absolue | Les versions inférieures (TLS/SSL ou non cryptées) ne sont autorisées que pour les communications avec des domaines non TLD qui ne prennent pas en charge le cryptage. |
| Autres services | Utiliser TLS v1.1 ou plus | Il n'est pas nécessaire de désactiver TLS v1.0 à ce stade. |
| RFC 5746 (Transport Layer Security Renegotiation Indication Extension) | Doit être mis en œuvre | Empêche une forme spécifique d'attaque de type "man-in-the-middle" dans laquelle un attaquant établit une connexion TLS avec le serveur cible, insère un contenu malveillant, puis le fusionne avec une nouvelle connexion TLS initiée par un client. |
Composants de la suite de chiffrement interdits
Les lignes directrices déconseillent d'utiliser ou d'inclure les éléments suivants dans vos configurations ou certificats TLS :
Anon, CBC, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA1, RC4, EXPORT, EXPORT1024, SRP
Avantages de la configuration
- Garantit une communication sécurisée et cryptée sur le web et par courrier électronique
- Empêche la falsification, l'interception ou l'écoute des données
Récapitulatif rapide de la conformité
- Publier et appliquer DMARC (p=rejet), ainsi que SPF
- Mise en œuvre de TLS v1.1+ dans tous les services
- Rediriger tous les HTTP vers HTTPS
- Utiliser uniquement des suites de chiffrement approuvées
- Appliquer Politiques DMARC dans les 90 jours suivant la mise en place du courrier électronique
Pourquoi DMARC est-il essentiel pour les fTLD ?
DMARC est essentiel pour les domaines financiers en raison des avantages suivants :
Empêche l'utilisation frauduleuse de domaines
A p=rejeter est une instruction directe aux serveurs de messagerie du monde entier de bloquer tout courriel qui échoue à l'authentification. Cette mesure empêche efficacement les criminels d'usurper directement un domaine financier dans le cadre d'attaques de phishing.
Amélioration de l'efficacité de l'envoi d'e-mails
Une configuration DMARC adéquate améliore la réputation de l'expéditeur et favorise l'acheminement fiable et sans problème des communications officielles.
Favorise le respect de la réglementation
Le secteur financier est truffé de de lois et de règlements. DMARC est un contrôle technique important qui aide les organisations à satisfaire aux exigences en matière de cybersécurité.
Réduction de l'exposition aux pertes financières
La prévention des attaques par courrier électronique permet à une institution d'éviter les coûts élevés associés aux violations de données, tels que les amendes réglementaires, les frais de remédiation et l'atteinte à la réputation.
Meilleures pratiques pour la mise en œuvre de DMARC
La mise en œuvre de l'authentification par courrier électronique exige une approche méthodique.
1. Ne pas se précipiter pour p=rejeter
La configuration finale devrait être une politique de rejet (p=rejet). Toutefois, cette mesure doit être prise avec prudence, après une période de surveillance de vos domaines avec p=none et quarantine. Même les lignes directrices relatives aux fTLD prévoient une période de grâce de 90 jours avant l'application de la politique.
2. Confirmer la concordance entre SPF et DKIM
SPF et DKIM nécessitent tous deux une configuration précise pour chaque source de courrier électronique autorisée. Les domaines utilisés dans ces mécanismes d'authentification doivent correspondre au domaine "From :" que voit le client.
3. Utiliser les outils d'analyse des rapports DMARC
DMARC génère des rapports agrégés (RUA) et judiciaires (RUF) qui contiennent des données essentielles sur le trafic de courrier électronique de votre domaine, mais qui ne sont ni intuitifs ni lisibles par l'homme. Un analyseur de rapports analyseur de rapports DMARC analyse ces informations pour vous aider à les déchiffrer et à mieux les comprendre.
4. Aligner les politiques internes et celles des fournisseurs en matière de courrier électronique
Tous les services tiers qui transmettent du courrier électronique au nom de votre institution doivent se conformer à vos besoins d'authentification. Il est essentiel de communiquer avec ces fournisseurs à ce sujet.
Défis communs
Les organisations peuvent être confrontées à certains obstacles techniques au cours du processus d'adoption de DMARC.
La découverte d'expéditeurs tiers
Un inventaire complet de tous les services externes qui envoient des courriels peut s'avérer une entreprise complexe pour les grandes organisations et les entreprises dotées de piles technologiques diverses.
Délais de propagation DNS
DMARC, SPF et DKIM sont configurés par le biais du DNS. Les mises à jour de ces enregistrements prennent du temps à se propager sur l'internet, ce qui peut retarder le calendrier de déploiement.
Gestion des données du rapport DMARC
Les données XML brutes des rapports DMARC sont denses et volumineuses. L'analyse sans plateforme spécialisée est exceptionnellement difficile et inefficace.
Outils et fournisseurs recommandés
Le volume et la complexité des données DMARC font de la gestion manuelle une stratégie peu pratique. Des plates-formes spécialisées sont nécessaires pour une surveillance efficace. Les principales caractéristiques à rechercher chez un fournisseur sont les suivantes
Visualisation intelligente des rapports
La plateforme doit traduire les données XML brutes en tableaux de bord clairs et exploitables qui montrent les tendances et les menaces.
Identification de l'expéditeur
Le service doit automatiquement classer les sources de courrier électronique et fournir des indications claires sur les étapes d'authentification requises pour chaque expéditeur légitime.
Alertes proactives sur les menaces
C'est également un atout majeur si la plateforme offre des notifications en temps réel sur les échecs d'authentification ou les nouvelles tentatives d'usurpation afin de permettre une réponse rapide en matière de sécurité.
Chez PowerDMARC, notre plateforme offre une gamme complète de services gérés d'authentification des courriels. Notre DMARC Analyzer transforme les rapports XML complexes en graphiques lisibles par l'homme pour une visibilité claire des menaces. L'analyseur PowerSPF optimise dynamiquement les enregistrements SPF complexes afin d'éviter les erreurs de validation et de garantir que tous les expéditeurs légitimes sont autorisés.
En outre, nous simplifions le déploiement de normes avancées telles que Hosted BIMI pour afficher votre logo dans les courriels et MTA-STS pour crypter les courriels en transit.
Réflexions finales
En fin de compte, l'adoption de DMARC est une exigence opérationnelle fondamentale pour toute institution sur le réseau .BANK et .INSURANCE . Il s'agit d'une technologie indispensable à la défense de la marque de l'institution, à la protection de ses clients et au respect des obligations réglementaires.
Le chemin vers une conformité totale commence par une politique de surveillance uniquement afin d'obtenir une visibilité totale du paysage de la messagerie électronique. À partir de là, une organisation peut authentifier méthodiquement ses expéditeurs légitimes et passer à une politique finale de rejet. Un partenariat avec un expert en services DMARC permet de réduire les risques liés à cette transition et de garantir une sécurité durable.
Prêt à sécuriser votre domaine financier ? Découvrez notre solution de conformité DMARC et commencez dès aujourd'hui votre voyage vers une mise en œuvre complète.
Foire aux questions
En quoi les exigences DMARC des fTLD changent-elles la donne pour le courrier électronique de mon domaine ?
L'impact sur vous dépend de votre configuration actuelle :
- Si vous avez déjà un enregistrement DMARC : Vos politiques et rapports existants en matière de courrier électronique ne changeront pas. PSD DMARC agit simplement comme une puissante sauvegarde.
- Si vous n'avez PAS d'enregistrement DMARC : Il s'agit d'une amélioration considérable de la sécurité. La politique DMARC de la DSP donne aux fournisseurs de courrier électronique des instructions claires sur ce qu'il convient de faire avec les courriers électroniques frauduleux. Cette protection s'applique à tous vos domaines enregistrés, y compris votre site web principal, les domaines parqués et tous ceux que vous possédez à des fins défensives.
Le fTLD DMARC modifie-t-il les données collectées à partir de mon courrier électronique ?
Si vous avez déjà votre propre politique DMARC, vos données de rapport restent inchangées. Le principal changement est que les fTLD peuvent désormais recevoir des rapports agrégés de haut niveau pour les domaines qui ne sont pas activement publiés (comme les enregistrements défensifs) ou pour les tentatives d'usurpation sur des domaines qui n'existent pas. Ces données les aident à contrôler la santé de l'ensemble du système.
Comment le fTLD utilise-t-il ces données ?
Le fTLD utilise ces données agrégées pour repérer les menaces émergentes, identifier les activités malveillantes, renforcer la conformité en matière de sécurité et améliorer la stabilité et la sécurité globales de ces TLD.
Où puis-je trouver plus d'informations ?
- La norme technique : Vous pouvez consulter la spécification officielle de l'IETF, RFC 9091.
- Pour en savoir plus sur PSD DMARC : visitez la documentation DMARC officielle de la DSP pour des ressources supplémentaires.
fTLD : Vous pouvez consulter les exigences de sécurité DMARC directement sur les sites web des registres .BANK et .INSURANCE sur les sites web des registres .BANK et .INSURANCE.
Expert en sécurité des domaines et des e-mails chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
