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

1,142 views
1,059 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
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
1,142
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
45
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide
  • Rapide présentation de mon pédigrée. D’une part par politesse, d’autre part parce que mon parcours explique la raison de ma présence ici.Professionnellement, j’ai consacré les années 2000 à la réalisation d’audits de sécuritéEn ce qui concerne la simulation d’attaques externes, deux méthodes efficaces: trojan + social engineering et exploitation de vulnérabilités webDu coup, j’ai eu envie de m’investir plus en amont, et donc j’ai rejoint il y a une année la société ELCAJ’avais envie de comprendre pourquoi, à l’heure actuelle, lorsque l’on organise une séance de sensibilisation à des développeurs, on suscite toujours autant d’émerveillement
  • Pour introduire la problématique de l’exposéLe tout premier papier exposant un POC relatif à la faille SQL injectionDate de 1998, âge de la pierre en informatique23rd October 2000 – SQL Injection FAQ – Chip Andrews (sqlsecurity.com) – First public usage of term “SQL Injection” in a paperTop 10 2010: Injections représentent le risque le plus prévalent selon l’OWASP
  • Un exmple vaut mieux qu’un long discours
  • Solutions miracles: On met en avant les fonctionnalités, en omettant de mentionner ce que les solutions ne font pasPropos simplificateurs: En marketing, il faut des messages porteurs, compréhensibles par le plus grand nombreGalvaudage: Qui doit-on écouter? Où commence, où s’arrête la sécurité? Jusqu’où doit-on aller?Aujourd’hui la perception de la sécurité dans les applications c’est communications client-serveur chiffrées et contrôle d’accès (mécanisme d’authentification + définition de droits par profil)
  • Historiquement, la sécurité s’est d’abord appliquée au niveau du réseauLa majorité des ressources sécurité en entreprise n’ont pas de compétences au niveau applicatifUne augmentation du nombre d’applications en ligne (extranets, ecommerce, erecruiting, saas, cloud) entraîne automatiquement une augmentation de la surface d’attaqueTechnologies issues du web 2.0 Ajax, RIA, MashupsLe profit avant la sécurité: Exemple du CTO dont le bonus est lié au respect des délais
  • Un projet de développement applicatif est souvent parsemé d’embûches (pbs de performance, utilisateurs critiques, dépassement de budget, retards de livraison). La sécurité est systématiquement reléguée au second planPour illustrer ce propos, j’ai choisi de me baser sur un document fondamentalCette partie illustre le dialogue de sourds entre client et fournisseur. Ressources sécurité pas impliquées, d’un côté comme de l’autre. Signe caractéristique: Pas d’exigences de sécurité dans les spécifications ni dans l’offre.Architectes, développeurs raisonnent en termes de création d’un produit, d’une fonctionnalité. Ne considèrent pas les scénarios hostilesL’exemple typique est l’install du serveur web. Limite de la responsabilité entre l’infra et le développement. Qui fait le hardening?
  • Quels sont les éléments dont on doit tenir compte dans un projetFonctionnalités: Fonctionnalités ou capacités intrinsèques de l’application à assurer la sécuritéPolitiques de sécurité: S’assurer de la transposition correcte des règles de sécurité existantes au projet (ex: web server hardening guide, politique d’accès aux données à distance, principe des 4 yeux)Dépendances: Eléments autres que l’application en elle-même qui influent sur la sécurité des données traitées par l’application (ex: FW autorise le port 80)Convivialité ou ergonomie ou confort d’utilisation: Les mesures de sécurité imposent des contraintes aux utilisateurs.Il convient de définir le juste milieu entre niveau de sécurité acceptable et convivialité de la solution.Ce sujet est source potentielle de conflit entre les protagonistes du projet(Ex: Synchronisation des données sur équipement mobile, expiration d’une session après une durée donnée, politique de mots de passe)Prendre en compte les aspects de sécurité liés au déroulement du projet (Ex: Anonymisation des données de test, NDA, Chiffrement des échanges sensibles fournisseur-client)Menaces: Déterminer de quoi on veut se protéger et en déduire les mesures de sécurité à appliquer et non pas l’inverse, sinon oublis et problèmes de justification de certaines mesures
  • 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

    ×