DÉVELOPPER DES APPLICATIONS WEB SÉCURISÉES De la théorie à la pratique Juillet 2012 www.advens.fr Document confidentiel - Advens 2012
Développer des Applications Web Sécurisées Intervenants Agenda Frédéric Patouly Sales & Technical Unit Manager Quotium frederic.patouly@quotium.com Etat des lieux Limites des processus et outils utilisés dans le cycle de développement Jérémie Jourdin Responsable R&D Advens jeremie.jourdin@advens.fr Bénéfices d une approche «datacentric» dans la sécurité applicative L exemple Seeker Questions / Réponses 2
Déroulement La présentation vous sera envoyée par email après le webinar Vous pouvez poser vos questions à tout moment dans la fenêtre de chat Nous y répondrons en fin de session pendant le Q&A Mais pour l instant, nous vous conseillons d afficher les slides en plein écran pour votre confort 3
Quotium Technologies Editeur français de solutions logicielles innovantes pour maîtriser la performance et la sécurité des applications métiers tout au long de leur cycle de vie: ü Qtest: Test de charge et diagnostic de la performance ü AppliManager: Monitoring du ressenti utilisateur ü Seeker: Test interactif de la sécurité applicative Éléments clés Côté au NYSE Euronext à Paris Bureaux à Paris, Toulouse, Tel Aviv, Londres et New-York 200+ références grands comptes Label EUREKA entreprise innovante décerné par l OSEO Chairman au Comité OWASP Nos différences Une suite intégrée assurant la continuité entre les équipes 8 ans d expérience en performance et sécurité des applications métier Une offre de solution logicielle en sécurité applicative, Seeker, distinguée par Gartner en 2011 et 2012 pour son innovation et sa performance 4
Qui sommes-nous? Advens Depuis plus de dix ans, nous aidons les organisations, publiques ou privées, à piloter la sécurité de l'information en parfait alignement avec leurs enjeux métiers et pour en améliorer la performance. Éléments clés Créée en 2000 CA 6 millions d euros 60 collaborateurs Bureaux à Paris et à Lille Organisme certificateur agréé par l ARJEL (*) * Autorité de Régulation des Jeux En Ligne www.arjel.fr Nos différences Un pôle R&D et une expertise sécurité adaptée au monde du développement Une approche métier s appuyant sur des compétences sectorielles Une offre unique pour délivrer la sécurité de bout en bout, comme un service Une approche pragmatique et des tableaux de bord actionnables Une vision globale et indépendante des technologies 5
Etat des lieux en 2012 Augmentation de la fréquence et de la complexité des attaques WEB Des intrusions parfois difficiles à détecter APT: Plusieurs exemples d intrusion et de maintient durant plusieurs jours / semaines AET: Qui en parle? De nombreuses entreprises ne maitrisent pas leur exposition sur le Web Les métiers qui contractualisent en direct Architectures distribuées Externalisation de services Des exemples réguliers dans la presse Cyber-Espionnage Cyber-Crime Cyber-Activisme 6
Etat des lieux en 2012 Augmentation des interventions forensic / post-mortem en 2011 E-Commerce: Chantages à l injection SQL Jeux vidéo en Ligne: Vol de données joueur Collectivité: Défiguration de site institutionnel Les applications restent vulnérables Aux attaques par injection Au Cross Site Scripting Aux faiblesses dans l authentification Aux faiblesses dans la gestion des sessions Le niveau de sécurité des applications Web ne progresse pas. Plus de 85% des applications Web auditées par Advens en 2011 présentent des failles dans le top 5 de l OWASP. 7
Des causes multiples Manque de sécurité dans les cahiers des charges Manque de sensibilisation des développeurs et des chefs de projets Manque de communication entre les développeurs / les architectes / le réseau Time to Market: Pression du métier Contrôles de sécurité insuffisants ou inadaptés Un comportement inacceptable de certains éditeurs sur les logiciels de niche Un manque de maitrise dans les techniques de sécurisation Une sécurité «périphérique» (ex: focus sur le frontal Web) 8
Sécuriser le cycle de développement Suivi de l application en production Analyse des besoins et faisabilité Contrôles / Audits Recette Spécifications générales Tests de validation Conception de l architecture Tests d intégration Conception détaillée Tests unitaires Développement 9
Sécuriser le cycle de développement Es#ma#on des coûts de correc#on des anomalies Secure Development Life Cycle Concep'on QA Produc'on 1x 5x 10x Conception Développement Intégration 15x Qualification 30x Pré-production 10
Ne pas raisonner en silo Web App Web Service Base de données Web Service Base de données Prendre en compte la sécurité de toute la chaine applicative 11
Les limites des tests de sécurité L audit de code statique a ses limites Long et fastidieux s il est fait manuellement Limites et coûts des outils automatisés L audit de code ne permet pas de prendre du recul sur le fonctionnement global de l application Un audit de code est inadapté dans le cycle de développement Sauf s il est fait au fil du projet, de manière régulière et automatisée Ou pour valider de petites portions de code critique, qui ne seront plus modifiées par la suite (ex: Routines d authentification) Ne pas oublier qu un développeur n est pas un expert en sécurité Les outils existants sont très souvent des outils d experts Nécessité d analyser les résultats avec un œil d expert pour identifier les failles dans le code 12
Les limites des tests de sécurité Les contrôles en boîte noire sont insuffisants et pourtant ce sont les plus utilisés On se focalise généralement sur les «portes d entrée» L approche boite noire impose de tout tester On ne teste que ce que l on découvre (limites du crawling sur certain site) Certains mécanismes d authentification empêchent l utilisation de scanners Obligation de tester «à la main» L application ne renvoie pas toujours d informations à l attaquant (ex: blind SQL injection) Un scan de vulnérabilités peut se révéler lourd pour les applications Impact non négligeable sur les ressources (notamment les bases SQL) Un scan est parfois très long pour être exhaustif (activation des fonctions heuristiques) Un test en boîte noire est inadapté dans le cycle de développement Il est préférable de le mener juste avant la mise en production C est un peu tard 13
Les limites des tests de sécurité Les outils d analyse dynamique du flux de code applicatif sont plus pertinents dans le processus de développement 14
Choisir les outils et les processus pour une défense en profondeur Applications Web Autres Applications Politique de sécurité Middlewares Bases de données Systèmes d exploitation Autres Environnements Réseau, stockage Privilégier une approche «Data Centric» dans les contrôles Plus rapide, plus sûre (moins de faux-positifs) 15
Analyse du codeflow L exemple Seeker Analyse du code flow et du flux de données de l application lg = d*p#3$f pwd = quotium01 Fonction Authenticate (lg, pwd) { Vue utilisateur Analyseur lg = dana dynamique = quotium01 Fonction dologinpwd (lg, pwd) { Agent Console Seeker Seeker lg =pwd) d*p#3$f rt = Authenticate (lg, pwd = quotium01 if rt <> 0 { Mot de passe non encrypté en base de données XSS SQL Injection } else exit -1; } lg =from d*p#3$f Select login, passwd Authentication where login=lg and = pwd pwdpasswd = quotium01 //Authentication Succeed if.. { Agent.. Analyseur dynamique Seeker } else // Authentication failed; } Agent Seeker www.advens.fr Document confidentiel - Advens 2012 Agent Seeker Analyseur dynamique 16
Analyse du codeflow L exemple Seeker Analyse du code flow et du flux de données de l application 1 2 Construction d un arbre d attaque Exploitation de chaque faille potentielle Elimination des faux positifs Diminution importante des faux négatifs 17
Analyse du codeflow L exemple Seeker Visualisation de l exploitabilité de chaque vulnérabilité Seeker visualise le code où se trouve la faille sans disposer des fichiers sources. Avec une grande précision, Seeker détermine si une vulnérabilité est exploitable et où elle se trouve dans le code source sans avoir accès au code source pour conduire cette analyse. Joseph Feiman, Gartner 18
Analyse du code flow - avantages L analyse dynamique de l application (suivi du flux de code) est plus efficace Elle permet d identifier les risques suivants avec davantage de pertinence Persistent Cross Site Scripting Cross Site Request Forgery Problématiques sur la politique de mots de passe Mots de passe en clair dans les bases de données Contournement de l authentification Manipulation de paramètres Les outils d analyse dynamique s intègrent plus facilement dans les processus de développement Ils sont installés sur les environnements de développement / de test Ils «surveillent» l exécution du code et remontent les anomalies sans que le développeurs n aient besoin de s en soucier Le management peut piloter la réduction continue du nombre d alertes dans le temps 19
Analyse dynamique et SDLC: L exemple Seeker Posi#onnement de Seeker dans le SDLC Secure Development Life Cycle Concep'on QA Produc'on Durant la phase de développement Durant la phase d intégration Durant la phase de qualification 20
Outils et processus L exemple Seeker Développement QA Management Communication automatique avec les logiciels de contrôle qualité Tickets d incident documentés envoyés aux systèmes de gestion des incidents Reporting avancé mettant à disposition toutes les informations nécessaires à la prise de décision 21
Outils et processus L exemple Seeker Évolution dans le temps du niveau de sécurité de l application 22
Outils et processus L exemple Seeker Communication facilitée entre les différents acteurs Pour chaque risque du top 10 OWASP, Seeker indique le nombre de vulnérabilités et leur Nombre de vulnérabilités de sévérité. l application classées par criticité Nombre de pages vulnérables de l application classées par criticité 23
En synthèse La sécurité des applications doit être gérée de manière globale Analyser l application dans son architecture globale Ne pas se limiter aux portes d entrée Nécessité d analyser le code-flow et le data-flow La sécurité des applications doit se placer au cœur du cycle de développement Elle doit s intégrer le plus simplement possible et de la façon la plus transparente possible Elle doit pouvoir être portée par tous les acteurs (développement / sécurité / risk management) Cela nécessite une gestion du changement et un accompagnement adapté La prise en compte de la sécurité dans le cycle de développement va nécessiter : Une solution adaptée La mise à niveau des processus existants Une prise en compte progressive pour obtenir l adhésion de tous La sécurité est l affaire de tous et pas seulement de quelques spécialistes 24
Développer des applications Web sécurisées Questions? Jérémie Jourdin - jeremie.jourdin@advens.fr Advens www.advens.fr Frédéric Patouly - frederic.patouly@quotium.com www.quotium.com 25
MERCI DE VOTRE PARTICIPATION Téléchargez notre avis d expert : http://www.advens.fr/publications Retrouvez-nous sur LinkedIn : http://www.linkedin.com/company/advens Télécharger notre livre blanc sur la sécurité : http://www.quotium.fr/whitepaper_seeker.pdf Retrouvez Seeker en vidéo: http://www.quotium.fr/prod/video_seeker.php Juillet 2012 www.advens.fr Document confidentiel - Advens 2012