Anti-virus.... mutatis mutandis ?
Oh, quelle belle polémique que cette polémique là. A l'occasion de la prochaine DefCon de Las Vegas se déroulera un concours peu ordinaire. Chaque participant de Race to Zero se verra offrir un échantillon de virus connu, matière à partir de laquelle il devra composer une oeuvre de son choix capable de franchir les barrières des principaux A.V. C'est selon ce principe que Brillat-Savarin réinventa la fondue Savoyarde (une nouvelle version agrémentée de crème fraîche et de truffes noires du Périgord) Comme le rapporte Slashdot, certaines entreprises fulminent et arguent du fait que de tels concours facilitent le travail des « c0d3rZ ». Comme c'est bizarre. Des remarques analogues avaient été émises lors de la publication sur la génération automatique d'exploits après analyse des effets des rustines (travaux d'Universitaires de Carnegie Mellon, Berkeley et Pittsburg). Cédric Blancher revient d'ailleurs sur cette information, en précisant qu'il n'y a là rien de nouveau sous le soleil. Vous avez dit bizarre ? Comme c'est étrange. Les cris les plus désespérés -mais sont-ils les plus beaux- sont poussés par les éditeurs d'anti-virus eux-mêmes. Mais de quoi ont-ils peur ? Que les recherches « aident » réellement une véritable industrie du malware qui n'a franchement pas tellement besoin d'aide, ou redoutent-ils que les résultats du concours ne viennent prouver combien il est aisé et rapide de créer une souche mutante ? Combien il est illusoire de se réclamer de l'école des « anti-virus euristiques », ceux qui chassent le virus même dans le noir, sans dictionnaire de signature... ce même dictionnaire que tout le monde déclare ne plus être indispensable, mais dont la rapidité de mise à jour demeure l'un des arguments commerciaux les plus prisé ? entre contradiction et préservation d'une rente de situation, il est difficile de dire qui a tort ou bien... encore plus tort. « Il n'est pas nécessaire de savoir écrire un virus pour se protéger des virus »... argument négationniste extrême, qui associe dans une formidable salade russe à la fois le pentesting, l'écriture d'exploits, le scripting de « preuves de faisabilité », l'automatisation du fuzzing... Ne jouons pas à l'apprenti sorcier, la cinquième colonne nous écoute. Ce à quoi Robert Graham (décidément très en verve depuis deux semaines) réplique par un argument pesant ses quatre grains d'ellébore : « Ce n'est certes pas obligatoire lorsque l'on souhaite développer des outils de défense, puisque l'on s'attache à analyser une méthode d'attaque et à la contrer en toutes circonstances. C'est là une vision analytique, euristique au sens propre du terme. C'est en revanche absolument nécessaire lorsque l'on est du coté du « client », lequel doit impérativement tester la solidité de la cuirasse. C'est l'approche empirique, matérielle, qui vient vérifier par la pratique les assertions de la théorie. Comment, continue Maynor, faire confiance à des marchands qui, d'un coté, prétendent résister à 99% des virus connus et qui, d'un autre coté, considèrent comme une mauvaise pratique le fait de lancer de réels assauts viraux contre leurs propres outils ? » Une nouvelle fois, on ne comprend pas très bien pourquoi, en vertu d'une soi-disant normalisation des pratiques de sécurité, les principes immuables du « test destructif » seraient devenues caduques. Ce qui dérange les éditeurs et le coeur des vierges qui les accompagne, c'est que de tels travaux sont révélés au public et montrent à quel point l'industrie dans laquelle nous vivons tous est d'une fragilité extrême. Une attitude que dénonce quelques gourous, dont Bruce Schneier, qui reviennent sur leurs fondamentaux : Nous vivons, estiment-ils, une situation paradoxale, qui nous fait dépenser des sommes parfois considérables dans le seul but de consolider des outils qui nous sont vendus très chers et très imparfaits. Et la seule excuse à cette imperfection s'appelle la fatalité ou l'inévitable erreur humaine. Certes, la sécurité est un compromis, une quête sans fin. Mais ce n'est pas une raison pour que les véritables responsables ne prodiguent pas tous les efforts possible pour minimiser les conséquence de leurs imperfections. Coté utilisateur, la question est d'un tout autre ordre. Le rôle du RSSI -ou du CSO- est-il, avant tout, de veiller à la sécurité intrinsèque des produits achetés par l'entreprise -ergo de se charger de résoudre des problèmes de sécurité affectant un « fournisseur »- ou consiste-t-il à protéger les richesses matérielles et intellectuelles propre à l'entreprise ? A cette très vieille question n'existe qu'une réponse censée : La responsabilité du fournisseur. Longtemps, les lobbys de l'automobile, par exemple, on joué un jeu semblable, aujourd'hui, à celui de bon nombre d'éditeurs de logiciels. Il faudra attendre les années 70 pour qu'un Ralf Nader parle, le premier, de responsabilité légale du fournisseur. Qui sera le Nader du « safe coding » et du « secure programming » ?
