The OWASP Foundation
http://www.owasp.org
La sécurité applicative et son
intégration dans le cycle de
dévelopement
Patrick...
Patrick Leclerc
• 20 ans d’expérience en développement,
architecture logicielle et sécurité
• Architecte logiciel et sécur...
OWASP World
L’OWASP (www.owasp.org) est
une organisation mondiale à but
non-lucratif (501c3)
Elle a pour mission de rendre...
|4
Plan de la présentation
• Pourquoi la sécurité applicative?
• Pourquoi intégrer la sécurité applicative dans le cycle
d...
|5
Pourquoi la sécurité
applicative?
6
Quelques faits
“75% des vulnérabilités sur Internet se retrouvent au
niveau de la couche applicative Web”
- Gartner Grou...
7
8
Quelques faits
19 décembre 2013: Target reconnait
une fuite de plus 100 millions de
cartes de crédit
Novembre 2013: Loya...
9
Faux sentiments de sécurité?
• Nous sommes en sécurité derrière nos firewalls!
• Nous utilisons toujours le meilleur ant...
|10
Aux vulnérabilités applicatives…
ça prend des mesures applicatives!
11
Top 10 (2013) des risques applicatifs
|12
-“Bahhh! On en fait déjà de la
sécurité applicative!”
• Certes on emploi des mesures de sécurité, mais sont-elles
effi...
13
|14
Pourquoi intégrer la
sécurité applicative
dans le SDLC?
15
Parce que malgré des
investissements
grandissants en sécurité
les mesures
traditionnelles ne
fonctionnent pas!
16
2 semaines
d’hacking éthique
10 années-personnes
de développement
Lacunes dans
la logique
d’affaire
Lacunes
dans le
cod...
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…...
|18
Enjeux de ressources…
Enjeux de conformité:
PCI –DSS, SOX, 52-109, loi sur AIPRP, etc…
Enjeux d’affaires:
 Vols de données et de renseignements...
|20
Alors... réactif ou proactif?
• Les coûts reliés à la correction des risques de sécurité augmentent en
fonction de la ...
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
•...
|22
Une approche efficace
pour prendre en
charge la sécurité dans
le cycle de
développement…
|23
L’approche idéale...
…devrait assumer que:
• Aucune recette spécifique ne fonctionne dans toutes les organisations
« N...
|24
L’approche idéale devrait
• Définir les pratiques de base (fondations) d’un processus qualité
• Clarifier les concepts...
|25
Open SAMM
|26
SAMM (Software Assurance Maturity Model)
• Propose une méthodologie pour définir l’approche idéale
de prise en charge ...
SAMM: 12 pratiques de sécurité
• Chaque domaine définit 3 pratiques de sécurité,
chaque pratique incorpore des activités d...
|28
SAMM: Niveau de maturité
• Chaque pratique définit 3 niveaux de maturité cible et la
stratégie pour les atteindre
• Ni...
29
SAMM: Évaluation de la maturité
• Un questionnaire aide à établir quel est le niveau de maturité
de l’organisation dans...
|30
SAMM: Fiches par niveaux (3) / par pratiques (12)
Chaque fiche spécifie:
• L’objectif de maturité
• Les activités à ré...
|31
SAMM: Améliorations itératives
• Approche par l’amélioration
itérative (phase)
• On découpe les objectifs à
atteindre ...
SAMM: Gabarits et exemple
• SAMM pourvoit des exemples de plan de
prise en charge en fonction du type
d’industrie:
• Conce...
33
|34
Facteurs de succès
• Appui de la direction et des domaines d’affaires
• Collaboration / accompagnement de ressources c...
|35
Références
 OWASP Open Software Assurance Maturity Model (SAMM)
 OpenSAMM presentation by Pravir Chandra
 OpenSAMM ...
|36
37
Outils OWASP
38
Plusieurs ressources OWASP...
• Open SAMM
• Top 10 (2013) des risques de sécurité applicatives
• OWASP Secure Coding Pr...
39
Impliquez vous! Supportez-nous!
Bénéfices des membres OWASP: $50/an
• Rabais sur les conférences
• Une adresse de courr...
40
Supportez OWASP!
Devenir membre pour un don annuel de:
• Individuel $50
• Corporatif $5000
Permet à OWASP de supporter ...
|41
Merci!
Prochain SlideShare
Chargement dans…5
×

Securite applicative et SDLC - OWASP Quebec - 15 avril 2014

1 095 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 095
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
76
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Securite applicative et SDLC - OWASP Quebec - 15 avril 2014

  1. 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. 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. 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. |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. |5 Pourquoi la sécurité applicative?
  6. 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. 7
  8. 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. 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. |10 Aux vulnérabilités applicatives… ça prend des mesures applicatives!
  11. 11. 11 Top 10 (2013) des risques applicatifs
  12. 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. 13
  14. 14. |14 Pourquoi intégrer la sécurité applicative dans le SDLC?
  15. 15. 15 Parce que malgré des investissements grandissants en sécurité les mesures traditionnelles ne fonctionnent pas!
  16. 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. 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. |18 Enjeux de ressources…
  19. 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. |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. 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. |22 Une approche efficace pour prendre en charge la sécurité dans le cycle de développement…
  23. 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. |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. |25 Open SAMM
  26. 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. 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. |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. 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. |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. |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. 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. 33
  34. 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. |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. |36
  37. 37. 37 Outils OWASP
  38. 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. 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. 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. |41 Merci!

×