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.
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
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
Définition : process définissant toutes les étapes de réalisation d’un logiciel dans le but de construire des applications de qualité
Agile ou non on retrouve toujours globalement ces étapes de manière itérative ou sequenciel
Dépendances externes (OS, SGBD, WAF, etc.)
Identifier les points d’entrée/sortie de l’application et les autorisations nécessaires pour y accéder
Identifier les ressources intéressantes pour un attaquant :
ressources physique (ex : données)
ressources abstraites (ex : possibilité de données des droits à un utilisateurs
Identifier les différents rôles présents sur l’application (anonyme, utilisateur authentifié, utilisateur de la base de données, etc.)
Réaliser les diagrammes de data flow (DFD)
Etablir une catégorisation des menaces:
ex : STRIDE : Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
Lister les contrôles de sécurité à mettre en place
Listing des menaces possibles
Priorisation les menaces
Listing des contremesures par catégorie
Définir la stratégie appliquée par contremesure (acceptation, correction, transfer à un tier, etc.)
http://www.veracode.com/solutions/by-need/streamlining-compliance
https://www.checkmarx.com/2015/04/29/sast-vs-dast-why-sast-3/
Build failed si vulnérabilité high ou medium détectées
http://www.veracode.com/solutions/by-need/streamlining-compliance
https://www.checkmarx.com/2015/04/29/sast-vs-dast-why-sast-3/
Build failed si vulnérabilité high ou medium détectées
https://www.owasp.org/images/9/92/Top10ConsiderationsForIncidentResponse.pdf
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Security_Guide/s1-response-plan.html
PCA : assurer que ca continue de fonctionner
PRA : indique comment remettre tout sur les rails
Exemple : formation :
Level 1 : mettre à disposition de la documentation
Level 2 : former les collaborateurs
Level 3 : prouver que les collaborateurs sont formés
Etapes :
Préparer (définition du périmètre, des parties prenantes, etc.)
Evaluer (Lister les pratiques courantes et définir le niveau de maturité)
Définir les objectifs (et lister les impacts)
Définir le plan (Planning)
Implémenter
Deployer (évangéliser, mesurer l’efficacité)
Liens : https://github.com/OWASP/samm/tree/master/v1.5/Final
ASVS : Application Security Verification Standard
Utilisation
Guide lors d’un pentest
Checklist de vérification
Exemples : communication sécurisées
1 => toutes les communications sont en https
2 => interactions externes sont authentifiées
3 => toutes les connexions tls failed sont loggées