Sécurité par conception

Secure by Design
Agile, Scrum, DevOps,
Github

Réalisé par: Hicham

 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
Sécurité Applicative
Cycle de vie de développement (SLDC)
Approches de développement sécurisé (SSDLC)
Démonstration (retour d’expérience)
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
Sécurité Applicative
Cycle de vie de développement (SLDC)
Approches de développement sécurisé (SSDLC)
Démonstration (retour d’expérience)
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 ».
Quelques statistiques
Pourquoi des applications ? (menaces internes)
DICT:
 Disponibilité
Réseaux
 Intégrité
 Confidentialité
 Traçabilité Serveurs

Application
Pourquoi des applications ? (menaces externes)
Le périmètre de sécurité
Le périmètre de sécurité
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

Réseau Machine Application

Port blocking Updates Validation
Filtering IIS hardening Hashing
Encryption ACLs Encryption
CAS Secrets Mgt.
Défendre le réseau Logging Cookie Mgt.
Least privilege Session Mgt.
Account Error handling
Spoofed packets, etc. management

Défendre la machine
Buffer overflows, illicit paths, etc.

Défendre l’application
SQL injection, XSS, input tampering, etc.
Menaces applicatives (OWASP TOP TEN – 2017)

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

A2 - Violation de A4 - Références
Gestion A3 - Cross-Site directes non
A1 - Injection
d'Authentification Scripting (XSS) sécurisées à un
et de Session objet

A7 – Manque de
A5 – Mauvaise A8 - Falsification
A6 – Exposition de contrôle d’accès
configuration de requête
données sensibles au niveau
Sécurité intersite(CSRF)
fonctionnel

A9 - Utilisation de A10 –
composants avec Redirections et
des vulnérabilités renvois non
connues validés
Quelques faits
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
Sécurité Applicative
Cycle de vie de développement (SDLC)
Approches de développement sécurisé (SSDLC)
Démonstration (retour d’expérience)
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.

Définition Architecture Développement Test Déploiement Maintenance

du besoin et conception
Modèles classiques de cycle de développement

Modèle en cascade Modèle en V

Modèle en spirale Modèle en Y

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.
DevOps Outils
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 et perspectives
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

 Cigital Touchpoints
Norme: ISO/IEC
27034:2011

 OWASP
 BSIMM OpenSAMM
Processus du cycle de développement de la sécurité

Déploiement
Formation Exigences Conception Implémentation Test et
Maintenance

• Formation de • Pré-requis de • Revues de • Revues de • DAST • Configuration

base et sécurité conception code sécurisée
sensibilisationà • Modélisation • Modélisation • SAST • Plan de
la sécurité des menaces des menaces • Analyse des réponse à
dépendances incident
Phase préliminaire : Formation et Sensibilisation

Déploiement
Formation Exigences Conception Implémentation Test et
Maintenance

Objectifs:
 Connaître les différents types de vulnérabilités Conception sécurisée
et les contremesures associées, Modélisation des menaces
 Comprendre l’enjeux de la sécurité,
Tests de la sécurité
 Connaître les bonnes pratiques de sécurité.
Écriture de code sécurisé

- Guides de l’OWASP
- Top 10 OWASP
Phase 1 : Exigences

Formation Exigences Conception Implémentation Vérification Réponse

Objectif 2 : Modélisation des menaces

Objectif 1:Prérequis de sécurité

Identifier et classer les potentielles menaces en

Définir les exigences de sécurité en fonction du
analysant l’architecture et les fonctionnalités de
contexte de l’application
l’application
Identification des dépendances
L’application traite-elle de données sensibles
(militaire, médicale, etc.) ? Identifier les ressources intéressantes pour
un attaquant
Identifier les différents types d’utilisateurs
et rôles
L’application est-elle exposée publiquement ? Catégoriser les menaces

Lister les contrôles à mettre en place

Exigences DICT 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
Formation Exigences Conception Implémentation Test et
Maintenance

SAST Analyse des

Revues de code
Analyse statique dépendances
Standards utilisés :

TOP 10 OWASP, SANS Top 25,

guidelines PCI DSS, HIPAA
Outils:

Standards utilisés :
Nexus
DependencyCheck (OWASP)
OWASP Code Review Guide
WhiteHatSecurity
Outils : Jenkins
VeraCode, Checkmarx,
WhiteHatSecurity, IBM
AppScan
Phase 4 : Test

Déploiement
Formation Exigences Conception Implémentation Test et
Maintenance

DAST
Analyse dynamique
Analyse des requêtes/réponses
à l’application

Standards utilisés :

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
Formation Exigences Conception Implémentation Test et
Maintenance

Configuration sécurisée Plan de réponse à incident

Objectif : Répondre aux incidents de sécurité dans le
but de :
Eviter les incidents de sécurité liés à la Restaurer les services
configuration Minimiser les pertes
Colmater les failles exploitées
Réduire les risques qui pourraient survenir dans le
futur
Contremesures:
Contenu:
Déploiement automatisé Rôles et responsabilités de chacun
Checklist de vérification Actions immédiates en cas d’incident
Investigation en cas d’incident
Restauration des ressources affectées
Rapport sur l’incident survenu
Agenda

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