GS Days 2012 - Analyse statique de code dans un cycle de développement Web (retour d'expérience)

Transcript

1. Laurent Butti et Olivier Moretti – Orange France prenom.nom@orange.com Analyse statique de code dans un cycle de développement Web Retour d'expérience GS Days 2012 Diffusion Libre France Telecom – Orange
2. 2 Agenda  Introduction  Notre contexte  L’(in)sécurité des applications web  Approche: Insérer un jalon d’analyse statique de code dans le cycle de développement  Les objectifs et les enjeux  Méthode (analyse statique de code par un logiciel spécialisé)  Projet de mise en œuvre  Évaluation et choix d’une solution technique  Comparatif et choix de la solution  Mise en œuvre  Bénéfices et capitalisation… et imprévus !  Les facteurs clés de succès  Les écueils à éviter GS Days 2012 Diffusion Libre France Telecom – Orange
3. 3 Le contexte GS Days 2012 Diffusion Libre France Telecom – Orange
4. 4 Notre domaine  Orange Portails, une entité d’Orange France  Hébergement multi-site de services Web  Développement d’applications Web et mobile  Évolutions fréquentes  Nombreuses applications à développer de manière sûre  Plusieurs dizaines d’audits par an  En charge du portail orange.fr  Services aux clients Orange (mail, factures…)  Moteur de recherche  Annuaire (118712.fr)  Régie publicitaire  Assistance en ligne  Boutiques Plusieurs dizaines de millions de visites et de pages vues chaque mois GS Days 2012 Diffusion Libre France Telecom – Orange
5. 5 L’application maillon faible ? Menaces & impacts Le vol de données est très médiatisé Les grandes organisations sont des cibles de choix Cf. http://datalossdb.org Les outils « script kiddies » sont légion Vecteurs d’attaques La sécurité n’est pas native dans les pratiques de développement Vulnérabilités GS Days 2012 Diffusion Libre France Telecom – Orange
6. 6 Pas encore convaincus ?  Les Applications Web sont la cible #1 des pirates  75% des attaques concernent la couche application (Gartner)  XSS et SQL Injection : #1 et #2 des vulnérabilités dans le top 10 OWASP  La plupart des sites sont vulnérables  90% des sites sont vulnérables aux attaques d'application (Watchfire)  99% des sites ne sont pas conformes PCI DSS (WASC)  78% d'applications Web affectées de vulnérabilités exploitables (Symantec)  80% des organisations auront un incident de sécurité d'application d'ici 2010 (Gartner) GS Days 2012 Diffusion Libre France Telecom – Orange
7. 7 Notre approche GS Days 2012 Diffusion Libre France Telecom – Orange
8. 8 Le constat initial  Analyses de code réalisées sans outils, en phase de recette  Rapport d’audit et correctifs  Mais …  L’auditeur échantillonne : il n’audite pas l’ensemble du code  Les applications ne sont pas toutes auditées et pas à chaque changement  L’audit n’est pas réalisé lors d’évolutions mineures du code (hors projet)  Peu de capitalisation d’un audit à l’autre et le suivi des correctifs est fastidieux GS Days 2012 Diffusion Libre France Telecom – Orange
9. 9 Notre réponse : Systématiser l’analyse statique de code  Comment ? Outils et processus sont complémentaires  Analyse de code statique dans le cycle de développement  Via un outil d’analyse boite blanche adapté à nos besoins  Dans quel but ?  Déclencher des analyses à chaque changement  Couvrir potentiellement tous les projets (pas de limite)  Systématiser le suivi des vulnérabilités  Responsabiliser et faire progresser les développeurs (s’auto auditer) GS Days 2012 Diffusion Libre France Telecom – Orange
10. 10 Ce qui n’exclut pas  Une post-analyse par l’auditeur sécurité  Faux positifs, sévérité des failles…  La recherche de failles fonctionnelles (e.g. absence de Captcha sur un formulaire)  L’analyse du comportement dynamique de l’application  Pen-test, fuzzing GS Days 2012 Diffusion Libre France Telecom – Orange
11. 11 Le projet de mise en œuvre GS Days 2012 Diffusion Libre France Telecom – Orange
12. 12 Etude préliminaire de solutions, puis mise en œuvre  Sélection de l’outil d’analyse statique  Cahier des charges  Benchmark de solutions Open source et commerciales  Sélection de la solution la plus appropriée  Convaincre le management   Installation et utilisation  Installation initiale dans la chaine d’intégration continue  Technique et organisation  Analyse des applications  Intégration des applications réparties par projet  Lancement des analyses par l’outil  Traitement des vulnérabilités GS Days 2012 Diffusion Libre France Telecom – Orange
13. 13 Sélection de la solution d’analyse de code 1. Cahier des charges  Intégration avec les outils internes (intégration continue, bug tracking, …)  Intégration avec les processus existants  Support impératif de PHP (C/C++ et Java en priorité plus basse)  Taux de Faux Positifs / Faux Négatifs  Coûts acquisition, intégration et de fonctionnement 2. Benchmark : 3 produits leaders du Magic Quadrant et une solution Open Source  Pixy (Open Source)  Source Code Analyzer édité par Fortify  AppScan Source Edition (ex-Ounce Labs) édité par IBM  Armorize édité par CodeSecure 3. Méthodologie d’étude  Évaluation des produits (sur du code vulnérable et code réel)  Demandes de proposition commerciales « sur mesure »  Analyses et débriefing avec les éditeurs GS Days 2012 Diffusion Libre France Telecom – Orange
14. 14 Résultats (efficacité) GS Days 2012 Diffusion Libre France Telecom – Orange Overall Comparison 68 42 6 5 1 60 50 15 7 8 46 64 7 7 0 61 49 3 2 1 0 10 20 30 40 50 60 70 80 Sum True Positives Sum False Negatives Sum False Positives (total) Sum False Positives (tests) Sum False Positives (additionnal) CodeSecure SCA AppScan SE Pixy Overall Comparison (without Pixy tests) 74% 74% 57% 45% 0% 10% 20% 30% 40% 50% 60% 70% 80% CodeSecure SCA AppScan SE Pixy Product Detected Vulnerabilities  Code exemple avec 110 vulnérabilités connues  Code exemple avec 58 tests  Attention : tout benchmark peut être biaisé (volontairement ou pas)
15. 15 Les arguments pour convaincre le management  Réduction des coûts à périmètre constant d’audits  Réduction du nombre d'incidents  Gain de temps net pour les auditeurs sécurité (lié à l’automatisation)  Correctifs : le plus tôt est le mieux !  Contexte commercial et légal  Conformité PCI/DSS  Directives européennes (Paquet Télécom) GS Days 2012 Diffusion Libre France Telecom – Orange
16. 16 En pratique: Insertion dans le dispositif d’analyse continue Checkout Scan & upload Notifie Qualifie Auditeur Développeur Consulte & modifie Corrige GS Days 2012 Diffusion Libre France Telecom – Orange
17. 17 En pratique: à quelle occasion déclencher l’analyse ? Spécifications Conception Développement Test et recette Maintenance Changement mineur Evolution majeure (projet) GS Days 2012 Diffusion Libre France Telecom – Orange
18. 18 Généralisation : choix des applications à analyser  Cible prioritaire : les applications web et mobile « user facing »  Traitement d’entrées utilisateur (directes ou indirectes)  Phase de sélection par l’intermédiaire de critères  Business  Sensibilité et exposition de l’application  Techniques  Capacité de l’outil à être efficace sur le code audité GS Days 2012 Diffusion Libre France Telecom – Orange
19. 19 Retour d’expérience GS Days 2012 Diffusion Libre France Telecom – Orange
20. 20 Organisation : Des acteurs et des processus clés  Les responsables d’application  Sur un portefeuille d’applications ils s’assurent de :  L’insertion de l’analyse statique de code dans leur cycle de développement  La correction des vulnérabilités avant passage en production  La gestion des accès des développeurs aux résultats des scans  Rôle crucial d’interlocuteur entre sécurité et développeurs  Deux processus parallèles pour l’analyse récurrente  Approche opportuniste  Déclenchement automatique de l’analyse statique à chaque changement  Avertissement par l’outil des failles découvertes vers l’équipe sécurité ET  Approche projet  Déclenchement de l’analyse par le responsable d’application  Mise en œuvre de l’analyse des résultats dans le contexte projet GS Days 2012 Diffusion Libre France Telecom – Orange
21. 21 Organisation : La relation et le rôle des développeurs  Traitement des évolutions et correctifs différente selon les équipes  Bug-tracking, politique de gestion de versions…  Pas de mode imposé de communication avec les équipes de développement  Via interface client lourd ou Web d’analyse des résultats  Via rapport d’audit généré par l’auditeur avec l’outil  Via échanges mail, téléphone ou réunion physique  Après une période suffisante d’apprentissage  Les développeurs s’auto-auditent localement pendant leurs développements (plugin)  Gain de temps  Adapté aux méthodes d’intégration continue GS Days 2012 Diffusion Libre France Telecom – Orange
22. 22 Organisation : Conseils et synthèse  Processus parallèles : meilleure couverture grâce à cette approche combinée  Limiter les tâches manuelles pour fluidifier les rouages  Ne confier / déléguer l’outil qu’après une période d’apprentissage  L’outil et les nouveaux processus doivent s’intégrer aux outils et processus existants GS Days 2012 Diffusion Libre France Telecom – Orange
23. 23 Valeur ajoutée : Calcul automatique d’indicateurs  Les indicateurs ne doivent pas se reposer sur les résultats « bruts » du scan  Éliminer les faux positifs  Apprécier la sévérité en fonction du contexte (non réalisable par un outil)  Différentes audiences, différents indicateurs  Responsables d’application & développeurs  Évaluation de la charge de travail associée au nombre de correctifs à mettre en œuvre  Tendances d’évolution par familles de vulnérabilité  Management  Évaluation du niveau de risque courant  Conformité (PCI DSS par exemple)  Experts sécurité  Ratio de « Not an Issue » à l’issue d’un scan  Conformité aux standards (TOP 10 OWASP) GS Days 2012 Diffusion Libre France Telecom – Orange
24. 24 Valeur ajoutée : Généralisation du déploiement  Volume de code analysable  Application PHP 16.000 LOC : 5 minutes (mono-cœur, 2Go RAM)  Application C/C++ 110.000 LOC : 1h30 (mono-cœur, 2 Go RAM)  L’auditeur passe 1 journée pour analyse des résultats  L’auditeur passe habituellement 1 semaine pour un audit applicatif  Capitalisation des audits  Élimination des faux positifs marqués à l’audit précédent  Gain de temps pour l’auditeur qui se concentre sur les nouveaux résultats GS Days 2012 Diffusion Libre France Telecom – Orange
25. 25 Les limites intrinsèques de l’analyse statique Exemple 1 : pas de notion de contexte <?php $val = $_GET*‘val’+; if (preg_match(‘/^*A-Za-z0-9_++$/’, $val) , do_stuff($val); } else { do_something_else($val); } …  L’outil ne peut préjuger si le contrôle effectué est adapté au contexte GS Days 2012 Diffusion Libre France Telecom – Orange
26. 26 Les limites intrinsèques de l’analyse statique Exemple 2 : pas de connaissance des données définies à l’exécution <?php function kikoo($val) { echo $_GET*‘val’+; - function lol($val) { echo ‘lol’; - $func = $_GET*‘func’+; $func(); …  Les données définies à l’exécution ne peuvent être devinées GS Days 2012 Diffusion Libre France Telecom – Orange
27. 27 Valeur ajoutée et limites : Conseils et synthèse  Connaître et maitriser les limites de l’analyse statique et de vos outils  Les résultats d’un scan automatique doivent être analysés pour être pertinents  La généralisation du déploiement nécessite réflexion et organisation GS Days 2012 Diffusion Libre France Telecom – Orange
28. 28 Quelques imprévus  Support avancé mais incomplet de PHP objet  Héritage non supporté  Pas de support d’applications basées sur Zend  Chargement dynamique de classes  Calcul de la priorité associée aux vulnérabilités « codée en dur »  Pas de prise en compte du contexte : problématique car tout est basé là- dessus  Priorité des correctifs, modèle de rapport d’audit , indicateurs, communication au management… GS Days 2012 Diffusion Libre France Telecom – Orange
29. 29 La question des faux négatifs et des faux positifs Faux négatifs Faux positifs Faux sentiment de sécurité Mauvais ressenti Manques dans le support du langage par l’outil Pénibilité de l’analyse Limites intrinsèques de l’analyse statique Difficulté accrue pour déléguer l’analyse aux équipes de développement Réduction des faux négatifs Réduction des faux positifs Identification des bugs / manques et rapports vers l’éditeur pour correctifs Identification des bugs / manques et rapports vers l’éditeur pour correctifs Développement de règles personnalisées Marquage des faux positifs - Expérience de l’auditeur GS Days 2012 Diffusion Libre France Telecom – Orange
30. 30 En synthèse  Impossibilité de trouver toutes les failles, mais :  Une bonne partie des failles d’implémentation le sont !  Aiguille l’auditeur vers des parties de code « suspectes »  L’outil est systématique, l’auditeur est sélectif  Effets « vertueux »  Responsabilisation des développeurs (audits récurrents)  Indicateurs marquants et factuels (visibilité)  Capitalisation des résultats (suivi)  Communication vers les équipes et la hiérarchie  Convaincre de la valeur ajoutée de l’approche et de l’outil  Complémentaire des audits manuels, mais ne les remplace pas ! GS Days 2012 Diffusion Libre France Telecom – Orange
31. 31 Conclusions  Automatiser, automatiser, automatiser !  Un bon outil d’analyse statique  augmente l’efficacité et la couverture de l’audit boite blanche  complète bien la lecture de code réalisée par un auditeur  prouve son efficacité et sa complémentarité avec les outils de pen-test  Mais tout n’est pas qu’une affaire d’outils  « Security is a Process, not a Product » (B. Schneier)  Les audits doivent être programmés dans le cycle de développement  Capitaliser les résultats des audits précédents  Institutionnaliser les audits à chaque changement Les outils d’analyse de code source bien qu’ imparfaits ont prouvé leur nécessité Leur valeur ajoutée réside dans leur usage systématique et récurrent dans un SDLC GS Days 2012 Diffusion Libre France Telecom – Orange