La question e-mail que les questionnaires fournisseur posent de travers

Ouvrez n’importe quel questionnaire de sécurité fournisseur standard, SIG, CAIQ ou modèle interne de banque, et trouvez la section e-mail. Elle pose trois questions :

• Publiez-vous un enregistrement SPF ?
• Signez-vous le courrier sortant avec DKIM ?
• DMARC est-il en mode application ?

Répondez oui trois fois et la section est complète. Le contrôle de l’acheteur est satisfait. Et rien dans cet échange n’a établi si le courrier contenant ses données traverse Internet chiffré.

Pourquoi le questionnaire comporte ce trou

Les trois questions viennent de la même époque et de la même préoccupation : l’usurpation de marque. Des attaquants envoyaient du courrier se réclamant de votre domaine, et SPF, DKIM et DMARC ont été la réponse. Ils fonctionnent, et ils méritent d’être en place.

Ils authentifient le message. Aucun ne touche à la connexion.

SMTP négocie le chiffrement par une annonce non authentifiée. Un attaquant placé sur le réseau retire l’offre STARTTLS du message d’accueil du serveur destinataire, et l’émetteur, ne voyant aucun chiffrement disponible, délivre en clair. DMARC passe toujours, car le message reste signé et provient toujours d’un émetteur autorisé. Il est simplement lisible.

Le questionnaire n’a pas de question pour cela, donc ce n’est pas évalué, donc presque personne ne déploie le contrôle. Les mesures publiées situent l’adoption de MTA-STS sur le million de domaines les plus visités sous la barre du pour cent.

Comment répondre à la question qu’ils voulaient poser

Quand un questionnaire demande « décrivez vos contrôles de sécurité e-mail », la réponse faible énumère SPF, DKIM et DMARC. La réponse forte sépare explicitement les deux problèmes, car ce faisant elle démontre que vous comprenez une distinction que le formulaire lui-même a manquée.

Quelque chose de proche de ceci :

Authentification de l’expéditeur. SPF, DKIM et DMARC sont publiés, DMARC en p=reject. Ils empêchent des tiers d’envoyer du courrier paraissant provenir de notre domaine.

Chiffrement du transport. Séparément, MTA-STS (RFC 8461) est publié en mode enforce, imposant aux émetteurs un TLS authentifié pour la remise vers notre domaine. Cela empêche un attaquant placé sur le réseau de retirer STARTTLS et de forcer une remise en clair, ce que l’authentification de l’expéditeur ne traite pas. TLS-RPT (RFC 8460) est actif et nous surveillons les rapports quotidiens.

Les deux sont vérifiables de l’extérieur : dig TXT _mta-sts.<domaine> et curl https://mta-sts.<domaine>/.well-known/mta-sts.txt.

Trois éléments font mouche. La réponse nomme l’attaque que le premier groupe n’arrête pas. Elle cite les RFC. Elle donne au relecteur une commande pour vérifier lui-même sans vous faire confiance, pour la même raison qu’un rapport externe pèse plus qu’une auto-évaluation.

Si vous ne l’avez pas encore

Ne l’affirmez pas. Un relecteur peut vérifier en dix secondes, et une fausse affirmation dans un questionnaire est nettement pire qu’un trou, car elle recontextualise toutes vos autres réponses.

La version honnête, si le travail est planifié :

Le chiffrement du transport pour le courrier entrant est déployé en mode testing et passe en enforce le [date], une fois que les rapports TLS-RPT auront confirmé que tous les hôtes MX négocient correctement.

Puis faites-le réellement. Le déploiement, ce sont deux enregistrements DNS et un fichier statique.

La question réciproque qui vaut la peine

Si c’est vous qui évaluez des fournisseurs, voici une question peu coûteuse et exceptionnellement instructive à ajouter :

Votre domaine publie-t-il une politique MTA-STS, et dans quel mode ?

La vérification ne coûte rien, et la réponse sépare les équipes qui traitent la sécurité comme une liste à cocher de celles qui lisent les standards sous-jacents. Un fournisseur en mode: testing qui répond « enforce » vous apprend quelque chose d’utile. Un fournisseur qui connaît la différence et explique pourquoi il est encore en test vous apprend mieux.

Cela alimente directement vos obligations de chaîne d’approvisionnement au titre de l’article 21(2)(d) de NIS2, où vous êtes censé évaluer vos prestataires plutôt que d’accepter des affirmations.

Les contrôles voisins que personne ne demande non plus

Tant que vous êtes dans cette section du formulaire, deux trous supplémentaires méritent d’être anticipés, car les questions commencent à apparaître :

DANE. Plus fort que MTA-STS, authentifié par DNSSEC plutôt que par une AC. Déployez-le après MTA-STS, puisqu’il dépend d’une zone signée.

BIMI. Indicateurs de marque. Valeur marketing plutôt que valeur de sécurité, et il exige DMARC en mode application au préalable. Le mentionner dans une réponse de sécurité n’est pas un atout.

Où cela se mappe

• NIS2 article 21(2)(h) cryptographie, 21(2)(e) sécurité des réseaux.
• ISO/IEC 27001:2022 A.5.14, transfert d’information, qui couvre les règles de transfert et pas seulement l’identité de l’expéditeur.
• DORA article 9 pour les entités financières.
• BSI TR-03108 si vous vendez en Allemagne, où c’est attendu plutôt qu’optionnel.

En résumé

Le questionnaire demande qui a écrit le message. Il ne demande pas si le message était lisible en transit.

Répondez aux deux. Nommez le trou que laissent les questions standard, citez la RFC, et donnez au relecteur la commande pour vérifier. Cette réponse marque précisément parce que presque aucun autre fournisseur ne la donne.