MSCE French: Sécurisation de la messagerie chez un distributeur victime d'usurpation

Sécurisation de la messagerie chez un distributeur victime d'usurpation

Fabrikam Distribution (3 200 BAL, Exchange 2016) reçoit 240 000 messages par jour, dont 78 % sont rejetés par une passerelle en fin de vie. Depuis trois semaines, des clients signalent des messages usurpant le domaine fabrikam.fr : l'expéditeur affiché est [email protected] alors que le SPF de l'entreprise n'autorise que les adresses IP de Fabrikam. Un compte utilisateur a envoyé 18 000 messages en deux heures avant d'être bloqué manuellement. Le service marketing veut confier ses envois de masse (400 000 messages par mois) à un prestataire externe qui utilise ses propres adresses IP et le sous-domaine news.fabrikam.fr. Trois partenaires bancaires exigent TLS 1.2 avec un certificat émis par une autorité publique reconnue et une vérification du nom. La CNIL impose le blocage de tout message sortant contenant un NIR (numéro de sécurité sociale) non chiffré. L'équipe sécurité refuse d'ouvrir SMTP 25 entrant directement sur les serveurs Mailbox et veut un point de passage unique journalisé.

1. Comment empêcher l'usurpation de fabrikam.fr tout en autorisant le prestataire à envoyer au nom de news.fabrikam.fr ? Décrivez les contrôles SPF, DKIM et DMARC et la règle de transport entrante.

Read the worked answer

Le point clé est de séparer l'alignement du domaine principal de celui du sous-domaine utilisé par le prestataire.

SPF de fabrikam.fr : ne lister que les adresses IP de la passerelle Fabrikam et terminer par -all. Ne jamais ajouter les IP du prestataire au SPF du domaine principal, sinon on autorise le prestataire à envoyer avec n'importe quelle adresse @fabrikam.fr.
SPF de news.fabrikam.fr : créer un enregistrement séparé qui inclut les IP du prestataire, avec -all.
DKIM : le prestataire signe avec sa propre clé sur le sélecteur convenu ; publiez la clé publique dans le DNS de news.fabrikam.fr. Demandez-lui une signature alignée sur news.fabrikam.fr, pas sur fabrikam.fr.
DMARC : publiez v=DMARC1; p=quarantine; rua=mailto:[email protected] sur fabrikam.fr. Pour le sous-domaine, commencez par sp=none sur news.fabrikam.fr afin d'observer les échecs, puis passez à quarantine après validation. Un p=reject immédiat sur le domaine principal casserait les messages légitimes mal alignés.

Sur la passerelle entrante, ajoutez une règle de transport : si le domaine expéditeur est fabrikam.fr, que le message vient de l'extérieur et qu'il n'est pas authentifié par SPF ou DKIM, rejeter. Exchange 2016 n'évalue pas nativement DMARC ; la passerelle ou la règle de transport doit le faire. Vérifiez aussi l'usurpation par nom d'affichage, car l'adresse peut être externe avec « [email protected] » en nom affiché : une règle sur l'en-tête From ne suffit pas, il faut aussi une politique anti-hameçonnage.

2. Concevez les connecteurs et le certificat pour satisfaire les trois partenaires bancaires en TLS 1.2, sans imposer TLS à tout Internet.

Read the worked answer

Je pars du principe que les partenaires se connectent au nom smtp.fabrikam.fr et que Fabrikam se connecte à leurs passerelles par leur nom publié.

Certificat : acheter un certificat public SAN contenant smtp.fabrikam.fr et mail.fabrikam.fr, avec la chaîne complète. Un certificat auto-signé est exclu, car les partenaires exigent une AC publique et une vérification du nom. Le certificat doit être installé sur la passerelle et sur le connecteur de réception SMTP utilisé par les partenaires.
Connecteur de réception : lier le certificat au connecteur, activer TLS 1.2, désactiver SSL 3.0 et TLS 1.0/1.1. Ne pas exiger TLS sur ce connecteur pour tous les expéditeurs, sinon les petits partenaires sans TLS ne pourront plus écrire.
Connecteur d'envoi : créer un connecteur d'envoi dédié par partenaire, avec RequireTLS et le domaine de destination comme espace d'adressage. Le certificat présenté est celui de Fabrikam ; le partenaire vérifie le nom. Pour les autres destinataires, garder TLS opportuniste.
Journalisation : la passerelle doit journaliser les sessions TLS, les échecs de négociation et les noms de certificat, car un partenaire qui passe en échec TLS doit être diagnostiqué sans modifier le connecteur global.

Je ne configure pas de « domain secure » sans accord écrit : cela impose une authentification mutuelle TLS et casse le flux si le partenaire ne présente pas le bon certificat.

3. Rédigez la contrôle DLP/transport pour les NIR sortants et la détection du compte compromis. Pourquoi une simple règle sur le mot « NIR » est-elle insuffisante ?

Read the worked answer

Une règle sur le mot « NIR » ne détecte que les messages qui emploient ce libellé ; un numéro de sécurité sociale peut être envoyé dans un tableau, une pièce jointe ou sans légende. Il faut une détection de motif.

Créer un type d'information sensible personnalisé avec l'expression régulière du NIR : 13 chiffres, éventuellement espacés, suivis d'une clé de 2 chiffres, avec les règles de validation de la clé. Exchange 2016 permet des types DLP personnalisés et des règles de transport avec correspondance de motifs.
Règle de transport sortante : si le message sort de l'organisation et contient ce type d'information sensible, bloquer le message, générer un rapport d'incident vers la boîte conformité et informer l'expéditeur. Ne pas se contenter de journaliser : la CNIL exige le blocage.
Si le chiffrement est autorisé pour certains correspondants, ajouter une exception documentée avec chiffrement des messages ; sinon le blocage reste la règle par défaut.

Pour le compte compromis : activer une limite de destinataires sortants par utilisateur, une alerte sur le volume et une règle de transport qui bloque un expéditeur interne au-delà d'un seuil. En parallèle, désactiver le compte, réinitialiser les identifiants, rechercher les règles de boîte créées par l'attaquant et vérifier les connecteurs. Le blocage manuel après 18 000 messages montre que la détection doit être automatique et testée.