Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Secure Software
Develoment Life Cycle
(SSDLC)
Statistiques
 81% des entreprises françaises ont été visées par une cyberattaque en 2015
 80% des attaques viennent d’un...
Software Development Life Cycle
Définition du
besoin
Architecture Développement Test
Release
Maintenance
Software Development Life Cycle
Définition du
besoin
Architecture Développement Test
Release
Maintenance
- Pré-requis de s...
Prérequis : formation/sensibilisation
 Objectifs
 Connaître les différents types de vulnérabilités et les contremesures ...
Définition du besoin
Prérequis de sécurité
 Objectifs
 Définir les exigences de sécurité en fonction du contexte de l’ap...
Définition du besoin
Threat modeling
 Objectifs
 Penser à la sécurité avant de commencer à construire
 Identifier et cl...
Architecture
Revues d’architecture
 Objectif
 S’assurer que l’architecture proposée ne comporte pas de problème de sécur...
Développement
Secure Agile Development
 Abuse user story « Think as a bad guy »
 Entrées dans le backlog
 Exemple :
 E...
Développement
Revues de code
 Objectif
 Détecter des vulnérabilités et les défauts de logique
 Réalisés avec des person...
Développement
Analyse statique (SAST)
 Objectif
 Analyse du code source pour déceler de potentielles vulnérabilités
 In...
Développement
Analyse des dépendances
 Objectif
 Vérification des dépendances externes intégrées dans les projets avec u...
Test
Analyse dynamique (DAST)
 Objectif
 Analyse des requêtes/réponses à l’application
 Intérêts
 Simulation d’attaque...
Release/Maintenance
Configuration sécurisée
 Objectif
 Eviter les incidents de sécurité liés à la configuration
 Exempl...
Release/Maintenance
Plan de réponse à incident
 Objectifs
 Répondre aux incidents de sécurité dans le but de :
 Restaur...
Allez plus loin
Aller plus loin
OpenSAMM
 Objectifs
 Evaluer le niveau de maturité actuel
 Définir les objectifs
 Définir comment atte...
Aller plus loin
ASVS
 Objectifs
 Définir une liste d’exigences par domaine classée par niveaux de sécurité
 Usage
 Rev...
Aller plus loin
IAST et RASP
 IAST (Interactive Application Security Testing)
 Palier aux lacunes du SAST et DAST
 Anal...
Questions
?
Upcoming SlideShare
Loading in …5
×

Secure Software Development Life Cycle (SSDLC)

3,117 views

Published on

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.

Published in: Software
  • Be the first to comment

Secure Software Development Life Cycle (SSDLC)

  1. 1. Secure Software Develoment Life Cycle (SSDLC)
  2. 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. 3. Software Development Life Cycle Définition du besoin Architecture Développement Test Release Maintenance
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Allez plus loin
  17. 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. 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. 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. 20. Questions ?

×