Comment inclure la scurit dans vos appels doffre

Comment inclure la sécurité dans vos appels d'offre ? Code Session : SEC 203 Philippe BERAUD Consultant Architecte Direction Technique Microsoft France philippe. beraud@microsoft. com Eric Mittelette Division Plateforme et Ecosystème Microsoft France ericmitt@microsoft. com

Objectif de la session Vous sensibiliser au fait que la sécurité (du code et de vos applications et de vos services en ligne) n’arrive pas par hasard Définir les principes d’établissement d’un processus pour la sécurité dans vos projets et la façon de l'inclure dans vos appels d'offres …Illustrée au travers d’un exemple concret : Security Development Lifecycle (SDL) Considérer l'application de ces principes dans le contexte du Mouvement agile 3

Sommaire Développement sécurisé, pourquoi ? Pour quoi ? Security Development Lifecycle (SDL) Mouvement agile "SDL for Agile" 4

Pourquoi et pour quoi ? Les attaques se déplacent… …et le paysage change Microsoft Security Intelligence Report (SIR) – vol 7 (01 -07 2009) http: //www. microsoft. com/sir 6

Objectifs d’un logiciel sécurisé Pour tout système et PAS uniquement pour des systèmes de sécurité Les 3 grands classiques pour les logiciels : "CIA" Confidentialité, Intégrité, Disponibilité Et les autres Authentification (vs. identification), Non répudiation, Anti-rejeu, Respect de la vie privée Notion relative au contexte 7

Pas simplement des technologies… 9

Qu’est-ce qu’une vulnérabilité ? Une vulnérabilité est une faiblesse inhérente d’un objet En informatique, une faiblesse dans un logiciel peut menacer la confidentialité, l’intégrité ou la disponibilité du bien On peut distinguer Les fautes de conception Les fautes d’implémentation Les fautes d’utilisation Une vulnérabilité peut être mise en évidence par des variations sur les entrées du logiciel 10

Qu’est-ce qu’une faute de conception ? Le logiciel est vulnérable avant même sa réalisation Exemples de vulnérabilités inhérentes des algorithmes de chiffrement Involontaire : algorithme faible par conception Volontaire : introduction de portes dérobées (backdoor) dans l’algorithme Exemple de vulnérabilité d’un logiciel IHM (Web) de configuration à distance non protégée Possibilité de reconfigurer le logiciel à distance 11

Qu’est-ce qu’une faute d’implémentation ? Vulnérabilités introduites (volontairement ou non) dans le code source du système Lors de l’introduction volontaire de vulnérabilités, on parle de portes dérobées Lors d’une introduction involontaire, on parle de failles Selon leur gravité, ces problèmes peuvent être utilisés pour récupérer de l’information, faire planter le système affecté (Déni de service ou Do. S), prendre le contrôle du système affecté Dans ce dernier cas, on dit que la vulnérabilité est "exploitable" 12

Pourquoi les développeurs écrivent des logiciels vulnérables ? Les logiciels ne sont pas conçus pour être utilisés dans un environnement hostile Les développeurs sont des humains et les hommes font des erreurs !! La majorité des développeurs n’ont pas été formés pour écrire du code sécurisé Cf. 2009 CWE/SANS Top 25 Most Dangerous Programming Errors : http: //cwe. mitre. org/top 25, http: //www. sans. org/top 25 -programmingerrors/ 14

Nécessité de changer Les logiciels, comme toute création humaine, comportent des erreurs, dont certaines touchent à la sécurité (=vulnérabilité) La "simple recherche des bogues" ne rend pas un logiciel sécurisé !! Il est IMPERATIF de réduire la probabilité que des défauts soient entrés dans la conception et le code… L'ouverture des systèmes d'information vers Internet comporte de nombreux bénéfices mais s'accompagne aussi d'inconvénients, dont certains liés à la sécurité : les vulnérabilités découvertes dans les technologies utilisées, les fautes de conception et d'implémentation, etc. exposent directement l'entreprise à des attaques 15

Nécessité de changer Principales menaces pour les logiciels client Attaques locales– une application non approuvée sur la machine locale exploite une application approuvée Attaques fondées sur les vers – particulièrement sur les sockets ouverts par défaut Compromission cachée - réseaux de zombies, logiciels espions, publiciels Principales menaces pour les logiciels serveur Compromission à distance via un socket anonyme Elévation de privilège d'un utilisateur authentifié Ennemi public n° 1 : Débordement de tampon (CWE-119) 16

Nécessité de changer Les services en ligne sont différents Les menaces de type serveur s'appliquent, mais sont atténuées par l'infrastructure Les vulnérabilités de type ver sont rares Code presque toujours managé – pas de débordement de tampon Principales menaces pour les services en ligne Utilisation du service comme un vecteur d'attaque des clients (XSS) Faille dans l'authentification et le contrôle d'accès (XSRF) Attaques sur le serveur (injection SQL, upload de fichier) Ennemis publics n° 1 et n° 2: Injection SQL (CWE-79) et Cross-site Scripting (XSS, CWE-89) Cf. OWASP Top 10 Most Critical Web Application Security Risks (2010 RC 1) : http: //www. owasp. org/index. php/Top_10 Cf. Microsoft SDL "Quick Security References" (QSRs) : http: //go. microsoft. com/? linkid=9706129 17

Nécessité de changer Les entreprises doivent passer/imposer à un processus de développement de logiciels plus strict, c'est-à-dire centré sur la sécurité 18

Perspective de l’attaquant Recherche des vulnérabilités qui peuvent exploitées pour pouvoir entreprendre une attaque Les vulnérabilités et les attaques résultantes sont simplement un vecteur/moyen pour une fin Compte tenu de l’asymétrie des positions, l’état réel de la sécurité d’un logiciel est principalement fonction du point de vue de l’attaquant 20

Perspectives du défenseur Les menaces ne peuvent pas être comprises à partir de la perspective de l’attaquant Avant de commencer l'ingénierie, et ensuite, il est impératif de comprendre les menaces qui pèsent… Revues de conception Sécurité : détection de vulnérabilités dans l’architecture du logiciel Revues de code Sécurité, analyses statiques de code et injection de fautes (Fuzzing) : détection de vulnérabilités dans le code de base Tests de pénétration : tentative de se mettre à la place de l’attaquant et de réussir une intrusion Règle n° 1 – Il n’y a PAS de règles 21

Impératifs de changement Nécessite de prendre en compte la sécurité Dès l’initialisation du processus, pendant la conception et le développement, pendant le déploiement Nécessite de continuer l’effort de sécurité jusqu‘à la fin du processus de développement, à chaque étape clé de la révision du logiciel La sécurité du code ne se met pas en œuvre en une seule fois (erreur classique : à la fin du projet par exemple) ; Elle fait partie intégrante du cycle de vie des projets Il s’agit d’un processus répétitif et itératif Qui n’est jamais fini et doit être corrigé, testé et amélioré régulièrement Qui nécessite pour cela le support de l’exécutif à son plus haut niveau Qui inclut la formation des développeurs Qui propose des éléments de mesure et de transparence La sécurité (du code) absolue est inatteignable, c’est un voyage, pas une destination (Cf. An 2000 sans date butoir) 22

Illustration Microsoft Security Development Lifecycle (SDL) Conceptualisé en 2002 avec l'initiative Trustworthy Computing http: //www. microsoft. com/mscorp/execmail/2002/07 -18 twc. mspx Mis en place à partir de 2004 de façon obligatoire L'équipe Secure Windows Initiative (SWI) en assure le développement, la maintenance et les améliorations : optimisation(s) et évolution(s) tous les 6 mois grâce à la rétroaction, l'analyse et l'automatisation Documenté dès 2005 http: //msdn 2. microsoft. com/en-us/library/ms 995349. aspx 23

Efficacité de SDL Quelques chiffres 94 % des vulnérabilités ciblées au niveau de la couche application SDL produit des améliorations de sécurité mesurables pour Microsoft Réduction des failles de sécurité de 91% dans SQL Server Réduction des failles de sécurité de 45% dans Windows Réduction des failles de sécurité de 35% dans Internet Explorer Impact majeur dans les services en ligne également Les sites non-SDL (développement tierce) ont des taux beaucoup plus élevés d'incidents de sécurité 24

SDL En bref Objectifs Réduire le nombre et la gravité des vulnérabilités logicielles Composants Bonnes pratiques, processus, standards, activités/tâches de sécurité, outils Obligation d'application en interne pour les logiciels susceptibles D'êtres utilisés pour stocker, traiter et/ou transmettre des informations personnelles et sensibles (PII) D'êtres utilisés en environnements d'entreprise De communiquer sur Internet ou sur d'autres réseaux 25

SDL Approche Ajout d'une série d'activités et de tâches relatives à la sécurité à chacune des phases de vos processus Intégration de mesures permettant d'améliorer la sécurité des logiciels sans remettre en cause l’organisation actuelle Ajout de points de contrôle de sécurité bien définis et des tâches relatives à la sécurité 26

SDL Principes et processus Paradigme PD 3+C Paradigme SD 3+C Respect de la vie privée dès la conception Respect de la vie privée par défaut Respect de la vie privée dans le déploiement s Sécurité dès la conception Sécurité par défaut Sécurité du déploiement Communications 27

Efficacité des éléments du SDL L'équipe SWI s’accorde à dire que la modélisation des menaces est le composant le plus important du SDL Les tests de pénétration ne constituent pas la meilleure façon de parvenir à un niveau de sécurité satisfaisant Centrées sur la modélisation des menaces, les révisions de code et l'utilisation d'outils automatisés, ainsi que des tests de robustesse offrent une bonne approche L'expérience de Microsoft montre que le SDL est efficace pour réduire le nombre de vulnérabilités en matière de sécurité SDL sert aussi à réduire potentiellement la gravité des vulnérabilités restantes 28

Un zoom sur la modélisation des menaces Principe fondateur : d’aucun ne peut dans la pratique construire un système sécurisé jusqu'à ce qu‘il comprenne les menaces qui pèsent sur celui-ci Vision/Objectifs Identifier les menaces relatives à un système Découvrir les défauts de conception de sécurité Mettre en place les contre-mesures (fonctionnalités de sécurité) adaptées et permettre ainsi d'établir la base des spécifications de conception en matière de sécurité Réduire les risques 29

Un zoom sur la modélisation des menaces Bénéfices directes en terme de sécurité Constitution d’une stratégie de sécurité, socle de gestion du risque du système tout au long de son cycle de vie de développement et au-delà, établissement de programmes de test de sécurité bien conçus Mais également… Permet de recher des erreurs non forcément liées à la sécurité Permet d'identifier les erreurs de conception complexes 30

Processus de modélisation des menaces 31

Outil SDL Thread Modeling v 3. 1 en téléchargement gratuit http: //msdn. microsoft. com/en-us/security/sdl-threat-modeling-tool. aspx Objectif Transformer la modélisation des menaces d’un processus dirigée par un expert à un processus que tout architecte logiciel peut conduire avec pertinence Principales fonctionnalités Conseils dans la définition/le dessin des diagrammes de menaces (DFD) Analyse interactive et guidée des menaces et contre-mesures Intégration avec Microsoft Visual Studio Team Foundation Server et les systèmes de suivi des bogues Capacités robustes de génération d'états 32

Mise en œuvre simplifiée de SDL Quelques idées fausses reçues à propose de SDL 34

Ce qu'il faut en retenir En termes d'exigences lors de l'appel d'offres SDL Simplifié définit une collection de 16 activités principales obligatoires… …et un série d'options laissées à la discrétion des projets et de leur nature En guise de préalable : 35

Ce qu'il faut en retenir En termes d'exigences lors de l'appel d'offres 36

Ce qu'il faut en retenir En termes d'exigences pour la réception Une fois transformée en questions, l'annexe O de Microsoft SDL 4. 1 a peut servir de trame Prévoir l'archivage de la solution et la mise en place un plan de réponse 37

Ce qu'il faut en retenir En termes de ROI… L'adoption de SDL par d'autres entreprises ne doit pas accroitre excessivement les coûts du développement de logiciels D'après l'expérience de Microsoft, les avantages procurés par des logiciels mieux sécurisés (moins de correctifs, plus de satisfaction client, etc. ) l'emportent sur ces coûts additionnels… …la correction précoce des vulnérabilités conduit à réduire les dépenses en termes de ressources de développement et de maintenance globale 38

Méthodes agiles Depuis 1991, RAD (Rapid Application Development), (RAD 2, DSDM (Dynamic System Development Method), ) XP (e. Xtreme Programming), SCRUM, MSF for Agile Software Development et d'autres Cf. Session Tech. Days 2009 IND 110 "Grille de lecture des méthodes agiles" http: //www. microsoft. com/france/vision/mstechdays 09/Webcast. aspx ? EID=cf 643 ad 4 -e 4 be-4649 -b 3 cd-0055 cb 4 f 354 c la dernière décennie qui a vue à une utilisation accrue des méthodes agiles Le mouvement agile aura pris une vingtaine d'années pour bousculer les méthodes classiques Cf. 39

Méthodes agiles Le Manifeste agile, une formalisation consensuelle par les auteurs de ces méthodes agiles http: //agilemanifesto. org L'emphase est mise sur la création rapidement des fonctions qui satisfont aux exigences spécifiques et directes des clients Les "artefacts", tels que la documentation nécessitant des mises à jour fréquentes, sont à éviter 40

Méthodes agiles Organisé, itératif et à temps contraint, développement agile ne signifie pas un développement anarchique de type “just sit down and code” Cycle de développement itératif, incrémental et adaptatif avec une base de pratiques (ressources humaines, pilotage de projet, qualité de la production) Le cycle phasé unique est remplacé par de nombreux "sprints" Chaque sprint couvre un petit ensemble de fonctionnalités à partir du "backlog" projet Ces fonctionnalités sont conçues, mises en œuvre, testées et mises à disposition 41

SDL et les méthodes agiles SDL tel qu'abordé jusque là nécessite que toutes les tâches soient terminées avec de diffuser/déployer une solution : SDL "Classique" est conçu pour un processus séquentiel Chaque "sprint" constitue une release…et remplir toutes les exigences/activités de SDL/FSR pour chacun d'eux peut nécessiter autant de charge que pour le sprint en tant que tel ! Avec également peu d'intérêt de réaliser ces tâches systématiquement Les exigences, l'architecture et la conception évoluent au cours du temps La base de code peut demeurer inchangée Le modèle de menaces peut devenir rapidement daté Les connexions vers des tiers et la sensibilités des données peuvent ne pas être connues immédiatement Etc. 42

SDL et les méthodes agiles SDL pour le développement Agile : SDL for Agile http: //msdn. microsoft. com/en-us/library/ee 790621. aspx Personnalisation et instrumentation des pratiques essentielles de SDL "Classique" sur un socle stable (et évolutif) autour de 3 catégories d'exigences SDL : Chaque-Sprint, "Seau", Une-fois Modèle MSF Agile + processus SDL pour Microsoft Visual Studio Team System 2008 43

SDL for Agile Activités de type Chaque-Sprint Cf. Annexe P de Microsoft SDL 4. 1 a Doivent être effectuées pour chaque sprint Mettre à jour le modèle de menaces pour toute modification de conception dans le sprint Les activités restantes sont automatisées ou en continue : Suivre les exigences et bonnes pratiques de SDL (cryptographie, le filtrage, la validation entrée, garantir l'utilisation sécurisée de SQL, etc. ) Ne pas utiliser les APIs interdites en code natif Exécuter les outils d'analyse statique dans le cadre du processus de "check-in/build" et résoudre les problèmes identifiés Utiliser les compilateurs, éditeurs de liens, bibliothèques et Frameworks dans leur version la plus récente Utiliser les drapeaux requis par SDL au niveau des compilateur et éditeur de liens Se tenir à jour avec une formation sur la sécurité (1 an) 44

SDL for Agile Activités de type "Seau" Cf. Annexe Q de Microsoft SDL 4. 1 a Les activités les plus consommatrices sont "dans le seau" Il ne s'agit pas de "phases" et elles ne sont pas exécutées en séquence Elles sont regroupées en 3 catégories Revue de conception : modélisation des menaces approfondie Vérification de la sécurité : exécuter les outils d'injection, conduire des revues de code manuelle et automatisée Planification de la réponse : définir la barre des bogues de sécurité/respect de la vie privée, créer des documents de supports (si nécessaire) Les équipes priorisent le pool d'activités sur plusieurs sprints Au moins une activité de chacune des 3 catégories doit être réalisée dans chaque sprint Toute activité non réalisée au cours des 6 derniers mois est requise 45

SDL for Agile Activités de type Une-Fois Cf. Annexe R de Microsoft SDL 4. 1 a Généralement effectuées qu'une seule fois Pourquoi ? Répétition nécessaire, doivent avoir lieu au début du projet, non possibles dès le début du projet Principalement des activités de documentation : Etablir/configurer le système de suivi des bogues Définir le modèle de menaces de référence (baseline) Etablir un plan de réponse de sécurité Doivent être accomplies dans le min(3 sprints, 3 mois) 46

SDL for Agile Revue finale de sécurité (FSR) Se produit à la fin de chaque sprint Points de contrôle : Toutes les activités de type Chaque-Sprint ont été réalisées Aucune activité de type Une-fois n'a dépassé la date limite Au moins activité de type Une-fois de chaque catégorie de a été réalisée Aucune activité de type "Seau" ne dépasse le délai de 6 mois Aucun bogue de sécurité/respect de la vie privée ouvert ne dépasse le seuil de gravité Les projets agiles sont livrés sans une FSR complète (toutes les activités SDL) – c'est un risque accepté 47

En guise de conclusion La sécurité dans le cycle de développement (agile ou non) n'en est qu'à ses débuts… 70% % des entreprises réalisant des tests de sécurité 20% 10% 0% Design Implementation Verification (pre release) 49 Operations (post release)

En guise de conclusion Vos projets peuvent bénéficier de SDL ! La mise en œuvre SDL n'est pas un processus phasé lourdement consommateur Cycles itératifs dès l'initialisation du projet…et jusqu’à la phase de maintenance SDL peut s'appliquer à vos projets Même s'ils sont sous-traités Même si vous avez recours à des méthodes agiles Même si vos cycles sont aussi courts que deux semaines Les outils SDL (for Agile) (de test et de mesures) sont disponibles Une équipe de sécurité formée est un plus 50

Modèle d’optimisation SDL Introduit en novembre 2008 Destiné à faciliter la mise en œuvre progressive, cohérente et économiquement viable de SDL Permettre l’auto-évaluation et la constitution d’une feuille de route vis-à-vis de l’adoption de SDL • La sécurité est réactive Elémentaire • La notion de risque n'est pas définie Standardisé • La sécurité est proactive • Le risque est compris Avancé • La sécurité est intégrée • Le risque est contrôlé • La sécurité est spécialisée • Le risque est minimisé Dynamique 51

Modèle d’optimisation SDL Exemple 52

Les sessions connexes dans le cadre des Microsoft Tech. Days 2010 3 autres sessions pour faire un point ensemble Session "Une méthode d'évaluation de la sécurité Web" Lundi 8 février, à revivre prochainement en Session Web Session "Audit sécurité d'une application. NET : le cas OCS 2007 (Office Communications Server)" Lundi 8 février, à revivre prochainement en Session Web Session "Fun with fuzzing. . . SDL reloaded !" Mercredi 10 février de 16 h 00 à 17 h 00 53

Former vos équipes à SDL Cours d'initiation à SDL : Kit de démarrage Microsoft Security Development Lifecycle (SDL) http: //msdn. microsoft. com/en-us/security/ee 361993. aspx A destination des chefs de projets, architectes, et développeurs Principes de conception sécurisée, principes d'implémentation sécurisée, principes de modélisation des menaces, compréhension des vulnérabilités, analyse de code, revue de code de sécurité, outillage, etc. Ateliers virtuels en ligne http: //msdn. microsoft. com/en-us/aa 740391. aspx Ex. Défendre votre code avec des conseils de sécurité que chaque développeur se doit de connaître, écrire du code managée sécurisée avec Visual Studio Team System, etc. 54

Outillage gratuit SDL Centre des outils SDL : Outillez votre processus de développement structuré ET sécurisé ! http: //go. microsoft. com/? linkid=9681360 SDL Threat Modeling Tool 3. 1 SDL Process Template for VSTS MSF-Agile plus SDL Process Template for VSTS 2008 Microsoft Bin. Scope Binary Analyzer Fx. Cop Code Analysis Tool. NET (CAT. NET) 2. 0 CTP Microsoft Mini. Fuzz File Fuzzer Web Protection Library (WPL) v 1 CTP Web Application Configuration Analyzer (WACA) v 1 CTP Etc. 55

Etre accompagné sur SDL Pro Network lancé en Novembre 2008 pour accompagner les entreprises dans la mise en œuvre des activités SDL http: //blogs. msdn. com/sdl/archive/2008/09/18/about-the-sdl-pronetwork. aspx Trois catégories d'entreprises : "Formation", "Conseil" et "Outils et solutions d'automatisation" http: //msdn. microsoft. com/en-us/security/dd 219581. aspx 56

Ressources SDL Modèle d'optimisation SDL http: //msdn. microsoft. com/en-us/security/sdl-model-optimization. aspx Framework d'intégration graduelle de la dimension Sécurité au sein de vos projets : élémentaire, standard, avancé, dynamique http: //www. microsoft. com/downloads/details. aspx? Family. ID=90 a 40 2 a 0 -ca 84 -42 a 2 -b 2 ab-1 ce 8 de 999582&displaylang=en Guide du processus SDL 4. 1 a http: //msdn. microsoft. com/en-us/security/sdl-process-guidance. aspx Intègre le support des méthodes agiles : SDL/A Livre blanc : http: //go. microsoft. com/? linkid=9695287 Modèle de processus Microsoft SDL pour VSTS http: //msdn. microsoft. com/en-us/security/sdl-vsts-template. aspx Livre blanc : http: //go. microsoft. com/? linkid=9683340 Guide de modélisation des menaces pour les services d'infrastructure http: //go. microsoft. com/fwlink/? Link. Id=154010 57

Pour aller plus loin sur SDL et la sécurité… Quelques livres blancs et articles… Streamline Security Practices For Agile Development http: //msdn. microsoft. com/en-us/magazine/dd 153756. aspx How to Manually Integrate the SDL Process Template into an existing Visual Studio project http: //go. microsoft. com/? linkid=9683340 Microsoft Silverlight 1. 0: An SDL Implementation Story http: //go. microsoft. com/? linkid=9695422 Security Considerations for Client and Cloud Applications http: //go. microsoft. com/? linkid=9694872 Microsoft Application Architecture Guide, 2 nd Edition http: //www. microsoft. com/downloads/details. aspx? familyid=CE 40 E 4 E 1 -9838 -4 C 89 -A 197 -A 373 B 2 A 60 DF 2&displaylang=en 60

Pour aller plus sur SDL et la sécurité… Quelques ouvrages… Security Development Lifecycle http: //www. microsoft. com/learning/en/us/book. aspx? ID=8753 Threat Modeling http: //www. microsoft. com/learning/en/us/Books. aspx? ID=6892 Hunting Security Bugs http: //www. microsoft. com/learning/en/us/book. aspx? ID=8485 Writing Secure Code, Second Edition http: //www. microsoft. com/learning/en/us/book. aspx? ID=5957 Writing Secure Code for Windows Vista http: //www. microsoft. com/learning/en/us/book. aspx? ID=10723 61

Pour aller plus loin sur SDL et la sécurité… Site Web SDL http: //www. microsoft. com/sdl Sites Web SDL sur MSDN Sécurité http: //msdn. microsoft. com/fr-fr/security/msdn. mecapoulets. aspx http: //msdn. microsoft. com/fr-fr/security/dd 285369. aspx Site US : http: //msdn. microsoft. com/en-us/security/cc 448177. aspx Weblog SDL Team http: //blogs. msdn. com/sdl/ Weblog Code Analysis and Code Metrics http: //blogs. msdn. com/fxcop/ Weblog Michael Howard http: //blogs. msdn. com/michael_howard/ 62

Pour aller plus loin sur OWASP The Open Web Application Security Project (OWASP) http: //www. owasp. org OWASP Software Assurance Maturity Model (SAMM) http: //www. owasp. org/index. php/SAMM http: //www. opensamm. org/ OWASP Application Security Verification Standard (ASVS) http: //www. owasp. org/index. php/ASVS OWASP Enterprise Security API (ESAPI) http: //www. owasp. org/index. php/ESAPI OWASP Code Review Guide http: //www. owasp. org/index. php/Code_Review_Guide OWASP Testing Guide http: //www. owasp. org/index. php/Testing_Guide OWASP Top 10 Most Critical Web Application Security Risks (2010 RC 1) http: //www. owasp. org/index. php/Top_10 Etc. 63

Pour aller plus loin sur les méthodes agiles… Site Web du Manifeste Agile http: //agilemanifesto. org Site Web de l’Alliance Agile http: //www. agilealliance. org Site Web Scrum http: //www. controlchaos. com http: //www. scrum. org Site Web de l'Alliance Scrum http: //www. scrumalliance. org Site Web du French Scrum User Group http: //www. frenchsug. org 64

Pour aller plus loin sur les méthodes agiles… Site Web MSDN Développement agile http: //www. microsoft. com/agile Microsoft Shared. View, pour les organisations de type Front Office / Back Office (Nearshore, Offshore) Scrum for Team System Etc. Site Web Microsoft Solutions Framework (MSF) http: //www. microsoft. com/msf MSF for Agile Software Development Process Guidance & Template Scrumptious Livre blanc "Tools for Agility - A White paper by Kent Beck, Three Rivers Institute" Etc. 65

Pour aller plus sur les méthodes agiles… Quelques ouvrages… Agile Portfolio Management http: //www. microsoft. com/learning/en/us/book. aspx? ID=12514 The Enterprise and Scrum http: //www. microsoft. com/learning/en/us/book. aspx? ID=10024 Agile Project Management with Scrum http: //www. microsoft. com/learning/en/us/book. aspx? ID=6916 66

Questions / Réponses

Votre potentiel, notre passion TM © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U. S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 68