La liste des 25 « fautes » de programmation les plus souvent commises (voir article « happy new bug » du 14 janvier ), ne semble pas soulever un enthousiasme général. Quelques esprits critiques pensent que de telles listes ne servent à rien, et qu’elles pourraient même provoquer un effet contraire à ce qui est recherché. A lire donc deux interventions, l’une de Gary McGraw dans les colonnes d’InformIT, intitulée « 11 raisons expliquant pourquoi les listes ‘’top ten’’ ne fonctionnent pas », et l’autre publiée sur le blog de Matasano, titrant « Pourquoi les spécialistes des tests de pénétration détestent les listes de vulnérabilités ». En résumé, nos deux experts pensent –ceci étant le reflet de leur expérience-, que polariser l’attention des usagers sur une « dizaine d’erreurs majeures à ne pas commettre ou à corriger » limite considérablement leur attention aux points mis à l’index. C’est, expliquent-ils, une sorte « d’effet Owasp », un effet pervers inattendu des campagnes de sensibilisation. D’ailleurs, pour 25 failles ou erreurs mises sous les feux de la rampe, l’on peut en trouver 25 autres tout aussi dangereuses et qui ne sont pas autant médiatisées… et il suffit d’une seule faille exploitable pour qu’un système soit compromis.
McGraw se demande également à qui s’adresse ce message. En priorité, semble-t-il, aux sociétés d’Audit. Car, si la sensibilisation « marchait » auprès des développeurs, cela ferait belle lurette que l’on ne découvrirait plus de trous conduisant à des XSS, BoF et consorts. Les directions, quant à elles, n’ont cure de ce genre d’alertes… trop techniques, pas assez « gestion des risques », trop éloignées des considérations financières qui font équilibrer coûts des procédures de développement et pertes potentielles en cas d’exploitation. Et puis, continue McGraw, cette zoologie de la faille, cette taxonomie des dangers n’est que le prélude à une éventuelle campagne de nettoyage… il serait bien plus intelligent de sortir des codes propres, autrement dit de modifier les habitudes de programmation à la source plutôt que de tabler sur le succès d’opérations correctives a posteriori. D’ailleurs, cette liste des dangers est à peine apprise qu’elle est déjà dépassée. Les failles évoluent avec les technologies, et s’échiner à rechercher des catégories de failles plutôt que de se concentrer sur un cahier des charges de la sécurité est vain. D’ailleurs, pour chercher des failles, il y a des outils automatiques qui font çà très bien. Ce dernier avis est peut-être un peu spécieux. L’on peut d’ailleurs se référer aux démonstrations d’André Gironda sur le « continuous prevention testing » …
