Your SlideShare is downloading. ×
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Securite applicative et SDLC - OWASP Quebec - 15 avril 2014

343
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
343
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The OWASP Foundation http://www.owasp.org La sécurité applicative et son intégration dans le cycle de dévelopement Patrick Leclerc patrick.leclerc@owasp.org
  • 2. Patrick Leclerc • 20 ans d’expérience en développement, architecture logicielle et sécurité • Architecte logiciel et sécurité applicative Directeur de la pratique sécurité applicative chez EGYDE Conseils • Leader du chapitre OWASP Québec • Chroniqueur occasionnel du magazine SÉCUS
  • 3. OWASP World L’OWASP (www.owasp.org) est une organisation mondiale à but non-lucratif (501c3) Elle a pour mission de rendre la sécurité applicative visible afin de permettre au gens et organisations de prendre des décisions informées sur les vrais risques de sécurité des applications. Tout le matériel OWASP est disponible gratuitement sous licence « open software ». OWASP demeure neutre et indépendante des fournisseurs de produits et de services
  • 4. |4 Plan de la présentation • Pourquoi la sécurité applicative? • Pourquoi intégrer la sécurité applicative dans le cycle de développement? (SDLC) • Une approche efficace pour prendre en charge la sécurité dans le cycle de développement • Open SAMM (Software Assurance Maturity Model) • Outils OWASP
  • 5. |5 Pourquoi la sécurité applicative?
  • 6. 6 Quelques faits “75% des vulnérabilités sur Internet se retrouvent au niveau de la couche applicative Web” - Gartner Group (2002 report) “Le cyber Crime… seconde cause des crimes économique observées dans le secteur des services financier” – PwC “À l’échelle mondiale, à chaque secondes 18 adultes sont victimes du cyber crime” - Norton US - $20.7 billion – (pertes directes) À l’échelle mondiale en 2012 - $110,000,000,000 – pertes directes
  • 7. 7
  • 8. 8 Quelques faits 19 décembre 2013: Target reconnait une fuite de plus 100 millions de cartes de crédit Novembre 2013: LoyaltyBuild reconnait une fuite de plus de 1.5 millions d’enregistrements Snapchat: 4.6 millions de d’enregistrements utilisateurs volés Avril 2014: La vulnérabilité d’OpenSSL qui affecte 2/3 des sites Web est dévoilée… impacts non encore mesurés, mais on s’attend à un record… Janvier 2014: Le compte Twitter de Skype est piraté par l’armé électronique Syrienne avec des tweets anti-Microsoft Janvier 2014: fuite de plus 1.1 millions de cartes de crédit
  • 9. 9 Faux sentiments de sécurité? • Nous sommes en sécurité derrière nos firewalls! • Nous utilisons toujours le meilleur antivirus! • Nous utilisons des plateformes sécuritaires comme Mac/Unix/Linux! • Nous utilisons les fonctions d’authentification et d’autorisation depuis longtemps! • Nos sites supportent HTTPS! • Nous faisons des balayages de vulnérabilités et ceux-ci ne trouvent rien! • Nous avons réalisé un test d’intrusion, et le gars n’a rien trouvé avec ses outils spécialisés!
  • 10. |10 Aux vulnérabilités applicatives… ça prend des mesures applicatives!
  • 11. 11 Top 10 (2013) des risques applicatifs
  • 12. |12 -“Bahhh! On en fait déjà de la sécurité applicative!” • Certes on emploi des mesures de sécurité, mais sont-elles efficaces pour tous les utilisateurs? • Sécurité « traditionnelle »: “la sécurité selon le processus normal et par des utilisateurs légitimes” • Sécurité applicative: “la sécurité traditionnelle + la prévention de l’escamotage + la vérification des mécanismes pour prévenir du mauvais usage de la part des pirates et délinquants”
  • 13. 13
  • 14. |14 Pourquoi intégrer la sécurité applicative dans le SDLC?
  • 15. 15 Parce que malgré des investissements grandissants en sécurité les mesures traditionnelles ne fonctionnent pas!
  • 16. 16 2 semaines d’hacking éthique 10 années-personnes de développement Lacunes dans la logique d’affaire Lacunes dans le code Erreurs de sécurité
  • 17. 17 La fenêtre d’opportunité d’un attaquant est égale à votre fenêtre de disponibilité! et généralement ils sont plus d’un… Si de votre côté, vous disposez en moyenne que de 20 jours-hommes pour détecter et défendre… À qui l’avantage?
  • 18. |18 Enjeux de ressources…
  • 19. Enjeux de conformité: PCI –DSS, SOX, 52-109, loi sur AIPRP, etc… Enjeux d’affaires:  Vols de données et de renseignements personnels, de numéros de cartes de crédit, d’information sur les actifs de l’entreprise  Détournement de fonds, espionnage industriel, atteinte è la rentabilité, extorsion  Dénis de service, atteinte à l’image de marque  atteinte à la rentabilité  … Vous y pensez à quel moment? 19 Enjeux d’affaires et de conformité
  • 20. |20 Alors... réactif ou proactif? • Les coûts reliés à la correction des risques de sécurité augmentent en fonction de la phase de développement où ils ont été découverts. • Pour réaliser les plus grandes économies la sécurité ne doit par être RÉACTIVE mais plutôt PROACTIVE
  • 21. Bâtir des applications sécuritaire! • En intégrant les préoccupations de sécurité dès le début du cycle de développement • En formant les participants sur les vulnérabilités et les bons contrôles à mettre en place …mais comment? 21 L’autre approche?
  • 22. |22 Une approche efficace pour prendre en charge la sécurité dans le cycle de développement…
  • 23. |23 L’approche idéale... …devrait assumer que: • Aucune recette spécifique ne fonctionne dans toutes les organisations « No one-size-fits-all » • Les comportements d’une organisation changent doucement • La solution doit permettre de choisir des options adaptées sur mesure à l’organisation selon les risques qu’elle veut mitiger ou accepter • Les changements doivent être itératifs et définis tout au long d’un parcours d’objectifs balisés • Faire en sorte que toutes améliorations subsistent dans les itérations
  • 24. |24 L’approche idéale devrait • Définir les pratiques de base (fondations) d’un processus qualité • Clarifier les concepts liées à la sécurité d’une façon plus générique possible • Utiliser un langage compréhensible de tous • Être intégrable et adaptable à toute forme de méthodologie et processus de développement • Les profils métiers et les activités de sécurité doivent être précis et adaptables (rôles et responsabilités, qualifications requises, résultats attendus)
  • 25. |25 Open SAMM
  • 26. |26 SAMM (Software Assurance Maturity Model) • Propose une méthodologie pour définir l’approche idéale de prise en charge de la sécurité applicative en fonction du contexte particulier et des risques de l’organisation • Fournit des outils pour mesurer la maturité de l’organisation en matière de gestion de la sécurité applicative • Couvre tout le cycle de vie des applications sous 4 grands domaines: de l’encadrement au développement et de la vérification à l’exploitation
  • 27. SAMM: 12 pratiques de sécurité • Chaque domaine définit 3 pratiques de sécurité, chaque pratique incorpore des activités de sécurité • Les pratiques couvrent toute la surface de l’assurance sécurité des logiciels • Chaque pratique est un « silo » pour l’amélioration
  • 28. |28 SAMM: Niveau de maturité • Chaque pratique définit 3 niveaux de maturité cible et la stratégie pour les atteindre • Niveaux de maturité: Pratiques non établies Compréhension initiale, plutôt réactif Monté en efficacité, plus proactif Maitrise de la pratique
  • 29. 29 SAMM: Évaluation de la maturité • Un questionnaire aide à établir quel est le niveau de maturité de l’organisation dans chacune des pratiques • Une synthèse permettra d’établir le niveau de maturité actuel et identifier les lacunes et les endroits où des gains pourraient être faits rapidement
  • 30. |30 SAMM: Fiches par niveaux (3) / par pratiques (12) Chaque fiche spécifie: • L’objectif de maturité • Les activités à réaliser • Résultats attendus • Facteurs mesurables de succès • Coûts à prévoir • Identification des ressources clés et des efforts approximatifs • Liens avec les autres pratiques
  • 31. |31 SAMM: Améliorations itératives • Approche par l’amélioration itérative (phase) • On découpe les objectifs à atteindre en quelques phases mesurables • On définit la stratégie et les métriques • Jusqu’à ce que les douze pratiques soient parvenues à la maturité désirée, les phases successives érigent les fondations du programme d’assurance sécurité
  • 32. SAMM: Gabarits et exemple • SAMM pourvoit des exemples de plan de prise en charge en fonction du type d’industrie: • Concepteurs de logiciels • Fournisseurs de services en ligne • Services financiers • Organisations gouvernementales • Un cas d’étude complet avec les explications motivant les décisions prises • Chaque phase décrit en détails: • Les contraintes organisationnelles • Choix achats vs construction 32
  • 33. 33
  • 34. |34 Facteurs de succès • Appui de la direction et des domaines d’affaires • Collaboration / accompagnement de ressources compétentes • Établir clairement les rôles et responsabilités ainsi que les attentes • Prise en charge selon une recette éprouvée • Connaissance du profil de risque et du contexte normatif et légal de l’organisation • Connaitre d’où on part et où l’on va (questionnaire de maturité, analyse des systèmes, risques à mitiger) • Établir un plan, une stratégie en quelques phases balisées • Sensibiliser et former les ressources • Outiller les ressources (guides, checklists, outils d’analyse, etc.) • Amélioration continue (le paysage de la sécurité change constamment)
  • 35. |35 Références  OWASP Open Software Assurance Maturity Model (SAMM)  OpenSAMM presentation by Pravir Chandra  OpenSAMM presentation by Seba Deleersnyder  Microsoft SDL / SLD Optimization Model  CLASP (Comprehensive Lightweight Application Security Process)  BSIMM (Building Security In Maturity Model ) – Cigital et Fortify  Software Security - Building Security in (Gary McGraw)  ISO 27001 / 27002 / 27034  Building Assured Systems Framework (Sept 2010) – Carnegie Mellon Software Engineering Institute  Another Excellent Application Security Maturity Model – (Neil MacDonald from Gartner)  Wikipedia  IBM Security Intelligence  http://manicode.blogspot.ca/2011/01/touchpoints-and-bsimm-hurt-appsec.html
  • 36. |36
  • 37. 37 Outils OWASP
  • 38. 38 Plusieurs ressources OWASP... • Open SAMM • Top 10 (2013) des risques de sécurité applicatives • OWASP Secure Coding Practices • OWASP Cheat sheets • OWASP Code Review Guide • OWASP Testing Guide • OWASP ASVS (Application Security Verification Standard) • OWASP Zed Attack Proxy (ZAP) • OWASP Webgoat et BWA (Broken Web Application) • OWASP podcasts, vidéos, webinars, présentations, livres… De tout pour tous les profils!
  • 39. 39 Impliquez vous! Supportez-nous! Bénéfices des membres OWASP: $50/an • Rabais sur les conférences • Une adresse de courriel: toi@owasp.org • Droit de vote dans les élections • Reconnaissance sur le site de l’OWASP • 40% du montant peut être versé au chapitre • Pour nous commanditer, suivre le lien « donate » sur https://www.owasp.org/index.php/Quebec_City
  • 40. 40 Supportez OWASP! Devenir membre pour un don annuel de: • Individuel $50 • Corporatif $5000 Permet à OWASP de supporter les initiatives: projets, listes de distribution, conférences, podcasts, bourses et coordination des activités mondiales…
  • 41. |41 Merci!