Comment inclure la sécurité dans vos appels d'offre ?

Présentation au sujet: "Comment inclure la sécurité dans vos appels d'offre ?"— Transcription de la présentation:

1 Comment inclure la sécurité dans vos appels d'offre ?
Code Session : SEC203 Philippe BERAUD Consultant Architecte Direction Technique Microsoft France Eric Mittelette Division Plateforme et Ecosystème Microsoft France

2 Description de la session
Quelles sont les exigences que vous devez inclure dans vos appels d'offre pour que la solution retenue ne devienne votre talon d'Achille sécuritaire ?

3 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

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

5 Pourquoi et pour quoi ? …Sur la nécessité de la sécurité du code
19 novembre 2004 Pourquoi et pour quoi ? …Sur la nécessité de la sécurité du code Les systèmes d’information remplissent des fonctions critiques dans les entreprises et états modernes Ordinateurs, réseaux d’entreprise, systèmes de communication (PABX, réseaux télécom, satellites, etc.), infrastructures critiques (énergie, défense), systèmes embarqués, etc. Les entreprises doivent protéger leurs biens pour prospérer, voire survivre La sécurité informatique (et par voie de conséquence la sécurité du code) n’est qu’un pan de la sécurité de l’information, elle-même incluse dans la notion de sécurité Quelques biens à protéger Réputation, image, données, logiciels, matériel, documentation, etc. Le fait que nous soyons de plus en plus dépendants des systèmes d’information et que ceux-ci remplissent des fonctions critiques nécessite qu’ils offrent un bon niveau de sécurité. En effet, l’informatique fait son apparition dans de nombreux domaines qui nous touchent chaque jour : ordinateurs, réseaux de données ou de télécommunication, infrastructures critiques (centrales productrices d’énergie électrique, systèmes de défense de la nation), téléphones, assistants, voitures, électroménager, domotique,… Qui plus est, le fait que de plus en plus de différents périphériques convergent pour devenir des appareils numériques dotés de fonctions réseau intensifie le besoin d’application de mesures de sécurité au niveau de ces différents périphériques. La sécurité est désormais un enjeu vital. Nombreuses sont les entreprises qui ne peuvent pas travailler normalement, voire même risquent la faillite, si leur système d’information tombe en panne plusieurs jours ou est détruit. La sécurité informatique et du code en particulier, objet de ce module, n’est qu’un sous ensemble de la sécurité de l’information qui s’intéresse elle à des aspects non liés à l’informatique (comme l’ingénierie sociale, cette technique qui consiste à faire révéler à quelqu’un une information confidentielle en se faisant passer pour quelqu’un habilité à recevoir cette information). On se doit de protéger les biens « matériels » comme les équipements, la documentation, les logiciels, les données mais aussi les biens « immatériels » comme la réputation et l’image de l’entreprise. En effet, imaginez le site Web d’une entreprise de jouets pour enfants défiguré avec une image pornographique en page d’accueil. Rien ne l’empêche de produire ses jouets, de prendre des commandes, de les livrer mais l’atteinte à son image mettrait en danger son activité.

6 Pourquoi et pour quoi ? Les attaques se déplacent…
19 novembre 2004 Pourquoi et pour quoi ? Les attaques se déplacent… …et le paysage change Microsoft Security Intelligence Report (SIR) – vol 7 ( ) “Today over 70% of attacks against a company’s Web site or Web application come at the ‘Application Layer’ not the Network or System layer.” - Gartner Group

7 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 A LIRE Dans l’approche classique française, les fonctionnalités constituant le triptyque Confidentialité, Intégrité, Disponibilité sont appelées propriétés de sécurité. Confidentialité : Disponibilité et divulgation limitées de l’information manipulée aux seules entités autorisées Intégrité : absence d’altération ou de destruction de l’information manipulée Disponibilité : capacité à répondre à un instant précis, à être accessible dans des conditions définies de performance, d’horaires Le reste est considéré comme un ensemble de fonctions contributrices : Authentification (vs. identification) : vérification / validation d’une identité d’une entité Non répudiation : impossibilité de nier avoir participé à une transaction Anti-rejeu : impossibilité de rejouer une séquence d’événements ou d’actions enregistrés Concept émergent : respect de la vie privée (protection contre la découverte et la mauvaise utilisation de son identité)

8 Content Starter Set Logiciel sécurisé ? Qu’est-ce qui a été sécurisé ? Par rapport à quoi ? Par rapport à qui ? Contre quoi ? Pour combien de temps ? Jusqu’à quel niveau d’attaque ? … La sécurité est une notion relative à un contexte “The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.” Eugene H. Spafford,

9 Pas simplement des technologies…
A LIRE Que voyez-vous ? Une porte ouverte qui devrait être fermée. Attention, ce n’est pas en achetant une porte blindée que je résoudrai mon problème mais en faisant en sorte que les consignes soient respectées. La sécurité n’est certainement pas qu’une affaire de technologies.

10 Qu’est-ce qu’une vulnérabilité ?
CSO Summit 2006 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 © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

11 Qu’est-ce qu’une faute de conception ?
CSO Summit 2006 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 © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

12 Qu’est-ce qu’une faute d’implémentation ?
CSO Summit 2006 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 DoS), prendre le contrôle du système affecté Dans ce dernier cas, on dit que la vulnérabilité est "exploitable" Dans le "jargon" sécurité, un programme d’attaque utilisant une faille d’un système pour en prendre le contrôle ou le faire planter est appelé un "exploit". On parle de Remote exploit lorsque l’attaque est possible à distance et de Local exploit lorsqu'un accès préalable au système est nécessaire avant de pouvoir lancer l’attaque © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

13 Comment sont classifiées les vulnérabilités ?
CSO Summit 2006 Comment sont classifiées les vulnérabilités ? Common Vulnerabilities and Exposures (CVE) : dictionnaire des vulnérabilités de sécurité connues Initié lorsqu’une faille est découverte, un identificateur CVE-yyyy-nnn permet l'échange de données Common Weakness Enumeration (CWE) : dictionnaire unifié des typologies de faille logiciel Les identificateurs CVE permettent de référencer les exemples observés © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

14 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 CWE/SANS Top 25 Most Dangerous Programming Errors : OWASP Top 10 (2010 RC1): A1: Injection A2: Cross Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Failure to Restrict URL Access A8: Unvalidated Redirects and Forwards A9: Insecure Cryptographic Storage A10: Insufficient Transport Layer Protection "The 2009 CWE/SANS Top 25 Programming Errors project is a great resource to help software developers identify which security vulnerabilities are the most important to understand, prevent and fix." - Michael Howard, Principal Security Program Manager, Security Development Lifecycle Team Microsoft Corporation

15 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

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

17 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 RC1) : Cf. Microsoft SDL "Quick Security References" (QSRs) : OWASP Top 10 (2010 RC1): A1: Injection A2: Cross Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross Site Request Forgery (XSRF, CSRF) A6: Security Misconfiguration A7: Failure to Restrict URL Access A8: Unvalidated Redirects and Forwards A9: Insecure Cryptographic Storage A10: Insufficient Transport Layer Protection date

18 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é “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” - Sun Tzu, The Art of War

19 Déséquilibre attaquant - défenseur
[Title of the course] 11-Apr-17 Déséquilibre attaquant - défenseur …ou l’asymétrie des positions Principe n°1 : Le défenseur doit défendre tous les points ; l’attaquant peut choisir le point le plus faible Principe n°2 : Le défenseur ne peut défendre que ce qu’il connaît ; l’attaquant peut rechercher des points vulnérables Principe n°3 : Le défenseur se doit d’être vigilant en permanence ; l’attaquant peut attaquer quand il le veut Principe n°4 : Le défenseur doit respecter les règles ; l’attaquant peut faire ce qu’il veut Les media ont tendance à donner une image élitiste des hackers (au sens maintenant couramment admis d’attaquants). En fait, le prestige devrait revenir aux informaticiens qui défendent les systèmes d’informations car leur tâche est bien plus difficile que celle de l’intrus pour les raisons suivantes : La défense se doit d’être uniforme alors que l’attaque peut se faire en un seul point faible Le défenseur doit avoir des connaissances variées et mener une veille sécuritaire poussée là où l’attaquant peut se contenter de ne connaître qu’un seul hack (sans peut-être même comprendre comment il fonctionne) Le défenseur doit être vigilant en permanence alors que l’attaquant choisit quand il veut attaquer Le défenseur se doit de respecter la loi, ce qui limite ses moyens là où l’attaquant ne se gène pas… Copyright © Cyril Voisin. All rights reserved.

20 Perspective de l’attaquant
CSO Summit 2006 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 © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

21 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 “Fuzz Testing or Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed or semi malformed data injection in a automated fashion.” OWASP.org A LIRE La défense se doit d’être uniforme alors que l’attaque peut se faire en un seul point faible Le défenseur doit avoir des connaissances variées et mener une veille sécuritaire poussée là où l’attaquant peut se contenter de ne connaître qu’un seul hack (sans peut-être même comprendre comment il fonctionne) Le défenseur doit être vigilant en permanence alors que l’attaquant choisit quand il veut attaquer Le défenseur se doit de respecter la loi, ce qui limite ses moyens là où l’attaquant ne se gène pas… date

22 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) L'expérience de Microsoft et du secteur de l'édition de logiciels a montré que la création de logiciels fiables nécessite l'amélioration des processus tout au long du développement des applications. Souvent, la sécurité n'est pas considérée en priorité, et l'évaluation de la sécurité du produit est reléguée à une étape ultérieure du processus de développement. Bien que la mise en œuvre des mesures de sécurité à cette étape ultérieure présente des avantages, elle ne doit pas faire oublier que la sécurité fait partie intégrante du processus, et ce du début de la phase de conception au déploiement, en passant par le développement. En résumé, vous devez intégrer la sécurité dans le cycle de vie du développement de vos logiciels. La sécurité (du code) n’est pas une activité ponctuelle. On doit donc l’intégrer dans ses activités normales. Comme la sécurité absolue ne peut pas être atteinte, on donne souvent l’image d’un voyage, plutôt que d’une destination. En effet, on n’en a jamais fini avec la sécurité (du code) et il faut sans cesse évaluer son niveau, le corriger, tester sa conformité, etc. Enfin, pour ceux qui s’en rappellent, la gestion de la sécurité peut être comparée aux projets de passage à l’an 2000 : il faut travailler pour qu’il ne se passe rien ! Et malheureusement il n’y a pas de 1er janvier 2000 pour vérifier que tout s’est bien passé et considérer que tout est terminé.

23 Illustration Microsoft Security Development Lifecycle (SDL)
Conceptualisé en 2002 avec l'initiative Trustworthy Computing Faire de la sécurité une priorité, la traiter comme une fonctionnalité de base de nos produits et technologies… 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 2003–2004: Bill Gates writes “Trustworthy Computing” memo early 2002 “Windows security push” for Windows Server 2003 Security push and FSR extended to other products 2004: Microsoft Senior Leadership Team agrees to require SDL for all products that: are exposed to meaningful risk and/or process sensitive data : SDL is enhanced : “Fuzz” testing, code analysis, crypto design requirements, privacy, banned APIs, and more… Windows Vista is the first OS to go through full SDL cycle Now: Optimize the process through feedback, analysis and automation Begin to evangelize the SDL to the software development community Microsoft® Security Development Lifecycle Autre illustration non développée ici: OWASP SAMM (Software Assurance Maturity Model): date

24 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é

25 SDL En bref Objectifs Composants
Réduire le nombre et la gravité des vulnérabilités logicielles "Minimize security-related vulnerabilities in the design, code, and documentation and to detect and eliminate vulnerabilities as early as possible in the development life cycle" 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 A LIRE 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 l'emportent sur ces coûts additionnels : par exemple, moins de correctifs, plus de satisfaction client date

26 SDL Approche Un logiciel sécurisé est un sous-ensemble d’un logiciel de qualité…car il ne peut pas y avoir de qualité sans sécurité 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é A LIRE Pour y parvenir, l'approche consiste à ajouter 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é Postulat : il existe une équipe de sécurité centrale (à prévoir en interne ou en externe…) date

27 SDL Principes et processus
Paradigme SD3+C Sécurité dès la conception Sécurité par défaut Sécurité du déploiement Communications Paradigme PD3+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 Exigences Formation des base Analyse des risques de sécurité et de respect de la vie privée Définition des seuils de qualité et des critères de sortie Conception Modélisation des menaces Analyse de la surface d'attaque Implémentation Spécification des outils Mise en place/œuvre des bonnes pratiques et règles associées Non utilisation des APIs interdites Analyse statique Vérification Revue de code poussée Analyse dynamique / injection de fautes ciblée Vérification du modèle des menaces / surface d'attaque Revue des nouvelles menaces Diffusion/ Déploiement Plan de réponse Revue finale de sécurité (FSR) Archivage de la release Réponse de sécurité Exécution de la réponse Boucle de retour vers le processus de développement Cf. "Guide du processus SDL" 4.1a : La première étape, et la plus importante, dans le processus de sécurisation est de s'assurer que la sécurité fait partie intégrante du processus de développement complet. L'équipe SWI (Secure Windows Initiative) de Microsoft a adopté un ensemble de stratégies simple baptisé SD3+C. L'architecture SD3+C regroupe trois concepts principaux : la Sécurité dès la conception, la Sécurité par défaut et la Sécurité du déploiement. Ces concepts ont donné sa forme au processus de développement pour permettre la création de systèmes sécurisés. La sécurité dès la conception signifie que vous avez pris les mesures appropriées pour garantir que la conception globale du produit est sécurisée dès le début. Intégrez la modélisation des menaces dans la phase de conception et tout au long du projet afin d'identifier les vulnérabilités potentielles. Suivez les instructions relatives au test, au codage et à la conception sécurisés. La sécurité par défaut signifie que le produit diffusé est sécurisé dès son installation sans configuration supplémentaire. Si des fonctionnalités sont facultatives, désactivez-les par défaut. Si une fonctionnalité n'est pas activée, un intrus ne pourra pas utiliser celle-ci pour endommager votre produit. Assurez-vous que les comptes utilisateur nécessitent le moins de privilèges possible pour exécuter votre application. Ainsi, les conséquences d'un dommage sont moins graves que si un intrus a la possibilité d'exécuter un code nuisible sous un compte disposant des privilèges d'administrateur. Assurez-vous que des contrôles d'accès efficaces sont en place pour les ressources. La sécurité du déploiement signifie que le système est gérable après l'installation. Si l'administration d'un produit est complexe, la gestion des risques à l'égard de la sécurité s'avère plus difficile. Assurez-vous que les utilisateurs sont formés pour utiliser le système de manière sécurisée. Si une faille de sécurité est détectée et qu'un correctif s'avère nécessaire, vérifiez que ce correctif est entièrement testé en interne et qu'il est fourni en temps voulu. date

28 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

29 Un zoom sur la modélisation des menaces
CSO Summit 2006 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 La modélisation des menaces est une approche analytique qui permet aux concepteurs de définir l'aspect sécurité des spécifications de conception. L'idée sous-jacente de la modélisation des menaces est que vous ne pouvez pas créer des systèmes sécurisés si vous ne comprenez pas les menaces auxquelles vous êtes exposé. Le processus a pour but d'évaluer les menaces qui pèsent sur l'application et de réduire les conséquences d'une attaque. La modélisation des menaces est une opération simple, qui nécessite toutefois un investissement significatif en termes de temps et une certaine pratique pour sa mise en place. Cependant, le temps passé lors de cette phase est du temps investi intelligemment. La résolution des problèmes détectés au cours de cette phase du développement a un coût beaucoup moins élevé que pour ceux découverts juste avant la diffusion ! La modélisation des menaces fournit une approche structurée beaucoup plus économique et efficace que l'application hasardeuse de fonctionnalités de sécurité. Sans modélisation des menaces, vous risquez de ne pas savoir précisément à quelles menaces doit répondre chaque fonctionnalité. Elle permet naturellement la conception d'une sécurité solide qui fait partie des spécifications formelles de conception de votre application. La modélisation des menaces vous permet d'identifier et d'évaluer systématiquement les menaces susceptibles d'endommager votre système. Une ressource est également appelée « cible d'une attaque » dans le langage spécifique aux menaces. Il s'agit en fait de tout élément qu'il convient de protéger. Une vulnérabilité est un défaut de conception ou une faille d'un système, par exemple une erreur de codage. Une menace pour un système est un événement potentiel qui aura des conséquences néfastes s'il se transforme en attaque. Cf. également OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) de l’université de Carnegie Mellon : © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

30 Un zoom sur la modélisation des menaces
CSO Summit 2006 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 rechercher des erreurs non forcément liées à la sécurité Permet d'identifier les erreurs de conception complexes La modélisation des menaces fournit une approche structurée beaucoup plus économique et efficace que l'application hasardeuse de fonctionnalités de sécurité. Sans modélisation des menaces, vous risquez de ne pas savoir précisément à quelles menaces doit répondre chaque fonctionnalité. Elle permet naturellement la conception d'une sécurité solide qui fait partie des spécifications formelles de conception de votre application. La modélisation des menaces vous permet d'identifier et d'évaluer systématiquement les menaces susceptibles d'endommager votre système. La modélisation des menaces vous permet : de mieux comprendre le système (les membres de l'équipe qui passent du temps à analyser le système de manière structurée ont une connaissance plus approfondie du fonctionnement du système) ; de rechercher les problèmes (l'examen minutieux supplémentaire exécuté lors de la modélisation des menaces permet la découverte d'autres problèmes non liés à la sécurité) ; d'identifier des problèmes de conception complexes (la nature analytique du processus peut révéler des problèmes de sécurité à plusieurs étapes complexes, où plusieurs défaillances mineures s'accumulent et entraînent une défaillance majeure. Ce type de vulnérabilité peut ne pas être détecté lors des tests d'unités exécutés par le développeur et au cours de la plupart des plans de test) ; d'intégrer de nouveaux membres (la modélisation des menaces est un outil utile qui permet aux nouveaux membres de l'équipe de se familiariser avec l'architecture du produit). La modélisation des menaces doit déterminer la conception de votre programme de test de sécurité. Les testeurs doivent exécuter les tests selon le modèle de menace, ce qui leur permettra de développer de nouvelles procédures et de nouveaux outils de vérification. © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

31 Processus de modélisation des menaces
CSO Summit 2006 Processus de modélisation des menaces Vision/Objectifs Modélisation Identification des menaces Atténuation Validation Modification A LIRE Modélisation Définir les scénarios d’utilisation Créer un ou plusieurs diagrammes de flux de données pour le système à modéliser Identification des menaces Déterminer le type de menaces via la taxonomie STRIDE, plus fine que CIA : uSurpation, falsificaTion, Répudiation, divulgation d'Informations, Déni de service, Elévation de privilèges Utiliser les modèles d’arbres des menaces SDL Atténuation Déterminer les risques pour pouvoir agir sur ceux qui sont inadmissibles Via des heuristiques similaires aux bulletins de sécurité (faible, modéré, important, critique) Définir le plan d’atténuation Identifier la catégorie de menace via STRIDE, sélectionner la ou les techniques d’atténuation puis la technologie Définir le plan de test approprié © 2006 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

32 Outil SDL Thread Modeling
19 novembre 2004 Outil SDL Thread Modeling v3.1 en téléchargement gratuit 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

33 Processus de modélisation des menaces (revisité)
Définir les scénarios d’utilisation Créer un ou plusieurs diagrammes de flux de données pour le système à modéliser Identification des menaces Déterminer le type de menaces via la taxonomie STRIDE, plus fine que CIA : uSurpation, falsificaTion, Répudiation, divulgation d'Informations, Déni de service, Elévation de privilèges Utiliser les modèles d’arbres des menaces SDL Atténuation Déterminer les risques pour pouvoir agir sur ceux qui sont inadmissibles Via des heuristiques similaires aux bulletins de sécurité (faible, modéré, important, critique) Définir le plan d’atténuation Identifier la catégorie de menace via STRIDE, sélectionner la ou les techniques d’atténuation puis la technologie Définir le plan de test approprié STRIDE : Spoofing, Tampering, Repudiation, Information disclosure, Elevation of privilege See also OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) de l’université de Carnegie Mellon : Manuel Abaques/Modèles

34 Mise en œuvre simplifiée de SDL
Quelques idées fausses reçues à propose de SDL “…seulement pour Windows” Approprié pour les plateformes et environnements non Microsoft Fondé sur des pratiques de sécurité éprouvées, généralement acceptées “…pour des produits logiciels du commerce” Couvre également le développement des applications métier (LOB) et des services en ligne “…pour le développement en spirale ou en cascade” Support des méthodes agiles “…exige des outils Microsoft” Utiliser les outils appropriés pour la tâche – Si ceux-ci sont des outils MS, très bien, dans le cas contraire, qu'il en soit ainsi. Insister sur la qualité ! “…exige des ressources Microsoft pour le mettre en œuvre” SDL comme appliqué chez Microsoft != SDL pour d'autres organisations

35 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 : Exigence Ressources Définir les exigences de sécurité (et de respect de la vie privée) de l'application vis-à-vis de son environnement opérationnel cible Microsoft Threats and Countermeasures Guide, Microsoft Application Architecture Guide, OWASP Guide to Building Secure Web Applications, etc. Procéder à une analyse de risque de sécurité pour identifier les aspects fonctionnels qui demanderont une attention particulière Microsoft SDL 4.1a (annexes A, C et U) Définir les seuils de qualité et des critères d'acceptation/réception Microsoft SDL 4.1a (annexes M et N) Faire de la formation aux concepts fondamentaux de sécurité un critère de sélection SDL Developer Training Kit, OWASP Top 10 Most Critical Web Application Security Risks, etc. Appendix A: Privacy at a Glance Appendix C: SDL Privacy Questionnaire Appendix M: SDL Privacy Bug Bar Appendix N: SDL Security Bug Bar Appendix U: SDL-LOB Risk Assessment Questionnaire date

36 Ce qu'il faut en retenir En termes d'exigences lors de l'appel d'offres
Ressources Systématiser/Imposer l'élaboration d'un modèle de menaces et sa validation Microsoft SDL Threat Modeling Tool 3.1 Systématiser/Imposer une analyse de réduction de la surface d'attaque fondée sur les exigences en termes de sécurité et le modèle de menace résultant Imposer des bonnes pratiques de conception dont le périmètre d'application découle directement du modèle de menaces Microsoft Threats and Countermeasures Guide, Microsoft Application Architecture Guide, OWASP Guide to Building Secure Web Applications, etc. Imposer des outils approuvés avec leur version minimale acceptée et les vérifications de sécurité associées Microsoft SDL 4.1a (annexe E) Imposer des règles de codage et (d'interdiction) d'utilisation d'APIs Microsoft SDL 4.1a (annexes F, H, et I), banned.h, Microsoft Standard Annotation Language (SAL), Microsoft Web Protection Library (WPL), OWASP Enterprise Security API, etc. Imposer l'utilisation d'outils d'analyse statique de code (managé) lors de l'implémentation Microsoft SDL 4.1a (annexe J), Microsoft Code Analysis Tool .NET (CAT.NET), FxCop, Microsoft BinScope Binary Analyzer, etc. Appendix E: Required and Recommended Compilers, Tools and Options for All Platforms Appendix F: SDL Requirements: No Executable Pages Appendix H: SDL SAL Recommendations for Native Win32 Code Appendix I: SDL Requirement: Heap Manager Fail Fast Setting Appendix J: SDL Requirement: Application Verifier date

37 Ce qu'il faut en retenir En termes d'exigences pour la réception
Ressources Imposer comme préalable une revue et une validation de la modélisation des menaces produite Intégrer une revue et une analyse de la surface d'attaque, prenant en compte, pour des services en ligne, la vérification et la validation de la configuration sécurisée des environnements Serveur Microsoft SDL 4.1a (annexe D), Microsoft Windows xx Security Guide, Microsoft Services and Service Accounts Security Planning Guide, Microsoft Web Application Configuration Analyzer (WACA), etc. Procéder à des analyses statiques de code (voir à des revues de code) dont les cibles sont pilotées par la modélisation des menaces OWASP Code Review Guide, Microsoft Code Analysis Tool .NET (CAT.NET), FxCop, Microsoft BinScope Binary Analyzer, Fortify Rough Auditing Tool for Security (RATS), etc. Procéder des tests de sécurité (analyse dynamique/injection) dont les cibles sont pilotées par la modélisation des menaces et l'analyse de la surface d'attaque OWASP Testing Guide, Microsoft MiniFuzz File Fuzzer, LUA Buglight, etc. Procéder à une examen de sécurité final effectué par une équipe indépendante Fortify Rough Auditing Tool for Security (RATS) : Appendix D: Firewall Rules and Requirements Appendix O: Security Plan Une fois transformée en questions, l'annexe O de Microsoft SDL 4.1a peut servir de trame Prévoir l'archivage de la solution et la mise en place un plan de réponse date

38 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

39 Méthodes agiles Depuis 1991, RAD (Rapid Application Development), (RAD2, DSDM (Dynamic System Development Method),) XP (eXtreme Programming), SCRUM, MSF for Agile Software Development et d'autres Cf. Session TechDays 2009 IND110 "Grille de lecture des méthodes agiles" la dernière décennie qui a vue à une utilisation accrue des méthodes agiles Cf. Enquête Nationale Méthode Agiles, Scrum Alliance Scrum User Group France, juin 2009 Le mouvement agile aura pris une vingtaine d'années pour bousculer les méthodes classiques Cf. From Agile Development to Agile Engagement, Forrester Research, mai 2009 Scrum in 5 minutes : 85 % des informaticiens viennent d'adopter, se situent à mi-chemin du processus ou ont totalement mis en œuvre les méthodes agiles (From Agile Development to Agile Engagement, Forrester Research, mai 2009) date

40 Méthodes agiles Le Manifeste agile, une formalisation consensuelle par les auteurs de ces méthodes agiles Personnes et interaction plutôt que processus et outils Logiciel fonctionnel plutôt que documentation complète Collaboration avec le client plutôt que négociation de contrat Réagir au changement plutôt que suivre un plan 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 date

41 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

42 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.

43 SDL et les méthodes agiles
SDL pour le développement Agile : SDL for Agile "Microsoft continue d’investir dans les domaines importants de la sécurité et de la confidentialité en développant de nouveaux processus innovants de sécurité logicielle, tels que SDL pour le Développement Agile, afin de répondre aux besoins changeants des développeurs" Steve Lipner, directeur de la Security Engineering Strategy Trustworthy Computing Group, Microsoft 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 date

44 SDL for Agile Activités de type Chaque-Sprint
Cf. Annexe P de Microsoft SDL 4.1a Doivent être effectuées pour chaque sprint "…so essential to security that no software should ever be released without these requirements being met." 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)

45 SDL for Agile Activités de type "Seau"
Cf. Annexe Q de Microsoft SDL 4.1a 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 date

46 SDL for Agile Activités de type Une-Fois
Cf. Annexe R de Microsoft SDL 4.1a Généralement effectuées qu'une seule fois Pourquoi ? Répétition non 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)

47 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é

48 SDL for Agile MSF Agile + SDL Template for VSTS
Modèle destiné aux utilisateurs de l'offre ALM Visual Studio Team System 2008 / Team Foundation Server : intégration des activités SDL for Agile directement au sein de l'IDE Visual Studio Création automatique de nouveaux éléments Workflow de sécurité vis-à-vis des exigences de SDL chaque fois qu'un utilisateur entérine (check-in) du code ou crée de nouveaux sprints : Garantie que les processus de sécurité important ne sont pas ignorés ou accidentellement oubliés Intégration avec les outils SDL gratuits déjà mis à disposition (SDL Threat Modeling Tool, Binscope Binary Analyzer et Minifuzz File Fuzzer) Intègre plusieurs technologies dans un projet, couvre toutes les disciplines de projet critiques, etc.

49 Diffusion / Déploiement
En guise de conclusion La sécurité dans le cycle de développement (agile ou non) n'en est qu'à ses débuts… Diffusion / Déploiement Source : Gartner 2007

50 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

51 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 Elémentaire La sécurité est réactive 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é Dynamique La sécurité est spécialisée Le risque est minimisé Personnes, processus, technologies

52 Modèle d’optimisation SDL
Exemple Elémentaire Standardisé (Activités conduites par un expert) Avancé (Activités conduites par une équipe de sécurité centrale) Dynamique (Distribution appropriée en termes d’organisation entre les équipes produit et l'équipe centrale de sécurité) Vérification Tests de sécurité occasionnels Analyse de base de l’application Web Tests d’injection fichiers Tests de pénétration par des tierces-parties le cas échéant Analyse complète de l’application Web Tests d’injection de fautes complet Modèle de menaces validé Développement interne et personnalisation des outils pour : Détecter les vulnérabilités Examiner la conformité avec SDL

53 Les sessions connexes dans le cadre des Microsoft TechDays 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)" Session "Fun with fuzzing... SDL reloaded !" Mercredi 10 février de 16h00 à 17h00

54 Former vos équipes à SDL
Cours d'initiation à SDL : Kit de démarrage Microsoft Security Development Lifecycle (SDL) 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 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. date

55 Outillage gratuit SDL Centre des outils SDL : Outillez votre processus de développement structuré ET sécurisé ! SDL Threat Modeling Tool 3.1 SDL Process Template for VSTS MSF-Agile plus SDL Process Template for VSTS2008 Microsoft BinScope Binary Analyzer FxCop Code Analysis Tool .NET (CAT.NET) 2.0 CTP Microsoft MiniFuzz File Fuzzer Web Protection Library (WPL) v1 CTP Web Application Configuration Analyzer (WACA) v1 CTP Etc.

56 Etre accompagné sur SDL SDL Pro Network
SDL Pro Network lancé en Novembre 2008 pour accompagner les entreprises dans la mise en œuvre des activités SDL Trois catégories d'entreprises : "Formation", "Conseil" et "Outils et solutions d'automatisation" Go through points on slide

57 Ressources SDL Modèle d'optimisation SDL Guide du processus SDL 4.1a
Framework d'intégration graduelle de la dimension Sécurité au sein de vos projets : élémentaire, standard, avancé, dynamique Guide du processus SDL 4.1a Intègre le support des méthodes agiles : SDL/A Livre blanc : Modèle de processus Microsoft SDL pour VSTS Livre blanc : Guide de modélisation des menaces pour les services d'infrastructure

58 Autres ressources SDL Une autre façon de communiquer : SDL et les mécapoulets

59 Autres ressources SDL Une autre façon de communiquer : "Baking Security In"

60 Pour aller plus loin sur SDL et la sécurité…
Quelques livres blancs et articles… Streamline Security Practices For Agile Development How to Manually Integrate the SDL Process Template into an existing Visual Studio project Microsoft Silverlight 1.0: An SDL Implementation Story Security Considerations for Client and Cloud Applications Microsoft Application Architecture Guide, 2nd Edition

61 Pour aller plus sur SDL et la sécurité…
Quelques ouvrages… Security Development Lifecycle Threat Modeling Hunting Security Bugs Writing Secure Code, Second Edition Writing Secure Code for Windows Vista

62 Pour aller plus loin sur SDL et la sécurité…
Site Web SDL Sites Web SDL sur MSDN Sécurité Site US : Weblog SDL Team Weblog Code Analysis and Code Metrics Weblog Michael Howard

63 Pour aller plus loin sur OWASP
The Open Web Application Security Project (OWASP) OWASP Software Assurance Maturity Model (SAMM) OWASP Application Security Verification Standard (ASVS) OWASP Enterprise Security API (ESAPI) OWASP Code Review Guide OWASP Testing Guide OWASP Top 10 Most Critical Web Application Security Risks (2010 RC1) Etc.

64 Pour aller plus loin sur les méthodes agiles…
Site Web du Manifeste Agile Site Web de l’Alliance Agile Site Web Scrum Site Web de l'Alliance Scrum Site Web du French Scrum User Group

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

66 Pour aller plus sur les méthodes agiles…
Quelques ouvrages… Agile Portfolio Management The Enterprise and Scrum Agile Project Management with Scrum

67 Questions / Réponses SPEAKERS PLEASE NOTE: our standard timing for your availability for Q&A at the Ask- the-Experts pavilion will be the next lunch-break following your session, and variations from this standard will be scheduled based on your availability and for all Friday afternoon sessions.

68 Votre potentiel, notre passion TM
© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.