Développement sécurisé

Réalisé par: Hicham
Sécurité par conception
Secure by Design
Agile, Scrum, DevOps,
Github

Agenda
Introduction
Sécurité Applicative
Cycle de vie de développement (SDLC)
Approches de développement sécurisé (SSDLC)
Démonstration (retour d’expérience)
Conclusion

Agenda
Introduction
Cycle de vie de développement (SLDC)
Conclusion

Introduction
 La sécurité applicative est au centre des nouvelles menaces et des
intrusions récentes. Souvent centrées sur la protection des
infrastructures, les équipes sécurité sont souvent trop éloignées des
problématiques applicatives.
 Les développeurs savent très bien coder mais sont moins
performants au niveau de la sécurité et inversement. Dans le but de
savoir si une application est sécurisée ou non et dans l’optique d’un
travail plus performant, il est important que ces 2 mondes
communiquent et échangent. Car le pire, c’est de ne pas savoir.
 Outre la sécurité de l’infrastructure, quelle est l’arme de défense
contre les menaces informatiques?
 Réponse :
la bonne conception du code source de l’application.
Voici, la sécurité applicative.

Un système est aussi sûr que son lien le plus
faible.

Agenda
Introduction
Cycle de vie de développement (SLDC)
Conclusion et perspectives

Qu’est ce que la sécurité applicative?
Sécurité applicative: (Définition selon ISO/IEC 27034:2011)
« La sécurité des applications est un processus effectué pour appliquer des
contrôles et des mesures aux applications d’une organisation afin de gérer
le risque de leur utilisation ».
« Les contrôles et les mesures peuvent être appliquées à l' application elle-
même (ses processus, les composants, les logiciels et résultats), à ses
données (données de configuration, les données de l'utilisateur, les
données de l'organisation), et à toutes les technologies, les processus et
acteurs impliqués dans le cycle de vie de l'application ».

Pourquoi des applications ? (menaces internes)
Réseaux
Serveurs
Application
DICT:
 Disponibilité
 Intégrité
 Confidentialité
 Traçabilité

Pourquoi des applications ? (menaces externes)

Le périmètre de sécurité du passé…
Autrefois:
• Sécurité physique et d’infrastructure autour des applications de missions
(internes)
• Utilisateurs internes, appareils internes sous le contrôle de l’organisation
Hier:
• Applications internes déployées sur le Web avec +/- les mêmes mesures
• Applications Web => accessibles de tous : usagers légitimes et pirates
informatiques
• Plusieurs applications développées par des développeurs qui en
connaissent peu sur la sécurité
 Perte d’étanchéité du périmètre… par les applications Web

Le nouveau périmètre
Aujourd’hui :
• Applications éparpillées sur le Cloud, chez plusieurs fournisseurs,
utilisent plusieurs librairies et API tiers,
• Les applications connectées sont partout: mobiles, voitures, « wearable
computers », domotique, appareils électroniques…
Où est le périmètre?
 La sécurité applicative devient le nouveau périmètre

Les niveaux de défense
Port blocking
Filtering
Encryption
Spoofed packets, etc.
Réseau
Défendre le réseau
Updates
IIS hardening
ACLs
CAS
Logging
Least privilege
Account
management
Buffer overflows, illicit paths, etc.
Machine
Défendre la machine
Validation
Hashing
Encryption
Secrets Mgt.
Cookie Mgt.
Session Mgt.
Error handling
SQL injection, XSS, input tampering, etc.
Application
Défendre l’application

Menaces applicatives (OWASP TOP TEN – 2017)
A1 - Injection
A2 - Violation de
Gestion
d'Authentification
et de Session
A3 - Cross-Site
Scripting (XSS)
A4 - Références
directes non
sécurisées à un
objet
A5 – Mauvaise
configuration
Sécurité
A6 – Exposition de
données sensibles
A7 – Manque de
contrôle d’accès
au niveau
fonctionnel
A8 - Falsification
de requête
intersite(CSRF)
A9 - Utilisation de
composants avec
des vulnérabilités
connues
A10 –
Redirections et
renvois non
validés
OWASP (Open Web Application Security Project): Organisation mondiale à but non lucratif
http://www.owasp.org
Son rôle : sensibiliser à la sécurité applicative pour aider à prendre les bonnes décisions en
matière de sécurité des applications

Comment trouver les vulnérabilités avant les pirates?
- Faire plus de balayages de
vulnérabilités?
- Faire davantage de tests
d’intrusion?
- Faire des révisions de code!

Intégrer la sécurité plus tôt dans le cycle de
développement
Observation:
Les coûts reliés aux corrections des risques de
sécurité augmentent de façon exponentiel
quand les corrections sont découvertes
tardivement dans le cycle de développement…
Évidence:
Prise en charge des enjeux de sécurité tout au
long du cycle de développement
Approche prôné par OWASP, NIST, Microsoft et
plusieurs autres organisations

Aux vulnérabilités applicatives…
ça prend des mesures applicatives!

Agenda
Introduction
Cycle de vie de développement (SDLC)
Conclusion et perspectives

Le cycle de de vie du développement
SDLC (Software Development Life Cycle)
Le « cycle de vie d'un logiciel », désigne toutes les étapes du
développement d'un logiciel, de sa conception à sa disparition. L'objectif
d'un tel découpage est de permettre de définir des jalons intermédiaires
permettant la validation du développement logiciel, c'est-à-dire la
conformité du logiciel avec les besoins exprimés, et la vérification du
processus de développement, c'est-à-dire l'adéquation des méthodes mises
en œuvre.
MaintenanceDéploiementTestDéveloppementArchitecture
et conception
Définition
du besoin

Modèles classiques de cycle de développement
Modèle en Y
Modèle en VModèle en cascade
Modèle en spirale

Méthodes de développement Agiles

Exemples de méthodes Agiles
SCRUM XP
(Extreme Programming)

DevOps
Développeurs Opérationnels
DevOps est une méthode de développement logiciel qui met
en avant la communication, la collaboration, l’intégration,
l’automatisation et les métriques entre développeurs et
opérationnels.

Qu’est-ce que le SSDLC?
Le SSDLC est l’acronyme pour le « Secure Software Develpment Life
Cycle ». C’est un processus continu contenant différents axes et étapes
permettant d’assurer et augmenter le niveau de sécurité d’une
application.
Dans le SSDLC, les tests de sécurité sont effectués tout au long du
processus de développement.

Framework SSDLC
 Microsoft SDL
 OWASP
OpenSAMM BSIMM
 Cigital Touchpoints
Norme: ISO/IEC
27034:2011

Processus du cycle de développement de la sécurité
Formation Exigences Conception Implémentation Test
Déploiement
et
Maintenance
• Formation de
base et
sensibilisationà
la sécurité
• Pré-requis de
sécurité
• Modélisation
des menaces
• Revues de
conception
• Modélisation
des menaces
• Revues de
code
• SAST
• Analyse des
dépendances
• DAST • Configuration
sécurisée
• Plan de
réponse à
incident

Phase préliminaire : Formation et Sensibilisation
Déploiement
et
Maintenance
Conception sécurisée
Tests de la sécurité
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é.
- Guides de l’OWASP
- Top 10 OWASP
Écriture de code sécurisé
Modélisation des menaces

Phase 1 : Exigences
Formation Exigences Conception Implémentation Vérification Réponse
Objectif 1:Prérequis de sécurité
Définir les exigences de sécurité en fonction du
contexte de l’application
L’application traite-elle de données sensibles
(militaire, médicale, etc.) ?
L’application est-elle exposée publiquement ?
Exigences DICT
Objectif 2 : Modélisation des menaces
Identifier et classer les potentielles menaces en
analysant l’architecture et les fonctionnalités de
l’application
Identification des dépendances
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
Définir la stratégie à appliquer

Phase 2 : Conception
Formation Exigences Conception Implémentation Vérification Réponse
Objectif :Prérequis de sécurité
S’assurer que l’architecture proposée ne
comporte pas de problème de sécurité
Protocoles sécurisés
Méthode
d’authentification/autorisation
Mécanisme de gestion des logs
Séparation des composants
Flux nécessaires

Phase 3 : Implémentation
Déploiement
et
Maintenance
SAST
Analyse statique
Standards utilisés :
TOP 10 OWASP, SANS Top 25,
guidelines PCI DSS, HIPAA
Outils :
VeraCode, Checkmarx,
WhiteHatSecurity, IBM
AppScan
Revues de code
OWASP Code Review Guide
Analyse des
dépendances
Outils:
Nexus
DependencyCheck (OWASP)
WhiteHatSecurity
Jenkins

Phase 4 : Test
Déploiement
et
Maintenance
DAST
Analyse dynamique
Analyse des requêtes/réponses
à l’application
TOP 10 OWASP, SANS Top 25,
guidelines PCI DSS, HIPAA
Outils :
VeraCode, Arachni, IBM
AppScan , miniFuzz,
AppVerifier, BinScop

5- Phase de déploiement et maintenance
Déploiement
et
Maintenance
Configuration sécurisée
Objectif :
Eviter les incidents de sécurité liés à la
configuration
Contremesures:
Déploiement automatisé
Checklist de vérification
Plan de réponse à incident
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

Agenda
Introduction
Cycle de vie de développement logiciel (SDLC)
Conclusion

Développement sécurisé

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Développement sécurisé

Similaire à Développement sécurisé (20)

Développement sécurisé