Analyse statique de code dans un cycle de développement Web Retour d'expérience

Transcription

1 Analyse statique de code dans un cycle de développement Web Retour d'expérience Laurent Butti et Olivier Moretti Orange France

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 2

3 Le contexte 3

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 Plusieurs dizaines de millions de visites et de pages vues chaque mois En charge du portail orange.fr Services aux clients Orange (mail, factures ) Moteur de recherche Annuaire ( fr) Régie publicitaire Assistance en ligne Boutiques 4

5 L application maillon faible? Vulnérabilités Menaces & impacts Le vol de données est très médiatisé Les grandes organisations sont des cibles de choix Cf. Les outils «script kiddies» sont légion Vecteurs d attaques La sécurité n est pas native dans les pratiques de développement 5

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) 6

7 Notre approche 7

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 8

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) 9

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 10

11 Le projet de mise en œuvre 11

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 12

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 13

14 Résultats (efficacité) Code exemple avec 110 vulnérabilités connues Code exemple avec 58 tests Overall Comparison Sum True Positives Sum False Negatives Sum False Positives (total) Sum False Positives (tests) Sum False Positives (additionnal) Detected Vulnerabilities 80% 70% 60% 50% 40% 30% 20% 10% 0% Overall Comparison (without Pixy tests) 74% 74% 57% 45% CodeSecure SCA AppScan SE Pixy Product CodeSecure SCA AppScan SE Pixy Attention : tout benchmark peut être biaisé (volontairement ou pas) 14

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) 15

16 En pratique: Insertion dans le dispositif d analyse continue Checkout Scan & upload Auditeur Notifie Corrige Développeur Consulte & modifie Qualifie 16

17 En pratique: à quelle occasion déclencher l analyse? Changement mineur Spécifications Maintenance Conception Evolution majeure (projet) Test et recette Développement 17

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é 18

19 Retour d expérience 19

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 20

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 21

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 22

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) 23

24 Valeur ajoutée : Généralisation du déploiement Volume de code analysable Application PHP LOC : 5 minutes (mono-cœur, 2Go RAM) Application C/C 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 24

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) { else { do_stuff($val); } do_something_else($val); } L outil ne peut préjuger si le contrôle effectué est adapté au contexte 25

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 26

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 27

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 28

29 La question des faux négatifs et des faux positifs Faux négatifs Faux sentiment de sécurité Manques dans le support du langage par l outil Limites intrinsèques de l analyse statique Faux positifs Mauvais ressenti Pénibilité de l analyse Difficulté accrue pour déléguerl analyse aux équipes de développement Réduction des faux négatifs Identification des bugs / manques et rapports vers l éditeur pour correctifs Développement de règles personnalisées Réduction des faux positifs Identification des bugs / manques et rapports vers l éditeur pour correctifs Marquage des faux positifs - Expérience de l auditeur 29

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 L outil suit une logique de Dataflow, vs lecture de code simple 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! 30

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 31