La culture de la sécurité peine à s’étendre aux développeurs
La sécurité périmétrique a-t-elle vécu ? Non. Mais selon plusieurs RSSI de grands groupes français qui s’exprimaient aux Assises de la Sécurité, qui se déroulaient la semaine dernière à Monaco, la menace concerne de plus en plus les applications. Et d’imposer une révision de l’approche de la sécurité du SI en sécurisant les développements logiciels. Même si les développeurs peinent encore à intégrer cette logique.
Au centre opérationnel de sécurité d’Arval, la branche location longue durée (LLD)/leasing/gestion de flotte de BNP Paribas, on relevait, en 2007, que 5 % des attaques visaient les applications - sur un total non communiqué. En 2009, ce chiffre est monté à 26 %. Pour Willem Peerbolte, RSSI d’Arval, la marche à suivre était toute indiquée : «nous nous sommes engagés sur la sécurité de l’applicatif ». Thierry Olivier, RSSI de SFR, ne contredirait pas ce constat. Lors d’un autre atelier, il indiquait ainsi observer «de plus en plus de menaces visant directement les applications en pénétrant, en profondeur, dans le périmètre du système d’information ».
Une culture émergente
Pour lui, «il y a un réel problème de sensibilisation des développeurs à la sécurité ». Une analyse partagée par Willem Peerbolte dont l’un des objectifs avoués est de «sensibiliser les DSI et les équipes de développement ». Ce fut l’objet d’un premier audit lancé à l’occasion d'une révision sur le système d’information du spécialiste de la LLD, «trois jours avant la mise en production...» Pour éviter de travailler à la dernière minute, «nous avons proposé d’intégrer la démarche de l’audit de code source dans le cycle de développement ». Avec deux cibles principales : les applications exposées à l’extérieur et les services Web. Et lorsque qu’une correction de vulnérabilité serait impossible, «on formalise la prise de risque ».
| Le développement offshore en ligne de mire |
| Offshore et développement sécurisé font-ils bon ménage ? Pas forcément. Pour Willem Peerbolte, RSSI d’Arval, le niveau de maturité des partenaires sur le sujet «est variable». Du coup, «il y a un investissement à faire pour apprendre à développer de manière sécurisée. Ce qui n’est pas forcément facile à vendre en interne», à la direction qui a commandé le développement... Même constat chez SFR où Thierry Olivier, avec des développements externalisés en nearshore ou même en offshore, en Inde, a constaté que «seulement la moitié des postes [de travail des partenaires, NDLR] étaient à jour de signatures anti-virus» en début de collaboration... |
| Cliquez pour dérouler |
Mais tout n’est pas rose pour autant : malgré une formation aux outils de Fortify (récemment racheté par HP) et au développement sécurisé, «les jeunes développeurs ne lisent pas le manuel; ils testent après coup». Surtout, pour le RSSI d’Arval, «il faut penser cycle de vie» et voir au-delà du livrable initial. Bien que cela «pose des problèmes sur les délais de livraison.» Pour autant, «l’analyse automatique n’est pas parfaite» et, par exemple, il est arrivé aux équipes de Willem Peerbolte de relever des écarts entre les résultats produits par les outils de Fortify et ceux de Qualys.
Des solutions trop complexes
Pour autant, un premier pas serait peut-être d’utiliser réellement les fonctions de sécurité natives de certaines environnements applicatifs : selon Thierry Olivier, «pour les développements autour de gros applicatifs tels que SAP, on n’utilise pas leurs fonctions de sécurité intrinsèques». Gil Delille, RSSI du groupe Crédit Agricole, reconnaît volontiers l’intérêt de ces fonctions mais, pour lui, c’est un peu comme «se retrouver avec une pile de lego à devoir assembler une voiture sans savoir où vont les roues. Bref, les développeurs ne savent pas quoi en faire». Pour lui, il est nécessaire de «packager, de produire des solutions complètes avec des API intégrant la sécurité sans que les développeurs aient besoin de s’interroger».
Willem Peerbolte pointe quant à lui certaines limites de l’exercice : «la difficulté que nous n’avions pas prévue, c’est la dépendance vis-à-vis de frameworks et de plug-ins. On les a audités parce qu’on ne peut pas les laisser de côté, mais les corriger, c’est une autre histoire.» De fait, «ce serait un frein pour la portabilité de versions ultérieures. Cela conduit donc à devoir gérer un risque résiduel». Pour le RSSI d’Arval, le problème se pose surtout avec le monde du logiciel libre : «nous n’avons pas encore tenté de faire appel à la communauté pour corriger une faille identifiée car... cela consiste à se déclarer utilisateur tout en produisant une cartographie des vulnérabilités.»
Vers des applications nativement robustes ?
Gil Delille va plus loin s’interrogeant sur la fiabilité, à long terme, des solutions permettant de garantir un environnement d’exécution sûr pour les applications : «si la menace s’accroît, il faudra se poser la question d’applications conçues pour fonctionner dans un environnement non maîtrisé. Des applications ‘cafard’, en quelque sorte; cet insecte étant capable d’aller dans les poubelles sans attraper la moindre infection.» Une direction, pour Thierry Olivier, «mais on ne peut pas se permettre d’attendre» que ce type d’application soit disponible.
