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 ? Bernard Ourghanlian Directeur Technologie et Sécurité Microsoft France.

Présentations similaires


Présentation au sujet: "Écriture de code sécurisé : la quête du Graal ? Bernard Ourghanlian Directeur Technologie et Sécurité Microsoft France."— Transcription de la présentation:

1 Écriture de code sécurisé : la quête du Graal ? Bernard Ourghanlian Directeur Technologie et Sécurité Microsoft France

2 La quête du Graal ? « La programmation est aujourdhui une course entre les ingénieurs informaticiens qui essaient de construire des programmes plus grands et mieux à lépreuve des idiots, et lunivers qui essaie de produire des idiots plus grands et plus idiots. Jusquà présent, lunivers 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 lan La lutte contre le bogue de lan 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 lon 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 : lun pour les secondes, remis à zéro chaque semaine ; lautre 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 navaient 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 lorientation des panneaux solaires

5 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 denquê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 nest quune simple, une toute petite erreur mais son coût a été énorme (coût du programme détude dAriane V : 38 milliards de francs) et à provoqué un retard de plus dun an pour le programme du nouveau lanceur

6 La quête du Graal ? Difficultés sur la mission Mars Pathfinder (atterrissage le 4 juillet 1997) Cause : Des réinitialisations inopinées de lordinateur de bord retardent la mission A Pasadena, les informaticiens travaillent darrache-pied pour dénicher le bogue. Celui-ci est finalement débusqué au sortir dune nuit blanche : une mauvaise gestion des priorités des tâches à effectuer est à lorigine 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

7 Logiciel de qualité Logiciel sécurisé Logiciel fiable Logiciel de qualité Un logiciel sécurité est un sous-ensemble dun logiciel de qualité

8 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++; La quête du Graal ? Port 135 (en provenance de lInternet)

9 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++; } La quête du Graal ? CORRIGE

10 Le coeur de lerreur… 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 while (*c != \\) *p++ = *c++; Contraint seulement par les données source Vient du réseau !

11 Pourquoi est-ce important de se préoccuper des applications ? Today over 70% of attacks against a companys 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 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 linstallation 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 lapplication 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 dun correctif est de $

13 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 Les problèmes liées à une confiance injustifiée dans les entrées Tout le reste… Tout le reste…

14 Problèmes liées à une confiance injustifiée dans les entrées Buffer Overruns Injection SQL Cross-Site Scripting DupontDupont drop table facture --Dupont var i=document.cookie

15 Pourquoi est-ce important de se préoccuper des applications ? Pourcentage dattaques réussies au niveau applicatif en fonction du type dattaque Cross-site scripting 80% Database server 33% SQL injection 62%Web server23% 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 ? Les données en provenance de lexté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 dexécution Ceci a pour conséquence la modification par lapplication du flux dexécution Vers le code de lattaquant 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

17 A quel point les BO sont-ils fréquents ? Source : Les sites Web des fournisseurs du 1 jan au 1 oct MicrosoftSunRedHatDebian Bulletins (2003)Buffer Overruns

18 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é à lInternet De nombreuses structures de données contiennent des jumps à du code Adresse de pile, pointeurs vers des fonctions, gestionnaires dexception, v-tables de classes C++, etc. Les menaces évoluent constamment Il y eut dabord 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 dun octet Maintenant les débordements dentiers Qui aura-t-il ensuite ? Les développeurs ne contrôlent pas les données en entrée !

19 Les évolutions de Visual Studio Adresses croissantes BuffersVariables EBP EIP Args Visual Studio 6 BuffersVariables EBP EIP Args cookie Visual Studio.NET (avec /GS) BuffersVariables EBP EIP Args cookie Visual Studio 2003 (avec /GS et sécurités supplémentaires) EBP : Registre Stack Base pointer : détient ladresse de base de la pile EIP : Registre Index Pointer détient le déplacement de la prochaine instruction Option /GS : Insertion dune valeur tampon aléatoire dans la pile appelée « canary » ou « cookie »

20 Buffer Overflow

21 Injection SQL

22 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

23 Le logiciel : une bête curieuse Il est visible mais intangible Il vieillit mais ne suse pas Il ne se détériore pas sous leffet 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é...

24 Construire du logiciel… Logiciel Sécurité Respect de la vie privée Fiabilité Supportable Gérable Déployable Compatible Abordable International Accessible Utilisable (fonctions) Faisable (calendrier, $, compétences)

25 Construire du logiciel LogicielSécurité Respect de la vie privé Fiabilité Supportable Gérable Déployable Compatible Abordable International Accessible Utilisable (fonctions) Faisable (cal., $, compétences)

26

27 Sécurité Respect vie privée Fiabilité Intégrité entreprise Résistance aux attaques Protection de la confidentialité, de lintégrité, de la disponibilité et des données Sûr Disponible lorsque nécessaire Offre le service attendu 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 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 Trustworthy Computing Les principes de base

28 SD 3 + Communications Engagement clair sur la sécurité Membre à part entière de la communauté de la sécurité Microsoft Security Response Center La sécurité Secure by Design Secure by Default Secure in Deployment Communications Architecture sécurisée Fonctionnalités « conscientes » de sécurité Réduction des vulnérabilités dans le code Réduction de la surface dattaque Fonctionnalités inutilisées hors service par défaut Besoin minimum en privilèges Protéger, détecter, défendre, récupérer, gérer Processus : How tos, guides darchitecture Hommes : les former !

29 Améliorer la qualité Processus de développement Trustworthy Computing M1 M2 Mn Beta Conception Développement Sortie Support Revue de sécurité Chaque équipe développe une modélisation des menaces de son composant afin de sassurer que la conception bloque bien les menaces applicables Dév & test 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 dattaque Security Push 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 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 Security Response Correction des problèmes nouvellement découverts Analyse des causes pour trouver et corriger de manière proactive les vulnérabilités associées Docs de conception & spécifications Développement test et documentation Produit Service Packs, correctifs

30 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

31 Chronologie du d é veloppement d'un logiciel s é curis é Plans de test terminés Conceptionsterminées Concept Codeterminé DiffusionPost-diffusion Déterminer les critères de validation de la sécurité Apprendre et affiner Analyser les menaces Révision de la sécurité par l'équipe 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é = continu

32 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

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

34 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

35 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 Documenter les menaces 5 Évaluer les menaces 6 Processus de modélisation des menaces

36 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

37 Processus de mod é lisation des menaces É tape 2 : Cr é er une vue d'ensemble de l'architecture 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 (authentification) Rôle défini par l'utilisateur (authentification) SSL (Confidentialité/ Intégrité) Frontière sécurisée Alice Mirwault Laura Bartoli Victor Nahas IIS Authentification anonyme Authentification par formulaires IPSec (Privé/Intégrité) Frontière sécurisée ASPNET (identité du processus) Microsoft ASP.NET Microsoft ASP.NET Authentification de Microsoft ® Windows Microsoft SQL Server

38 Processus de mod é lisation des menaces É tape 3 : D é composer l'application 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 les frontières sécurisées Identifier le flux de données Identifier les points d'entrée Identifier le code privilégié Documenter le profil de sécurité

39 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

40 Types de menaces Exemples U S urpation Falsification de messages électroniques Rediffusion de paquets d'authentification Falsifica T ion 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' I nformations Exposition d'informations dans des messages d'erreur Exposition de code sur des sites Web D eni de service Submersion d'un réseau avec des paquets SYN Submersion d'un réseau avec des paquets ICMP falsifiés E lé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 Processus de mod é lisation des menaces Identifier les menaces à l'aide de STRIDE

41 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 Espionner le trafic avec un analyseur de protocole Écouter le trafic du routeur Routeur non équipé d'un correctif Endommager le routeur Deviner le mot de passe du routeur 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 Espionner le trafic avec un analyseur de protocole Écouter le trafic du routeur Routeur non équipé d'un correctif (ET) Endommager le routeur Deviner le mot de passe du routeur Processus de mod é lisation des menaces Identifier les menaces à l'aide d'organigrammes des menaces

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

43 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 Dommage potentiel Reproductibilit é Reproductibilit é Exploitation Exploitation Affect é s Utilisateurs Affect é s D é couverte D é couverte

44 Processus de mod é lisation des menaces Exemple : É valuer les menaces 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 Espionner le trafic avec un analyseur de protocole Écouter le trafic du routeur Routeur non équipé d'un correctif Endommager le routeur Deviner le mot de passe du routeur Dommage potentiel Utilisateurs affectés Ou Dommage Reproductibilité Exploitation Découverte Ou Probabilité

45 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

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

47 Processus d'att é nuation des risques Type de menace (STRIDE) Technique d'atténuation Technologie UsurpationAuthentification NTLM Certificats X.509 Clés PGP De base Digest Kerberos SSL/TLS 1.Identifier la catégorie Par exemple : Usurpation 2.Sélectionner les techniques Par exemple : Authentification ou protection des données confidentielles 3.Sélectionner la technologie Par exemple : Kerberos

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

49 Quelques méthodes permettant damé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 dun modèle de défense en profondeur Méfiance par rapport à la sécurité par la dissimulation Non stockage dinformations 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 Secure by Default Secure in Deployment 1.Construire des modèles de menace 2.Supprimer les défauts dans le code 3.Éviter de nouveaux défauts de sécurité 4.Utiliser du code managé aujourdhui 5.Utiliser outils & checklists Réduire la surface dattaque : 6.Mettre hors service les fonctionnalités 7.Requérir le minimum de privilèges 8.Ajouter des couches défensives supplémentaires 9.Être bien disposé à légard des firewalls et antivirus 10.Créer des guides de sécurité et une bonne documentation

51 Développeurs : pour résumer Secure by Design Un processus qui favorise les systèmes sécurisés Un processus qui favorise les systèmes sécurisés Construire des modèles de menace Construire des modèles de menace Conduire des revues de code, des tests de pénétration Conduire des revues de code, des tests de pénétration Exécuter le code avec des privilèges minimaux Exécuter le code avec des privilèges minimaux Secure by Default Minimiser la surface dattaque (services off par défaut) Minimiser la surface dattaque (services off par défaut) Sécuriser les services Sécuriser les services Utiliser les fonctions de sécurité de Visual Studio.NET Utiliser les fonctions de sécurité de Visual Studio.NET Secure in Deployment Tirer parti des meilleures pratiques Tirer parti des meilleures pratiques Créer des guides de sécurité Créer des guides de sécurité Construire des outils pour évaluer la sécurité des applications Construire des outils pour évaluer la sécurité des applications Microsoft Developer Network Patterns and Practices Guides Écrire du Code Sécurisé 2

52 Le balancier de la sécurité logicielle – Où nous étions… Facile à utiliser Large surface dattaque « Automagique » Rapidité de lInternet Les logiciels (et les attaques) fonctionnent sans que lon se pose de questions Usage&FonctionsSécurité& Vie Privée

53 Le balancier de la sécurité logicielle – Où nous sommes… Surface dattaque réduite Souvent plus difficile à utiliser Sécurité anxiogène Plus long à mettre sur le marché De nombreuses questions relatives à la sécurité (pour lutilisateur) Usage&FonctionsSécurité& Vie Privée

54 Le balancier de la sécurité logicielle – Où nous devrions être… Petite surface dattaque 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 cest possible Configurable là où cest nécessaire Utilisable de manière sécurisée Usage&FonctionsSécurité& Vie Privée

55 Créer un système sécurisé 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 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 Construire du code sécurisé Visual Studio Secure Execution Environment (SEE) Construire du code sécurisé Visual Studio Secure Execution Environment (SEE) Communiquer en toute sécurité Carte à puce, système didentité, support de la biométrie Réseau sécurisé, WS-Security Internet Connection Firewall Cross-Organizational Trust Communiquer en toute sécurité Carte à puce, système didentité, support de la biométrie Réseau sécurisé, WS-Security Internet Connection Firewall Cross-Organizational Trust Rester sécurisé Windows Update Service (WUS) Microsoft Audit Collection Service Security Configuration Wizard Windows Update Trust Center Rester sécurisé Windows Update Service (WUS) Microsoft Audit Collection Service Security Configuration Wizard Windows Update Trust Center 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 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

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 sassurer quil est bien dans lun 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 sexécuter Le code peut être identifié par : hash, emplacements dinstallation ou dexé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 dadministration peuvent être marquées comme dignes de confiance (trusted) Le système fournit un environnement dexécution isolé où seules ces applications peuvent sexé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 (cest-à-dire des non administrateurs) Les applications normales sexé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 dAPI puissantes, sécurisées en code managé qui peuvent être utilisées pour écrire des application qui sexécutent dans un environnement sandbox Interface homme-machine de consentement Interface homme-machine cohérente qui sassure que lutilisateur est toujours informé des implications associées au fait dexécuter une nouvelles application Code digne de confiance NGSCB supporte des opérations dignes de confiance sexécutant sur un hardware digne de confiance dans un environnement dexécution isolé

59 Futur Aujourdhui 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) Longhorn SDK Longhorn LUA (Least- privileged User Accounts) Renforcement de la sécurité de Windows avec NGSCB Plan de route

60 Un long voyage Nouvelle infrastructure, nouvelle culture Réalisation de TWC Mémo de Bill Gates Une nouvelle attention XP SP1, 2003 server, Standards WS Début du déploiement Longhorn, DRM, NGSCB Nouvelles briques Temps

61 La confiance… Nous ne pouvons pas aller plus loin sans elle !

62

63 É tapes suivantes Être inform é sur la s é curit é Être inform é sur la s é curit é S'inscrire aux bulletins de 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 l'aide la plus r é cente de Microsoft sur la s é curit é : Obtenir des formations suppl é mentaires 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 des s é minaires de formation en ligne et en classe : Trouver un centre de formation local agr éé Microsoft (CTEC) pour des cours pratiques : Trouver un centre de formation local agr éé Microsoft (CTEC) pour des cours pratiques :

64 Pour plus d'informations Site Microsoft sur la s é curit é (tout public) Site MSDN sur la s é curit é (d é veloppeurs) /technos/securite/default.asp /technos/securite/default.asp Site TechNet sur la s é curit é (informaticiens) efault.asp efault.asp


Télécharger ppt "Écriture de code sécurisé : la quête du Graal ? Bernard Ourghanlian Directeur Technologie et Sécurité Microsoft France."

Présentations similaires


Annonces Google