2010 03-11-sdlc-v02

Secure Development Life Cycle
Simple et Concret

CONFOO – Montréal
Québec - Canada
11 Mars 2010

Sébastien Gioria (French Chapter Leader & OWASP Global
Education Committee Member)
sebastien.gioria@owasp.org
Copyright © 2009 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.

The OWASP 2009 - S.Gioria & OWASP
©
Foundation
http://www.owasp.org

Qui suis-je ?
Consultant Sécurité au sein du cabinet d’audit Groupe Y
(s.gioria@groupey.fr)
Président du CLUSIR Poitou-Charentes
OWASP France Leader - Evangéliste - OWASP Global Education
Comittee Member (sebastien.gioria@owasp.org)

 +12 ans d’expérience en Sécurité des Systèmes d’Information
 Différents postes de manager SSI dans la banque, l’assurance
et les télécoms
 Expertise Technique
 PenTesting, Digital Forensics
@SPoint  S-SDLC
 Gestion du risque, Architectures fonctionnelles, Audits
 Consulting et Formation en Réseaux et Sécurité

 Domainesde prédilection :
 Web 4.2 : WebServices, Insécurité du Web.

© 2009 - S.Gioria & OWASP

Agenda

 ourquoi ?
P
 es acteurs
L
 a boite a outils
L
 imple et concret ?
S
 etour d’expérience
R
 uestions ?
Q


Faiblesse des Applications Web
%
A$aques
%
Dépenses

10 %
Applica1on
Web

75 %

90 %

25 % Eléments
Réseaux

Etude
du
GARTNER
2003
Etude
du
SANS
(septembre
2009)

75%
des
a4aques
ciblent
le
niveau
Applica=f
h4p://www.sans.org/top-‐cyber-‐security-‐risks/

66%
des

applica=ons
web
sont
vulnérables

4

L’exposition a une vulnérabilité


Cout de la correction d’une faille


Secure Development Lifecyle Microsoft

 Modèle complet mais complexe
 Développé spécialement pour Microsoft par Microsoft
 Adapté a des projets logiciel classiques


Cigital TouchPoints

 éthode de Gary McGraw
M


CLASP

 Comprehensive, Lightweight Application Security
Process
 bonnes pratiques dans le développement
7
sécuritaire
 ouvre tout le cycle de vie logiciel
C
 Adaptable tout processus
 Dispose d’une checklist d’activités intéressante.
 Assez complexe d’approche pour un non initié !

Les autres….

 ERT (http://www.cert.org/secure-
C
coding/)
 e retrouve dans la méthode de Cigital
S

 es Méthodes privées
L
 hacune différente
C


Pourquoi cela ne marche pas ?

 rop Complexe
T

 pproche trop haut niveau
A

 pproche trop « sécurité »
A

 rop de confiance ?
T


Mais encore….


Mais la meilleure solution


Par ou commencer ?

 éfinir ce que l’on a à sa disposition :
D
 emps/Budget/Effort a fournir
T
Nb de
 enaces
M lignes
de Code
Effort

 ommes
H Budget

 usceptibilités
S
 ackchiches
B
 izza, Coca, sushi, bière
P
 .
…
Charge/Cout Induit


Savoir se prendre des coups

 e n’ai pas le budget
J

 u parles, t’es trop jeune ici toi, on est
T
« secure »

 u parles, t’y connais rien en programmation
T
Confoo#

 écurité ? C’est pas mon boulot, moi je code les
S
specs qu’on me donne

Eduquer, éduquer, éduquer, …..
Si vous pensez que l’éducation coute cher, essayez
l’ignorance ! © Abraham Lincoln
 u’a-t-on a gagner personnellement :
Q
 rgent ?
A
 emps ?
T
 econnaissance professionnelle ?
R
 u’a-t-on a perdre ?
Q
 rgent ?
A
 emps ?
T
 e cerveau humain est la plus belle machine,
L
mais aussi la plus vulnérable !

Responsabiliser, responsabiliser,
responsabiliser, …..
 haque acteur doit se sentir « impliqué » dans
C
la sécurité.
 emander au métier des besoins sécurité
D
 ettre en place des clauses de sécurité dans les
M
contrats prestataires
 éfinir des exigences à suivre
D
=> Utiliser l’ASVS OWASP
 l faut trouver les bons mots/les bons vices…
I


Orchestrer, orchestrer, orchestrer, ….

 e posez en tant que chef d’orchestre
S

 e pas tenter des explications complexes sur la
N
présentation de la sécurité projet

 érer des activités simples et ne pas les rendre
G
« dépendantes »


Planifier et documenter les approches

 Détailler l’architecture de sécurité en terme de
composants, connexions et contrôles de sécurité

Penser malveillant !

 Modéliser les menaces, les attaques, les
vulnérabilités, les impacts techniques et business

=> Un risque existe lorsqu’une menace utilisant
une attaque sur une vulnérabilité génère un
impact business.

Le cycle

Planification des tests sécurité

Exp Besoin Exigences
Planning Conception
Business Business

Codage Test Deploiement Production

Exécution des tests sécurité

Plus une vulnérabilité est identifiée tôt dans
le cycle de vie, plus le coût de correction
sera faible. © 2009 - S.Gioria & OWASP

Définir un fiche sécurité métier

 border les problèmes qui parlent aux métiers :
A
 mage de marque
I
 isponibilité du site
D
…


 ettre en place un questionnaire de 10 points
M

 crire des questions fermées !
E
 Voulez vous un cadenas en bas du navigateur (O/N)
 Voulez vous que le site soit accessible pour une population
limitée (O/N)

Des politiques – OWASP ASVS

 Quelles sont les fonctionnalités à mettre en oeuvre dans les
contrôles de sécurité nécessaires à mon application

Spécifications/Politique de sécurité des développements

 Quelle est la couverture et le niveau de rigueur à mettre en
oeuvre lors de la vérification de sécurité d'une application.
 Comment comparer les différentes vérifications de sécurité
effectuées
Aide à la revue de code

 Quel niveau de confiance puis-je avoir dans une application
Chapitre sécurité des contrats de
développement ou des appels d’offres !
2
5

Principes de développement

KISS : Keep it Short and Simple
 étapes clés :
8
 alidation des entrées
V
 alidation des sorties
V
 estion des erreurs
G
 uthentification ET Autorisation
A
 estion des Sessions
G
 écurisation des communications
S
 écurisation du stockage
S
 ccès Sécurisé aux ressources
A

KISS : Keep it Short and Simple

 uivre constamment les règles précédentes
S
 e pas « tenter » de mettre en place des
N
parades aux attaques
 évelopper sécurisé ne veut pas dire prévenir la
D
nouvelle vulnérabilité du jour
 onstruire sa sécurité dans le code au fur et a
C
mesure et ne pas s’en remettre aux éléments
d’infrastructures ni au dernier moment.


Mettre en place les Tests Qualité

 De pas parler de tests sécurité !

 Définir des fiches tests simples, basées sur le Top10/
TopX :
 Tests d’attaques clients/image de marque (XSS)
 Tests d’intégrité (SQL Injection, …)
 Tests de conformité (SQL/LDAP/XML Injection)
 Tests de configuration (SSL, interfaces d’administration)

 Ajouter des revues de code basées sur des checklists
 SANS/Top25
 OWASP ASVS
 …. © 2009 - S.Gioria & OWASP

Tests - Proposer des indicateurs compréhensibles


Le décor
 ociété Française d’environ 400 personnes
S

 orte dépendance à l’informatique
F
 étier principal
m
 eaucoup de compétences internes
B
 eu d’externalisation
P
 réation d’un poste de RSSI
C
 bjectif de réduire le nombre de corrections sécurité
O
 méliorer la crédibilité vis a vis des clients
A
 ests de sécurité réguliers après mise en
T
production de modules/applications

Les étapes

 tat des lieux
E
 electure des différents audits passés pour établir le
R
contexte et le niveau de maturité en sécurité :
 En mode ‘pifométrique’ adapté de l’OpenSAMM (http://
www.OpenSamm.ORG)
 pproche de gestion des projets
A
 isualisez les endroits ou il est possible d’entrer de la
V
sécurité

 éploiement
D
 ducation
E
 jout progressif d’activités
A © 2009 - S.Gioria & OWASP

Le cycle et l’ajout des points
Spécifications
Fiche Besoin Métier fonctionnelles de sécurit

Exp Besoin Exigences
Planning Conception
Business Business

Codage Test Deploiement Production

Tests qualité métiers


Les choix

 rojet nouveau et stratégique
P
 élais très courts
D
 xigences de sécurité élevée
E

 éfinir des exigences fonctionnelles et politiques
D
de sécurité associées
 tilisation des documents internes de code pour les
U
développeurs


Les murs franchis

 ’ajout de la sécurité dès l’initiation du cycle
L
projet

 a focalisation des tests intrusifs sur des tests
L
complexes et utiles

 a mise en place d’un framework d’entreprise
L
sécurisé

 a sensibilisation de tous les acteurs sur la
L
sécurité © 2009 - S.Gioria & OWASP

Les fausses routes
 arler de tests sécurité en fin de cycle…
P
=> Rejet de la part des équipes de tests

 ouloir présenter au top management
V
rapidement le processus pour validation…
=> Incapacité à négocier un budget

 mposer des outils/frameworks aux
I
développeurs
=> Incapacité à les intégrer correctement

Le bilan final du projet

 ugmentation du cout unitaire du projet
A
de plus de 30 % !
 ais centré sur le processus + framework
M
 OI attendu rapidement
R

 eilleur intégration des équipes et des
M
compétences.
 oins de ségrégation architectes/
M
développeurs/MOA


Et aujourd’hui (9 mois plus tard…) ?

 Toujours des tests de sécurité en production, mais
réduits de 50%.

 Une prise de conscience progressive des personnes en
amont(commerciaux).

 Une bonne implication du management

 Des tests sécurité externes de meilleure qualité

 Une légère augmentation dans le cycle projet (5%)

2010 03-11-sdlc-v02

Contenu connexe

Tendances

En vedette

Similaire à 2010 03-11-sdlc-v02

Plus de Sébastien GIORIA

2010 03-11-sdlc-v02