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

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

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

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

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 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

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

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

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 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

|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

code

Erreurs de sécurité

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

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 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

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

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

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 « 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

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

Open SAMM

|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

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

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

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

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

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é

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

|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

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

37

Outils OWASP

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

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

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

Merci!