Présentation sur le cycle de vie du Secure Software Development Life Cycle (SSDLC). Threat modeling, revue d'architecture, analyse statique, analyse dynaique, OWASP ASVS, OpenSAMM, etc.

1. Secure Software
Develoment Life Cycle
(SSDLC)

2. Statistiques
 81% des entreprises françaises ont été visées par une cyberattaque en 2015
 80% des attaques viennent d’une vulnérabilité logicielle (Gartner) (versus infrastructure)
 10% des applications ont des mots de passe hardcodés
 95% des applications contiennent des dépendances open source, 65% contiennent des dépendances
vulnérables
 90% des applications web sont vulnérables à cause de fonction de sécurité (hash, authentification,
etc.)

3. Software Development Life Cycle
Définition du
besoin
Architecture Développement Test
Release
Maintenance

4. Software Development Life Cycle
Définition du
besoin
Architecture Développement Test
Release
Maintenance
- Pré-requis de sécurité
- Threat modeling
- Abuse user stories
- Revues d’architecture
- Threat modeling
- Revues de code
- SAST
- DAST
- Analyse des
dépendances
- Abuse user stories
- Pentesting
- Vérification des pré-
requis de sécurité
- Abuse user stories
- Configuration sécurisée
- Plan de réponse à
incident

5. Prérequis : formation/sensibilisation
 Objectifs
 Connaître les différents types de vulnérabilités et les contremesures associées
 Comprendre l’enjeux de la sécurité
 Connaître les bonnes pratiques de sécurité
 Ressources
 Guides de l’OWASP
 https://www.owasp.org/index.php/OWASP_Guide_Project
 OWASP Top 10
 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
 Cheatsheets
 https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
 Cornucopia
 https://www.owasp.org/index.php/OWASP_Cornucopia

6. Définition du besoin
Prérequis de sécurité
 Objectifs
 Définir les exigences de sécurité en fonction du contexte de l’application
 Exemples
 L’application traite-elle de données sensibles (médicales, bancaires, etc.) ?
 L’application est-elle exposée publiquement ?
 Exigences DICT

7. Définition du besoin
Threat modeling
 Objectifs
 Penser à la sécurité avant de commencer à construire
 Identifier et classer les potentielles menaces en analysant l’architecture et les fonctionnalités de l’application
 Contenu
 Identification des dépendances
 Identification des points d’entrée/sortie de l’application
 Identifier les ressources intéressantes pour un attaquant
 Identifier les différents types d’utilisateurs et rôles
 Catégoriser les menaces
 Lister les contrôles à mettre en place
 Lister les menaces potentielles
 Prioriser les menaces
 Définir la stratégie à appliquer

8. Architecture
Revues d’architecture
 Objectif
 S’assurer que l’architecture proposée ne comporte pas de problème de sécurité
 Exemple
 Protocoles sécurisés (ex : HTTPS)
 Méthode d’authentification/autorisation
 Mécanisme de gestion des logs
 Séparation des composants
 Flux nécessaires

9. Développement
Secure Agile Development
 Abuse user story « Think as a bad guy »
 Entrées dans le backlog
 Exemple :
 En tant qu’utilisateur authentifié, j’identifie mon numéro de compte dans l’URL et je le change pour voir le
résultat
 En tant qu’utilisateur authentifié, je colle du HTML contenant du javascript dans tous les champs de
formulaire pour voir comment se comporte l’application
 Itérations dédiées à la refactorisation/sécurité (You ain’t gonna need it)

10. Développement
Revues de code
 Objectif
 Détecter des vulnérabilités et les défauts de logique
 Réalisés avec des personnes sensibilisées à la sécurité et connaissant le fonctionnel de l’application
 OWASP Code Review Guide 2.0
 https://www.owasp.org/images/5/53/OWASP_Code_Review_Guide_v2.pdf
 ”The code is your only advantage over the hackers. Don’t give up this advantage and rely only on
external penetration testing. Use the code.” par Jeff Williams

11. Développement
Analyse statique (SAST)
 Objectif
 Analyse du code source pour déceler de potentielles vulnérabilités
 Intérêts
 Découvrir les vulnérabilités le plus tôt possible dans le SDLC
 Encourager la pratique de développement sécurisé
 Standards utilisés
 TOP 10 OWASP, SANS Top 25, guidelines PCI DSS, HIPAA
 Intégration dans les IDEs, les outils d’IC et les Bug trackers
 Outils
 VeraCode, Checkmarx, WhiteHatSecurity, IBM AppScan
 Agrégation de résultats : ThreadFix, CodeDx

12. Développement
Analyse des dépendances
 Objectif
 Vérification des dépendances externes intégrées dans les projets avec une base de vulnérabilités
connues
 Outils
 Nexus
 DependencyCheck (OWASP)
 WhiteHatSecurity
 Intégration dans les outils d’intégration continue type Jenkins

13. Test
Analyse dynamique (DAST)
 Objectif
 Analyse des requêtes/réponses à l’application
 Intérêts
 Simulation d’attaques réelles
 Moins de faux positifs
 Pas d’explication sur la root cause du problème
 Standards utilisés
 TOP 10 OWASP, SANS Top 25, guidelines PCI DSS, HIPAA
 Intégration dans les IDEs et dans les outils d’intégration continue type Jenkins
 Outils
 VeraCode, Arachni, IBM AppScan
 Intrusif, environnement dédié ou restaurable automatiquement

14. Release/Maintenance
Configuration sécurisée
 Objectif
 Eviter les incidents de sécurité liés à la configuration
 Exemples
 Mode debug resté activé
 Utilisation de protocoles obsolètes (ex : SSLv3)
 Version de framework dans les headers HTTP
 Contremesures
 Déploiement automatisé
 Checklist de vérification

15. Release/Maintenance
Plan de réponse à incident
 Objectifs
 Répondre aux incidents de sécurité dans le but de :
 Restaurer les services
 Minimiser les pertes
 Colmater les failles exploitées
 Réduire les risques qui pourraient survenir dans le futur
 Contenu
 Rôles et responsabilités de chacun
 Actions immédiates en cas d’incident
 Investigation en cas d’incident
 Restauration des ressources affectées
 Rapport sur l’incident survenu

16. Allez plus loin

17. Aller plus loin
OpenSAMM
 Objectifs
 Evaluer le niveau de maturité actuel
 Définir les objectifs
 Définir comment atteindre ces objectifs
 Proposer des conseils d’implémentation
Définition
 Définir 3 niveaux de maturités dans 4 domaines et 12 sous-domaines :
 La gouvernance (stratégie et métriques, éducation et conseil, politique et conformité)
 La construction (prérequis de sécurité, architecture sécurisée, évaluation des risques)
 La vérification (revues de code, revue de conception, tests de sécurité)
 Le déploiement (durcissement, gestion des vulnérabilités, habilitation opérationnelle)

18. Aller plus loin
ASVS
 Objectifs
 Définir une liste d’exigences par domaine classée par niveaux de sécurité
 Usage
 Revue de la sécurité d’une application
 Guide pour un pentest

19. Aller plus loin
IAST et RASP
 IAST (Interactive Application Security Testing)
 Palier aux lacunes du SAST et DAST
 Analyse au runtime de l’application
 Utilisé en environnement de tests
 RASP (Runtime Application Self Protection)
 Palier aux erreurs de développement et aux équipement périmétriques
 Basé sur de l’apprentissage
 IAST et RASP sont basés sur des librairies embarquées dans les applications
 Impacts sur les performances

20. Questions
?