ASFWS 2011 - Microsoft SDL dans un monde Java

Microsoft Security Development
LifeCycle
dans un monde Java

Sébastien Gioria (OWASP French Chapter Leader & OWASP
Global Education Comittee Member)
sebastien.gioria@owasp.org

Application Security Forum
Western Switzerland

27 octobre 2011 - HEIGVD Yverdon-les-Bains
http://appsec-forum.ch

Sunday, October 30, 11

http://www.google.fr/#q=sebastien gioria
‣Responsable de la branche Audit S.I et Sécurité au
sein du cabinet Groupe Y
‣OWASP France Leader & Founder -
Evangéliste
‣OWASP Global Education Comittee Member
(sebastien.gioria@owasp.org)

‣Responsable du Groupe Sécurité des
Applications Web au CLUSIF
Twitter :@SPoint

CISA && ISO 27005 Risk Manager
‣ +13 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,
- Secure-SDLC
- Gestion du risque, Architectures fonctionnelles, Audits
- Consulting et Formation en Réseaux et Sécurité

2
2

Agenda

• La souris, le fromage et le chat
• Qu’est-ce que Microsoft SDL ?
• SDL Warrior
• Duke in the game

3


Agenda

• La souris, le fromage et le chat
• Qu’est-ce que Microsoft SDL ?
• SDL Warrior
• Duke in the game


Pourquoi ?

Les
hackers
sont
astucieux


Le cout est important


Soyons donc précis !


Security Development
LifeCycle(SDL)
§ 2004
:
«
Stop
Security
Kiddies
»
§ Méthode
de
développement
sécurisée
de
tous
les

produits
MicrosoA
!


Security Development
LifeCycle(SDL)
§ 2004
:
«
Stop
Security
Kiddies
»
§ Méthode
de
développement
sécurisée
de
tous
les

produits
MicrosoA
!

Vainqueurs a la CVE 2010
Produit 1er 2ème 3ème
Système
Linux
Kernel
Windows
Server
Apple
IOS
(35)
d’exploitaEon (129) 2008
(93)
SGBD Oracle
(36) Mysql
(3) MS-‐SQL
Server

(1)
Navigateur Chrome
(164) Safari
(130) Firefox
(115)


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


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.


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éﬁnir et documenter l’échelle, les valeurs et
seuil attribués aux bogues de respect de la vie
privée


Spécifications – Recommandations de sécurité



1. Me_re
en
place
le
plan
de
sécurité



1. Me_re
en
place
le
plan
de
sécurité

2. Vériﬁer
que
l’ouEl
de
bogue
peut
prendre
en
compte
les
éléments
de
la

modélisaEon
des
a_aques
.
Il
doit
comporter
2
foncEonnalités
:



1. Me_re
en
place
le
plan
de
sécurité

2. Vériﬁer
que
l’ouEl
de
bogue
peut
prendre
en
compte
les
éléments
de
la

modélisaEon
des
a_aques
.
Il
doit
comporter
2
foncEonnalités
:

– Il
doit
être
compaEble
STRIDE



1. Me_re
en
place
le
plan
de
sécurité

2. Vériﬁer
que
l’ouEl
de
bogue
peut
prendre
en
compte
les
éléments
de
la

modélisaEon
des
a_aques
.
Il
doit
comporter
2
foncEonnalités
:

– Il
doit
être
compaEble
STRIDE

– Perme_re
d’idenEﬁer
la
cause
du
Bug


Spécifications – Evaluer le projet et les couts éventuels

1. Evaluer
les
porEons
du
projet
nécessitant
:

– modélisaEons
des
menaces

– revues
de
concepEon
de
sécurité

– tests
de
pénétraEon

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
informaEons

confidenEelles

– P2
:
Risque
modéré
=>
un
transfert
unique
de
données

anonymes,
iniEé
par
l’uElisateur
– P3
:
Risque
faible
=>

Rien
n’affecte
le
respect
de
la
vie


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)


STRIDE ?
Catégorie Descrip@on
Pas
un
bogue
de
sécurité

UsurpaEon
(Spoofing) A_aque
par
laquelle
un
a_aquant
ou
un
serveur
non

autorisé
se
fait
passer
pour
un
uElisateur
ou
un
serveur

valide,
ou
un
code
malveillant
se
présente
comme
valide

FalsificaEon
(Tampering) ModificaEon
malveillante
des
données

RépudiaEon
(RepudiaEon) Menaces
associées
aux
uElisateurs
qui
nient
avoir

effectué
une
acEon
sans
que
les
autres
parEes
aient
le

moyen
de
prouver
le
contraire

DivulgaEon
d’informaEons
Menaces
qui
impliquent
l’exposiEon
des
informaEons
à

(InformaEons
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
uElisateur
autorisé

Service) d’accéder
aux
services

ÉlévaEon
de
privilège
Menace
qui
permet
à
un
uElisateur
de
s’octroyer
une

(ElevaEon
of
Privilege) autorisaEon
supplémentaire

RéducEon
de
la
surface
Il
est
important
d’idenEfier
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

ReducEon.
) vulnérabilités
au
sens
technique


DREAD ?
Catégorie Descrip@on

Dommage
Poten/el
(Damage) Si
la
menace
se
produit,
quel
est
le
niveau
de
dommage
:
0
–
Rien
10
–
Total
compromission

Reproduc/ble
(Reproducibility) Quelle
est
la
complexité
pour
reproduire
la
menace
0
–
quasi-‐impossible
10
–
pas
d’authen/fica/on,
a
travers
un
navigateur
Web
Exploita/on
(Exploitability) De
quoi
a-‐t-‐on
besoin
pour
l’exploita/on

0
–
connaissance
en
programma/on,
des
ou/ls,
…
10
–
juste
un
navigateur
Web

U/lisateurs
touchés
(Affected
Combien
d’u/lisateurs
seront
affectés

Users)
0
–
Aucun
5
–
Quelques
uns
10
–
Tous

Découverte
(Discoverability) La
faille
est-‐elle
simple
a
découvrir

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


Calcul ﬁnal DREAD

DAMAGE
REPRODUCIBILITY
EXPLOITABILITY
AFFECTED USERS
5
DISCOVERABILITY


Implémentation

1. Créer
la
documenta1on
et
les
ou1ls
perme4ant

d’adresser
les
problèmes
de
sécurité
et
de
vie

privée

2. Suivre
les
bonnes
pra1ques
de
développement

3. Intégrer
les
listes
de
contrôle
de
sécurité

4. Eﬀectuer
une
revue
automa1sée
de
code


Vérification
1. Utilisation du Fuzzing
• Fichier
• Réseau
• Web
2. Revue de code
• Déﬁnir 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


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 ﬁnale 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.


Réponse aux incidents

1. Déﬁnition 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


Avant-propos…
• Ceci est une proposition à
certains endroits de la SDL
pour éviter :
• d’être aux aguets tous les 2èmes
mardi du mois.
• des bulletins du CERT longs…
• que Larry(*) nous sorte toujours
la même chanson….

*:Oracle unbreakable? => dernier Patch Update 10/10 à la CVSS (encore une fois)…


Le problème
• Conﬁdentialité
• 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é modiﬁés de manière
non intentionnelle.

• Disponibilité
• Assurer que les données, systèmes et processus
sont accessible au moment voulu


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
Conformité
Adhérer
aux
lois
et
réglementaEons

Image
de
marque
Ne
pas
se
retrouver
à
la
une
du
journal
«
Le
Monde
»
suite

à
un
incident


Le problème


0x01


0x01

Régler 80% des problèmes avec 20% d’effort


0x10b
• Se jeter à l’eau :


0x10b
Corrigez tous les problèmes
que vous pouvez trouver


0x10b
Corrigez tous les problèmes
que vous pouvez trouver

Si vous n’êtes pas prêts à
corriger, ne cherchez pas !


Phase 0 - Formation
• OWASP Top10 2010 : Les 10 risques les plus critiques
des applications
• CWE/SANS list : Top 25 Most Dangerous Programming
Errors.
• CERT Java Secure Coding
• https://www.securecoding.cert.org/conﬂuence/display/java/
The+CERT+Oracle+Secure+Coding+Standard+for+Java


Phase
1
-‐
Spéciﬁca/ons
§ Mise
en
place
du
bugtracker
– Catégories
d’eﬀet
des
bugs
:

• Elements
STRIDE
(ou
autre
des
modélisaEons)
– Catégories
de
cause
des
bugs
:

• XSS,
CSRF,
SQL-‐i,
DOS,
Crypto….


Phase 2 – Design
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 !


Poli/que
de
sécurité
logicielle


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


Phase 2 - 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 !


Phase
3
-‐
Développement
§ Suivre
les
best-‐pracEces
:
– OWASP
Secure
Coding
Prac@ces
• hJps://www.owasp.org/index.php/Secure_Coding_Principles
– CERT/Oracle
Secure
Coding
for
Java
• https://www.securecoding.cert.org/conﬂuence/display/java/The+CERT
+Oracle+Secure+Coding+Standard+for+Java
– Secure
Coding
Guidelines
for
Java
(Oracle)
• hJp://www.oracle.com/technetwork/java/seccodeguide-‐139067.html

§ UEliser
les
bons
ouEls/bibliothèques
(h_ps://www.owasp.org)
– OWASP
CSRF
Guard
– OWASP
Java
Sani@zer
– OWASP
S@nger


Phase
3
-‐
Cookies


Phase
3
-‐
Valida/ons


Phase
3
–
SQL


Phase
3
–
Pour
aller
plus
loin
OWASP Enterprise Security API


Phase 4 - Revue de code
§ Design :
• OWASP Cheat Sheets : https://www.owasp.org/index.php/
Category:Cheatsheets
• OWASP Application Veriﬁcation Standard : https://
www.owasp.org/index.php/
Category:OWASP_Application_Security_Veriﬁcation_Standard_Projec
t

§ Semi-Automatisé :

• OWASP LAPSE+ : https://www.owasp.org/index.php/
OWASP_LAPSE_Project

• CodePro Analytix : http://code.google.com/javadevtools/
download-codepro.html


Phase
4
–
Revue
de
code

(Code
Pro
AnalyEx)


Phase 4 - Tests de
pénétration
1. S’adresser
à
des
cabinets/consultants
dont
le
méEer
est
la
gesEon
des

risques
informaEques.

2. Demander
des
rapports
orientés
méEers
Ø ne
pas
se
contenter
de
rapports
techniques

3. Demander
des
classiﬁcaEons
compaEbles
avec
votre
ouEl
de
bogue.
Ø Ne
pas
u@liser
des
référen@els
non
standards

4. Demande
un
transfert
de
compétences
sur
les
failles
pour
éduquer
les

acteurs
Ø Et
donc
savoir
comment
corriger


Phase 4 - Mettre en place des tableaux de décision


Phase
5
–
Release
/
Produc/on


• Introduction à la Sécurité Web avec Ruby on Rails
• Les 10 Risques sur les mobiles
• Microsoft SDL


• Introduction à la Sécurité Web avec Ruby on Rails
• Les 10 Risques sur les mobiles
• Microsoft SDL

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


ASFWS 2011 - Microsoft SDL dans un monde Java

Recomendados

Recomendados

Más contenido relacionado

Más de Cyber Security Alliance

Más de Cyber Security Alliance (20)

ASFWS 2011 - Microsoft SDL dans un monde Java