Le 1er novembre 2001, Online Solution découvre une faille de sécurité dans Internet Explorer permettant à un pirate de récupérer les cookies d’un utilisateur. Online Solution commence par informer le centre d’alerte de Microsoft puis le presse de publier un bulletin. Le 9 novembre, devant l’absence de réaction de Microsoft, Online Solution publie seul l’information, avant d’être taxé d’irresponsabilité par l’éditeur. Finalement, Microsoft, contraint par la pression de l’annonce au public, reconnaît la faille et propose un correctif le 14 novembre…
Un code de bonne conduite…
Selon la société Arbor Networks, les récents virus Code Red, Nimda et Badtrans ?” qui exploitent justement des failles de sécurité ?” ont provoqué 640 milliards d’attaques en sept semaines. Il devient donc urgent de prendre les choses en main. C’est ce qu’on fait deux experts en sécurité, Steve Christey et Chris Wysopal, qui ont mis au point un code de bonne conduite pour le traitement des failles de sécurité. Ils ont soumis à l’IETF (Internet Engineering Task Force, chargé de normaliser les technologies d’Internet) un ensemble de procédures standards destinées à organiser la remontée d’informations entre industriels et découvreurs de failles (voir illustration). Intitulé Responsible Vulnerability Disclosure Process, le document est issu de discussions menées auprès du club d’industriels OIS (Organisation pour la sécurité d’Internet), constitué, entre autres, de membres de Microsoft, d’Internet Security Systems, d’Oracle, d’Information Security, ou encore de Cisco. L’idée consiste à accuser réception des bugs envoyés par le découvreur et à livrer des correctifs dans les 30 jours. “Nous découvrons 200 failles informatiques en moyenne par semaine, ce qui peut paraître normal, parmi des millions de lignes de code. Ce qui l’est moins, c’est de refuser de les reconnaître”, souligne ainsi Joël Rivière, PDG de Lexsi. Certains trouvent la démarche inique et s’étonnent de cette banalisation des failles de sécurité. “Encore une fois, l’utilisateur est contraint de faire les frais des failles informatiques, et de courir après un correctif. Un comble, alors qu’il devrait être déchargé du travail de débogage et utiliser des produits fiables”, s’exclame pour sa part Lazaro Pejsachowicz, secrétaire général du Clusif (Club de la sécurité des systèmes informatiques français).
… qui doit s’imposer
Quoi qu’il en soit, au vu des pratiques actuelles en matière de divulgation de failles de sécurité, la proposition de code de bonne conduite n’apportera pas de réel bouleversement. En effet, aujourd’hui les failles remontent jusqu’aux industriels de deux façons différentes. La première, mise en ?”uvre par les Cert, consiste à prévenir tout d’abord les fournisseurs et les fabricants dès qu’une faille est identifiée et leur laisser le temps de mettre au point un correctif, avant de rendre l’information publique. “Nous laissons en général 7 jours aux industiels pour élaborer un correctif. À quelques rares exceptions, aucun d’entre eux ne nous a obligés à publier une information par manque de réaction”, explique Renaud Bidou, le directeur des opérations d’Intexxia, l’un des Cert privés. Mais les failles peuvent aussi être librement divulguées par des utilisateurs isolés. Ce qui présente un risque d’autant plus important que les informations diffusées transitent par des canaux connus de la communauté underground (IRC, liste de discussion BugTraq…). “Bien qu’ils n’agissent pas au nom d’organisations comme la nôtre, ces individus connaissent les codes de bonne conduite implicites en matière de divulgation de failles. Lorsqu’ils rendent une faille publique, sans avertir au préalable le fournisseur, ils le font en connaissance de cause. Ils ne seront pas plus respectueux d’une nouvelle charte”, poursuit Renaud Bidou. Rien en effet ne peut être pire que de rendre une faille publique avant qu’un correctif ne soit disponible. Cette tentative de normalisation vise de toute façon les fournisseurs plus que les pirates et son mérite sera de donner un cadre formel à une procédure jusque-là implicite. Mais avant d’en arriver là, le document devra être étudié par l’IETF. S’il est accepté au sein de l’un des groupes de travail, il peut devenir une RFC (Request For Comments) et être amélioré dans le cadre de procédures publiques. Les éditeurs pourront alors se réclamer de ce code de bonne conduite dans leurs licences, gage de transparence dans la gestion des failles auprès du client. Certains découvreurs auront tout intérêt à respecter cette procédure s’ils souhaitent être cités en tant qu’initiateurs de la découverte. Le prix de la notoriété en somme.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
