Le document présente l'OWASP, une organisation à but non lucratif dédiée à la visibilité et à l'amélioration de la sécurité applicative. Il souligne l'importance d'intégrer la sécurité dans le cycle de développement logiciel en raison des vulnérabilités fréquentes au niveau applicatif. L'OWASP propose des méthodologies comme le Software Assurance Maturity Model (Open SAMM) pour aider les organisations à évaluer et améliorer leur sécurité applicative.

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!