1

Microsoft Security Development LifeCycle :

par ou commencer ?

8 Février 2011- Paris - Palais des congrès

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

2

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

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é

Qui suis-je ? 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  Domaines  de  prédilec0on  :    ü  Web,    WebServices, Insécurité du Web.  

Twitter :@SPoint

Consultant Sécurité Sénior au sein du cabinet d’audit

3

Votre  applica,on  sera  piratée  

 Laissez  moi  vous  reme5re  sur  la  bonne  voie  

site:xssed.com  mycompany.com  

site:mycompany.com    

hacked  

OUI

NON

NON

OUI

OK, mais

alors ?

4

Agenda

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

5

Pourquoi ?

Les hackers sont astucieux

6

Le cout est important

7

Soyons donc précis !

8

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

Microsoft !

Produit   1er   2ème   3ème  

Système  d’exploita0on  

Linux  Kernel  (129)  

Windows  Server  2008  (93)  

Apple  IOS  (35)  

SGBD   Oracle  (36)   Mysql  (3)   MS-­‐SQL  Server  (1)  

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

Vainqueurs a la CVE 2010

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

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.

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

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

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

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)

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  (Informa0ons  Disclosure)  

Menaces  qui  impliquent  l’exposi0on  des  informa0ons  à  des  individus  qui  ne  sont  pas  censés  y  accéder.    

Déni  de  service  (Denial  of  Service)  

A^aques  (DoS)  qui  empêchent  un  u0lisateur  autorisé  d’accéder  aux  services    

Éléva0on  de  privilège  (Eleva0on  of  Privilege)  

Menace  qui  permet  à  un  u0lisateur  de  s’octroyer  une  autorisa0on  supplémentaire    

Réduc0on  de  la  surface  d’a^aque.    (A^ack  Surface  Reduc0on.  )  

Il  est  important  d’iden0fier  la  surface  d’a^aque,  même  si  les  interfaces  qui  y  sont  exposées  ne  sont  pas  des  vulnérabilités  au  sens  technique    

17

DREAD ? Catégorie   Descrip,on  

Dommage  Poten0el  (Damage)  

Si  la  menace  se  produit,  quel  est  le  niveau  de  dommage  :  0  –  Rien  10  –  Total  compromission  

Reproduc0ble  (Reproducibility)  

Quelle  est  la  complexité  pour  reproduire  la  menace  0  –  quasi-­‐impossible  10  –  pas  d’authen0fica0on,  a  travers  un  navigateur  Web  

Exploita0on  (Exploitability)  

De  quoi  a-­‐t-­‐on  besoin  pour  l’exploita0on    0  –  connaissance  en  programma0on,  des  ou0ls,  …  10  –  juste  un  navigateur  Web  

U0lisateurs  touchés  (Affected  Users)  

Combien  d’u0lisateurs  seront  affectés    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  

18

Calcul final DREAD

DAMAGE REPRODUCIBILITY EXPLOITABILITY AFFECTED USERS DISCOVERABILITY

5

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

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

21

Diffusion

1. Effectuer une revue des manipulations de données privées

2. Préparer les équipes au 2ème mercredi du mois

3. Effectuer la revue finale de sécurité

4. Publier la version et archiver une copie.

Loi de Murphy

Dernière version des documents projets et risques à destination de l’équipe sécurité.

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

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)…

25

0x01

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

26

0x10b

•  Se jeter à l’eau :

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

Je corrige tous les problèmes de sécurité que je trouve !

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

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  

 

29

Le problème

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/

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

•  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

•  Quel niveau de confiance puis-je avoir dans une application

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

Aide à la revue de code

Chapitre sécurité des contrats de développement ou des appels d’offres !

33

Modélisation des attaques •  Utilisation des méthodologies :

•  STRIDE •  ISO 27005 •  SDL Threat Modeling Tool •  …..

• Garder à l’esprit : •  0x01 : la règle du 80/20

•  0x10b

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

Garder a l’esprit l’impact métier !

34

Mettre en place des tableaux de décision

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

36

Exemple CWE25

37

OWASP Enterprise Security API

37

Custom Enterprise Web Application

Enterprise Security API

Au

then

tica

tor

Use

r

Acc

essC

on

tro

ller

Acc

essR

efer

ence

Map

Val

idat

or

En

cod

er

HT

TP

Uti

liti

es

En

cryp

tor

En

cryp

ted

Pro

per

ties

Ran

do

miz

er

Ex

cep

tio

n H

and

lin

g

Log

ger

Intr

usi

on

Det

ecto

r

Sec

uri

tyC

on

fig

ura

tio

n

Existing Enterprise Security Services/Libraries

38

Revue de code •  Code Managé :

•  CAT.NET •  FxCop

• Microsoft Source Code Analyzer for SQL Injection. • OWASP Code Crawler •  CodePro AnalytiX (Java)

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

41

ET  APRES  ?    

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 !

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]