SDL Trustworthy Computing Security Development Lifecycle

Présentation au sujet: "SDL Trustworthy Computing Security Development Lifecycle"— 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… l'élaboration de modèles de menace 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é 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é. C’est un processus répétitif Qui inclus la formation des développeurs 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. 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 L’approche et la méthode
l'intégration de mesures permettant d'améliorer la sécurité des logiciels Sans remettre en cause l’organisation actuelle 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 A prévoir en interne ou en externe…

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

7 Trustworthy Computing
« 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. » - 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. 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).

10 Architecture de sécurité SD3
Code et architecture sécurisés Analyse des menaces Diminution des vulnérabilités Sécurité dès la conception Sécurité par défaut Surface d'attaque réduite Fonctionnalités inutilisées désactivées par défaut Privilèges minimum utilisés L'équipe SWI (Secure Windows Initiative) de Microsoft a adopté un ensemble de stratégies simple baptisé SD3. L'architecture de sécurité SD3 regroupe trois concepts principaux : La Sécurité dès la conception, la Sécurité par défaut et la Sécurité du déploiement. Ces concepts ont donné sa forme au processus de développement pour permettre la création de systèmes sécurisés. Sécurité dès la conception signifie que vous avez suivi les étapes appropriées pour garantir que la conception globale du produit est sécurisée dès le début. Intégrez la modélisation des menaces dans la phase de conception et tout au long du projet afin d'identifier les vulnérabilités potentielles. Suivez les instructions relatives au test, au codage et à la conception sécurisés. Sécurité par défaut signifie que le produit diffusé est sécurisé dès son installation sans configuration supplémentaire. Si des fonctionnalités sont facultatives, vous pouvez les désactiver par défaut. Si une fonctionnalité n'est pas activée, un intrus ne pourra pas utiliser celle-ci pour endommager votre produit. Assurez-vous que les comptes utilisateur nécessitent le moins de privilèges possible pour exécuter votre application. Ainsi, les conséquences d'un endommagement peuvent être moins graves que si un intrus a la possibilité d'exécuter un code nuisible sous un compte disposant des privilèges d'administrateur. Assurez-vous que des contrôles d'accès efficaces sont en place pour les ressources. Sécurité du déploiement signifie que le système est gérable après l'installation. Si l'administration d'un produit est complexe, la gestion de la protection contre les menaces à l'égard de la sécurité s'avère plus difficile car de nouvelles menaces apparaissent. Assurez-vous que les utilisateurs sont formés pour utiliser le système de manière sécurisée. Si une vulnérabilité de sécurité est détectée et qu'un correctif s'avère nécessaire, vérifiez que ce correctif est entièrement testé en interne et qu'il est fourni en temps voulu. Protection : Détection, défense, récupération, gestion Processus : Guides pratiques, guides d'architecture Personnes : Formation Sécurité du déploiement

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 :

12 Sécurité tout au long du cycle de vie d'un projet
Plans de test terminés Conceptions terminées Concept Code terminé Diffusion Post-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 La sécurité doit être intégrée à l'ensemble du cycle de développement, de la conception de l'architecture au fonctionnement, en passant par le développement, les tests et le déploiement. Les activités représentées sur cette diapositive sont itératives et permanentes. Il ne s'agit pas d'activités ponctuelles : elles ont lieu tout au long du cycle de développement.

13 Le processus SDL Phase de définition des exigences Phase de conception
, 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 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 Effectuer une modélisation des menaces

14 Le processus SDL 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 Appliquer les normes de codage et de test. Appliquer des outils de test de la sécurité Appliquer des outils d'analyse statique de code Effectuer des révues de code

15 Le processus SDL 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. 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
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 ? » 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é 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

17 Le processus SDL 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.

18 A qui s’applique SDL Obligation d'application du SDL
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 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 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. 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. 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.

20 Efficacité et outils 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 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. 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 Evaluation des menaces
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é automatisées Pirates Virus, chevaux de Troie et vers Déni de service (DoS) DoS Les attaques contre les entreprises impliquent une intrusion dans le réseau de l'entreprise afin d'accéder aux informations confidentielles et d'en tirer un avantage commercial. Les pirates adorent s'exercer à contourner vos dispositifs de sécurité et à obtenir un accès illégal à votre réseau. Les attaques automatisées utilisent un logiciel qui recherche les vulnérabilités de votre réseau ou qui mettent en œuvre une attaque en force. Les attaques en force essaient différents noms d'utilisateurs, mots de passe ou informations d'authentification afin d'accéder à vos ressources. Les attaques par déni de service (DoS) submergent un serveur de demandes, ce qui l'empêche de fournir un service normal. Les virus, chevaux de Troie et vers sont des programmes nuisibles qui exploitent une vulnérabilité connue afin de s'installer sur un ordinateur (par le biais d'une pièce jointe à un message électronique, par exemple). Une fois qu'ils sont présents sur un ordinateur, ils se propagent aux autres ordinateurs connectés et ces copies se propagent à leur tour, ce qui résulte en une infection rapide de l'intégralité du réseau. Les violations accidentelles de la sécurité résultent souvent de méthodes ou de procédures peu fiables. Par exemple, si des informations de sécurité, telles que des noms d'utilisateurs et des mots de passe, sont exposées, un intrus peut exploiter ces informations pour accéder à votre réseau.

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 : Aider l'équipe produit à identifier les vulnérabilités du produit É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.

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

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

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

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

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

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

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

31 Voir les informations relatives aux salaires
Processus de modélisation des menaces Identifier les menaces à l'aide d'organigrammes des menaces 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 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 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

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

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

34 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