Le document présente le cycle de vie de développement de sécurité (SDL) de Microsoft, détaillant les méthodes et pratiques pour intégrer la sécurité dans le développement des logiciels. Il insiste sur l'importance de former les équipes, de définir des exigences de sécurité et de vie privée, ainsi que de mettre en œuvre des étapes de vérification et de réponse aux incidents. Enfin, il conclut en encourageant les organisations à commencer dès maintenant à adopter ces bonnes pratiques pour améliorer leur sécurité.

1. Microsoft Security
Development LifeCycle :
par ou commencer ?
Sébastien Gioria (OWASP French Chapter Leader & OWASP Global
Education Comittee Member)
sebastien.gioria@owasp.org
8 Février 2011- Paris - Palais des congrès
1

2. Qui suis-je ?
Consultant Sécurité Sénior au
sein du cabinet d’audit
Président du CLUSIR Poitou-Charentes
OWASP France Leader - Evangéliste -
OWASP Global Education Comittee
Member (sebastien.gioria@owasp.org)
CISA && ISO 27005 Risk Manager
q Expérience en Sécurité des Systèmes d’Information > 0x0D années
q Différents postes de manager SSI dans la banque, l’assurance et
les télécoms
Twitter :@SPoint
q Expertise Technique
ü Gestion du risque, Architectures fonctionnelles, Audits
ü S-SDLC : Secure-Software Development LifeCycle.
ü PenTesting, Digital Forensics
ü Consulting et Formation en Réseaux et Sécurité
q Domaines
de
prédilec0on
:
ü Web,
WebServices, Insécurité du Web.
2

3. site:mycompany.
com
hacked
OUI
NON
OK,
site:xssed.com
mycompany.com
OUI mais
alors ?
NON
Laissez
moi
vous
Votre
applica,on
sera
piratée
reme5re
sur
la
bonne
voie
3

4. Agenda
• La souris, le fromage et le chat
• Qu’est-ce que Microsoft SDL ?
• SDL Warrior
• Par ou commencer
• Et après…
4

5. Pourquoi ?
Les hackers sont astucieux
5

6. Le cout est important
6

7. Soyons donc précis !
7

8. Security Development LifeCycle
(SDL)
• 2004 : « Stop Security Kiddies »
• Méthode de développement sécurisée de tous les produits
Microsoft !
Vainqueurs a la CVE 2010
Produit
1er
2ème
3ème
Système
Linux
Kernel
Windows
Server
Apple
IOS
(35)
d’exploita0on
(129)
2008
(93)
SGBD
Oracle
(36)
Mysql
(3)
MS-­‐SQL
Server
(1)
Navigateur
Chrome
(164)
Safari
(130)
Firefox
(115)
8

9. 9

10. Formation
• Obligatoire pour toute l’équipe projet : Architecte, Développeur,
Testeur, Chef de projet
• Contenu minimum
• Conception sécurisée
• Modélisation des menaces
• Ecriture de code sécurisé
• Tests de sécurité
• Respect de la vie privée
• Contenu avancé
• Architecture et conception de la sécurité.
• Conception de l’interface utilisateur
• Problèmes de sécurité en détail
• Processus de réponse de sécurité
• Mise en œuvre d’atténuations personnalisées de menaces
10

11. Spécifications - Exigences de sécurité
1. Identifier l’équipe ou la personne qui sera responsable du
suivi et de la gestion de la sécurité
2. Vérifier que les outils de suivi et de rapport des bogues
assurent effectivement le suivi des problèmes de sécurité
3. Définir et documenter l’échelle des bogues et les valeurs
et seuil ainsi attribués aux bogues de sécurité.
L’échelle des bogues et le seuil associé ne doivent
jamais être assouplis, même si la date de fin du
projet approche.
11

12. Spécifications - Exigences de respect
de la vie privée
1. Désigner le conseiller en respect de la vie privée
2. Désigner le responsable dans l’équipe pour la vie privée
3. Définir et documenter l’échelle, les valeurs et seuil
attribués aux bogues de respect de la vie privée
12

13. Spécifications – Recommandations
de sécurité
1. Mettre en place le plan de sécurité
2. Vérifier que l’outil de bogue peut prendre en compte les
éléments de la modélisation des attaques . Il doit
comporter 2 fonctionnalités :
• Il doit être compatible STRIDE
• Permettre d’identifier la cause du Bug
13

14. Spécifications – Evaluer le projet et
les couts éventuels
1. Evaluer les portions du projet nécessitant :
• modélisations des menaces
• revues de conception de sécurité
• tests de pénétration
2. Vérifier le taux d’impact sur la vie privée
• P1 : Risque élevé sur le respect de la vie privé => Le
produit enregistre ou transfère des informations
confidentielles
• P2 : Risque modéré => un transfert unique de données
anonymes, initié par l’utilisateur
• P3 : Risque faible => Rien n’affecte le respect de la vie
privée
14

15. Conception
1. Effectuer une revue de conception
2. Effectuer des Analyses de risque
• Modélisation des menaces (STRIDE/DREAD)
• Code externes
• Analyse des projets classés P1 (vie privée)
15

16. STRIDE ?
Catégorie
Descrip,on
Pas
un
bogue
de
sécurité
Usurpa0on
(Spoofing)
A^aque
par
laquelle
un
a^aquant
ou
un
serveur
non
autorisé
se
fait
passer
pour
un
u0lisateur
ou
un
serveur
valide,
ou
un
code
malveillant
se
présente
comme
valide
Falsifica0on
(Tampering)
Modifica0on
malveillante
des
données
Répudia0on
(Repudia0on)
Menaces
associées
aux
u0lisateurs
qui
nient
avoir
effectué
une
ac0on
sans
que
les
autres
par0es
aient
le
moyen
de
prouver
le
contraire
Divulga0on
d’informa0ons
Menaces
qui
impliquent
l’exposi0on
des
informa0ons
à
(Informa0ons
Disclosure)
des
individus
qui
ne
sont
pas
censés
y
accéder.
Déni
de
service
(Denial
of
A^aques
(DoS)
qui
empêchent
un
u0lisateur
autorisé
Service)
d’accéder
aux
services
Éléva0on
de
privilège
Menace
qui
permet
à
un
u0lisateur
de
s’octroyer
une
(Eleva0on
of
Privilege)
autorisa0on
supplémentaire
Réduc0on
de
la
surface
Il
est
important
d’iden0fier
la
surface
d’a^aque,
même
si
d’a^aque.
(A^ack
Surface
les
interfaces
qui
y
sont
exposées
ne
sont
pas
des
Reduc0on.
)
vulnérabilités
au
sens
technique
16

17. DREAD ?
Catégorie
Descrip,on
Dommage
Poten0el
Si
la
menace
se
produit,
quel
est
le
niveau
de
dommage
:
(Damage)
0
–
Rien
10
–
Total
compromission
Reproduc0ble
Quelle
est
la
complexité
pour
reproduire
la
menace
(Reproducibility)
0
–
quasi-­‐impossible
10
–
pas
d’authen0fica0on,
a
travers
un
navigateur
Web
Exploita0on
De
quoi
a-­‐t-­‐on
besoin
pour
l’exploita0on
(Exploitability)
0
–
connaissance
en
programma0on,
des
ou0ls,
…
10
–
juste
un
navigateur
Web
U0lisateurs
touchés
Combien
d’u0lisateurs
seront
affectés
(Affected
Users)
0
–
Aucun
5
–
Quelques
uns
10
–
Tous
Découverte
La
faille
est-­‐elle
simple
a
découvrir
(Discoverability)
0
–
quasi-­‐impossible
5
–
via
un
sniffing
réseau
ou
autre
type
9
–
les
détails
sont
dans
le
domaine
public
10
–
Il
suffit
de
regarder
la
barre
du
navigateur
Web
17

18. Calcul final DREAD
DAMAGE
REPRODUCIBILITY
EXPLOITABILITY
AFFECTED USERS
5
DISCOVERABILITY
18

19. Implémentation
1. Creer la documentation et les outils permettant
d’adresser les problèmes de sécurité et de vie privée
2. Suivre les bonnes pratiques de développement
3. Intégrer les listes de contrôle de sécurité
4. Effectuer une revue automatisée de code
19

20. Vérification
1. Utilisation du Fuzzing
• Fichier
• Réseau
• Web
2. Revue de code
• Définir les priorités de revue de code :
• Code critique : noyau, utilisation d’éléments sensible
• Code important : code élevant les privilèges
• Code mineur : rarement utilisé.
3. Effectuer les tests de pénétration
• Boite noire
• Boite blanche
4. Revoir la surface d’attaque et la minimiser si possible
20

21. Diffusion
1. Effectuer une revue des manipulations de données
privées
2. Préparer les équipes au 2ème mercredi du mois
Loi de Murphy
3. Effectuer la revue finale de sécurité
Dernière version des documents projets et
risques à destination de l’équipe sécurité.
4. Publier la version et archiver une copie.
21

22. Réponse aux incidents
1. Définition des processus de réponses
• Equipe dédiées à la vie privée
• Equipes autres
2. Mise en place des communications
• PGP
3. Interaction avec le cycle de vie
22

23. 23

24. Avant-propos…
• Personne n’a la solution !
• Sinon on ne serait pas aux aguets tous les 2èmes
mardi du mois.
• Sinon les bulletins du CERTA seraient vides…
• Et surtout Oracle ne mentirait pas sur son surnom*…
• La plupart des méthodologies sont en version beta mais
s’améliorent…
• Ceci est un exemple de ce que l’on peut faire
*:unbreakable => dernier Patch Update 10/10 à la CVSS (encore une fois)…
24

25. 0x01
Régler 80% des problèmes avec 20% d’effort
25

26. 0x10b
• Se jeter à l’eau :
Je corrige tous les problèmes de
sécurité que je trouve !
Si vous n’êtes pas prêts à
corriger, ne cherchez pas !
26

27. Le problème
• Confidentialité
• Protéger les données, les systèmes, les processus
d’un accès non autorisé
• Intégrité
• Assurer que les données, systèmes et processus
sont valides et n’ont pas été modifiés de manière non
intentionnelle.
• Disponibilité
• Assurer que les données, systèmes et processus
sont accessible au moment voulu
27

28. Le problème
• Traçabilité
• Assurer le cheminement de toute donnée, processus
et la reconstruction des transactions
• « Privacy »
• Assurer que les données personnelles sont sous le
contrôle de leur propriétaire
 Conformité
 Adhérer
aux
lois
et
réglementa0ons
 Image
de
marque
 Ne
pas
se
retrouver
à
la
une
du
journal
«
Le
Monde
»
suite
à
un
incident
28

29. Le problème
29

30. 30

31. Formation
• OWASP Top10 2010 : Les 10 risques les plus critiques
des applications
• Classification des Menaces (WASC)
Ø http://projects.webappsec.org/Threat-Classification
• CWE/SANS list :
Top 25 Most Dangerous Programming Errors.
• http://microsoft.com/sdl/
31

32. Définition des exigences
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 !
32

33. Modélisation des attaques
• Utilisation des méthodologies :
• STRIDE
• ISO 27005 Garder a l’esprit
• SDL Threat Modeling Tool l’impact métier !
• …..
• Garder à l’esprit :
• 0x01 : la règle du 80/20
• 0x10b
Si vous n’êtes pas prêts à
corriger, ne cherchez pas !
33

34. Mettre en place des tableaux de décision
34

35. Utilisation des bons outils
• Formation
• Cf précédemment
• Visual Studio Team System (VSTS) 2008
• SDL Process Template
• Checklists
• Quick Security Reference - SQL Injection :
• Quick Security Reference - Cross Site Scripting :
• Quick Security Reference - Exposure of Sensitive Information
• SANS/CWE25
• Librairies :
• ESAPI
• Web Protection Library
• Anti-XSS
• Security Runtime Engine
• http://www.microsoft.com/security/sdl/adopt/tools.aspx
35

36. Exemple CWE25
36

37. Authenticator
User
AccessController
AccessReferenceMap
Validator
Encoder
HTTPUtilities
37
Encryptor
EncryptedProperties
Randomizer
Enterprise Security API
Exception Handling
OWASP Enterprise Security API
Custom Enterprise Web Application
Logger
IntrusionDetector
Existing Enterprise Security Services/Libraries
SecurityConfiguration
37

38. Revue de code
• Code Managé :
• CAT.NET
• FxCop
• Microsoft Source Code Analyzer for SQL Injection.
• OWASP Code Crawler
• CodePro AnalytiX (Java)
38

39. 39

40. Tests de pénétration
1. S’adresser à des cabinets/consultants dont le métier est
la gestion des risques informatiques.
2. Demander des rapports orientés métiers
Ø ne pas se contenter de rapports techniques
3. Demander des classifications compatibles avec votre
outil de bogue.
Ø Ne pas utiliser des référentiels non standards
4. Demande un transfert de compétences sur les failles
pour éduquer les acteurs
Ø Et donc savoir comment corriger
40

41. ET
APRES
?
41

42. Et si vous commenciez ?
• Il y a trois pas à franchir
1. Commencer :
• Formation => cout == 0
• CheckList => cout == 0
• Outil de bogue =>
2. Je commence à utiliser ces fameuses
checklists et remplir l’outil de bogue
3. Je corrige tous les problèmes de sécurité
que je trouve !
42

43. A bientôt
Il n'y a qu'une façon d'échouer, c'est d'abandonner avant
d'avoir réussi [Olivier Lockert]
43