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) [email protected]
Dec 25, 2014
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) [email protected]
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 ([email protected])
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]