Le paradoxe est bien connu : la majorité des attaques frappent désormais l’applicatif mais l’effort de correction porte toujours essentiellement sur les systèmes. Et lorsqu’il s’agit des applications web, le déficit semble plus aigu encore. Le troisième petit-déjeuner SecurityVibes devait être l’occasion d’explorer les raisons de ce paradoxe sécuritaire et, surtout, de discuter des solutions mises en oeuvre par les membres de la communauté afin d’y remédier.

Mais, ouvert par une présentation de Sébastien Gioria, responsable du chapitre français de l‘OWASP et Sebastien Gioria, le débat aura surtout permis de faire le point sur les causes et les risques, et hélas moins sur les méthodes de contrôle à mettre en oeuvre : la sécurité applicative web dans l’entreprise semble devoir demeurer encore nimbée d’un flou artistique du plus bel (ou pire, c’est selon) effet.

Les causes techniques du problème sont, elles, évidemment bien connues : injections en tout genre (SQL, bien sûr, mais aussi LDAP ou XML par exemple) ou Cross-Site Scripting (« le buffer overflow du web » d’après Sébastien Gioria) n’ont plus de secret.

Quant aux risques, ce sont surtout ceux liés à la responsabilité pénale du dirigeant de l’entreprise en cas de vol de données qui ont étés abordés : jusqu’à cinq ans d’emprisonnement et 300 000 € d’amende en cas de négligence dans la mise en oeuvre du système de traitement des données personnelles. Mais si pour beaucoup dans l’audience l’aiguillon du pénal peut s’avérer un outil de persuasion efficace pour débloquer un budget, un membre a toutefois fait remarquer que l’aiguillon restera quelque peu émoussé tant qu’il n’y aura pas eu de véritable condamnation à une peine de prison ferme sur laquelle s’appuyer. Et la peine la plus sévère a ce jour n’a donné lieu qu’à une amende et à une inscription dans le casier judiciaire du dirigeant.

D’après Bruno Rasle , membre de SecurityVibes et spécialiste ès CNIL, l’organisme serait toutefois entrain de passer à la vitesse supérieure en matière de contrôles sur le terrain, et les sanctions pourraient devenir plus nombreuses et plus sévères à l’avenir.

Il y a donc les vulnérabilités, et les risques – notamment juridiques. Mais quid des solutions ? C’est là que le bât blesse. « Cela passe nécessairement par la prise en compte de la sécurité dès le début des projets de développement web internes », propose Sébastien Gioria en bon évangéliste qu’il est. Oui mais voilà, sur le terrain, les choses ne semblent pas aussi simples.

D’abord parce qu’il faudrait pour cela que la sécurité puisse connaître toutes les applications web dans le périmètre. Mais lorsque nous avons posé cette question à l’assemblée, personne n’a pris le risque de répondre que, en effet, il connaissait l’ensemble des applications web déployées dans son Système d’Information.

Et pour cause : les métiers ont besoin de flexibilité et peuvent déployer, par exemple, des micro-sites à la durée de vie très limitée, notamment dans le cadre d’opérations promotionnelles. « Pour ces cas de figure, comme les sites sont généralement pré-fabriqués à 90%, nous avons pris les devants et discuté avec le prestataire chargé de leur création, afin de nous assurer que la base commune était sûre. Et ensuite, nous faisons confiance. Et d’une manière générale, la seule solution que nous avons trouvé pour connaître les sites mis en ligne chez nous c’est d’avoir de bons rapports avec les métiers et leur prouver que nous ne sommes pas une contrainte, afin qu’ils nous mettent au courant. Sinon ça ne marche pas », raconte un membre présent.

Et même une fois les applications web identifiées, tout n’est pas forcément gagné pour la SSI. Ainsi pour un autre membre de SecurityVibes, le problème des développements web internes est souvent lié d’abord aux contraintes des projets : « La sécurité rallonge le projet et ajoute des contraintes, ce que l’on a du mal à faire passer », observe-t-il.

Quelles solutions, alors ?

Si le scan de vulnérabilités a été abordé, c’est essentiellement afin de relever son incapacité à tout prendre en charge, et la nécessité de savoir où placer le curseur entre tests d’intrusions manuels et analyses automatisées. Mais quelle que soit la solution choisie, elle ne résout pas entièrement le problème de « l’asset management du web » : connaître précisément et à tout moment ce qui est accessible en ligne.

Sébastien Gioria a également préconisé l’ajout aux contrats de développement web d’une annexe-type, dont un exemplaire est proposé gratuitement par l’OWASP. Un tel document permet de contrôler que le prestataire (voire l’équipe de développement interne) aura pris en compte les bonnes pratiques du développement sécurisé. Et il préconise également le recourt a l’Application Security Verification Standard (ASVS) de l’OWASP afin de qualifier le niveau de sécurité de toute application web (mais encore faut-il connaître son existence…)

De même, et toujours sur les rayonnages gratuits de l’OWASP, les développeurs seront probablement inspirés d’utiliser l’API de sécurité (ESAPI) de l’organisation, développée depuis sept ans et qui couvre tous les aspects des besoins sécurité d’une application web. Elle évite de ré-inventer la roue et surtout de créer des implémentations hasardeuses (en chiffrement, par exemple, mais aussi en matière de filtrage des entrées).

Il s’agit cependant ici de solutions essentiellement techniques, alors qu’il ressort de ce troisième petit-déjeuner SecurityVibes qu’il s’agisse avant tout d’un problème de visibilité de la sécurité sur les applicatifs web déployés par les métiers ou la communication (après la prolifération des machines virtuelles, doit-on parler de prolifération sauvage des applicatifs web ?), et ensuite d’éducation des développeurs internes.