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

SDL Trustworthy Computing Security Development Lifecycle Synthèse E. Mittelette, E Vernié Novembre 2005.

Présentations similaires


Présentation au sujet: "SDL Trustworthy Computing Security Development Lifecycle Synthèse E. Mittelette, E Vernié Novembre 2005."— Transcription de la présentation:

1 SDL Trustworthy Computing Security Development Lifecycle Synthèse E. Mittelette, E Vernié Novembre 2005

2 SDL: Principes …Ce processus consiste à ajouter une série d'activités et de tâches relatives à la sécurité à chacune des phases du processus de développement des logiciels Microsoft… …Ce processus consiste à ajouter une série d'activités et de tâches relatives à la sécurité à chacune des phases du processus de développement des logiciels Microsoft… l'élaboration de modèles de menace l'élaboration de modèles de menace l'utilisation d'outils d'analyse statique de code lors de leur implémentation l'utilisation d'outils d'analyse statique de code lors de leur implémentation l'exécution de révisions de code et de tests de sécurité pendant une période dédiée à la sécurité l'exécution de révisions de code et de tests de sécurité pendant une période dédiée à la sécurité Avant que les logiciels sujets au SDL puissent être diffusés, ils doivent subir un examen de sécurité final effectué par une équipe indépendante de son groupe de développement. Avant que les logiciels sujets au SDL puissent être diffusés, ils doivent subir un examen de sécurité final effectué par une équipe indépendante de son groupe de développement.

3 Nécessité de changer les éditeurs de logiciels doivent passer à un processus de développement de logiciels plus strict, c'est-à-dire centré sur la sécurité. les éditeurs de logiciels doivent passer à un processus de développement de logiciels plus strict, c'est-à-dire centré sur la sécurité. Cest un processus répétitif Cest un processus répétitif Qui inclus la formation des développeurs Qui inclus la formation des développeurs Qui propose des éléments de mesure et de transparence Qui propose des éléments de mesure et de transparence

4 Sécurité et Coût… l'adoption du SDL par d'autres entreprises ne doit pas accroitre excessivement les coûts du développement de logiciels. l'adoption du SDL par d'autres entreprises ne doit pas accroitre excessivement les coûts du développement de logiciels. D'après l'expérience de Microsoft, les avantages procurés par des logiciels mieux sécurisés (par exemple, moins de correctifs, plus de satisfaction client) l'emportent sur ces coûts additionnels. D'après l'expérience de Microsoft, les avantages procurés par des logiciels mieux sécurisés (par exemple, moins de correctifs, plus de satisfaction client) l'emportent sur ces coûts additionnels.

5 Lapproche et la méthode l'intégration de mesures permettant d'améliorer la sécurité des logiciels l'intégration de mesures permettant d'améliorer la sécurité des logiciels Sans remettre en cause lorganisation actuelle Sans remettre en cause lorganisation actuelle ajouter des points de contrôle de sécurité bien définis et des tâches relatives à la sécurité ajouter des points de contrôle de sécurité bien définis et des tâches relatives à la sécurité Postulat : il existe une équipe de sécurité centrale Postulat : il existe une équipe de sécurité centrale A prévoir en interne ou en externe… A prévoir en interne ou en externe…

6 Trustworthy Computing Initiative Trustworthy Computing Initiative Trustworthy Computing Initiative Mail de Bill à tous les employés : Mail de Bill à tous les employés : Faire de la sécurité une priorité, la traiter comme une fonctionnalité de base de nos produits… Faire de la sécurité une priorité, la traiter comme une fonctionnalité de base de nos produits… Début 2002 Début 2002 Depuis publication de Writing Secure Code Depuis publication de Writing Secure Code Publication et blog de M Howard Publication et blog de M Howard

7 « Le concept de Trustworthy Computing repose sur quatre piliers : Fiabilit é signifie qu'un syst è me informatique est s û r, disponible quand on en a besoin, et fonctionne correctement, aux niveaux appropri é s. S é curit é signifie qu'un syst è me r é siste aux attaques, et que la confidentialit é, l'int é grit é et la disponibilit é du syst è me comme des donn é es sont prot é g é es. Confidentialit é signifie que les individus ont la possibilit é d'avoir un contrôle sur les donn é es informatiques les concernant et que les organisations qui utilisent ces donn é es observent scrupuleusement des principes de respect des informations. Int é grit é signifie que les entreprises de notre secteur sont responsables vis- à -vis de leurs clients et doivent les aider à trouver des solutions adapt é es à leurs probl é matiques, à r é soudre ces probl è mes à l'aide de produits et services et à se montrer ouvertes dans leurs rapports avec leurs clients. » Trustworthy Computing - Bill Gates 18 juillet 2002

8 En 2005, SDL est documenté Liens associés :

9 Processus de développement Bien que la figure présente cinq étapes et semble indiquer un processus de développement en « cascade », il s'agit en fait d'un processus en spirale. Bien que la figure présente cinq étapes et semble indiquer un processus de développement en « cascade », il s'agit en fait d'un processus en spirale. Les exigences et la conception sont souvent reconsidérées lors de l'implémentation, en réponse aux besoins variables du marché et aux réalités apparues lors de l'implémentation du logiciel. Les exigences et la conception sont souvent reconsidérées lors de l'implémentation, en réponse aux besoins variables du marché et aux réalités apparues lors de l'implémentation du logiciel. De plus, le processus de développement insiste sur la nécessité de l'exécution d'un code pratiquement à chaque phase. Par conséquent, chaque étape principale est en fait divisée en une série de versions pouvant être constamment testées et utilisées de manière fonctionnelle (par l'équipe de développement). De plus, le processus de développement insiste sur la nécessité de l'exécution d'un code pratiquement à chaque phase. Par conséquent, chaque étape principale est en fait divisée en une série de versions pouvant être constamment testées et utilisées de manière fonctionnelle (par l'équipe de développement).

10 SD 3 Architecture de sécurité SD 3 Sécurité dès la conception Sécurité par défaut Sécurité du déploiement Code et architecture sécurisés Analyse des menaces Diminution des vulnérabilités Surface d'attaque réduite Fonctionnalités inutilisées désactivées par défaut Privilèges minimum utilisés Protection : Détection, défense, récupération, gestion Processus : Guides pratiques, guides d'architecture Personnes : Formation

11 SD3+C et SDL En introduisant les mesures de sécurité visant à intégrer le paradigme SD3+C dans le processus de développement existant, on obtient : En introduisant les mesures de sécurité visant à intégrer le paradigme SD3+C dans le processus de développement existant, on obtient :

12 Sécurité tout au long du cycle de vie d'un projet Plans de test terminés Conceptionsterminées Concept Codeterminé DiffusionPost-diffusion Accent sur la sécurité Questions sur la sécurité au cours des entretiens Déterminer les critères de validation de sécurité Révision externe Analyser les menaces Apprendre et affiner Révision de la sécurité par l'équipe Former l'équipe Tests sur la mutation des données et les privilèges minimaux Revoir les anciens défauts, intégrer les instructions vérifiées sur le codage sécurisé, utiliser les outils =continu

13 Le processus SDL Phase de définition des exigences Phase de définition des exigences, la phase de définition des exigences et de planification initiale d'une nouvelle version offre l'occasion idéale d'élaborer un logiciel sécurisé., la phase de définition des exigences et de planification initiale d'une nouvelle version offre l'occasion idéale d'élaborer un logiciel sécurisé. Phase de conception Phase de conception Définir la structure générale du logiciel du point de vue de la sécurité et identifier les composants dont le fonctionnement correct est essentiel à la sécurité (la « base informatique fiable »). Définir la structure générale du logiciel du point de vue de la sécurité et identifier les composants dont le fonctionnement correct est essentiel à la sécurité (la « base informatique fiable »). Répertorier les éléments présents dans la surface d'attaque du logiciel Répertorier les éléments présents dans la surface d'attaque du logiciel Effectuer une modélisation des menaces Effectuer une modélisation des menaces

14 Le processus SDL Phase d'implémentation Phase d'implémentation Les développeurs prêtent une attention toute particulière à l'exactitude du code permettant de limiter les menaces à haute priorité et les testeurs vérifient que de telles menaces sont effectivement bloquées ou limitées Les développeurs prêtent une attention toute particulière à l'exactitude du code permettant de limiter les menaces à haute priorité et les testeurs vérifient que de telles menaces sont effectivement bloquées ou limitées Appliquer les normes de codage et de test. Appliquer les normes de codage et de test. Appliquer des outils de test de la sécurité Appliquer des outils de test de la sécurité Appliquer des outils d'analyse statique de code Appliquer des outils d'analyse statique de code Effectuer des révues de code Effectuer des révues de code

15 Le processus SDL Phase de vérification Phase de vérification Au cours de cette phase, pendant que le logiciel est soumis à des tests bêtas, l'équipe produit effectue une « campagne de sécurité » comprenant des revues de code de sécurité plus poussées que celles réalisées à la phase d'implémentation, ainsi que des tests de sécurité ciblés. Au cours de cette phase, pendant que le logiciel est soumis à des tests bêtas, l'équipe produit effectue une « campagne de sécurité » comprenant des revues de code de sécurité plus poussées que celles réalisées à la phase d'implémentation, ainsi que des tests de sécurité ciblés. Mener une campagne de sécurité pendant la phase de vérification garantit que la revue de code et les tests sont effectués sur la version finale Mener une campagne de sécurité pendant la phase de vérification garantit que la revue de code et les tests sont effectués sur la version finale

16 Le processus SDL Phase de vérification Phase de vérification doit subir une revue de sécurité finale, ou FSR doit subir une revue de sécurité finale, ou FSR « Du point de vue de la sécurité, ce logiciel est-il prêt à être livré à des clients ? » « Du point de vue de la sécurité, ce logiciel est-il prêt à être livré à des clients ? » La FSR est une revue du logiciel indépendante La FSR est une revue du logiciel indépendante Toute FSR exige une révision des bogues initialement identifiés comme des bogues de sécurité Toute FSR exige une révision des bogues initialement identifiés comme des bogues de sécurité Une FSR comprend également une revue de la capacité du logiciel à résister à des vulnérabilités récemment signalées affectant des logiciels similaires Une FSR comprend également une revue de la capacité du logiciel à résister à des vulnérabilités récemment signalées affectant des logiciels similaires Tests de pénétration Tests de pénétration

17 Le processus SDL Phase de support et de maintenance Phase de support et de maintenance Malgré l'application du SDL au cours du développement, les pratiques de développement de pointe ne garantissent pas encore l'envoi de logiciels totalement invulnérables et il y a de bonnes raisons de croire que cela n'arrivera jamais. Malgré l'application du SDL au cours du développement, les pratiques de développement de pointe ne garantissent pas encore l'envoi de logiciels totalement invulnérables et il y a de bonnes raisons de croire que cela n'arrivera jamais.

18 A qui sapplique SDL Obligation d'application du SDL Obligation d'application du SDL Susceptibles d'être utilisés pour traiter des informations personnelles et sensibles Susceptibles d'être utilisés pour traiter des informations personnelles et sensibles Susceptibles d'être utilisés dans une entreprise ou par toute autre organisation (par exemple, une université, un gouvernement ou une association). Susceptibles d'être utilisés dans une entreprise ou par toute autre organisation (par exemple, une université, un gouvernement ou une association). Susceptibles d'être connectés à Internet ou bien utilisés dans un environnement réseau. Susceptibles d'être connectés à Internet ou bien utilisés dans un environnement réseau.

19 Une équipe « dédiée » sécurité L'équipe de sécurité centrale : SWI - Secure Windows Initiative L'équipe de sécurité centrale : SWI - Secure Windows Initiative Développement, maintenance et amélioration du SDL, y compris la définition des aspects obligatoires du processus. Développement, maintenance et amélioration du SDL, y compris la définition des aspects obligatoires du processus. Développement, amélioration et dispense d'une formation aux techniciens. Développement, amélioration et dispense d'une formation aux techniciens. Attribution/mise à disposition de « conseillers en sécurité » qui assistent les équipes produit tout au long du processus, effectuent des révisions pour elles et s'assurent que les questions de l'équipe produit reçoivent des réponses précises, bien documentées et dans les meilleurs délais. Attribution/mise à disposition de « conseillers en sécurité » qui assistent les équipes produit tout au long du processus, effectuent des révisions pour elles et s'assurent que les questions de l'équipe produit reçoivent des réponses précises, bien documentées et dans les meilleurs délais. Faire office d'experts dans une large gamme de sujets relatifs à la sécurité, en s'assurant que les questions adressées aux conseillers en sécurité reçoivent des réponses précises dans les meilleurs délais. Faire office d'experts dans une large gamme de sujets relatifs à la sécurité, en s'assurant que les questions adressées aux conseillers en sécurité reçoivent des réponses précises dans les meilleurs délais. Exécution des FSR avant le lancement du logiciel. Exécution des FSR avant le lancement du logiciel. Investigation technique des vulnérabilités signalées dans les logiciels envoyés aux clients afin de s'assurer que les causes premières sont comprises et que le niveau de réponse approprié est mis en œuvre. Investigation technique des vulnérabilités signalées dans les logiciels envoyés aux clients afin de s'assurer que les causes premières sont comprises et que le niveau de réponse approprié est mis en œuvre.

20 Efficacité et outils Efficacité des éléments du SDL Efficacité des éléments du SDL L'équipe SWI est d'accord sur le fait que la modélisation des menaces est le composant le plus important du SDL L'équipe SWI est d'accord sur le fait que la modélisation des menaces est le composant le plus important du SDL les tests de pénétration ne constituent pas la meilleure façon de parvenir à un niveau de sécurité satisfaisant les tests de pénétration ne constituent pas la meilleure façon de parvenir à un niveau de sécurité satisfaisant centrées sur la modélisation des menaces, les révisions de code et l'utilisation d'outils automatisés, ainsi que des tests de robustesse plutôt que sur des tests de pénétration. centrées sur la modélisation des menaces, les révisions de code et l'utilisation d'outils automatisés, ainsi que des tests de robustesse plutôt que sur des tests de pénétration. L'expérience de Microsoft montre que le SDL est efficace pour réduire le nombre de vulnérabilités en matière de sécurité L'expérience de Microsoft montre que le SDL est efficace pour réduire le nombre de vulnérabilités en matière de sécurité

21 Annexe Evaluation des menaces

22 Types d'attaques courants Échec de la connexion Attaques d'entreprise Données confidentielles Violations accidentelles de la sécurité Attaques automatisées Pirates Virus, chevaux de Troie et vers Déni de service (DoS) DoS

23 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 : La modélisation des menaces est une analyse basée sur la sécurité dont les objectifs sont les suivants : Aider l'équipe produit à identifier les vulnérabilités du produit Aider l'équipe produit à identifier les vulnérabilités du produit Évaluer les menaces relatives à une application Évaluer les menaces relatives à une application Réduire les risques globaux à l'égard de la sécurité Réduire les risques globaux à l'égard de la sécurité Identifier les ressources Identifier les ressources Découvrir les vulnérabilités Découvrir les vulnérabilités Identifier les menaces Identifier les menaces Permettre d'établir la base des spécifications de conception en matière de sécurité Permettre d'établir la base des spécifications de conception en matière de sécurité

24 Avantages de la modélisation des menaces Permet de mieux comprendre votre application Permet de mieux comprendre votre application Permet de rechercher les erreurs Permet de rechercher les erreurs Permet d'identifier les erreurs de conception complexes Permet d'identifier les erreurs de conception complexes Permet d'int é grer de nouveaux membres à l' é quipe Permet d'int é grer de nouveaux membres à l' é quipe Permet d' é tablir des programmes de test de s é curit é bien con ç us Permet d' é tablir des programmes de test de s é curit é bien con ç us Risque Vulnérabilité Ressource

25 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

26 Processus de modélisation des menaces Étape 1 : Identifier les ressources É tablissez la liste des ressources devant être prot é g é es : É tablissez la liste des ressources devant être prot é g é es : Donn é es confidentielles, telles que les bases de donn é es des clients Donn é es confidentielles, telles que les bases de donn é es des clients Pages Web Pages Web Disponibilit é syst è me Disponibilit é syst è me Tous les autres é l é ments qui, s'ils é taient endommag é s, pourraient empêcher le bon fonctionnement de votre application Tous les autres é l é ments qui, s'ils é taient endommag é s, pourraient empêcher le bon fonctionnement de votre application

27 Processus de modélisation des menaces Étape 2 : Créer une vue d'ensemble de l'architecture Identifier ce que fait l'application Identifier ce que fait l'application Cr é er un diagramme de l'architecture Cr é er un diagramme de l'architecture Identifier les technologies Identifier 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

28 Processus de modélisation des menaces Étape 3 : Décomposer l'application D é composez l'application D é composez l'application Cr é ez un profil de s é curit é bas é sur les domaines de vuln é rabilit é classiques 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 Examinez les interactions entre les diff é rents sous- syst è mes Utilisez les diagrammes UML ou de flux de donn é es 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é

29 Processus de modélisation des menaces Étape 4 : Identifier les menaces Constituez une é quipe Constituez une é quipe Identifiez les menaces Identifiez les menaces Menaces li é es au r é seau Menaces li é es au r é seau Menaces li é es aux hôtes Menaces li é es aux hôtes Menaces li é es à l'application Menaces li é es à l'application

30 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

31 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

32 Processus de modélisation des menaces Étape 5 : Documenter les menaces Documenter les menaces à l'aide d'un mod è le : Documenter les menaces à l'aide d'un mod è le : Ne pas renseigner le champ Risque (pour l'instant) Ne pas renseigner 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

33 Processus de mod é lisation des menaces É tape 6 : É valuer les menaces Utilisez la formule suivante : Utilisez la formule suivante : Risque = Probabilit é * Dommage potentiel Utilisez le mod è le DREAD pour noter les menaces 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

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


Télécharger ppt "SDL Trustworthy Computing Security Development Lifecycle Synthèse E. Mittelette, E Vernié Novembre 2005."

Présentations similaires


Annonces Google