Un “standard” pour trouver comment contacter un site Internet sur lequel vous auriez découvert une vulnérabilité ? Voila une ébauche et une approche fort intéressante !
De plus en plus d’entreprises s’intéressent aux tests d’intrusion préventifs et proactifs à l’encontre de leur SI ou de leur visibilité sur l’Internet (applications web, portails, sites vitrines, etc.). Gagnant en maturité en termes de sécurité, la tendance vise à ne plus se restreindre à de “simples” tests d’intrusion limités sur 1 ou 2 semaines à 1 ou 2 cibles, mais plutôt avec une approche dite “redteam” se traduisant par des tests continus et étalés (sur une année par exemple) impliquant plusieurs auditeurs.
Finalement, lorsqu’un système a été éprouvé et dont la sécurité nécessite d’être continuellement testé, l’approche du “Bug Bounty” est celle se démocratisant de plus en plus. Cette approche permet de bénéficier de tests continus, tout au long de l’année (tant que le programme de Bug Bounty est actif) et évalué par une multitude de “hunters” aux méthodologies et connaissances diverses et variées.
Ces évolutions des mœurs et nouvelles approches sur la sécurité offensive et préventive ont mené à l’émergence de nombreux chasseurs de bugs (hunter) participants de manière responsable et éthique à l’amélioration continue de la sécurité de nombreuses entreprises.
Seulement voila, bon nombre de hunter peuvent déceler une faiblesse de sécurité sur un site et ne savent pas toujours comment la remonter efficacement aux équipes sécurité / techniques du site en question.
C’est ce que le standard “security.txt” cherche à combler, l’idée de ce “standard” proposé par un chercheur en sécurité est de formaliser dans un simple fichier texte (similaire au bien connu “robots.txt”), les informations nécessaires à une prise de contact pour remonter toutes faiblesses de sécurité identifiées à qui de droit.
“When security risks in web services are discovered by independent security researchers who understand the severity of the risk, they often lack the channels to properly disclose them,” Foudil noted.
“As a result, security issues may be left unreported. Security.txt defines a standard to help organisations define the process for security researchers to securely disclose security vulnerabilities.”
4 directives principales se retrouvent dans ce “security.txt”, à savoir :
- Un point de contact (adresse email / numéro de téléphone) à qui repporter le problème de sécurité identifié
- Un lien vers la clé PGP (Pretty Good Privacy) afin de chiffrer les données relatives à la vulnérabilité identifiée
- Le niveau de “disclosure” que l’entreprise accepte, à savoir le fait qu’elle tolère que le chercheur communique publiquement ou non au sujet de sa trouvaille.
- Le point de remerciement (acknowledgement page), référençant publiquement les diverses contributions et crédits associés
What is the main purpose of security.txt?
The main purpose of security.txt is to help make things easier for companies and security researchers when trying to secure platforms. Thanks to security.txt, security researchers can easily get in touch with companies about security issues.
Is security.txt supposed to replace bug bounty platforms?
No. Security.txt is supposed to accompany them. You can use the Platform: option to link to your bug bounty program.
L’intérêt de l’adoption d’un tel “standard” serait bien évidemment une méthode commune et générique pour faciliter la remontée de faiblesses de sécurité, évitant ainsi des “full-disclosure” dans la nature pouvant porter atteinte à l’image de telle ou telle produit / entreprise.
De plus, la présence d’un “security.txt” démontre l’intérêt qu’une entreprise porte au regard de son image et de sa sécurité, facilitant ainsi les contributions diverses et variées de la communauté de hunters grandissantes.
SYNETIS encourage vivement l’adoption de ce “standard” via la mise en place de fichier “security.txt” sur les cibles web pour l’ensemble de ces clients. Nous informons et remontons d’ailleurs ce point en tant que “bonne-pratique” ou “recommandation additionnelle” lors de nos restitutions d’audits sécurité.
Sources & ressources :
