intégrer la sécurité dans le processus de développement des applications et services en ligne

Intégrer la sécurité dans le processus de développement des applications et services en ligne

PSDP (Proactive Secure Development Process)

Khaled BEN DRISSKhaled BEN DRISS([email protected])

Pôle Technologique El Gazala – Tunisie

28 avril 2009

� Ingénieur de l'Ecole Centrale de Lyon (ECL’1991)� Docteur de l'Université Paris 6 ( P&MC ‘ 1994)

[email protected] Secure Development Process Tunisie – Parc Elghazela- 28/04/2008

Kh

aled

BEN

DR

ISS

1

� Ancien Maître Assistant à l'Ecole Polytechnique de Tunisie� Directeur Technique OXIA

� Consultant Senior : Architecte de Système d'Information

� www.oxiasoft.com

Un leader des Systèmes d’Information et du Nearshore au Maghreb :• Date de création : 1998

• Forme juridique : Société Anonyme

• Effectif : 180 personnes (janvier 2009)

• 60% de l’activité réalisée en dehors de la Tunisie

• Filiale en Algérie

• Certification ISO 9001 version 2000 (AFAQ QUAL/2005/25140 )

Le groupe OXIA en bref


Kh

aled

BEN

DR

ISS

Software Engineering

Business Solutions

IT OutsourcingManagement

Consulting

Objectifs de la présentation


Kh

aled

BEN

DR

ISS

3

Plan de la présentation

� Pourquoi introduire la sécurité dans le cycle de vie du logiciel ?

� Présentation du processus PSDP

� Les principales activités dans le processus PSDP

� Vue d’ensemble : Les pratiques de sécurité

� conclusion

Proactive Secure Development Process


Kh

aled

BEN

DR

ISS

4

Question?


Kh

aled

BEN

DR

ISS

5

Le constat

Les Applications Web

sont la cible #1 des

hackers:

75% des attaques concernent la

couche application(Gartner)

La plupart des sites

sont vulnérables:

90% des sites sont vulnérables aux attaques d'application (Watchfire)

Les applications Web

sont des cibles de

valeurs élevées pour

les hackers:

Vol d’informations sensibles (données clients, Cartes de

crédit, vol et

Exigences de

conformité:

Payment Card Industry (PCI)

Standards, Sarbanes Oxley,

ISO.


Kh

aled

BEN

DR

ISS

6

(Gartner)

XSS et SQL Injection sont classées #1 et

#2 des vulnérabilités dans le top ten OWASP

2007

78% d'applications Web affectées de vulnérabilités

facilement exploitables (Symantec)

80% des organisations auront un incident de

sécurité d'application d'ici 2010 (Gartner)

crédit, vol et usurpation

d’identités) , altération de site,

insertion de logiciel

malveillants, etc.

ISO.

Développer une application web : les objectifs divergents

Objectifs des projets de développement d’applications

Fonctionnalité

Convivialité

Efficacité

Objectifs de la sécurité dans les applications

Prévention

Traçabilité

Surveillance


Kh

aled

BEN

DR

ISS

Arc

hit

ectu

re d

’en

trep

rise

–O

XIA

-2

00

8 c

op

yrig

ht

OX

IA

Développement rapide

Simplicité

Faible coût

Confidentialité

Sécurité multi-niveaux

Authentification

Intégrité

Les trois piliers de la sécurité


Kh

aled

BEN

DR

ISS

8

Les trois piliers de la sécurité : Les personnes

Les personnes

(acteurs)

Incluent les acteurs : utilisateurs, les développeurs, les analystes, les gestionnaires, les administrateurs de systèmes.

Appliquent, analysent ou implémentent les mesures de sécurité.

L'éducation est la clé

la première et la plus importante étape du processus de construction de systèmes fiables .

Définir des check-list et

des standards et les

expliquer

il faut comprendre son adversaire


Kh

aled

BEN

DR

ISS

9

implémentent les mesures de sécurité.

Peuvent contourner ou insérer des failles de sécurité.

Doivent être sensibilisées à leurs responsabilités, à l’importance de la sécurité.

Beaucoup de développeurs comprennent comment fonctionnent les éléments de sécurité, mais ne comprennent pas comment construire des systèmes sécurisés.

La technologie

Offre un ensemble d’outils pouvant être mis en place

pour compléter, vérifier Ne suffit pas à elle seule :

Les trois piliers de la sécurité: La technologie


Kh

aled

BEN

DR

ISS

10

pour compléter, vérifier ou automatiser certaines

mesures de sécurité exigées par la Politique de

sécurité ou la cible de

sécurité de la ressource informationnelle.

La majorité des attaques se produisent au niveau

de l’application elle même

Les trois piliers de la sécurité: Le processus

La sécurité est principalement un ensemble de processus.

• Politique de sécurité;

• Analyse de risque et modélisation des menaces;

• gestion des identités et des privilèges d’accès;

• Conduite des audits;


Kh

aled

BEN

DR

ISS

11

• Définition des plans de contingence;

Pratiquement toutes les Entreprises utilisent des infrastructures de sécurité (Firewalls, IDS, etc) :

• Mais, un nombre très limité investit dans une stratégie de sécurité pour le développement ds applications, la conception, et les services de revues de code

Définit Qui fait Quoi, Quand le faire, et Comment atteindre un objectif.

Besoin Nouveau

Ou un changement

système nouveau

ou mise à jour

Processus d'ingénierielogicielle

Qu'est ce qu'un Processus?


Kh

aled

BEN

DR

ISS

12

Définit Qui fait Quoi, Quand le faire, et Comment atteindre un objectif.

Besoin Nouveau

Ou un changement

système nouveau

ou mise à jour

Processus d'ingénierielogicielle

Qu'est ce qu'un Processus?


Kh

aled

BEN

DR

ISS

13

Analyse Conception Implémentation Vérification Déploiement Maintenance

� Processus de développement traditionnel (UP, XP, 2TUP …):

� la sécurité est traitée comme un besoin annexe!






� conclusion



Kh

aled

BEN

DR

ISS

14

PSDP – Proactive Secure Development Process?

• Utilisé avec le cycle de vie développement de logiciel pour inclure la sécurité dans toutes les étapes et les activités de développement


(PSDP)



Kh

aled

BEN

DR

ISS

15






� conclusion



Kh

aled

BEN

DR

ISS

16

Gestion des exigences : Considérer la sécurité dés le début

Constituer l’équipe sécurité du projet (ESP ) qui :

Réalise des revues des planning

L’équipe de Développent

identifie les besoins en

sécurité

Trouver les Anti-Exigences

Pensez à ce que le logiciel ne devrait pas faire.



Kh

aled

BEN

DR

ISS

17

Recommandes la stratégie de test

Demande les ressources aux management

Évalue les jalons fixés pour vérifier la

sécurité

Cas de détournement : c’est l'inverse d'un cas d'utilisation

( Misuse Case)

Anti-Acteur c’est l'inverse de l’acteur : un acteur que le

système ne doit pas support, un acteur qui initie

l'utilisation abusive du logiciel.

Lors de la conception

Activités :

Identifier les composants critiques pour la sécurité (“base de confiance”)

Identifier les techniques de conception (découpage en couche, moindre privilège, …)

A ce stage toutes les décisions de conception et

d’architecture ont été prise :

Architecture logicielle



Kh

aled

BEN

DR

ISS

18

Définir et documenter l’architecture sécurité

Créer un modèle des menaces (voir suite)

Identifier les outils spécifiques de test

Définir des critères supplémentaires en fonction de la spécificité du produit (cross-site scripting tests, …)

Vérifier l’exhaustivité des réponses par rapport à la check-List sécurité de l’entreprise…

composants logiciels

Langage(s) de Programmation

Interfaces

Créer un modèle des menaces : Analyse des risques

Analyser les risques et anticiper : “Correction des défauts de conception, pas les bugs de codage“

Développer un modèle d’architecture.

Identifier les menaces et les vulnérabilités possibles.



Kh

aled

BEN

DR

ISS

19

CSC

66

6: S

ecu

re S

oft

war

e En

gin

eeri

ng

Développer des scénarios d'attaque.

Classifier les risques en se basant sur la probabilité et l'impact.

Élaborer une stratégie d'atténuation et de contre mesures.

Documenter les resultants

menaces

Vulnérabilité

Ressource

Importance de l’architecture

Intégrer la sécurité au cœur

même de l’architecture

globale

Définir l’ensemble des politiques de sécurité sur lequel devra

reposer la sécurité.



Kh

aled

BEN

DR

ISS

20

sécurité.

Éviter à tout pris de baser la

sécurité sur le secret: Proscrire la

notion de «security-

by-obscurity».

Ne pas développer des mécanismes de sécurité inutiles.

Implémentation

C’est l’activité de codage : produire un logiciel “fiable”

Suivre la documentation de la conception

Standards de Codage

Modules de sécurité Centralisé



Kh

aled

BEN

DR

ISS

21

Modules de sécurité Centralisé

Sécuriser les builds et la configuration

utiliser les bonnes pratiques de programmation, adaptées aux risques et failles de sécurité connus

• Injection SQL

• Buffer overflow

• Formatage des chaines de caractères

• Cross-Site Scripting (XSS)

• …

Vérification

En parallèle

Ce n’est pas une substitution des activités de sécurité lors du

développement

Offre une nouvelle opportunité pour focaliser sur la sécurité

Revues de code

Découvrir les problèmes le plutôt

dans le cycle de développement

Tentative de pénétration et autres tests de sécurité

Revues de la conception et de



Kh

aled

BEN

DR

ISS

22

En parallèle des tests

d’intégration, effectuer des

tests de sécurité

Revues de la conception et de l’architecture,

Pour les anciens modules et codes sources (réutilisés dans le

projet)

Revue du modèle de menaces à la lumière des nouveaux risques

Appliquer la technique de fuzzing

L'idée est d'injecter des données aléatoires dans les entrées d'un programme.

Si le programme échoue (par exemple en crashant ou en générant une erreur), alors il y a des défauts à corriger.

Tests de sécurité : combiner plusieurs approches et méthodes

Deux familles de de test

Fonctionnel: vérifier les mécanismes de

Test Automatisé

Boite blanche (analyse statique du code)

Test manuel

Vulnérabilités Logique



Kh

aled

BEN

DR

ISS

23

CSC

66

6: S

ecu

re S

oft

war

e En

gin

eeri

ng

les mécanismes de sécurité.

Attaque: vérifier la résistance aux attaques découverts au cours de l'analyse des risques.

Boite noire (scanners pour application web)

Vulnérabilités techniques

Test de non régression

intelligence Humaine (connaitre son

adversaire)

SDL – Release Phase

Exigences relatives à la surveillance

et monitoring



Kh

aled

BEN

DR

ISS

24

24

Procédures de Mise à jour de la sécurité

Procédures de gestion sécurisée

SDL – Response Phase

Types de maintenance

Nécessité d'introduire de nouvelles

Les causes :

Feedback des utilisateurs



Kh

aled

BEN

DR

ISS

25

25

de nouvelles fonctionnalités

Besoin de mise à niveau pour suivre la technologie

Découverte de vulnérabilité

utilisateurs

incident de sécurité et rapports de vulnérabilité






� conclusion



Kh

aled

BEN

DR

ISS

26


Vue d’ensemble : Les pratiques de sécurité

Opérations

de Sécurité

Analyse de risque

Cas de détournement

Revus de Code +

Analyses Statique

Tests de

Pénétration

Tests de

Sécurité


Kh

aled

BEN

DR

ISS

27






� conclusion



Kh

aled

BEN

DR

ISS

28

Processus +Education +Responsabilisation = PSDP

Secure by Design

• Une architecture logicielle fiable et sécurisée, conception et implémentation permettant de protéger les informations traitées et résister aux attaques.

Secure by Default

• Être pessimiste, en supposant que des failles de sécurité seront toujours présentent. L’état par défaut devrait promouvoir la sécurité

• fonctionner avec le minimum nécessaire de privilèges SD3+E


Kh

aled

BEN

DR

ISS

29

• Installez uniquement les services et les fonctionnalités qui sont nécessaires

Secure in Deployment

• Fournir des outils et des guides pour aider les utilisateurs et les administrateurs à utiliser le logiciel en toute sécurité, et à déployer les mises à jour en temps opportun.

Education

• Former, informer et communiquer en permanence : la sécurité c’est l’affaire de tous

SD +E

Inspiré de Microsoft

Biblio + www


Kh

aled

BEN

DR

ISS

11 rue Claude Bernard

1002 Le Belvédère

Tunis, Tunisia

Tél : +216 71 28 27 00

Khaled BEN DRISSDirecteur Technique

Tel : +216 71 28 27 00

Mob.: +216 25 23 45 30Tél : +216 71 28 27 00

Fax : +216 71 28 27 05

www.oxia-group.com

Mob.: +216 25 23 45 30

[email protected]

Documents

intégrer la sécurité dans le processus de développement des applications et services en ligne