Carte security.txt des infrastructures énergétiques critiques suisses

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.

C’est un fichier texte publié à une adresse fixe, /.well-known/security.txt, normalisé par la RFC 9116. Il indique à qui signaler une faille de sécurité, dans quelle langue, et jusqu’à quelle date l’information est tenue à jour. Le publier revient à désigner, avant l’incident, qui traite les signalements – une attente de l’OFCS. Sans lui, la personne qui découvre un problème doit improviser : formulaire de contact générique, réseaux sociaux, ou renoncer. La bonne pratique est d’y indiquer une boîte générique relevée par plusieurs personnes plutôt que l’adresse d’une seule. Champs, politique de divulgation, obligations NIS2 et CRA, déploiement en six étapes : le guide complet de security.txt.