La méthode security.txt s'imposera-t-elle en 2024 ?
Promue RFC en 2022, la méthode security.txt vise à standardiser la communication de contacts pour les chercheurs en sécurité.
« Votre organisation a-t-elle un fichier security.txt ? » À l’été 2021, le chercheur en sécurité Brian Krebs avait fait un point sur le sujet, en l’introduisant par cette question.
L’intéressé notait alors qu’Alphabet, Amazon et Facebook, entre autres, avaient fait le pas. Il pointait aussi les limites de cette méthode censée faciliter la communication de contacts de sécurité sur les sites web.
Structuré, lisible par l’homme comme par la machine (texte simple, UTF-8), le fichier security.txt se place dans le dossier /.well-known – ou, en solution de repli, à la racine)*. Il doit comprendre au minimum une adresse e-mail ou un lien de contact, ainsi qu’une date à laquelle on doit considérer le contenu du fichier comme expiré. Les autres champs sont optionnels. Parmi eux : liens vers une clé de chiffrement, une page de remerciements ou des offres de recrutement ; langues préférées ; politique de sécurité.
Une RFC depuis 2022
En 2017, Edwin Foudil et Yakov Shafranovich avaient impulsé une démarche de standardisation de cette approche. Cinq ans plus tard, security.txt était passé au stade de la RFC. Ce qui n’en a pas fait une norme, mais a traduit une forme de consensus au sein de l’IETF.
Dans son analyse de cette « promotion RFC », Stéphane Bortzmeyer avait rappelé quelques autres options permettant de communiquer des contacts de sécurité. Par exemple, la RFC 2142, qui énumère des adresses de type nom@domaine pour joindre le personnel d’une organisation. Ou la possibilité de s’appuyer sur les bases de registres de noms de domaines et d’adresses IP, avec le whois ou RDAP comme canaux d’accès aux informations.
Concernant la première de ces solutions, les porteurs de security.txt soulignent qu’elle ne donne pas la possibilité de publier des informations sur les pratiques de divulgation de vulnérabilités. Quant à la seconde, elle ne faciliterait pas, en pratique, la découverte des informations de contact par les chercheurs en sécurité.
Londres et l’Assurance maladie ont adopté security.txt
En France, l’Assurance maladie a pris le pas. Quelques semaines après le focus de Brian Krebs, elle avait publié un retex d’implémentation. Son équipe sécurité expliquait avoir opté pour un fichier security.txt unique, hébergé sur un serveur centralisé. Autant pour éviter les impacts sur les sites/services que la dépendance aux chefs de projets applicatifs.
Les gouvernements néerlandais et britannique font partie de ceux qui ont adoubé security.txt depuis lors. Les autorités suisses recommandent aussi la méthode. Les CMS Drupal et WordPress ont chacun un module complémentaire spécifique.
Lire aussi : Sécurisation des identifiants et protection contre les attaques par déplacement latéral
Un site « Find Security Contacts » donne un aperçu des organisations qui ont mis en place un fichier security.txt.
security.txt… ou dnssecurity.txt ?
Quatre chercheurs de l’université de Munich ont par ailleurs conduit leur propre analyse, entre décembre 2021 et janvier 2023, sur un million de sites web. Leur principal constat : l’adoption reste faible, même si en progression sur l’intervalle pris en considération.
Au début de l’étude, 32 des 100 plus gros sites avaient implémenté security.txt. À la fin, ils étaient 34. Si on élargit aux 1000 plus gros, les taux de départ et d’arrivée sont respectivement de 16,1 et de 18,8 %. Pour les 10 000 plus gros, on passe sous les 10 %.
Cela dit, notent les chercheurs, les sites n’utilisent pas davantage la méthode dnssecurity.txt, qui a émergé en 2021 pour la publication des contacts de sécurité par DNS.
Quant au contenu des fichiers security.txt, ils contenaient :
– Infos de contact dans 89 % des cas (moyenne sur les 42 relevés effectués au cours de la période de référence)
– Date d’expiration dans 18 % des cas au début, 35 % à la fin
– Langue préférée : 35 % au début, 46 % à la fin
– Politique de divulgation : 36 % au début, 38 % à la fin
– Clé de chiffrement : 32 % en moyenne
– Recrutement : 23 %
– Remerciements : moins de 10 %
* Le fichier security.txt n’englobe ni les sous-domaines ni les domaines parents. Il est possible de le signer numériquement, ainsi que son emplacement, en renseignant le champ « Canonical ».
Illustration principale © Alfazet Chronicles – Adobe Stock
Sur le même thème
Voir tous les articles Cybersécurité