Développement applicatif &   sécurité: Menaces, bonnes   pratiques, retour d’expérience.             Stéphane Adamiste    ...
Avant-propos• Qui suis-je? Pourquoi suis-je ici?• Terminologie      – Application ~ application web27.10.2011             ...
Le paradoxe de l’apostrophe27.10.2011                                 3
12 ans plus tard…•“SQL injection attacks, cross-site scripting,(DBIR)   2011 Data Breach Investigations Report authenticat...
Typologie de menaces> Attaques directes sur    > Vol de donnéesapplication web            > Defacement                    ...
Impact                                                             Productivité                                           ...
Pourquoi en est-on là?                                Business                                  de la                     ...
Business de la sécurité27.10.2011                             8
Business de la sécurité• Discours marketing      – Solutions miracles      – Propos simplificateurs• Recherche du profit  ...
Stratégie de sécurité• L’expertise sécurité se concentre au niveau du  réseau• La gestion des risques informationnels n’es...
Sécurité dans le développement                        applicatif                                    Lacunes dans le projet...
TP: Créer une fonction «remember                       me»  • Solution:= mot de passe stocké en claircôté serveur        –...
Facteurs sécurité dans un projet                               Politiques                               de sécurité       ...
Approche fonctionnalités/approche                 menace                                                              Benu...
Activités de sécurité dans le SDLC                          Analyse de                           menaces                 ...
Avantage d’une approche sécurité• Assurance que le projet livré ne va pas augmenter le  risque de compromission des donnée...
Facteurs clés de succès•   Impliquer une ressource dédiée à la sécurité                                                   ...
Utiliser l’existant    Analyse                                           Implémentation           Release &               ...
Questions?             Contact: stephane.adamiste@elca.ch27.10.2011                                        19
Upcoming SlideShare
Loading in …5
×

ASFWS 2011 - Développement applicatif & sécurité: Menaces, bonnes pratiques, retour d’expérience

1,354 views

Published on

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

Published in: Technology
  • Be the first to like this

ASFWS 2011 - Développement applicatif & sécurité: Menaces, bonnes pratiques, retour d’expérience

  1. 1. Développement applicatif & sécurité: Menaces, bonnes pratiques, retour d’expérience. Stéphane Adamiste Application Security Forum 2011 – Western Switzerland27.10.2011 1
  2. 2. Avant-propos• Qui suis-je? Pourquoi suis-je ici?• Terminologie – Application ~ application web27.10.2011 2
  3. 3. Le paradoxe de l’apostrophe27.10.2011 3
  4. 4. 12 ans plus tard…•“SQL injection attacks, cross-site scripting,(DBIR) 2011 Data Breach Investigations Report authentication bypass, and exploitation of• Verizon, United States Secret Service (USSS), session variables contributed to nearly half of Dutch National High Tech Crime Unit (NHTCU) breaches attributed to hacking or network•intrusion.” de vol de données ~800 cas27.10.2011 4
  5. 5. Typologie de menaces> Attaques directes sur > Vol de donnéesapplication web > Defacement > DoS / Demande de rançon > Usurpation d’identité > Modification du code dans le but de diffuser du contenu malveillant > Intrusion dans réseau interne> Bug logiciel / bug > Dégradation des performances / panneprogiciel > Problème de traitement des données> Pollution de code source > Attaque des systèmes de gestion des versions(trojan, bombe logique) (SVN) 27.10.2011 5
  6. 6. Impact Productivité Réputation Santé/vie Financier Légal> Vol de données> Defacement> Usurpation d’dentité> DoS / Demande de rançon> Modification du code dans le but dediffuser du contenu malveillant> Intrusion dans réseau interne> Dégradation des performances / panne> Problème de traitement des données> Attaque des systèmes de gestion des versions(SVN) 27.10.2011 6
  7. 7. Pourquoi en est-on là? Business de la sécurité Stratégies de sécurité Sécurité dans le développement applicatif27.10.2011 7
  8. 8. Business de la sécurité27.10.2011 8
  9. 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 9
  10. 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 10
  11. 11. Sécurité dans le développement applicatif Lacunes dans le projet impactant la sécurité AArchitecture conçue par des férus de Sujet de la sécurité peu et technologie mal abordé en avant vente27.10.2011 11
  12. 12. TP: Créer une fonction «remember me» • Solution:= mot de passe stocké en claircôté serveur – Si l’utilisateur coche la case «remember me», l’application envoie un cookie aléatoire Si quelqu’un vole le téléphone, il – A la prochaine connexion,besoin du mot de passe!!! la n’a pas l’application vérifie présence du cookie 27.10.2011 12
  13. 13. Facteurs sécurité dans un projet Politiques de sécurité Menaces Sécurité d’un Dépendances projet de sécurité développement Gestion de projet Convivialité Fonctionnalités de sécurité27.10.2011 13
  14. 14. Approche fonctionnalités/approche menace Benutzer Mesures de sécurité contre la menace du DBA malveillant:  Chiffrement online «Transparent Data Encryption provides easy + DBA n’a pas accès à l’application and effective protection of stored data by yeux (e.g. séparation du  Principe des 4 SQL transparently encrypting data (using AES with deux parties) mot de passe SA en up to 256 bits or 3DES168) at the tablespace  Loi du moindre privilège: DBA a des droits or column level» de gestion mais pas d’écriture/lecture  Journalisation des changements de privilèges  Logs stockés sur un serveur distant27.10.2011 14
  15. 15. Activités de sécurité dans le SDLC  Analyse de menaces  Exigences de  Gestion des sécurité  Revue de code vulnérabilités  Risk  Architecture  Revue de design  Gestion du assessment sécurisée  Testing sécurité changement Analyse Implémentation Release & Design des besoins & Testing Maintenance Sécurité dans la gestion de projet  Vérification de l’adéquation entre les des  Maintien du niveau de sécurité Déterminer: spécifications et l’implémentation  Procéder à une modélisation des menaces (i.e. dans le temps composants  La criticité de l’application Identifier les du projet en termes de la solution (Revues sur plan, effectivebase d’un  Les principaux enjeuxscénarios hostiles surde revue de configuration, tests d’intrusion) sécurité schéma de flux entre les composants). Déduire: De cette modélisation découlent les  Les zones d’attention particulièresàdu projet dans le spécifications de sécurité intégrer  La profondeur de l’action à mener de mitiger les design et l’architecture afin risques.  La répartition des tâches et responsabilités27.10.2011 15
  16. 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évu27.10.2011 16
  17. 17. Facteurs clés de succès• Impliquer une ressource dédiée à la sécurité Projet Enterprise• 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
  18. 18. Utiliser l’existant Analyse Implémentation Release & Design des besoins & Testing Maintenance OWASP Top 10 web applications security risks OWASP Secure Software OWASP Secure Coding OWASP Enterprise OWASP Testing Guide Contract Annex / Guide Security API’s SANS Application Development Security Microsoft Web Security Ninja Secure Procurement Language Application threat Development Principles Modeling SANS/CWE Top 25 programming errors OWASP Application Security Verification Standard OWASP Code review guide27.10.2011 18
  19. 19. Questions? Contact: stephane.adamiste@elca.ch27.10.2011 19

×