Protection e-mail des infrastructures énergétiques critiques suisses : SPF, DMARC et DNSSEC

Non. Tout ce qui est mesuré ici est public et déjà lu par n’importe quel visiteur ou serveur de messagerie : les en-têtes renvoyés par la page d’accueil, des enregistrements DNS interrogés à chaque courriel reçu, et le fichier security.txt là où il est publié. S’y ajoutent deux bases publiques, consultées sans jamais contacter l’entité : la liste de préchargement HSTS intégrée aux navigateurs et la base de routage du RIPE NCC (RIPEstat). Aucun test d’intrusion, aucune recherche de vulnérabilité, aucune tentative d’authentification, aucun formulaire soumis. Une seule requête par domaine et par passage sert toutes les familles de contrôles à la fois, et le User-Agent des sondes désigne cette page, pour qu’un exploitant qui inspecte ses journaux sache d’où vient le trafic.

Publier « tel site n’applique pas telle protection » revient à dresser une liste de cibles, ce qui n’aide personne à corriger. Cette page publie donc des agrégats : combien d’entités appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. La carte montre le verdict de chaque entité, jamais la liste de ses manques. Le fichier security.txt fait exception et reste public car il permet de désigner à qui signaler une faille.

Le responsable de la sécurité des systèmes d’information (CISO) de l’entité concernée, ou de la collectivité dont elle dépend : un CISO cantonal voit son canton et l’ensemble des communes de ce canton, un CISO communal voit sa commune. Des portées sectorielle et nationale existent pour les organisations qui coordonnent plusieurs établissements.

L’accès est ouvert aux responsables sécurité des entités suivies, sur demande et après vérification. Dans sa portée, un accès approuvé donne le détail contrôle par contrôle, la liste de ce qui reste à corriger, l’historique de chaque entité, une fiche PDF et l’analyse consolidée avec son plan d’action. La demande se fait sur cette page : demander un accès.

Chaque contrôle porte un poids et une gravité. Le résultat d’une famille de contrôles est évalué selon trois niveaux : « Solide » à partir de 80 % des points, « Partiel » à partir de 40 %, « À renforcer » en dessous. Deux plafonds s’appliquent ensuite, quel que soit le total : un contrôle critique en échec ramène à « À renforcer », un contrôle critique partiel ou un contrôle majeur en échec interdit de dépasser « Partiel ». Le score global est la moyenne des sondes ayant produit un verdict, sur la même échelle. Ce qui n’a pas pu être mesuré reste « Non évalué » et n’entre pas dans cette moyenne. Pour en savoir plus : le détail des poids et des gravités, contrôle par contrôle.

Des mesures relevées à chaque analyse pour éclairer, sans noter : accès en IPv6 du site et de la messagerie, inscription dans la liste de préchargement HSTS des navigateurs, signature RPKI de la route vers le serveur, certificat des serveurs de messagerie ancré dans le DNS (DANE), traceurs publicitaires ou d’audience et polices Google appelés par la page d’accueil, opérateur et pays d’enregistrement des adresses du site et de la messagerie. Elles n’entrent dans aucun résultat : ces pratiques restent peu répandues ou dépendent de l’hébergeur, et une page lue sans exécuter de script ne dit pas si un traceur attend le consentement du visiteur. Le pays est celui sous lequel l’adresse est enregistrée, en général le siège de l’opérateur, pas l’emplacement du serveur. Le public en voit les parts par périmètre ; le détail par entité reste réservé à ses responsables sécurité.

Chaque périmètre est analysé sur une base mensuelle. La date exacte de la mesure affichée figure en tête des statistiques, plus haut sur cette page, et l’historique en conserve la trace mois après mois. Une correction apportée par une entité apparaît donc au passage suivant, pas le jour même.

Pas le contenu des messages, mais la capacité d’un tiers à écrire au nom du domaine. Les contrôles portent sur des enregistrements DNS publics, que chaque serveur de messagerie interroge déjà à la réception d’un courriel. Ils se publient dans la zone DNS, sans toucher au site web ni à la messagerie elle-même. Ils portent sur le domaine qui envoie réellement le courrier : quand les adresses d’une entité n’utilisent pas le domaine de son site (adresses au nom de la commune pour un site de service industriel, par exemple), c’est le domaine des adresses qui est mesuré. Les huit standards, les pièges courants et la trajectoire de p=none à p=reject : le guide complet de la sécurité des emails.

SPF déclare quels serveurs ont le droit d’envoyer du courrier pour le domaine. DMARC indique au destinataire quoi faire des messages qui échouent à cette vérification – les laisser passer, les mettre en quarantaine ou les rejeter – et où envoyer les rapports : un SPF sans DMARC constate la fraude sans la bloquer. DNSSEC signe les réponses DNS pour qu’elles ne puissent pas être falsifiées en route, ce qui protège les deux premiers – un SPF parfait ne sert à rien si la réponse qui le porte peut être remplacée. S’y ajoutent CAA (quelles autorités peuvent émettre un certificat pour le domaine), MTA-STS et TLS-RPT (chiffrement du transport SMTP, et rapports d’échec). Le rôle de chacun, standard par standard : le guide de la sécurité des emails.

DKIM compte, et sa signature est d’ailleurs utilisée par DMARC. Mais il n’est pas mesurable passivement : contrairement à SPF et DMARC, une clé DKIM se publie sous un sélecteur libre (default._domainkey, google._domainkey, selector1._domainkey…). Le vérifier supposerait de deviner ce nom, c’est-à-dire d’énumérer des sous-domaines – hors du mode passif des contrôles réalisés ici. Le fonctionnement de DKIM et son lien avec DMARC : le guide de la sécurité des emails.