ASFWS 2011 - Développement applicatif & sécurité: Menaces, bonnes pratiques, retour...

1

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

Stéphane AdamisteApplication Security Forum 2011 – Western Switzerland

27.10.2011

2

Avant-propos

• Qui suis-je? Pourquoi suis-je ici?• Terminologie

– Application ~ application web

27.10.2011

3

Le paradoxe de l’apostrophe

27.10.2011

4

12 ans plus tard…

• 2011 Data Breach Investigations Report (DBIR)• Verizon, United States Secret Service (USSS),

Dutch National High Tech Crime Unit (NHTCU)• ~800 cas de vol de données

27.10.2011

“SQL injection attacks, cross-site scripting, authentication bypass, and exploitation ofsession variables contributed to nearly half of breaches attributed to hacking or network intrusion.”

5

Typologie de menaces

27.10.2011

> Attaques directes sur application web

> Vol de données> Defacement

> Usurpation d’identité> DoS / Demande de rançon

> Intrusion dans réseau interne

> Modification du code dans le but de diffuser du contenu malveillant

> Bug logiciel / bug progiciel

> Dégradation des performances / panne> Problème de traitement des données

> Pollution de code source (trojan, bombe logique)

> Attaque des systèmes de gestion des versions (SVN)

6

Impact

27.10.2011

Financier

Productivité

Réputation

Légal

Santé/vie

> Vol de données

> Defacement

> Usurpation d’dentité

> Intrusion dans réseau interne

> Modification du code dans le but de diffuser du contenu malveillant

> Dégradation des performances / panne

> Problème de traitement des données> Attaque des systèmes de gestion des versions (SVN)

Systématique

Fréquent

Rare

> DoS / Demande de rançon

727.10.2011

Sécurité dans le développement

applicatif

Stratégies de

sécurité

Business de la

sécurité

Pourquoi en est-on là?

8

Business de la sécurité

27.10.2011

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

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

11

Sécurité dans le développement applicatif

27.10.2011

Sujet de la sécurité peu et mal abordé en avant vente

AArchitecture conçue par des férus de technologie

Lacunes dans le projet impactant la sécurité

12

TP: Créer une fonction «remember me»

27.10.2011

• Solution:– Si l’utilisateur coche la case «remember me»,

l’application envoie un cookie aléatoire– A la prochaine connexion, l’application vérifie la

présence du cookie

Si quelqu’un vole le téléphone, il n’a pas besoin du mot de passe!!!

= mot de passe stocké en clair côté serveur

13

Facteurs sécurité dans un projet

27.10.2011

Sécurité d’un projet de développement

Politiques de sécurité Menaces

Gestion de projet

Dépendances sécurité

ConvivialitéFonctionnalités de sécurité

14

Approche fonctionnalités/approche menace

27.10.2011

«Transparent Data Encryption provides easy and effective protection of stored data by transparently encrypting data (using AES with up to 256 bits or 3DES168) at the tablespace or column level»

SQL

Mesures de sécurité contre la menace du DBA malveillant: Chiffrement online + DBA n’a pas accès à

l’application Principe des 4 yeux (e.g. séparation du

mot de passe SA en deux parties) Loi du moindre privilège: DBA a des droits

de gestion mais pas d’écriture/lecture Journalisation des changements de

privilèges Logs stockés sur un serveur distant

Benutzer

15

Activités de sécurité dans le SDLC

27.10.2011

Sécurité dans la gestion de projet

Analyse des besoins Design Implémentation

& TestingRelease & Maintenance

Risk assessment

Analyse de menaces

Exigences de sécurité

Architecture sécurisée

Revue de code Revue de design Testing sécurité

Gestion des vulnérabilités

Gestion du changement

Maintien du niveau de sécurité des composants dans le temps

Déterminer: La criticité de l’application Les principaux enjeux du projet en termes de

sécuritéDéduire: Les zones d’attention particulières du projet La profondeur de l’action à mener La répartition des tâches et responsabilités

Procéder à une modélisation des menaces (i.e. Identifier les scénarios hostiles sur base d’un schéma de flux entre les composants).

De cette modélisation découlent les spécifications de sécurité à intégrer dans le design et l’architecture afin de mitiger les risques.

Vérification de l’adéquation entre les spécifications et l’implémentation effective de la solution (Revues sur plan, revue de configuration, tests d’intrusion)

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

27.10.2011

Facteurs clés de succès

• Impliquer une ressource dédiée à la sécurité• 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

Projet

Enterprise

18

Utiliser l’existant

27.10.2011

Analyse des besoins Design Implémentation

& TestingRelease & Maintenance

OWASP Secure Software Contract Annex / SANS Application Development Security Procurement Language

OWASP Top 10 web applications security risks

OWASP Secure Coding Guide

Microsoft Web Application threat Modeling

OWASP Enterprise Security API’s

Security Ninja Secure Development Principles

OWASP Testing Guide

OWASP Application Security Verification Standard

SANS/CWE Top 25 programming errors

OWASP Code review guide

19

Questions?

27.10.2011

Contact: stephane.adamiste@elca.ch