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

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

Retour d'expérience

Agenda

Introduction

Notre contexte

L’(in)sécurité des applications web

Approche:

Méthode (analyse statique de code par un logiciel spécialisé) 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

Le contexte

Le contexte

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

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 (118712.fr) Régie publicitaire Assistance en ligne Boutiques

L’application maillon faible ?

Menaces & impacts Vulnérabilités

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

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)

Notre approche

Notre approche

Le constat initial

Analyses de code réalisées sans outils, en phase de recette

Rapport d’audit et correctifs

Mais … 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

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 ?

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)

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

Le projet de mise en œuvre

Le projet de mise en œuvre

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

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

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

Résultats (efficacité)

Overall Comparison

68

42 60

50 46

64 61

50 49 60 70 80

Overall Comparison (without Pixy tests)

74% 74%

57%

50% 45%

60%

70%

80%

Detected Vulnerabilities

Code exemple avec 110 vulnérabilités connues

Code exemple avec 58 tests

42

6 5

1 15

7 8

7 7

3 2 0 1

0 10 20 30 40

Sum True Positives Sum False Negatives Sum False Positives (total)

Sum False Positives (tests)

Sum False Positives (additionnal) CodeSecure SCA AppScan SE Pixy

0%

10%

20%

30%

40%

50%

CodeSecure SCA AppScan SE Pixy

Product

Detected Vulnerabilities

Attention : tout benchmark peut être biaisé (volontairement ou pas)

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

En pratique: Insertion dans le dispositif d’analyse continue

Checkout Scan & upload

Notifie

Auditeur

Notifie

Qualifie

Développeur

Consulte & modifie

Corrige

En pratique: à quelle occasion déclencher l’analyse ?

Spécifications

Conception Maintenance

Changement mineur

Evolution majeure (projet)

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é

Retour d’expérience

Retour d’expérience

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’interlocuteurentre sécurité et développeurs

Deux processus parallèles pour l’analyse récurrente

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

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

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

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

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

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); }

do_stuff($val); } else {

do_something_else($val); }

…

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

function lol($val) { echo ‘lol’; }

$func = $_GET[‘func’];

$func();

…

Les données définies à l’exécution ne peuvent être devinées

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

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 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…

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

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 »

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

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

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