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.chSunday, 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 2Sunday, October 30, 11

Agenda • La souris, le fromage et le chat • Qu’est-ce que Microsoft SDL ? • SDL Warrior • Duke in the game 3Sunday, October 30, 11

Agenda • La souris, le fromage et le chat • Qu’est-ce que Microsoft SDL ? • SDL Warrior • Duke in the gameSunday, October 30, 11

Pourquoi ? Les hackers sont astucieuxSunday, October 30, 11

Le cout est importantSunday, October 30, 11

Soyons donc précis !Sunday, October 30, 11

Security Development LifeCycle(SDL) § 2004 : « Stop Security Kiddies » § Méthode de développement sécurisée de tous les produits MicrosoA ! Sunday, October 30, 11

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)Sunday, October 30, 11

Sunday, October 30, 11

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 menacesSunday, October 30, 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.Sunday, October 30, 11

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éeSunday, October 30, 11

Spécifications – Recommandations de sécuritéSunday, October 30, 11

Spécifications – Recommandations de sécurité 1. Me_re en place le plan de sécuritéSunday, October 30, 11

Spécifications – Recommandations 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 : Sunday, October 30, 11

Spécifications – Recommandations 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 : – Il doit être compaEble STRIDESunday, October 30, 11

Spécifications – Recommandations 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 : – Il doit être compaEble STRIDE – Perme_re d’idenEﬁer la cause du BugSunday, October 30, 11

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 Sunday, October 30, 11

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)Sunday, October 30, 11

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 Sunday, October 30, 11

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 WebSunday, October 30, 11

Calcul ﬁnal DREAD DAMAGE REPRODUCIBILITY EXPLOITABILITY AFFECTED USERS 5 DISCOVERABILITYSunday, October 30, 11

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 codeSunday, October 30, 11

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 possibleSunday, October 30, 11

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.Sunday, October 30, 11

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 vieSunday, October 30, 11

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)…Sunday, October 30, 11

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 vouluSunday, October 30, 11

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 incidentSunday, October 30, 11

Le problèmeSunday, October 30, 11

0x01Sunday, October 30, 11

0x01 Régler 80% des problèmes avec 20% d’effortSunday, October 30, 11

0x10b • Se jeter à l’eau :Sunday, October 30, 11

0x10b • Se jeter à l’eau : Corrigez tous les problèmes que vous pouvez trouverSunday, October 30, 11

0x10b • Se jeter à l’eau : Corrigez tous les problèmes que vous pouvez trouver Si vous n’êtes pas prêts à corriger, ne cherchez pas !Sunday, October 30, 11

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+JavaSunday, October 30, 11

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….Sunday, October 30, 11

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é dune 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 !Sunday, October 30, 11

Poli/que de sécurité logicielleSunday, October 30, 11

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 • 0x10bSunday, October 30, 11

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 !Sunday, October 30, 11

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@ngerSunday, October 30, 11

Phase 3 -‐ Cookies Sunday, October 30, 11

Phase 3 -‐ Valida/onsSunday, October 30, 11

Phase 3 – SQL Sunday, October 30, 11

Phase 3 – Pour aller plus loin OWASP Enterprise Security APISunday, October 30, 11

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.htmlSunday, October 30, 11

Phase 4 – Revue de code (Code Pro AnalyEx)Sunday, October 30, 11

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 corrigerSunday, October 30, 11

Phase 4 - Mettre en place des tableaux de décisionSunday, October 30, 11

Phase 5 – Release / Produc/onSunday, October 30, 11

• Introduction à la Sécurité Web avec Ruby on Rails • Les 10 Risques sur les mobiles • Microsoft SDLSunday, October 30, 11

• Introduction à la Sécurité Web avec Ruby on Rails • Les 10 Risques sur les mobiles • Microsoft SDL Il ny a quune façon déchouer, cest dabandonner avant davoir réussi [Olivier Lockert]Sunday, October 30, 11

Microsoft SDL dans un monde Java

by Sébastien GIORIA

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 23

Statistics

Microsoft SDL dans un monde Java Presentation Transcript

http://paper.li	20
http://a0.twimg.com	3