Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Applications Web : la démarche de sécurité est inéluctable

décembre 2011 par Emmanuelle Lamandé

La technologie Web est aujourd’hui devenue omniprésente, et se retrouve dans toutes les communications applicatives en entreprise. Le Web devient le support de tous les échanges, laissant peu à peu l’ensemble du Système d’Information accessible via ces technologies… et par là même le champ libre à plusieurs niveaux d’attaque. Dans ce contexte, la sécurité des applications Web se trouve au cœur de tous les enjeux pour chaque entreprise. Quelles sont les étapes clés pour mettre en œuvre une politique de sécurité applicative ? Comment évaluer le niveau de sécurité d’une application ? Quelles sont les obligations légales ? Le CLUSIF nous livre quelques éléments de réponse.

© nmedia_19602967

© nmedia_19602967

Mise en place d’une politique de sécurité applicative : retour d’expérience d’un RSSI

CBP est un Cabinet de courtage et de conseil en assurance emprunteurs et produits de prévoyance. La DSI compte 65 personnes, réparties en différents services, et la politique de sécurité s’inscrit dans le respect de la norme ISO 27001. Dans une logique d’amélioration continue du niveau de sécurité, CBP a choisi de mettre en place une politique de sécurité applicative.
Cette volonté est partie d’un double constat. « D’un côté, l’application est devenue la cible principale des attaques. Aujourd’hui, 75% des attaques sont portées sur l’application Web, seulement 25% sur les infrastructures. De l’autre, les applications de CBP sont de plus en plus exposées sur le Web. Il est donc apparu évident que nous avions besoin d’une politique de sécurité applicative » souligne Philippe Larue, Responsable Sécurité de CBP. Le projet s’est déroulé de février à novembre 2011.

Dans un premier temps, la DSI a demandé un audit externe, afin de définir l’existant. Il faut déjà savoir ce qu’on a et d’où l’on vient si on veut savoir où l’on va. Par rapport aux différents niveaux de sécurité observés, l’objectif premier pour l’entreprise était de pouvoir atteindre un niveau homogène de protection. Fort de ce constat, un certain nombre de recommandations ont été dégagées dans les phases de projet de sécurité logicielle, notamment basées sur les bonnes pratiques et très orientées sur la prévention en amont. En effet, plus une faille est découverte tard dans le processus de développement, plus sa correction coûtera cher.
Pour ce faire, l’entreprise s’est principalement référée à la méthode ASVS (Application Security Verification Standard) de l’OWASP. Cette méthode définit 14 familles d’exigences fonctionnelles classées en 33 niveaux, que CBP a lui-même choisi de classifier en différentes catégories : obligatoire (pas de dérogation), recommandé (obligatoire pour les opérations sensibles), conseillé (au libre arbitre du CDP). Chacune d’elle est référencée selon un code couleur et bénéficie d’un certain nombre d’indications (exigence, référence et exemple de mise en applications).

Cette politique de sécurité part du principe que si le code est meilleur et plus sûr, la sécurité n’en sera que renforcée. L’autre objectif de ce référentiel, consultable par tous, est de mettre l’accent sur la sensibilisation et la formation, en suscitant une prise de conscience et un intérêt pour le sujet.
L’effort demandé aux équipes DSI était, dans un premier temps, de lire cette politique pour la comprendre et savoir où retrouver l’information, puis de contribuer à la faire vivre, en la mettant en œuvre dès à présent pour tout nouveau projet. Un questionnaire pédagogique a également été mis en ligne, afin de savoir si la politique avait été bien comprise ou non. Les résultats à cet exercice se sont avérés pour l’instant plutôt positifs.

« Dans cette démarche, l’accompagnement et la formation sont essentiels pour faire vivre la politique de sécurité. C’est pourquoi nous avons mis en place des formations spécifiques et pratiques, ainsi qu’une page wiki technologique ».

Cette politique est mise en œuvre pour tous les nouveaux projets et, de façon opportuniste, pour d’anciennes applications. Concernant son contrôle, des revues de code sont prévues et un travail autour d’outils automatiques de revue de code aussi (sonar). Le RSSI est, quant à lui, prévenu des différentes failles « sécurité ». L’accès à l’outil de « bug tracking » Mantis lui permet à la fois d’intervenir sur la priorisation d’un bug, de suivre l’évolution des failles, mais aussi de faire un bilan des bonnes pratiques à des fins de rappels pédagogiques et de mises à jour de sécurité.

« Notre politique de sécurité logicielle n’est pas aujourd’hui exhaustive, mais CBP s’inscrit dans une démarche d’amélioration continue » souligne-t-il. Pour conclure, il rappelle que c’est avant tout une démarche d’équipe qui nécessite l’implication de tous les services DSI. De plus, il est préférable de commencer par un point de situation. Quoiqu’on en dise, les non convaincus déclarés sont, selon lui, indispensables pour parfaire la politique de sécurité. L’objectif est de trouver un bon équilibre entre en faire trop (risque de décrochage) et pas assez (risque sécurité). Et bien accompagnée, la démarche provoque l’intérêt.

Revue de code source ou test d’intrusion applicatif ?

Comment faire pour évaluer un niveau de sécurité applicatif ? Revue de code source ou test d’intrusion applicatif ? Lequel est le plus efficient en termes de délais, de coûts ? Sébastien Gioria, Consultant Senior Groupe Y et leader du chapitre Français de l’OWASP - OWASP France, nous explique les avantages et inconvénients de l’un et de l’autre. Selon le cas et les besoins de l’entreprise, chacun peut avoir son intérêt.

Avant de déterminer quelle technique utiliser pour chercher des vulnérabilités, il faut déjà que l’entreprise sache pourquoi elle veut le faire et quels sont ses objectifs : est-ce juste pour les trouver, pour savoir où elles se trouvent exactement dans le code, pour s’assurer qu’elles ne sont pas dans votre application, pour répondre à des exigences réglementaires…

La revue de code donne accès au code source, à la documentation fonctionnelle et à la configuration. Le test d’intrusion applicatif donne, quant à lui, accès via le réseau à l’application, mais s’effectue en un temps limité, qui plus est par un humain qui ne peut pas tout connaître. Même si un certain nombre d’outils permettent d’automatiser différentes tâches, la compétence humaine reste également essentielle dans les deux procédés.

Afin d’évaluer le niveau de sécurité d’une application, il faut, tout d’abord, avoir un référentiel : OWASP TOP 10 (orienté risques), SANS TOP25 (orienté code), CWE (plus complexe), OWASP ASVS… Il est toutefois souvent nécessaire d’en combiner plusieurs. Vous pouvez partir de votre politique de sécurité et y ajouter certaines parties de tel ou tel référentiel. L’important est d’adapter votre méthode à ce que vous pouvez faire dans votre code. Puis, il vous faudra déterminer des métriques, telles que les coûts/délais par exemple.

Afin de déterminer la méthode la plus efficiente entre revue de code et test d’intrusion, il s’est attaché à quelques exemples clés de risques récurrents pour une application Web, qui apparaissent d’ailleurs dans le Top 10 de l’OWASP :
 L’injection de code malveillant : il peut s’agir d’une injection SQL, LDAP, HTML… Les injections se ressemblent toutes, mais quelles qu’elles soient beaucoup d’injections s’avèrent lourdes de conséquences. La revue de code n’oubliera pas une seule injection, contrairement au test d’intrusion qui va en oublier beaucoup. Pour ce qui est des injections, la revue de code est donc conseillée, car exhaustive.
 Cross-Site Scripting (XSS) : le XSS est souvent mal considéré alors qu’il permet pourtant de prendre la main sur le poste client et donc sur le réseau de l’entreprise. Sa détection est assez complexe en pentest ; il est difficile de savoir si on a tout vu (en fonction du contexte, de l’expérience…). Un outil de revue de code automatisé sera, de son côté, incapable de le voir. Seul l’humain peut le détecter. Il est donc conseillé de procéder en la matière à une revue de code en mode manuel.
 Pour ce qui est de l’authentification, le test d’intrusion permet de vérifier certains points par rapport aux exigences, la revue de code certains autres. Chacun a donc ici son intérêt mais n’apportera pas de vue complète.

Recourir à un test d’intrusion est globalement plus facile. Il suffit de recourir à un cabinet externe. Il soumet l’ensemble de l’infrastructure au test et permet de prouver la vulnérabilité. De plus, l’expertise nécessaire est moindre. La revue de code permet, quant à elle, d’avoir une vue exhaustive et de découvrir toutes les failles d’une typologie. Elle permet, en outre, de vérifier que les contrôles sont corrects.

Pour conclure, même si la revue de code apparaît plus exhaustive, la découverte des vulnérabilités dans le code source nécessite, selon lui, une approche globale, qui mixte les différentes méthodes (test d’intrusion/revue de code, manuel/automatisé). Il n’y a pas d’approche miracle, ni d’outil ou de personne miracle d’ailleurs !

Comment le droit peut-il aider à protéger l’information ?

Comme le rappelle Maître Garance Mathias, Avocat - Cabinet Mathias, derrière les applications, se cachent des enjeux liés à la confidentialité et à la protection des données sensibles pour l’entreprise. La protection du patrimoine informationnel nécessite une politique de gestion de ces données. Pour ce faire, il faut déjà être en mesure de les identifier, de savoir où elles se trouvent et de les classifier en fonction de leur sensibilité. Certaines mesures de sécurité sont indispensables à la protection des informations, depuis leur création ou collecte, leur transmission, jusqu’à leur conservation et archivage.

Quelle responsabilité pénale du chef d’entreprise face à son patrimoine ?

Le responsable du traitement est tenu, entre autres, de prendre toutes précautions utiles pour protéger ses données personnelles, conformément à l’article 226-17 du code pénal : « Le fait de procéder ou de faire procéder à un traitement de données à caractère personnel sans mettre en œuvre les mesures prescrites à l’article 34 de la loi n° 78-17 du 6 janvier 1978 précitée est puni de cinq ans d’emprisonnement et de 300 000 Euros d’amende. »
Il se doit également d’assurer l’information et la gestion de ses applications Web, notamment face aux enjeux des transferts de données effectuées par ce biais. Il est important de savoir quelles réglementations nationales et internationales (Patriot Act) s’appliquent lorsque les données de l’entreprise quittent la France ou l’UE.

L’ordonnance du 24 août 2011, venue transposer le Paquet Télécom, souligne, quant à elle, l’obligation de notification « sans délai » des failles de sécurité pour les fournisseurs d’accès de communications électroniques, auprès de la CNIL. Toutefois, certaines zones d’ombre entourent ce texte de loi, à la fois sur les acteurs concernés par cette obligation et la notion de « sans délai » pour le moins ambigüe. Ce flou laissera certainement place à un long débat devant les tribunaux. Sans compter que la transposition du Paquet Télécom devrait encore évoluer, puisque la commission européenne souhaite étendre l’obligation de notification des failles de sécurité à toutes les entreprises.

La protection de l’information est complexe au niveau juridique, car l’information est partout. D’où l’importance d’établir une politique de sécurité et de bien ficeler ses contrats : contrat de travail, mais aussi ceux qui concernent les prestataires, partenaires… La charte informatique est également essentielle comme outil juridique.

Pour conclure, qu’il s’agisse de test d’intrusion ou de revue de code, la démarche de sécurité des applications Web est fondamentale au niveau juridique. Il est essentiel de savoir où sont les données, si elles sont sécurisées ou non, d’où l’importance d’établir une cartographie de l’information et des enjeux juridiques. Où sont mes données sensibles ? Si elles sont hors de France, quelles législations s’appliquent alors ? La collaboration avec le juriste en entreprise est également primordiale.


Pour approfondir le sujet, le CLUSIF vient de publier un nouveau document « Défense en profondeur des applications Web » qui fait suite au dossier « Sécurité des applications Web » paru en 2009.


Articles connexes:

Voir les articles précédents

    

Voir les articles suivants