La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Écriture de code sécurisé : la quête du Graal ?

Présentations similaires


Présentation au sujet: "Écriture de code sécurisé : la quête du Graal ?"— Transcription de la présentation:

1 Écriture de code sécurisé : la quête du Graal ?
MGB 2003 Écriture de code sécurisé : la quête du Graal ? Bernard Ourghanlian Directeur Technologie et Sécurité Microsoft France © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2 La quête du Graal ? « La programmation est aujourd’hui une course entre les ingénieurs informaticiens qui essaient de construire des programmes plus grands et mieux à l’épreuve des idiots, et l’univers qui essaie de produire des idiots plus grands et plus idiots. Jusqu’à présent, l’univers gagne. » Rich Cook

3 La quête du Graal ? Convocation de centenaires à l'école : Convocation à l’école de personnes âgées de 106 ans Cause : codage sur deux caractères Mission Vénus : Passage à Km de la planète, au lieu des Km prévus Cause : remplacement d'une virgule par un point (format US des nombres) Passage de la ligne : Au passage de l’équateur un F16 est déclaré se retrouver sur le dos Cause : changement de signe de la latitude mal pris en compte Y2K : La célèbre bogue de l’an 2 000 La lutte contre le bogue de l’an 2000 aurait coûté à la France 500 milliards de francs Cause : la donnée « année » était codée sur deux caractères, pour gagner un peu de place (et parce que l’on imaginait pas que les programmes dureraient si longtemps…)

4 La quête du Graal ? Faux départ de la première navette
Cause : manque de synchronisation entre les calculateurs assurant la redondance 280 morts « inutiles » pendant la guerre du Golfe Cause : non différenciation entre avion civil et avion militaire Bogue du 21 août 2000 pour le système GPS Cause : les 24 satellites du système GPS ont deux compteurs de temps : l’un pour les secondes, remis à zéro chaque semaine ; l’autre totalisant les semaines écoulées depuis le 5 janvier 1980, sur 10 bits (1024 valeurs) Ce compteur aurait malheureusement subi à un dépassement le 21 août en question si des précautions n’avaient pas été prises à temps 2 jours sans courant pour la station Mir, du 14 au 16 novembre 1997 Cause : problème sur un ordinateur qui contrôlait l’orientation des panneaux solaires

5 MGB 2003 La quête du Graal ? Échec du premier lancement d'Ariane V : la nouvelle fusée Ariane V, quarante secondes après son décollage, explosait en vol Cause : Une simple bogue dans une conversion de format pour faire un calcul ne servant à rien Le rapport de la commission d’enquête met clairement en cause une portion de code qui a essayé de convertir un nombre flottant trop grand en un entier codé sur 16 bits Un bogue dans une conversion de format pour faire un calcul qui ne sert à rien (le calcul de la composante horizontale de la vitesse ne sert pas sur Ariane V) ce n’est qu’une simple, une toute petite erreur mais son coût a été énorme (coût du programme d’étude d’Ariane V : 38 milliards de francs) et à provoqué un retard de plus d’un an pour le programme du nouveau lanceur La fusée Ariane V est équipée d’un gyro-laser permettant de calculer en permanence l’angle de l’axe de la fusée par rapport à la verticale. Le gyroscope effectue les mesures sur 32 bits. La composante horizontale de l’accélération est convertie pour être rangée dans un registre de 16 bits qui était utilisé par un programme informatique, hérité d’Ariane IV, pour calculer la vitesse horizontale de la fusée. Tant que cette composante horizontale de la poussée ne dépassa pas une valeur limite, comme c’était le cas avec Ariane IV, le programme remplit correctement sa fonction. Mais sur Ariane V, les moteurs sont beaucoup plus puissants et les poussées plus importantes. Le registre de 16 bits a donc débordé. Le système de contrôle a alors considéré que le gyro-laser était en panne et a donné la main à l’appareil de secours. Ce second gyro-laser, effectuant les mêmes mesures, a été déclaré à son tour en panne et le système de sécurité a considéré que la fusée était perdue. En conséquence, il a déclenché son autodestruction. Sources : ESA Inquiry Board. ARIANE 5: Flight 501 failure. Technical report, European Space Agency, July © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6 MGB 2003 La quête du Graal ? Difficultés sur la mission Mars Pathfinder (atterrissage le 4 juillet 1997) Cause : Des réinitialisations inopinées de l’ordinateur de bord retardent la mission A Pasadena, les informaticiens travaillent d’arrache-pied pour dénicher le bogue. Celui-ci est finalement débusqué au sortir d’une nuit blanche : une mauvaise gestion des priorités des tâches à effectuer est à l’origine du problème Une instruction suit pour le réparer. Le patch est téléchargé vers la sonde après quelques tests supplémentaires © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

7 Logiciel de qualité Logiciel de qualité
MGB 2003 Logiciel de qualité Logiciel de qualité Logiciel sécurisé Logiciel fiable Pourquoi avoir cité ici des bogues ne faisant pas explicitement référence à la sécurité ? Il faut se souvenir que les systèmes sécurisés sont des systèmes de qualité. Le code conçu et écrit d’emblée avec la problématique de la sécurité à l’esprit est bien plus robuste que celui auquel les composants de sécurité sont intégrés après coup. Les produits sécurisés sont aussi immunisés contre les critiques des médias, sont plus attractifs pour les clients et moins chers à corriger et à supporter. Car il ne peut pas y avoir de qualité sans sécurité… Un logiciel sécurité est un sous-ensemble d’un logiciel de qualité © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

8 La quête du Graal ? Port 135 (en provenance de l’Internet)
MGB 2003 La quête du Graal ? Port 135 (en provenance de l’Internet) error_status_t _RemoteActivation(WCHAR *pwszObjectName, ) { *phr = GetServerPath( pwszObjectName, &pwszObjectName); } HRESULT GetServerPath(WCHAR *pwszPath, WCHAR **pwszServerPath ){ WCHAR * pwszFinalPath = pwszPath; WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]; hr = GetMachineName(pwszPath, wszMachineName); *pwszServerPath = pwszFinalPath; } HRESULT GetMachineName( WCHAR * pwszPath, WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]) { pwszServerName = wszMachineName; LPWSTR pwszTemp = pwszPath + 2; while ( *pwszTemp != L'\\' ) *pwszServerName++ = *pwszTemp++; Code dans le code d’initialisation de DCOM (activation d’un objet à distance) ; invoqué lors d’un appel RPC (utilisation de TCP) © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

9 La quête du Graal ? CORRIGE
MGB 2003 La quête du Graal ? error_status_t _RemoteActivation(WCHAR *pwszObjectName, ) { *phr = GetServerPath( pwszObjectName, &pwszObjectName); } HRESULT GetServerPath(WCHAR *pwszPath, WCHAR **pwszServerPath ){ WCHAR * pwszFinalPath = pwszPath; WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]; hr = GetMachineName(pwszPath, wszMachineName); *pwszServerPath = pwszFinalPath; } HRESULT GetMachineName( WCHAR * pwszPath, WCHAR wszMachineName[MAX_COMPUTERNAME_LENGTH_FQDN + 1]) { pwszServerName = wszMachineName; LPWSTR pwszTemp = pwszPath + 2; while ((*pwszTemp != 0) && (( *pwszTemp != L'\\' ) && ( dwCount < MAX_COMPUTERNAME_LENGTH_FQDN ) )){ *pwszServerName++ = *pwszTemp++; dwCount++; CORRIGE © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

10 Le coeur de l’erreur… Copier des données indignes de confiance
MGB 2003 Le coeur de l’erreur… Copier des données indignes de confiance while (*c!=somechar) *p++ = *c++ est contraint par les données sources, pas par la taille de la destination Contraint seulement par les données source while (*c != ‘\\’) *p++ = *c++; Vient du réseau ! © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

11 Pourquoi est-ce important de se préoccuper des applications ?
“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 “Web Application incidents cost companies more than $260,000,000 in 2000.” CSI/FBI Survey

12 Les failles de sécurité coûtent cher à réparer…
Coût lié à la coordination du développement Coût des développeurs trouvant le code vulnérable Coût des développeurs créant le correctif Coût des testeurs testant l’installation du correctif Coûts liés à la création et aux tests des versions localisées Coût de la signature numérique du correctif Coût de la mise en ligne du correctif Coût de la rédaction de la documentation du correctif Coût liés aux relations publiques Coût de la bande passante et du téléchargement Coût de la perte de productivité des développeurs Coût de l’application du correctif Coût potentiel lié à la perte de revenus Chez Microsoft, au sein du MSRC, on estime que le coût de création d’un correctif est de $

13 Il y a deux types majeurs de défaut de sécurité
MGB 2003 Il y a deux types majeurs de défaut de sécurité Les problèmes liées à une confiance injustifiée dans les entrées Tout le reste… © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

14 Problèmes liées à une confiance injustifiée dans les entrées
MGB 2003 Problèmes liées à une confiance injustifiée dans les entrées Buffer Overruns Injection SQL Cross-Site Scripting Dupont Dupont’ drop table facture -- Dupont <script>var i=document.cookie</script> © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.", "width": "800" }

15 Pourquoi est-ce important de se préoccuper des applications ?
Pourcentage d’attaques réussies au niveau applicatif en fonction du type d’attaque Cross-site scripting   80% Database server   33% SQL injection   62% Web server 23% Parameter Tampering   60% Buffer overflow   19% Cookies poisoning   37% Source Imperva basée sur plus de 300 grands comptes et sur les 4 dernières années – Netcost & Security

16 Que sont ces Buffer Overruns ?
MGB 2003 Que sont ces Buffer Overruns ? Les données en provenance de l’extérieur ont une taille plus importante que la destination Le fait de déborder la taille du tampon mémoire de destination écrase certaines constructions mémoire sensibles qui déterminent le flux d’exécution Ceci a pour conséquence la modification par l’application du flux d’exécution Vers le code de l’attaquant qui est inclus dans les données Le code C ou C++ est la victime la plus classique Accès direct à la mémoire La cause : accorder une trop grande confiance aux entrées © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

17 A quel point les BO sont-ils fréquents ?
MGB 2003 A quel point les BO sont-ils fréquents ? 200 180 172 160 140 120 100 100 80 62 55 60 40 30 27 18 20 11 Microsoft Sun RedHat Debian Bulletins (2003) Buffer Overruns Source : Les sites Web des fournisseurs du 1 jan au 1 oct. 2003 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

18 Pourquoi sont-ils si fréquents ?
MGB 2003 Pourquoi sont-ils si fréquents ? Il y a beaucoup de code C ou C++ Une grande partie de ce code C ou C++ est maintenant connecté à l’Internet De nombreuses structures de données contiennent des jumps à du code Adresse de pile, pointeurs vers des fonctions, gestionnaires d’exception, v-tables de classes C++, etc. Les menaces évoluent constamment Il y eut d’abord les débordement sur la pile (la stack) Puis les débordements sur le tas (la heap) Puis les débordements de formatage de chaînes de caractères Puis les débordement d’un octet Maintenant les débordements d’entiers Qui aura-t-il ensuite ? Les développeurs ne contrôlent pas les données en entrée ! Il existe une VTABLE par classe, qui contient uniquement des pointeurs vers les méthodes de la classe. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

19 Les évolutions de Visual Studio
MGB 2003 Les évolutions de Visual Studio Option /GS : Insertion d’une valeur tampon aléatoire dans la pile appelée « canary » ou « cookie » Adresses croissantes Buffers Variables EBP EIP Args Visual Studio 6 Buffers Variables EBP EIP Args cookie Visual Studio.NET (avec /GS) L'option /GS détecte certains types de saturation de mémoire tampon, qui écrasent l'adresse de retour, technique courante permettant d'exploiter du code n'appliquant pas de restrictions sur la taille de la mémoire tampon. Cette opération est réalisée par l'injection de contrôles de sécurité dans le code compilé. /GS tente uniquement de détecter les saturations de mémoire tampon dans l'adresse de retour. Les saturations de mémoire tampon sont plus facilement exploitées sur les ordinateurs utilisant des conventions d'appel qui passent l'adresse de retour d'appels de fonctions sur la pile. Par exemple, x86 utilise des conventions d'appel qui passent l'adresse de retour d'appels de fonction sur la pile. Pour les fonctions que le compilateur pourrait associer à des problèmes de saturation de mémoire tampon, le compilateur alloue de l'espace sur la pile avant l'adresse de retour. À l'entrée de la fonction, l'espace alloué est chargé avec un cookie de sécurité qui est calculé une fois lors du chargement du module. Ensuite, à la sortie de la fonction, une application d'assistance du compilateur est appelée pour vérifier que la valeur du cookie est toujours la même. Améliorations de Visual Studio 2003 (liste non exhaustive) : Réordonnancement des variables Les variables de type tableau ne peuvent plus être utilisées pour écraser les autres variables Protection des pointeurs de fonction, y compris les v-tables Déplacés derrière le « cookie » Buffers Variables EBP EIP Args cookie Visual Studio 2003 (avec /GS et sécurités supplémentaires) EBP : Registre Stack Base pointer : détient l’adresse de base de la pile EIP : Registre Index Pointer détient le déplacement de la prochaine instruction © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

20 démo Buffer Overflow

21 démo Injection SQL

22 Le logiciel : une bête curieuse
MGB 2003 Le logiciel : une bête curieuse Définition (encyclopédie Encarta) : Programme de traitement de l'information contenant les procédures et les données nécessaires à une application Ensemble des programmes constituant le dispositif de base qui permet de faire fonctionner un ordinateur Le logiciel devrait un produit industriel comme les autres et pourtant, c'est un « être » scientifique pas comme les autres Le logiciel a des propriétés curieuses : Par exemple : quel est le sens de Coefficient de Sécurité ? On trouve cela dans le monde de la physique, mais pas dans celui de l'informatique. Pourquoi ? Nota : un logiciel est correct ou pas. On ne sait pas ajouter quelque chose qui fait que l'on a une certaine marge de manoeuvre. Attention au mythe du logiciel oeuvre humaine donc perfectible à volonté. 6 9 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

23 Le logiciel : une bête curieuse
MGB 2003 Le logiciel : une bête curieuse Il est visible mais intangible Il vieillit mais ne s’use pas Il ne se détériore pas sous l’effet des tests Il est encore et toujours fabriqué artisanalement Il est (trop ?) facilement reproductible Il est (trop ?) facile à modifier Il est d'une grande complexité : coût très (trop ?) élevé ... Visible : on en perçoit ses effets mais on ne peut l'atteindre directement qu'en étant dans le système. Vieillesse : un logiciel une fois construit peut vieillir (au sens de l'intérêt qu'il présente ou de son interface) mais il ne change pas ni ne s'use. Test : le test ne l'abîme pas. Rappeler la petite histoire de Pagnol dans la gloire de mon père. Question : un logiciel est-il toujours testable au sens où on sait quels tests pratiquer et prédire (via des oracles) si un résultat est bon. Fabrication artisanale : le logiciel est le fait d'êtres humains, pas toujours experts ! En fait dans le logiciel il y a surtout de la conception, très peu de fabrication. Reproduction : ne coûte rien. Très différent du matériel. Seule coûte le développement initial. Le piratage est une activité hélas bien réelle. Modification aisée : une évidence. Qui irait modifier son téléviseur ? Si on le fait, on observe très vite si une modification est bonne ou mauvaise. Chaque modification d'un logiciel conséquent se traduit par l'introduction de nouvelles erreurs. Complexité : c'est certainement sa principale caractéristique. Il en découle naturellement un coût important et une réelle difficulté à maîtriser cette complexité. 7 10 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

24 Construire du logiciel…
MGB 2003 Construire du logiciel… Sécurité Faisable (calendrier, $, compétences) Respect de la vie privée Utilisable (fonctions) Logiciel Fiabilité Accessible Supportable International Gérable Abordable Déployable Compatible © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

25 Construire du logiciel
MGB 2003 Construire du logiciel Logiciel Sécurité Respect de la vie privé Fiabilité Supportable Gérable Déployable Compatible Abordable International Accessible Utilisable (fonctions) Faisable (cal., $, compétences) © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

26 MGB 2003 © 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

27 Trustworthy Computing Les principes de base
MGB 2003 Trustworthy Computing Les principes de base Résistance aux attaques Protection de la confidentialité, de l’intégrité, de la disponibilité et des données Sécurité Chaque individu a un contrôle complet sur ses données personnelles Les produits et les services en ligne adhèrent à des principes de comportement justes et équitables Respect vie privée Sûr Disponible lorsque nécessaire Offre le service attendu Fiabilité Fournit des produits de qualité Aide les clients à trouver des solutions appropriées Règle les problèmes liés aux produits et services Interagit de manière ouverte avec ses clients Intégrité entreprise © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

28 La sécurité Secure by Design Secure by Default Secure in Deployment
MGB 2003 La sécurité SD3 + Communications Secure by Design Architecture sécurisée Fonctionnalités « conscientes » de sécurité Réduction des vulnérabilités dans le code Secure by Default Réduction de la surface d’attaque Fonctionnalités inutilisées hors service par défaut Besoin minimum en privilèges Secure in Deployment Protéger, détecter, défendre, récupérer, gérer Processus : How to’s, guides d’architecture Hommes : les former ! Communications Engagement clair sur la sécurité Membre à part entière de la communauté de la sécurité Microsoft Security Response Center © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

29 Améliorer la qualité Processus de développement Trustworthy Computing
MGB 2003 Améliorer la qualité Processus de développement Trustworthy Computing Docs de conception & spécifications Chaque équipe développe une modélisation des menaces de son composant afin de s’assurer que la conception bloque bien les menaces applicables Revue de sécurité Conception M1 Application des standards de codage et de conception de sécurité Outils pour éliminer les erreurs du code (PREfix & PREfast) Surveillance et blocage des nouvelles techniques d’attaque Dév & test Développement test et documentation M2 Développement Mn Focalisation de toute l’équipe Mise à jour de la modélisation des menaces, revue de code, passage au crible des tests et de la documentation Security Push Beta Produit Audit de sécurité Analyse vis à vis des menaces courantes Tests de pénétration par des équipes internes et de sociétés tierces Sortie Service Packs, correctifs Correction des problèmes nouvellement découverts Analyse des causes pour trouver et corriger de manière proactive les vulnérabilités associées Security Response Support © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

30 Amélioration du processus de développement d'applications
MGB 2003 Amélioration du processus de développement d'applications Prenez en compte la sécurité : Au début du processus Pendant le développement Pendant le déploiement À chaque étape clé de la révision du logiciel Recherchez les bogues liés à la sécurité jusqu'à la fin du processus de développement 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 applications. Pour obtenir des conseils étape par étape sur ces points, consultez la page Fast Track – How to Implement the Guidance, à l'adresse : (en anglais). © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

31 Chronologie du développement d'un logiciel sécurisé
MGB 2003 Chronologie du développement d'un logiciel sécurisé Analyser les menaces Révision de la sécurité par l'équipe Apprendre et affiner Envoyer pour une révision externe Tester la mutation des données et les privilèges minimaux Évaluer les connaissances sur la sécurité lors du recrutement de l'équipe Former les membres de l'équipe Tester les vulnérabilités de sécurité Résoudre les problèmes liés à la sécurité, vérifier que le code respecte les consignes de sécurité Déterminer les critères de validation de la sécurité Plans de test terminés Conceptions terminées Concept Code terminé Diffusion Post-diffusion Les activités régulières commencent aux points indiqués dans la chronologie de développement du produit. Cependant, ces activités continuent tout au long du cycle de vie du projet. Par exemple, le recrutement des membres d'une équipe peut ne pas avoir lieu uniquement au début du projet, mais également à des étapes ultérieures. Au début d'un projet, pendant les entretiens avec des membres potentiels de l'équipe, posez-leur des questions sur la sécurité afin d'évaluer leur niveau de connaissances sur ce sujet. Cela vous aidera à recruter des développeurs attachés à la sécurité et à évaluer les besoins en matière de formation à la sécurité. Pendant la phase de conception et dans la suite du projet, la modélisation des menaces est un outil précieux pour l'identification des défauts liés à la sécurité. La modélisation des menaces est traitée plus en détails dans la section suivante de cette présentation. Pendant le développement, les développeurs doivent être formés pour détecter les défauts de sécurité courants et créer des correctifs. La sécurité pendant les révisions de code doit faire l'objet d'une attention particulière. Les tests de la sécurité doivent tenir une place importante dans les programmes de test. Les personnes chargées des tests doivent imaginer des méthodes d'attaque du logiciel, afin de rechercher les défauts de sécurité. Une fois le produit diffusé, un programme de réponse approprié doit être établi pour tous les défauts de sécurité découverts. Il doit au moins inclure la formation des développeurs de sorte que les problèmes de sécurité identiques ou proches soient détectés. Il peut également inclure le développement rapide de correctifs pour les installations existantes. =continu © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

32 Sécurité dès la conception
MGB 2003 Sécurité dès la conception Sensibiliser l'équipe de conception à la sécurité Assurer une formation continue Bousculer les esprits : l’idée reçue selon laquelle « Ce que je ne connais pas n'est pas dangereux pour moi » n'est pas vraie ! Prendre en compte la sécurité dès la phase de conception Définir les objectifs du produit en termes de sécurité Mettre en œuvre la sécurité comme fonctionnalité clé du produit Utiliser la modélisation des menaces pendant la phase de conception La formation est le principal ingrédient d'un processus de développement sécurisé efficace. Vous devez vous assurer que tous les concepteurs et les programmeurs sont informés des failles de sécurité communes concernant les logiciels, de sorte qu'ils ne reproduisent pas les erreurs passées. Organisez régulièrement des formations afin de sensibiliser les utilisateurs à la sécurité et de garantir que la sécurité demeure une priorité pour tous les membres de l'équipe. La résolution des problèmes découverts tardivement dans le cycle de développement a un coût beaucoup plus élevé que pour ceux découverts plus tôt. Cela est particulièrement vrai pour les problèmes liés à la sécurité. Vous devez prendre en compte la sécurité de votre application dès le début de la phase de conception. Les objectifs de sécurité du produit sont aussi importants (voire plus) que les autres objectifs fonctionnels. Si vous concevez la sécurité en tant que fonctionnalité du produit, au lieu de la considérer comme une fonctionnalité « à valeur ajoutée » devant être incluse « si le temps le permet », le produit obtenu sera beaucoup plus sécurisé que si cette fonctionnalité est ajoutée après coup. La modélisation des menaces pendant la phase de conception et la phase de développement s'est avérée extrêmement efficace pour déterminer les risques les plus élevés à l'égard de la sécurité du produit ainsi que la manière dont les attaques se produisent. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

33 Qu'est-ce que la modélisation des menaces ?
MGB 2003 Qu'est-ce que la modélisation des menaces ? La modélisation des menaces est une analyse basée sur la sécurité dont les objectifs sont les suivants : Aider l’équipe à identifier les vulnérabilités du logiciel Évaluer les menaces relatives à une application Réduire les risques globaux à l'égard de la sécurité Identifier les ressources Découvrir les vulnérabilités Identifier les menaces Permettre d'établir la base des spécifications de conception en matière de sécurité 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 une faille d'un système, par exemple une erreur de codage ou un défaut de conception. Une menace pour un système est un événement potentiel qui aura des conséquences néfastes s'il se transforme en attaque. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

34 Avantages de la modélisation des menaces
MGB 2003 Avantages de la modélisation des menaces Permet de mieux comprendre votre application Permet de rechercher les erreurs Permet d'identifier les erreurs de conception complexes Permet d'intégrer de nouveaux membres à l'équipe Permet d'établir des programmes de test de sécurité bien conçus Risque Vulnérabilité Ressource La modélisation des menaces vous permet : de mieux comprendre votre application (les membres de l'équipe qui passent du temps à analyser l'application de manière structurée ont une connaissance plus approfondie du fonctionnement de l'application) ; 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. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

35 Processus de modélisation des menaces
MGB 2003 Processus de modélisation des menaces Processus de modélisation des menaces Identifier les ressources 1 Créer une vue d'ensemble de l'architecture 2 Décomposer l'application 3 Identifier les menaces 4 Un processus de modélisation des menaces implique plusieurs étapes : Identifier les ressources. Identifiez les ressources précieuses que vos systèmes doivent protéger. Créer une vue d'ensemble de l'architecture. Utilisez des tableaux et des diagrammes simples pour documenter l'architecture de votre application, notamment les sous-systèmes, les frontières sécurisées et les flux de données. Décomposer l'application. Décomposez l'architecture de votre application, notamment le réseau sous-jacent et la conception de l'infrastructure de l'hôte, afin de créer un profil de sécurité pour votre application. Ce profil de sécurité permet de découvrir des vulnérabilités dans la conception, la mise en œuvre ou la configuration de votre application. Identifier les menaces. En gardant à l'esprit les objectifs d'un intrus, et avec votre connaissance de l'architecture et des vulnérabilités potentielles de votre application, identifiez les menaces qui peuvent peser sur l'application. Documenter les menaces. Documentez chacune des menaces à l'aide d'un modèle de menace commun définissant un groupe de caractéristiques à relever pour chaque menace. Évaluer les menaces. Évaluez les menaces afin de les classer par ordre de priorité et de traiter en premier les menaces les plus graves. Ces menaces présentent le risque le plus élevé. Le processus de notation évalue une menace en estimant sa probabilité ainsi que le dommage qui en résulterait en cas d'attaque. Il arrive que certaines menaces ne demandent aucune action lorsque vous comparez le risque encouru et les coûts d'atténuation résultants. Documenter les menaces 5 Évaluer les menaces 6 © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

36 MGB 2003 Processus de modélisation des menaces Étape 1 : Identifier les ressources Établissez la liste des ressources devant être protégées : Données confidentielles, telles que les bases de données des clients Pages Web Disponibilité système Tous les autres éléments qui, s'ils étaient endommagés, pourraient empêcher le bon fonctionnement de votre application La première étape du processus de modélisation des menaces consiste à identifier les ressources à protéger. Une ressource est une ressource système qui a de la valeur, comme les données contenues dans une base de données ou dans le système de fichiers. Vous devez établir la liste des ressources devant être protégées, notamment : les données confidentielles, telles que les bases de données des clients ; les pages Web ; la disponibilité système ; tous les autres éléments qui, s'ils étaient endommagés, pourraient empêcher le bon fonctionnement de votre application. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

37 Processus de modélisation des menaces Étape 2 : Créer une vue d'ensemble de l'architecture
MGB 2003 Identifiez ce que fait l'application Créez un diagramme de l'architecture Identifiez les technologies Autorisations NTFS (authentification) Autorisation de fichier Autorisation d'URL Rôles .NET Rôle défini par l'utilisateur SSL (Confidentialité/ Intégrité) Frontière sécurisée Alice Mirwault Laura Bartoli Victor Nahas IIS Authentification anonyme par formulaires IPSec (Privé/Intégrité) ASPNET (identité du processus) Microsoft ASP.NET Authentification de Microsoft® Windows SQL Server L'objectif de la vue d'ensemble de l'architecture est de documenter le fonctionnement de votre application, son architecture et la configuration de son déploiement physique, ainsi que les technologies qui en font partie. La vue d'ensemble de l'application comprend trois parties principales : Identifiez ce que fait l'application. Documentez différents exemples d'utilisation pour permettre aux utilisateurs de comprendre comment votre application est utilisée. Cela vous permet également de déterminer comment elle peut être utilisée de manière illicite. Les exemples d'utilisation permettent de mettre en contexte la fonctionnalité de l'application. Créez un diagramme de l'architecture. Cela décrit la composition et la structure de votre application et de ses sous-systèmes, ainsi que les caractéristiques de son déploiement physique. Selon la complexité de l'application, plusieurs diagrammes centrés sur des aspects spécifiques seront éventuellement nécessaires. Identifiez les technologies. Cela vous permettra de vous concentrer sur les menaces spécifiques aux technologies dans la suite du processus. Vous pourrez également déterminer les techniques d'atténuation les plus appropriées. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

38 MGB 2003 Processus de modélisation des menaces Étape 3 : Décomposer l'application Identifier les frontières sécurisées Décomposez l'application Créez un profil de sécurité basé sur les domaines de vulnérabilité classiques Examinez les interactions entre les différents sous-systèmes Utilisez les diagrammes UML ou de flux de données Identifier le flux de données Identifier les points d'entrée Identifiez les frontières sécurisées qui entourent chacune des ressources de votre application. Pour chaque sous-système, vérifiez si les flux de données en amont, le code d'appel ou d'entrée utilisateur sont sécurisés ; sinon, déterminez comment l'entrée et les flux de données peuvent être authentifiés et autorisés. Prenez également en compte les relations d'approbation du serveur. Analysez les flux de données entre les différents sous-systèmes, en observant attentivement les flux de données qui traversent les frontières sécurisées. Prenez en compte tous les points d'entrée de votre application, tels que les pages Web ou les serveurs de sockets, car ils représentent des voies éventuelles pour des attaques. Vérifiez également les points d'entrée sur les composants ou les sous-systèmes internes. Bien que ces points d'entrée puissent exister uniquement pour permettre la communication interne entre les composants de votre application, ils peuvent également servir de points d'attaque si l'intrus arrive à contourner les contrôles de sécurité classiques « à l'entrée ». Tenez compte des codes qui accèdent aux ressources sécurisées comme les serveurs DNS, les services d'annuaire, les variables d'environnement, les journaux des événements, les systèmes de fichiers, les files d'attente de messages, les compteurs de performances, les imprimantes, le Registre, les sockets et les services Web. Tout code nécessitant des privilèges spécifiques ou fonctionnant avec le système de sécurité (par exemple, sécurité d'accès au code .NET) requiert une attention particulière. Créez un profil de sécurité pour l'application en documentant les approches de la conception et de la mise en uvre utilisées pour la validation des entrées, l'authentification, l'autorisation, la gestion de la configuration et les autres domaines dans lesquels les applications sont les plus vulnérables. Les diagrammes de flux de données sont un outil utile pour décomposer une application en plusieurs composants clés. Ils fournissent la base d'une technique adéquate pour illustrer le flux de données entre les processus. Vous pouvez également utiliser les diagrammes d'activités UML, qui ont un objectif similaire mais se concentrent davantage sur le transfert du contrôle entre les processus. Le principe de base des diagrammes de flux de données est qu'une application ou un système peut être décomposé en sous-systèmes, et les sous-systèmes en sous-systèmes de niveau encore inférieur. Passez outre les mécanismes internes de l'application et concentrez-vous sur la portée de l'application plutôt que sur les détails fonctionnels. Décomposez l'application jusqu'à deux, trois ou quatre sous-niveaux, suffisamment en profondeur pour comprendre les menaces qui pèsent sur l'application. Ne vous perdez pas dans le processus de modélisation des menaces en exécutant une analyse trop approfondie et en perdant de vue l'objectif de départ. Identifier le code privilégié Documenter le profil de sécurité © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

39 Processus de modélisation des menaces Étape 4 : Identifier les menaces
MGB 2003 Processus de modélisation des menaces Étape 4 : Identifier les menaces Constituez une équipe Identifiez les menaces Menaces liées au réseau Menaces liées aux systèmes hôtes Menaces liées à l'application À cette étape du processus de modélisation des menaces, vous devez identifier les menaces qui pèsent sur vos ressources système. La meilleure manière consiste à former une équipe rassemblant les membres des équipes chargées du développement et des tests afin d'organiser une séance de brainstorming devant un tableau blanc. Vous devez identifier trois types de menaces. Vous devez suivre les étapes suivantes : Identifier les menaces liées au réseau : Analysez les topologies du réseau et recherchez les vulnérabilités. Vérifiez que votre réseau n'est pas vulnérable à une configuration incorrecte des périphériques et du serveur. Identifier les menaces liées aux hôtes : Recherchez les vulnérabilités existantes dans une configuration inadaptée de la sécurité des hôtes. Prenez en compte les versions des correctifs, les mises à jour, les services, les protocoles, les comptes, les fichiers et les répertoires, les partages, les ports ainsi que l'audit et la journalisation. Identifier les menaces liées à l'application : Examinez minutieusement le profil de sécurité que vous avez créé dans l'étape précédente du processus de modélisation des menaces. Concentrez-vous sur les menaces liées aux applications, à la technologie et au code. Recherchez des éléments tels qu'une validation des entrées médiocre, la transmission des informations d'authentification via des connexions réseau non cryptées ou l'utilisation de stratégies de mot de passe et de compte inadaptées. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

40 MGB 2003 Processus de modélisation des menaces Identifier les menaces à l'aide de STRIDE Types de menaces Exemples USurpation Falsification de messages électroniques Rediffusion de paquets d'authentification FalsificaTion Modification des données lors d'une transmission Changement des données dans des fichiers Répudiation Suppression d'un fichier important et déni de l'action Achat d'un produit et déni de l'action Divulgation d'Informations Exposition d'informations dans des messages d'erreur Exposition de code sur des sites Web Deni de service Submersion d'un réseau avec des paquets SYN Submersion d'un réseau avec des paquets ICMP falsifiés Elévation de privilèges Exploitation du débordement de mémoire tampon pour obtenir des privilèges système Obtention illégale des privilèges d'administrateur Classer les menaces que représentent les pirates offre de nombreux avantages. Par exemple, le classement des menaces vous permet d'identifier et de développer des stratégies de sécurité qui s'appliquent à tout une série de menaces d'une même catégorie, et pas uniquement à une seule. Les catégories STRIDE sont les suivantes : Usurpation : Accès illégal aux informations d'authentification d'un autre utilisateur, comme le mot de passe et le nom d'utilisateur, et utilisation de ces informations. Par exemple, un pirate peut contourner une autorisation en injectant un code SQL et en adoptant le rôle d'administrateur système. Falsification de données : Modification malveillante de données. La modification non autorisée de données persistantes comme les données d'une base de données ou le remplacement de données alors qu'elles se trouvent entre deux ordinateurs sur un réseau ouvert, comme Internet, en sont autant d'exemples. Répudiation : Menaces applicables aux utilisateurs qui refusent (répudient) une action lorsque les autres parties ne peuvent pas prouver le contraire. Divulgation d'informations : Exposition d'informations à des utilisateurs non autorisés. La lecture de données en cours de transfert entre deux entreprises en est un exemple. Un autre exemple est l'attaque de script intersite (Cross Site Scripting) pour voler les cookies d'un utilisateur. Déni de service : Déni de service pour les utilisateurs valides. C'est le cas lorsqu'un serveur Web est rendu temporairement indisponible ou inutilisable. C'est également le cas lorsqu'on utilise un débordement de mémoire tampon qui entraîne le redémarrage d'un serveur. Élévation de privilèges : Un utilisateur non privilégié obtient l'accès privilégié et dispose ainsi d'un accès suffisant pour endommager ou détruire tout le système. Par exemple, un pirate peut exploiter un débordement de la mémoire tampon pour obtenir une invite de commande et s'ajouter dans le groupe des administrateurs. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

41 Voir les informations relatives aux salaires
MGB 2003 Processus de modélisation des menaces Identifier les menaces à l'aide d'organigrammes des menaces Menace n°1 (I) Voir les informations relatives aux salaires 1.0 Voir les informations relatives aux salaires (I) 1.1 Le trafic n'est pas protégé (ET) 1.2 L'intrus voit le trafic 1.2.1 Espionner le trafic avec un analyseur de protocole 1.2.2 Écouter le trafic du routeur Routeur non équipé d'un correctif (ET) Endommager le routeur Deviner le mot de passe du routeur 1.1 Le trafic n'est pas protégé 1.2 L'intrus voit le trafic La création d'organigrammes des menaces est une méthode efficace pour déterminer les problèmes de sécurité liés aux systèmes informatiques. L'idée des organigrammes des menaces est qu'une application se compose de cibles de menace, et que chaque cible peut présenter des vulnérabilités qui, lorsqu'elles sont exploitées avec succès, peuvent endommager le système. L'organigramme des menaces décrit le processus de décision par lequel passe un intrus pour endommager le composant logiciel. Le processus de décomposition vous a permis d'identifier tous les composants du système. Vous devez ensuite identifier les menaces potentielles qui pèsent sur chaque composant. Les organigrammes des menaces vous aident alors à comprendre comment cette menace peut se manifester. La méthode pour établir un organigramme des menaces consiste à identifier les objectifs et les sous-objectifs d'une attaque, ainsi que les opérations à exécuter pour que cette attaque réussisse. L'organigramme des menaces présenté sur cette diapositive indique comment un intrus peut voir les données confidentielles relatives aux salaires d'un autre utilisateur. Si les organigrammes des menaces présentent clairement les données, ils peuvent toutefois devenir imposants lorsque vous créez des modèles de menaces développés. Une autre méthode pour représenter l'organigramme des menaces consiste à utiliser une description, comme le montre la diapositive. 1.2.1 Espionner le trafic avec un analyseur de protocole 1.2.2 Écouter le trafic du routeur Routeur non équipé d'un correctif Endommager le routeur Deviner le mot de passe du routeur © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

42 Processus de modélisation des menaces Étape 5 : Documenter les menaces
MGB 2003 Processus de modélisation des menaces Étape 5 : Documenter les menaces Documentez les menaces à l'aide d'un modèle : Ne renseignez pas le champ Risque (pour l'instant) Description de la menace Injection de commandes SQL Cible de la menace Composant de l'accès aux données Risque Techniques d'attaque L'intrus ajoute des commandes SQL au nom d'utilisateur utilisé pour former une requête SQL Contre-mesures Utiliser une expression régulière pour valider le nom d'utilisateur et une procédure stockée avec des paramètres pour accéder à la base de données Documentez toutes les menaces que vous identifiez. Vous devez inclure la cible et la description de la menace. La zone Risque est vide pour l'instant, elle est remplie dans la dernière étape du processus. Vous souhaiterez peut-être inclure les techniques d'attaque, qui peuvent également mettre en évidence les vulnérabilités exploitées et les contre-mesures nécessaires pour éliminer la menace. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

43 Processus de modélisation des menaces Étape 6 : Évaluer les menaces
MGB 2003 Processus de modélisation des menaces Étape 6 : Évaluer les menaces Utilisez la formule suivante : Risque = Probabilité * Dommage potentiel Utilisez le modèle DREAD pour noter les menaces Dommage potentiel  Reproductibilité  Exploitation   Utilisateurs Affectés  Découverte  À cette étape, vous pouvez renseigner le champ Risque laissé vide à l'étape 5. Une fois que vous avez documenté vos menaces, vous devez déterminer les menaces les plus dangereuses. Pour ce faire, vous devez les classer. Vous pouvez calculer le risque à l'aide d'une échelle de probabilité de 1 à 10 (où 1 correspond à une probabilité nulle et 10 à une forte probabilité) et d'une échelle de 1 à 10 pour le dommage potentiel (1 correspond à un dommage minimal et 10 à une catastrophe). Cela donne un risque compris entre 1 et 100. Vous pouvez diviser l'échelle en trois bandes pour distinguer un niveau de risque Élevé, Moyen ou Faible. Cette méthode d'évaluation des risques est trop simpliste pour certains ; par exemple, les spécialistes de Microsoft appliquent le modèle DREAD pour affiner ce calcul, ce qui permet d'évaluer en plus les conséquences des menaces à l'égard de la sécurité. Dommage potentiel : Quels dommages la menace peut-elle faire subir au système ? Reproductibilité : Est-il très difficile de reproduire la menace ? Exploitation : Est-il très difficile d'exploiter une vulnérabilité avec succès pour les pirates ? Utilisateurs affectés : Combien d'utilisateurs seront affectés ? Découverte : Est-il très difficile de découvrir la menace ? Les applications et les entreprises utilisent plusieurs critères pour les différents éléments du modèle DREAD. La formule utilisée pour calculer le niveau n'est pas très importante car les valeurs dérivées sont liées entre elles. Vous devez juste faire preuve de cohérence. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

44 Processus de modélisation des menaces Exemple : Évaluer les menaces
MGB 2003 Processus de modélisation des menaces Exemple : Évaluer les menaces Dommage potentiel Utilisateurs affectés Ou Dommage Menace n°1 (I) Voir les informations relatives aux salaires 1.1 Le trafic n'est pas protégé 1.2 L'intrus voit le trafic Reproductibilité Exploitation Découverte Ou Probabilité Le modèle DREAD est une amélioration de la formule simple Risque = Dommage * Probabilité. D (Dommage potentiel) et A (Utilisateurs Affectés) correspondent à Dommage. R (Reproductibilité), E (Exploitation) et D (Découverte) correspondent à Probabilité. Vous pouvez utiliser cette stratégie pour classer les risques par ordre de priorité. Une fois que vous avez calculé la priorité de chaque risque identifié à l'égard de la sécurité, vous pouvez classer les risques par ordre de priorité et déterminer une stratégie de gestion basée sur la valeur de priorité. Dans chaque catégorie DREAD, utilisez la valeur 3 pour un risque élevé, 2 pour un risque moyen et 1 pour un risque faible. Évaluez chacune des menaces contenues dans votre organigramme des menaces et attribuez le niveau de risque à chaque catégorie DREAD, puis calculez le résultat. Par exemple, la menace liée à l'injection de code SQL identifiée précédemment peut être notée comme suit : D – 3, R – 3, E – 3, A – 3, D – 2. Cela donne une note totale de 14. Dans l'intervalle possible total de 5 à 15, une note de 12 à 15 peut constituer un risque élevé, de 8 à 11 un risque moyen et de 5 à 7 un risque faible. 1.2.1 Espionner le trafic avec un analyseur de protocole 1.2.2 Écouter le trafic du routeur Routeur non équipé d'un correctif Endommager le routeur Deviner le mot de passe du routeur © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

45 Codage pour un modèle de menace
MGB 2003 Codage pour un modèle de menace Utilisez la modélisation des menaces pour : déterminer les parties les plus « dangereuses » de votre application classer par ordre de priorité les efforts de sécurité classer par ordre de priorité les révisions de code régulières déterminer les techniques d'atténuation des menaces à utiliser déterminer le flux de données En résumé, la modélisation des menaces est un outil d'analyse précieux qui permet d'améliorer le processus de conception. Elle vous permet d'identifier les parties les plus vulnérables de votre application pour que vous puissiez concentrer vos efforts sur celles-ci. Elle vous permet également d'identifier les techniques appropriées pour atténuer les menaces. L'avantage de la modélisation des menaces ne s'arrête pas là. Utilisez la modélisation des menaces pendant le processus de codage pour revoir et tester de nouveau les décisions de sécurité prises au cours de la phase de conception et pour mettre l'accent sur la révision des codes de sécurité. Les résultats du processus de modélisation des menaces fournissent les informations nécessaires à la sélection des techniques et des technologies de sécurité appropriées pour atténuer les menaces identifiées. Les diagrammes de flux de données sont un outil efficace pour identifier les flux de données et sont particulièrement utiles pour l'identification de toutes les entrées dans votre application. Chaque entrée représente une source spécifique de vulnérabilités de la sécurité. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

46 Options relatives à l'atténuation des risques
MGB 2003 Options relatives à l'atténuation des risques Option 1 : Ne rien faire Option 2 : Avertir l'utilisateur Option 3 : Supprimer le problème Option 4 : Résoudre le problème Surveillé Les techniques d'atténuation protègent les ressources en sécurisant les vulnérabilités sur un système et en empêchant la mise à exécution des menaces. Lorsque vous prenez en compte les risques et la manière de les atténuer, vous avez quatre possibilités : Option 1 : Ne rien faire. Vous pouvez choisir de ne pas corriger un risque faible pour la sécurité. Cette solution est rarement appropriée car l'erreur restera latente dans l'application et sera probablement découverte, ce qui vous obligera à la corriger. Vos utilisateurs et la réputation de votre entreprise auront à en pâtir. Option 2 : Avertir l'utilisateur. Informez l'utilisateur du problème et laissez-lui le choix quant à l'utilisation ou non de la fonctionnalité. Cependant, vous ne pouvez pas attendre des utilisateurs qu'ils aient une connaissance suffisamment détaillée du système ou de la nature de la limitation pour prendre une décision. Option 3 : Supprimer le problème. Si vous n'avez pas le temps de résoudre le problème, vous pouvez retirer la fonctionnalité du produit avant sa diffusion. Il est préférable de la corriger pour la version suivante plutôt que de la laisser passer et mettre en danger les ordinateurs de vos utilisateurs. Option 4 : Résoudre le problème Sélectionnez les technologies appropriées pour résoudre le problème. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

47 Processus d'atténuation des risques
MGB 2003 Processus d'atténuation des risques Identifier la catégorie Par exemple : Usurpation Type de menace (STRIDE) Sélectionner les techniques Par exemple : Authentification ou protection des données confidentielles Technique d'atténuation Technique d'atténuation Technologie Technologie Technologie Technologie Le processus consistant à déterminer comment atténuer les risques identifiés par le processus de modélisation des menaces comprend trois étapes. Vous devez d'abord identifier la catégorie de menace à l'aide du modèle STRIDE. Ensuite, vous devez déterminer les techniques utiles en la matière. Enfin, vous devez choisir les technologies appropriées. Par exemple, si le processus de modélisation des menaces a identifié une menace d'usurpation d'identité, les technologies peuvent atténuer ce risque via l'authentification ou la protection des données confidentielles comme les informations d'identification relatives à la sécurité. Si l'authentification est sélectionnée comme technique d'atténuation appropriée, les technologies que vous pouvez utiliser pour l'authentification incluent NTLM, les certificats X.509, les clés PGP (Pretty Good Privacy), l'authentification Digest, Kerberos et SSL/TLS. Usurpation Authentification NTLM Certificats X.509 Clés PGP De base Digest Kerberos SSL/TLS Sélectionner la technologie Par exemple : Kerberos © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

48 Exemples de techniques d'atténuation
MGB 2003 Exemples de techniques d'atténuation Client Serveur Données persistantes Données d'authentification Données de configuration STRIDE SSL/TLS IPSec RPC/DCO avec confidentialité Pare-feu Limitation de l'utilisation des ressources pour les connexions anonymes Contrôle d'accès rigoureux Signatures numériques Audit Réseau non sécurisé La diapositive montre plusieurs techniques d'atténuation pour chaque catégorie de menace STRIDE. En général, les techniques d'atténuation applicables pour chacune de ces menaces incluent : Usurpation : Utilisez une authentification appropriée. Protégez les données confidentielles. Ne stockez pas des données confidentielles. Falsification de données : Utilisez une autorisation appropriée. Utilisez des hachages ou des codes MAC (Message Authentication Code). Utilisez des signatures numériques. Utilisez des protocoles résistants aux falsifications, tels que SSL/TLS. Répudiation : Utilisez des horodatages. Utilisez des journaux d'audit. Divulgation d'informations : Utilisez une procédure d'autorisation. Utilisez des protocoles avec confidentialité. Utilisez le cryptage. Ne stockez pas de données confidentielles. Déni de service : Utilisez une procédure d'autorisation appropriée. Utilisez le filtrage. Utilisez l'optimisation. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

49 Quelques méthodes permettant d’améliorer la sécurité du code
Exécution avec le moins de privilèges possible Réduction de la surface d'attaque Validation des entrées utilisateur Mise en place d’un modèle de défense en profondeur Méfiance par rapport à la sécurité par la dissimulation Non stockage d’informations confidentielles Utilisation de l'interface DPAPI Échec intelligent Test de la sécurité Apprentissage à partir de ses erreurs

50 Implémenter le Framework Les 10 points clés pour les développeurs
Secure by Design Construire des modèles de menace Supprimer les défauts dans le code Éviter de nouveaux défauts de sécurité Utiliser du code managé aujourd’hui Utiliser outils & checklists Secure by Default Réduire la surface d’attaque : Mettre hors service les fonctionnalités Requérir le minimum de privilèges Ajouter des couches défensives supplémentaires Secure in Deployment Être bien disposé à l’égard des firewalls et antivirus Créer des guides de sécurité et une bonne documentation

51 Développeurs : pour résumer
MGB 2003 Développeurs : pour résumer Secure by Design Un processus qui favorise les systèmes sécurisés Construire des modèles de menace Conduire des revues de code, des tests de pénétration Exécuter le code avec des privilèges minimaux Microsoft Developer Network Patterns and Practices Guides Écrire du Code Sécurisé 2 Secure by Default Minimiser la surface d’attaque (services off par défaut) Sécuriser les services Utiliser les fonctions de sécurité de Visual Studio .NET Secure in Deployment Tirer parti des meilleures pratiques Créer des guides de sécurité Construire des outils pour évaluer la sécurité des applications © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

52 Le balancier de la sécurité logicielle – Où nous étions…
MGB 2003 Le balancier de la sécurité logicielle – Où nous étions… Usage & Fonctions Sécurité Vie Privée Facile à utiliser Large surface d’attaque « Automagique » Rapidité de l’Internet Les logiciels (et les attaques) fonctionnent sans que l’on se pose de questions © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

53 Le balancier de la sécurité logicielle – Où nous sommes…
MGB 2003 Le balancier de la sécurité logicielle – Où nous sommes… Usage & Fonctions Sécurité Vie Privée Surface d’attaque réduite Souvent plus difficile à utiliser Sécurité anxiogène Plus long à mettre sur le marché De nombreuses questions relatives à la sécurité (pour l’utilisateur) © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

54 Le balancier de la sécurité logicielle – Où nous devrions être…
MGB 2003 Le balancier de la sécurité logicielle – Où nous devrions être… Usage & Fonctions Sécurité Vie Privée Petite surface d’attaque La sécurité et le respect de la vie privée sont des fonctionnalités de premier plan Peu de questions relatives à la sécurité Transparent quand c’est possible Configurable là où c’est nécessaire Utilisable de manière sécurisée © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

55 Créer un système sécurisé
MGB 2003 Rester sécurisé Windows Update Service (WUS) Microsoft Audit Collection Service Security Configuration Wizard Windows Update Trust Center Construire du code sécurisé Visual Studio Secure Execution Environment (SEE) Communiquer en toute sécurité Carte à puce, système d’identité, support de la biométrie Réseau sécurisé, WS-Security Internet Connection Firewall Cross-Organizational Trust Créer un système sécurisé Démarrer en toute sécurité : les utilisateurs savent que quand Windows démarre, il n’a pas été compromis, qu’il démarrera en toute sécurité dans un état connu et réputé correct. Exécution en toute sécurité : Les utilisateurs en connaissent assez à propos des applications Windows pour que, lorsqu’ils les exécutent, qu’elles soient chargées depuis Internet ou un CD, ils aient confiance dans le fait que l’application ne peut faire que ce qu’on la croit capable de faire et qu’elle s’exécutera en toute sécurité Communiquer en toute sécurité : les utilisateurs sont confiants dans le fait que lorsqu’ils font tourner Windows en étant connectés à l’Internet, les sociétés peuvent protéger leurs biens, que ceux-ci soient accédés en local ou à distance, et qu’elles peuvent collaborer sans risque en fonction de leurs besoins business et donc communiquer en toute sécurité Construire du code sécurisé : Les développeurs ont les outils nécessaires pour analyser la sécurité de leur code et ils peuvent définir les besoins d’exécution (runtime) de leur code de telles façons que les sociétés et les utilisateurs puissent prendre la décision de faire confiance à leur code en toute connaissance de cause ; ils peuvent donc construire du code sécurisé Rester sécurisé : quel que soit l’utilisateur, celui-ci peut garder à jour son système et le patcher en fonction de ses propres politiques de sécurité ou de celles de sa société; il peut donc rester sécurisé TrustBridge Infrastructure sécurisée pour les services Web, spécialement construit pour les développeurs qui utilisent le Message Bus Permet la mise en œuvre de solutions pour la fédération et un Single Sign-On Web (WebSSO) Outils d’administration et services pour gérer les politiques de sécurité (relations de confiance), politique d’autorisation, audit et surveillance de la performance Outils de gestion des cartes à puce Le déploiement et la gestion des cartes à puce est un facteur bloquant des déploiements aujourd’hui Outils et interfaces standards pour rendre plus simple le déploiement et la gestion des cartes à puce Longhorn Biométrie Les utilisateurs à la maison n’aiment pas les mots de passe et typiquement ne les utilisent pas La biométrie à la maison peut permettre de simplifier la connexion sécurisée de chacun des membres de la famille Trust Center Windows informe les utilisateurs de ce qu’ils divulguent vers l’extérieur Microsoft Audit Collection Service Les sociétés peuvent contrôler et auditer leur environnement de sécurité pour déterminer si elles sont sous attaque ou pour tracer les activités d’un compte suspect ; permet de séparer les responsabilités d’audit de celles de la gestion de la sécurité Security Configuration Wizard Les entreprises peuvent facilement configurer leurs machines en fonction de leurs rôles respectifs dans l’entreprise Exécution en toute sécurité Secure Execution Environment (SEE) Behavior Blocking/Sandboxing/NX Software Restriction Policy Code digne de confiance LUA/PA/SEE Interface homme machine de consentement Démarrer en toute sécurité Signature des drivers Protection des DLL système ICF tôt dans la phase de boot Intégrité du code Boot sécurisé assisté par le hardware © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

56 Longhorn et la sécurité
Intégrité du code Windows et tout le code système (y compris les drivers) sont signés Le loader contrôle le hash de chaque fichier lors du démarrage du système pour s’assurer qu’il est bien dans l’un de ses catalogues signés La politique de sécurité détermine ce qui peut être chargé Software Restriction Policy Les administrateurs peuvent spécifier le code qui peut et celui qui ne peut pas s’exécuter Le code peut être identifié par : hash, emplacements d’installation ou d’exécution Assistance hardware pour un boot sécurisé Des technologies comme Next Generation Secure Computing Base (NGSCB) fournissent le support pour un boot sécurisé assisté par le hardware

57 Longhorn et la sécurité
Protected Administrator (PA) Les quelques applications qui ont besoin d’être exécutées avec des privilèges d’administration peuvent être marquées comme dignes de confiance (trusted) Le système fournit un environnement d’exécution isolé où seules ces applications peuvent s’exécuter Les applications normales ne peuvent interagir avec ces applications Least-Privileged User Account (LUA) Les applications normales peuvent être installées et maintenues par des utilisateurs normaux (c’est-à-dire des non administrateurs) Les applications normales s’exécutent avec les privilèges normaux des utilisateurs

58 Longhorn et la sécurité
Strongbox Virtualise l’état du PC (la base de registre et le système de fichiers) redirigeant les appels des applications Permet au système de revenir en arrière sur les changements nuisibles Permet au système de supporter des applications anciennes « au mauvais comportement » dans un mode LUA Secure Execution Environment (SEE) Un ensemble d’API puissantes, sécurisées en code managé qui peuvent être utilisées pour écrire des application qui s’exécutent dans un environnement sandbox Interface homme-machine de consentement Interface homme-machine cohérente qui s’assure que l’utilisateur est toujours informé des implications associées au fait d’exécuter une nouvelles application Code digne de confiance NGSCB supporte des opérations dignes de confiance s’exécutant sur un hardware digne de confiance dans un environnement d’exécution isolé

59 Plan de route 2004- 2005 Aujourd’hui Futur Longhorn Windows XP SP2
MGB 2003 Plan de route Aujourd’hui Futur Longhorn SDK Longhorn LUA (Least-privileged User Accounts) Renforcement de la sécurité de Windows avec NGSCB Patches mensuels Formation et support Conseils de base (patterns & practices) MSDN Security Developer Center Amélioration de /GS Code managé avec .NET Framework Windows XP SP2 Windows Server 2003 SP1 Visual Studio 2005 (Whidbey) /GS version 8 « ClickOnce » SEE (Secure Execution Environment) Pour plus d’information sur « Click Once », voir en © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

60 Un long voyage 01 02 03 04 05 06 07 08 09 10 Temps Mémo de Bill Gates
MGB 2003 Un long voyage Mémo de Bill Gates Une nouvelle attention XP SP1, 2003 server, Standards WS Début du déploiement Longhorn, DRM, NGSCB Nouvelles briques Nouvelle infrastructure, nouvelle culture Réalisation de TWC 01 02 03 04 05 06 07 08 09 10 Temps © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

61 La confiance… Nous ne pouvons pas aller plus loin sans elle !
MGB 2003 La confiance… Nous ne pouvons pas aller plus loin sans elle ! © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

62 MGB 2003 © 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

63 Étapes suivantes Être informé sur la sécurité
MGB 2003 Étapes suivantes Être informé sur la sécurité S'inscrire aux bulletins de sécurité : (en anglais) Obtenir l'aide la plus récente de Microsoft sur la sécurité : Obtenir des formations supplémentaires sur la sécurité Trouver des séminaires de formation en ligne et en classe : Trouver un centre de formation local agréé Microsoft (CTEC) pour des cours pratiques : Les étapes suivantes comprennent la visite du site Web de Microsoft pour : Obtenir les informations les plus récentes sur la sécurité Obtenir des activités de formation supplémentaires sur la sécurité © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

64 Pour plus d'informations
MGB 2003 Pour plus d'informations Site Microsoft sur la sécurité (tout public) Site MSDN sur la sécurité (développeurs) Site TechNet sur la sécurité (informaticiens) Des informations techniques supplémentaires pour les informaticiens et les développeurs sont disponibles sur les sites Web suivants : Site Microsoft sur la sécurité (tout public) Site MSDN sur la sécurité (développeurs) Site TechNet sur la sécurité (informaticiens) © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.


Télécharger ppt "Écriture de code sécurisé : la quête du Graal ?"

Présentations similaires


Annonces Google