Faire ce qu’il faut : comment les RSSI devraient aborder la divulgation responsable

Le débat sur ce qui constitue une divulgation responsable dure depuis environ 20 ans, sans fin en vue. Il n’est pas difficile de comprendre pourquoi, avec des chercheurs passionnés toujours à la recherche de bugs, de grands écarts par rapport aux fournisseurs lorsqu’il s’agit de résoudre les problèmes et des réputations à construire et à préserver des deux côtés.

Pour comprendre la meilleure approche en matière de divulgation responsable, il est important que les RSSI comprennent d’abord comment la controverse survient. La cause la plus fréquente est lorsque les détails techniques d’une vulnérabilité sont publiés avant qu’un correctif ne soit disponible ou largement adopté, en particulier lorsqu’il est accompagné d’un code d’exploitation de preuve de concept facilement réutilisable.

D’un côté, il y a ceux qui considèrent que les chercheurs agissent de manière irresponsable en permettant de vrais attaquants et en attirant l’attention sur les problèmes. De l’autre côté, il y a ceux qui considèrent qu’une telle divulgation est dans l’intérêt public – aider les utilisateurs de produits à prendre des décisions éclairées et à mettre en œuvre leurs propres détections et atténuations en l’absence d’un correctif ou d’un correctif du fournisseur.

Les fournisseurs de logiciels les plus matures font face à un examen public minutieux quant à la réactivité et à la responsabilité de leurs efforts de divulgation et de correction.

Ce débat continuera sans aucun doute à faire rage. Mais lorsque vous regardez bon nombre des divulgations complètes controversées qui se sont produites au fil des ans, la communication, ou son absence, est à la racine. L’établissement clair des règles d’engagement contribue grandement à améliorer les choses.

Par exemple, bien que 90 à 120 jours soient considérés par beaucoup comme un délai maximal raisonnable pour remédier ou faire face à la divulgation publique, selon Projet Zéro : politique et divulgation : édition 2021, nous avons vu de nombreux cas où il a fallu un an ou plus à une organisation pour fournir une correction complète à un bogue signalé.

C’est particulièrement le cas des entreprises moins matures, en particulier celles qui déploient des appareils internet des objets (IoT) difficiles à mettre à jour et qui s’appuient fortement sur des fournisseurs de composants ou de logiciels tiers pour fournir un correctif qui peut ensuite être intégré à leur produit.

La bonne nouvelle est que les choses sont beaucoup plus claires qu’elles ne l’étaient auparavant pour les RSSI typiques, en particulier ceux qui travaillent pour des entreprises qui ne sont pas principalement engagées dans le développement de logiciels.

Il existe un large éventail de lignes directrices et de normes de bonnes pratiques, telles que la boîte à outils de divulgation des vulnérabilités du NCSC – NCSC.gov.uk et ISO – ISO/IEC 29147:2018 – Technologies de l’information – Techniques de sécurité – Divulgation des vulnérabilités. Ceux-ci fournissent aux RSSI et aux responsables de la sécurité des conseils clairs sur la façon d’établir des canaux de communication et de définir les attentes. Les RSSI peuvent les diffuser via le site Web de leur organisation, ou les rendre plus faciles à trouver en adoptant la norme émergente de sécurité.txt (sécurité.txt: norme proposée pour définir les politiques de sécurité (securitytxt.org)).

Les bug bounties permettent également aux organisations de solliciter de manière proactive des soumissions de bugs auprès de chercheurs publics. Toutefois, ils visent à compléter, plutôt qu’à remplacer, un programme d’assurance de la sécurité bien organisé et structuré. Ils doivent également s’accompagner d’investissements dans des équipes pour trier et résoudre rapidement les bogues entrants.

L’adoption des points ci-dessus devrait permettre à un chercheur en sécurité de savoir facilement où signaler les vulnérabilités et aider à réduire le risque que les rapports de vulnérabilité se retrouvent perdus dans une boîte aux lettres non surveillée. Ils établiraient également des attentes quant à la durée d’une correction et à la question de savoir si le chercheur peut s’attendre à une récompense ou à une reconnaissance pour avoir signalé un problème.

La plupart des chercheurs attendront avant de rendre publiques les vulnérabilités si l’organisation peut être contactée, est réactive et fournit des mises à jour régulières indiquant qu’elle progresse avec un correctif.

Parallèlement à cela, les RSSI et les équipes de sécurité sont bien avisés de surveiller de près les divulgations publiques très médiatisées et les nouvelles de l’industrie, afin qu’ils soient au courant des dernières vulnérabilités non corrigées ou activement exploitées et puissent réagir rapidement lorsque quelque chose au-delà du cycle de gestion des correctifs standard est nécessaire.

En résumé, il existe désormais de nombreux outils et conseils disponibles pour équiper les RSSI afin qu’ils gèrent bien la divulgation des vulnérabilités. La plupart des personnes signalant de véritables vulnérabilités ont de bonnes intentions – une communication claire et une bonne administration de tout programme de divulgation sont la clé pour minimiser les problèmes. Tout ce qui contribue à renforcer la sécurité et à protéger les entreprises contre les vrais pirates malveillants doit être une bonne chose et doit être adopté par les RSSI.