Embed Size (px)
DESCRIPTION
Dans un premier temps, la présentation s’attardera sur les raisons qui font que le développement applicatif constitue l’un des parents pauvres de la sécurité de l’information aujourd’hui. Ensuite, on découvrira comment intégrer efficacement la sécurité dans le développement applicatif . Application Security Forum 2011 27.10.2011 - Yverdon-les-Bains (Suisse) Conférencier: Stéphane Adamiste
Citation preview
1
Développement applicatif & sécurité: Menaces, bonnes pratiques, retour d’expérience.
Stéphane AdamisteApplication Security Forum 2011 – Western Switzerland
27.10.2011
2
Avant-propos
• Qui suis-je? Pourquoi suis-je ici?• Terminologie
– Application ~ application web
27.10.2011
3
Le paradoxe de l’apostrophe
27.10.2011
4
12 ans plus tard…
• 2011 Data Breach Investigations Report (DBIR)• Verizon, United States Secret Service (USSS),
Dutch National High Tech Crime Unit (NHTCU)• ~800 cas de vol de données
27.10.2011
“SQL injection attacks, cross-site scripting, authentication bypass, and exploitation ofsession variables contributed to nearly half of breaches attributed to hacking or network intrusion.”
5
Typologie de menaces
27.10.2011
> Attaques directes sur application web
> Vol de données> Defacement
> Usurpation d’identité> DoS / Demande de rançon
> Intrusion dans réseau interne
> Modification du code dans le but de diffuser du contenu malveillant
> Bug logiciel / bug progiciel
> Dégradation des performances / panne> Problème de traitement des données
> Pollution de code source (trojan, bombe logique)
> Attaque des systèmes de gestion des versions (SVN)
6
Impact
27.10.2011
Financier
Productivité
Réputation
Légal
Santé/vie
> Vol de données
> Defacement
> Usurpation d’dentité
> Intrusion dans réseau interne
> Modification du code dans le but de diffuser du contenu malveillant
> Dégradation des performances / panne
> Problème de traitement des données> Attaque des systèmes de gestion des versions (SVN)
Systématique
Fréquent
Rare
> DoS / Demande de rançon
727.10.2011
Sécurité dans le développement
applicatif
Stratégies de
sécurité
Business de la
sécurité
Pourquoi en est-on là?
8
Business de la sécurité
27.10.2011
9
Business de la sécurité
• Discours marketing– Solutions miracles– Propos simplificateurs
• Recherche du profit– Vente de produits– Conflits d’intérêt– Charlatanisme
-> Galvaudage du terme «sécurité»
27.10.2011
10
Stratégie de sécurité
• L’expertise sécurité se concentre au niveau du réseau
• La gestion des risques informationnels n’est pas formalisée, d’où une mauvaise prise en compte de l’évolution des risques:– La webification des services entraîne une
augmentation de la surface d’attaque– La complexité accrue des technologies augmente le
risque de failles• Le profit avant la sécurité27.10.2011
11
Sécurité dans le développement applicatif
27.10.2011
Sujet de la sécurité peu et mal abordé en avant vente
AArchitecture conçue par des férus de technologie
Lacunes dans le projet impactant la sécurité
12
TP: Créer une fonction «remember me»
27.10.2011
• Solution:– Si l’utilisateur coche la case «remember me»,
l’application envoie un cookie aléatoire– A la prochaine connexion, l’application vérifie la
présence du cookie
Si quelqu’un vole le téléphone, il n’a pas besoin du mot de passe!!!
= mot de passe stocké en clair côté serveur
13
Facteurs sécurité dans un projet
27.10.2011
Sécurité d’un projet de développement
Politiques de sécurité Menaces
Gestion de projet
Dépendances sécurité
ConvivialitéFonctionnalités de sécurité
14
Approche fonctionnalités/approche menace
27.10.2011
«Transparent Data Encryption provides easy and effective protection of stored data by transparently encrypting data (using AES with up to 256 bits or 3DES168) at the tablespace or column level»
SQL
Mesures de sécurité contre la menace du DBA malveillant: Chiffrement online + DBA n’a pas accès à
l’application Principe des 4 yeux (e.g. séparation du
mot de passe SA en deux parties) Loi du moindre privilège: DBA a des droits
de gestion mais pas d’écriture/lecture Journalisation des changements de
privilèges Logs stockés sur un serveur distant
Benutzer
15
Activités de sécurité dans le SDLC
27.10.2011
Sécurité dans la gestion de projet
Analyse des besoins Design Implémentation
& TestingRelease & Maintenance
Risk assessment
Analyse de menaces
Exigences de sécurité
Architecture sécurisée
Revue de code Revue de design Testing sécurité
Gestion des vulnérabilités
Gestion du changement
Maintien du niveau de sécurité des composants dans le temps
Déterminer: La criticité de l’application Les principaux enjeux du projet en termes de
sécuritéDéduire: Les zones d’attention particulières du projet La profondeur de l’action à mener La répartition des tâches et responsabilités
Procéder à une modélisation des menaces (i.e. Identifier les scénarios hostiles sur base d’un schéma de flux entre les composants).
De cette modélisation découlent les spécifications de sécurité à intégrer dans le design et l’architecture afin de mitiger les risques.
Vérification de l’adéquation entre les spécifications et l’implémentation effective de la solution (Revues sur plan, revue de configuration, tests d’intrusion)
16
Avantage d’une approche sécurité
• Assurance que le projet livré ne va pas augmenter le risque de compromission des données de l’organisation
• Approche risque: Optimisation de l’effort en fonction du niveau de risque acceptable pour l’organisation
• ROI• Effet structurant sur le projet. Par exemple:
– la modélisation des menaces permet d’orienter les choix de façon rationnelle dans le design, l’architecture, les options de configuration
– Les tests de sécurité permettent de détecter d’éventuelles défaillances dans les pratiques de codage suffisamment tôt pour permettre de corriger le tir sans remettre en cause le délai de livraison prévu
27.10.2011
Facteurs clés de succès
• Impliquer une ressource dédiée à la sécurité• Intégrer la sécurité dans la qualité• Utiliser l’existant• Mise en place de métriques
– Pour mesurer l’évolution• Taux de conformité avec les référentiels • % de développeurs formés• % d’applications couvertes• Etc.
– Pour justifier la démarche (ROI)• Temps passé à la correction des problèmes• Mesure des coûts liés à la résolution d’incidents
Projet
Enterprise
18
Utiliser l’existant
27.10.2011
Analyse des besoins Design Implémentation
& TestingRelease & Maintenance
OWASP Secure Software Contract Annex / SANS Application Development Security Procurement Language
OWASP Top 10 web applications security risks
OWASP Secure Coding Guide
Microsoft Web Application threat Modeling
OWASP Enterprise Security API’s
Security Ninja Secure Development Principles
OWASP Testing Guide
OWASP Application Security Verification Standard
SANS/CWE Top 25 programming errors
OWASP Code review guide
