Exporter (0) Imprimer
Développer tout

Modélisation de la menace

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Avant de commencer Avant de commencer
Principes de modélisation de la menace Principes de modélisation de la menace
Étape 1 : Identification des ressources Étape 1 : Identification des ressources
Étape 2 : Création d'une représentation de l'architecture Étape 2 : Création d'une représentation de l'architecture
Étape 3 : Décomposition de l'application Étape 3 : Décomposition de l'application
Étape 4 : Identification des menaces Étape 4 : Identification des menaces
Étape 5 : Documentation des menaces Étape 5 : Documentation des menaces
Étape 6 : Évaluation des menaces Étape 6 : Évaluation des menaces
Que faire après avoir modélisé la menace ? Que faire après avoir modélisé la menace ?
Résumé Résumé
Informations complémentaires Informations complémentaires

Dans ce module

La modélisation de la menace permet d'identifier et de classer, de manière systématique, les menaces qui risquent le plus d'affecter votre système.

Il s'agit d'un processus structuré bien plus efficace et rentable que l'application aléatoire de fonctions de sécurité, sans connaître exactement les menaces contre lesquelles chaque fonction est censée lutter.

Lorsque vous aurez lu ce module et associé le processus de modélisation de la menace à votre application Web, vous aurez identifié et évalué les menaces existantes en vous basant sur une solide compréhension des vulnérabilités de votre logiciel. Grâce à ces informations, vous pourrez gérer les menaces en adoptant des contre-mesures appropriées dans un ordre logique, en commençant par celles qui présentent le plus grand risque.

Il n'existe aucun système fiable à 100 % lorsqu'une application Web est exposée à un environnement hostile tel qu'Internet, un intranet ou un extranet. La seule solution possible est d'avoir conscience des menaces et d'atténuer ou de gérer les risques associés. La modélisation de la menace permet de réaliser cette analyse et de concentrer vos ressources sur les problèmes pertinents, en vue d'un retour maximum sur investissement.

Objectifs

Ce module vous permettra :

  • de créer des modèles de menace ;

  • d'apprendre à évaluer les menaces et à utiliser le modèle DREAD ;

  • de décomposer l'architecture d'une application et d'en découvrir les points faibles ;

  • d'identifier et de documenter les menaces spécifiques de votre application.

S'applique à

Applications Web

Avant de commencer

Avant de commencer le processus de modélisation de la menace, il est important de connaître la terminologie de base.

  • Ressource. Élément de valeur, tel que les données d'une base ou d'un système de fichiers, ou une ressource du système.

  • Menace. Événement potentiel, malveillant ou autre, qui peut endommager ou compromettre vos ressources.

  • Vulnérabilité. Faiblesse existant dans un aspect ou une fonctionnalité du système qui rend possible une menace. Les vulnérabilités peuvent exister aux niveaux réseau, hôte ou application.

  • Attaque (ou exploit). Action, d'origine humaine ou non, visant à nuire à une ressource. Une attaque peut être déclenchée par une personne qui a déjà menacé votre application ou qui cherche à exploiter une vulnérabilité.

  • Contre-mesure. Mesure de protection qui contre une menace et atténue un risque.

Prenons une comparaison domestique : dans une maison, un bijou représente une ressource et le voleur est le pirate. Une porte correspond à une fonction, et une porte ouverte à une vulnérabilité. Le voleur peut utiliser la porte ouverte pour accéder à la maison et voler le bijou. En d'autres termes, le pirate exploite une vulnérabilité pour accéder à une ressource. Dans ce cas, la contre-mesure adéquate consiste à fermer et à verrouiller la porte.

Principes de modélisation de la menace

La modélisation de la menace ne doit pas être un processus ponctuel. Il s'agit d'un procédé itératif qui démarre dès la conception de votre application et se poursuit durant son cycle de vie. Il y a deux raisons à cela. Premièrement, il est impossible d'identifier toutes les menaces possibles en une seule fois. Deuxièmement, les applications sont rarement statiques, elles ont besoin d'être améliorées et adaptées en fonction des changements de vos activités, de sorte que la modélisation de la menace doit être répétée et modifiée à mesure que votre application évolue.

Le processus

La figure 3.1 illustre le processus de modélisation de la menace que vous pouvez mettre en œuvre en six étapes.

Remarque : le processus suivant est utilisable pour des applications en cours de développement aussi bien qu'existantes.

Vue d'ensemble du processus de modélisation de la menace

Figure 3.1
Vue d'ensemble du processus de modélisation de la menace

  1. Identification des ressources.
    Identifiez les ressources de valeur que vos systèmes doivent protéger.

  2. Création d'une représentation de l'architecture.
    Utilisez des schémas et des tableaux simples pour documenter l'architecture de votre application, y compris les sous-systèmes, les limites de confiance et les flux de données.

  3. Décomposition de l'application.
    Décomposez l'architecture de votre application, y compris la conception de l'infrastructure sous-jacente du réseau et de l'hôte, de façon à créer un profil de sécurité pour l'application. Le but de ce profil est de mettre en évidence les vulnérabilités dans les domaines de la conception, de la mise en œuvre ou de la configuration du déploiement de l'application.

  4. Identification des menaces.
    Gardez à l'esprit les objectifs d'un pirate et, en vous appuyant sur votre connaissance de l'architecture et des vulnérabilités potentielles de votre application, identifiez les menaces qui risquent de peser sur elles.

  5. Documentation des menaces.
    Documentez chaque menace en utilisant un modèle courant qui définit un ensemble élémentaire d'attributs pour décrire chaque menace.

  6. Évaluation des menaces. Évaluez les menaces de façon à les classer et traitez en premier celles qui présentent le plus grand risque. L'évaluation permet d'estimer la probabilité de voir la menace causer des dommages en cas d'attaque. En effet, toutes les menaces ne justifient pas nécessairement une contre-mesure lorsque vous comparez le risque qu'elles posent aux coûts à engager pour atténuer ce risque.

Le résultat

La modélisation de la menace donne lieu à un document destiné aux divers membres de votre équipe. Il leur permet de comprendre clairement les menaces à prendre en considération et la manière de les traiter. Les modèles de menace comprennent une définition de l'architecture de votre application ainsi qu'une liste des menaces propres à votre scénario, comme le montre la figure 3.2.

Composant du modèle de menace

Figure 3.2
Composant du modèle de menace

Étape 1 : Identification des ressources

Identifiez les ressources à protéger. Il peut s'agir de données confidentielles comme votre base de données des commandes client, de pages Web ou encore de la disponibilité de votre site Web.

Étape 2 : Création d'une représentation de l'architecture

À ce stade, l'objectif est de documenter les fonctionnalités de votre application, la configuration de son architecture et de son déploiement physique, et les technologies qui composent votre solution. Vous devez rechercher les vulnérabilités potentielles dans la conception ou dans la mise en œuvre de l'application.

Durant cette étape, vous allez effectuer les opérations suivantes :

  • Identifier ce que fait l'application

  • Créer une représentation schématique de l'architecture

  • Identifier les technologies

Identifier ce que fait l'application

Identifiez ce que l'application accomplit, comment elle utilise les ressources et y accède. Décrivez des cas d'utilisation qui vous aideront ainsi que d'autres personnes à mieux comprendre ce que votre application est censée faire et à déterminer aussi comment elle peut être détournée. Ces utilisations permettent de voir les fonctionnalités de l'application en contexte.

Voici quelques exemples d'utilisation d'une application en libre service concernant des ressources humaines.

  • L'employé visualise des données financières.

  • L'employé met à jour ses données personnelles.

  • Le responsable visualise les informations relatives à l'employé.

Dans les cas ci-dessus, vous pouvez observer les implications d'une mauvaise utilisation des règles métier. Ainsi, prenez un utilisateur qui tente de modifier les données personnelles d'un autre utilisateur. Selon les exigences définies dans le cadre de l'application, il ne doit pas être autorisé à accéder à ces données.

Créer une représentation schématique de l'architecture

Créez un schéma architectural global qui décrit la composition et la structure de votre application et de ses sous-systèmes ainsi que ses caractéristiques de déploiement physique, comme dans le schéma de la figure 3.3. Selon la complexité du système, vous devrez créer d'autres schémas pour des domaines plus spécifiques, par exemple un schéma destiné à modéliser l'architecture d'un serveur d'applications de niveau intermédiaire, ou un autre pour montrer les interactions avec un système externe.

Exemple de représentation schématique de l'architecture de l'application

Figure 3.3
Exemple de représentation schématique de l'architecture de l'application

Commencez par tracer un diagramme général présentant la composition et la structure de l'application et de ses sous-systèmes ainsi que ses caractéristiques de déploiement. Complétez-le ensuite en ajoutant des détails sur les limites de confiance, l'authentification et les mécanismes d'autorisation à mesure que vous les identifiez (en général à l'étape 3, lorsque vous décomposez l'application).

Identifier les technologies

Identifiez les différentes technologies adoptées pour mettre en œuvre votre solution. Ceci vous aidera à préciser les menaces propres aux technologies plus tard dans le processus, mais aussi à déterminer les méthodes d'atténuation correctes les plus adaptées. Les technologies les plus probables sont l'ASP.NET, les services Web, les services d'entreprise, Microsoft .NET Remoting et ADO.NET. Identifiez aussi les codes non gérés appelés par votre application.

Documentez les technologies à l'aide d'un tableau semblable au tableau 3.1 ci-dessous.

Tableau 3.1 : Technologies mises en œuvre

Technologie / Plate-forme

Détails de la mise en œuvre

Microsoft SQL Server sur Microsoft Windows Advanced Server 2000

Inclut des connexions, des utilisateurs de base de données, des rôles de base de données définis par les utilisateurs, des tables, des procédures stockées, des vues, des contraintes et des déclencheurs.

Microsoft .NET Framework

Utilisé pour l'authentification des formulaires.

Secure Sockets Layer (SSL)

Utilisé pour crypter le trafic HTTP.

Étape 3 : Décomposition de l'application

Dans cette étape, vous décomposez l'application afin de créer un profil de sécurité basé sur les domaines traditionnels de vulnérabilité. Vous identifiez aussi des limites de confiance, des flux de données, des points d'entrée et le code privilégié. Plus vous connaîtrez les mécanismes de fonctionnement de votre application, plus facilement vous découvrirez les menaces. La figure 3.4 montre les diverses cibles du processus de décomposition.

Cibles du processus de décomposition de l'application

Figure 3.4
Cibles du processus de décomposition de l'application

Durant cette étape, vous allez effectuer les opérations suivantes :

  • Identifier les limites de confiance

  • Identifier les flux de données

  • Identifier les points d'entrée

  • Identifier le code privilégié

  • Documenter le profil de sécurité

Identifier les limites de confiance

Identifiez les limites de confiance qui entourent les ressources tangibles de votre application. Ces ressources sont fonction de votre conception. Pour chaque sous-système, examinez si les flux de données ou les entrées des utilisateurs en amont sont fiables et, si ce n'est pas le cas, étudiez le moyen de les authentifier et de les autoriser. Déterminez également si le code appelant est sûr et, dans le cas contraire, déterminez comment l'authentifier et l'autoriser lui aussi. Vous devez pouvoir garantir que les opérateurs de contrôle appropriés protègent tous les points d'entrée dans un périmètre de confiance particulier et que le point d'entrée du destinataire valide totalement toutes les données qui traversent une limite de confiance.

Commencez par analyser les limites de confiance du point de vue du code. L'assembly, qui représente une forme de limite de confiance, est l'idéal comme point de départ. Quels sont les assemblys qui font confiance aux autres ? Est-ce qu'un assembly spécifique fait confiance au code qui l'appelle ou est-ce qu'il utilise un dispositif de sécurité d'accès au code pour autoriser le code appelant ?

Examinez aussi les relations de confiance du serveur. Est-ce qu'un serveur fait confiance à un serveur en amont pour authentifier et autoriser les utilisateurs finals ou est-ce qu'il fournit ses propres services de contrôle ? Par ailleurs, un serveur fait-il confiance à un serveur en amont pour transmettre des données qui sont bien conformées et correctes ?

Par exemple, dans la figure 3.3, l'application Web accède au serveur de base de données en utilisant une identité fixe et sécurisée qui, dans ce cas, est le compte de processus de l'application Web ASPNET. Dans ce scénario, le serveur de base de données fait confiance à l'application pour authentifier et autoriser les appelants et ne transfère que des requêtes de données valides au nom des utilisateurs autorisés.

Remarque : dans une application .NET Framework, l'assembly définit la plus petite unité de confiance. Chaque fois que des données sont envoyées au-delà d'une limite d'assembly, ce qui par définition inclut un domaine d'application, un processus ou le périmètre d'une machine, le point d'entrée du destinataire doit valider ses entrées.

Identifier les flux de données

Le plus simple consiste à commencer au niveau supérieur, puis à décomposer systématiquement l'application en analysant les flux de données qui circulent entre les systèmes individuels. Par exemple, analysez le flux des données entre une application Web et une application Enterprise Services puis entre des composants de service individuels.

Le passage de données au travers les limites de confiance est particulièrement important du fait que le code qui reçoit des données provenant d'un point situé hors de sa propre limite doit supposer qu'elles sont malveillantes et procéder par conséquent à une validation minutieuse.

Remarque : les diagrammes de flux de données (DFD) et les diagrammes de séquence peuvent aider à la décomposition formelle d'un système. Un DFD est une représentation graphique des flux de données, des magasins de données et des relations entre les sources et les destinations de données. Un diagramme de séquence montre comment un groupe d'objets collabore en termes d'événements chronologiques.

Identifier les points d'entrée

Les points d'entrée de votre application peuvent aussi servir à des attaques. Il s'agit par exemple de l'application Web frontale à l'écoute des requêtes HTTP. Ce point d'entrée est volontairement exposé aux clients. D'autres, tels que des points d'entrée internes exposés par des sous-composants dans les couches de votre application, peuvent n'exister que pour gérer des communications internes avec d'autres composants. Cependant, vous devez savoir où ils sont et quels types d'entrée ils reçoivent dans le cas où un pirate réussirait à contourner l'accès frontal à l'application et attaquerait directement un point d'entrée interne.

Pour chaque point d'entrée, vous devez pouvoir déterminer les types d'opérateurs de contrôle qui fournissent l'autorisation et le degré de validation.

Les points d'entrée logiques de l'application incluent les interfaces utilisateur fournies par les pages Web, les interfaces de service fournies par des services Web, les composants de service et les composants .NET Remoting ainsi que les files d'attente de messages qui offrent des points d'entrée asynchrones. Les points d'entrée physiques ou de la plate-forme sont les ports et les sockets.

Identifier le code privilégié

Le code privilégié accède à des types de ressources sécurisées spécifiques et effectue d'autres opérations sur la base de privilèges. Les ressources sécurisées sont notamment des serveurs DNS, des services de répertoire, des variables d'environnement, des journaux d'événements, des systèmes de fichiers, des files d'attente de messages, des compteurs de performances, des imprimantes, le registre, des sockets et des services Web. Les opérations sécurisées incluent des appels à du code non géré, la réflexion, la sérialisation, les autorisations de sécurité d'accès au code et la manipulation de la stratégie de sécurité d'accès au code, y compris les preuves.

Le code privilégié doit bénéficier d'autorisations appropriées définies par la stratégie de sécurité pour accéder au code. Il doit garantir que les ressources et les opérations qu'il encapsule ne sont pas exposées à du code non fiable et potentiellement malveillant. La sécurité d'accès au code de .NET Framework vérifie les autorisations accordées au code appelant en exécutant des remontées de pile. Cependant, il est parfois nécessaire de remplacer cette procédure et de court-circuiter la remontée de la pile, par exemple si vous voulez restreindre le code privilégié avec un sandbox (littéralement, un « bac à sable ») ou avec un code privilégié isolé d'une autre manière. Or, ce faisant, vous soumettez votre code à un risque d'attaques par leurre, dans lesquelles un code hostile appelle le vôtre via un code intermédiaire sûr.

Aussi, si vous devez momentanément désactiver la procédure de sécurité par défaut en place, soyez prudent et utilisez les protections appropriées. Pour plus d'informations sur la recherche de faille de sécurité dans le code, reportez-vous au module 21, « Examen du code ». Pour plus d'informations sur la sécurité d'accès au code, reportez-vous aux modules 8, « La sécurité d'accès au code en pratique » et 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Documenter le profil de sécurité

Vous devez ensuite identifier les méthodes de conception et de mise en œuvre utilisées pour la validation des entrées, l'authentification, l'autorisation, la gestion des configurations et les autres domaines dans lesquels les applications restent vulnérables. Vous créez ainsi un profil de sécurité de l'application.

Le tableau suivant montre le type de questions qu'il convient de se poser pour analyser les nombreux aspects de la conception et de la mise en œuvre d'une application. Pour plus d'informations sur l'architecture et la conception des applications, reportez-vous au module 5, « Examen de la sécurité de l'architecture et de la conception ».

Tableau 3.2 : Création d'un profil de sécurité

Catégorie

Considérations

Validation des entrées

Toutes les données d'entrée sont-elles validées ?
Un pirate pourrait-il injecter des commandes ou des données malveillantes dans l'application ?
Les données sont-elles validées lorsqu'elles traversent des limites de confiance distinctes (par le biais du point d'entrée du destinataire) ?
Les données contenues dans la base peuvent-elles être sécurisées ?

Authentification

Les informations d'identification sont-elles sécurisées lorsqu'elles sont acheminées sur le réseau ?
Des stratégies de compte sûres sont-elles appliquées ?
Des mots de passe fiables sont-ils utilisés ?
Utilisez-vous des certificats ?
Utilisez-vous des vérificateurs de mot de passe (avec des hachages unidirectionnels) pour les mots de passe des utilisateurs ?

Autorisation

Quels opérateurs de contrôle utilisez-vous aux points d'entrée de l'application ?
Comment l'autorisation est-elle mise en œuvre au niveau de la base de données ?
Existe-t-il une stratégie de défense avancée ?
Prévoyez-vous une gestion d'échec sécurisée et autorisez-vous uniquement l'accès en cas de confirmation des données d'identification ?

Gestion de la configuration

Quelles interfaces d'administration l'application prend-elle en charge ?
Comment sont-elles sécurisées ?
Comment l'administration à distance est-elle sécurisée ?
Sous quelles formes stockez-vous les configurations et comment sont-elles sécurisées ?

Données sensibles

Quelles sont les données sensibles traitées par l'application ?
Comment sont-elles sécurisées sur le réseau et dans les lieux de stockage persistants ?
Quel type de cryptage utilisez-vous et comment les clés de cryptage sont-elles sécurisées ?

Gestion des sessions

Comment les cookies de session sont-ils générés ?
Comment sont-ils sécurisés pour empêcher le piratage de session ?
Comment l'état de session persistant est-il sécurisé ?
Quel est le type de sécurisation appliqué à l'état de session lorsque celui-ci transite sur le réseau ?
Comment s'effectue l'authentification de l'application avec la session stockée ?
Les informations d'identification transmises sur le réseau sont-elles gérées par l'application ?
Dans ce cas, comment sont-elles sécurisées ?

Cryptographie

Quels sont les algorithmes et les mécanismes cryptographiques employés ?
Quelle est la longueur des clés de cryptage et comment sont-elles sécurisées ?
L'application met-elle en œuvre son propre cryptage ?
À quelle fréquence les clés sont-elles recyclées ?

Manipulation des paramètres

L'application détecte-t-elle des paramètres falsifiés ?
Valide-t-elle tous les paramètres des champs de formulaire, l'état d'affichage, les données de cookie et les en-têtes HTTP ?

Gestion des exceptions

Comment l'application traite-t-elle les conditions d'erreur ?
Le renvoi des exceptions au client est-il autorisé ?
Utilisez-vous des messages d'erreur génériques qui ne contiennent pas d'informations exploitables ?

Audit et journalisation

Votre application procède-t-elle à un audit à tous les niveaux de tous les serveurs ?
Comment les fichiers journaux sont-ils sécurisés ?

Étape 4 : Identification des menaces

Cette étape consiste à identifier les menaces susceptibles d'affecter votre système et de compromettre vos ressources. Pour la mener à bien, réunissez des membres des équipes de développement et de test afin de procéder à un brainstorming informel. C'est là un moyen simple mais efficace de mettre en évidence les menaces possibles. Dans l'idéal, l'équipe doit comprendre des architectes d'application, des spécialistes de la sécurité, des développeurs, des vérificateurs et des administrateurs système.

Deux approches sont possibles :

  • Utiliser la méthode STRIDE pour identifier les menaces. Examinez les grandes catégories de menaces, comme l'usurpation d'identité, la falsification et le refus de service et adoptez le modèle STRIDE décrit dans le module 2, « Mesures et contre-mesures » afin de vous interroger sur les aspects architecturaux et conceptuels de votre application. Cette méthode s'appuie sur l'examen des objectifs d'un pirate. Par exemple, un pirate pourrait-il usurper une identité et accéder de la sorte à votre serveur ou à votre application Web ? Un utilisateur pourrait-il falsifier des données sur le réseau dans un lieu de stockage ? Pourriez-vous être confronté à un refus de service ?

  • Utiliser des listes de menace classifiées. Avec cette approche, vous commencez par établir une liste exhaustive des menaces courantes en les regroupant par catégorie réseau, hôte et application. Appliquez ensuite cette liste à l'architecture de votre application et aux vulnérabilités que vous avez préalablement identifiées. Vous pourrez alors écarter immédiatement certaines menaces qui ne correspondent pas à votre scénario.

Utilisez les ressources suivantes pour vous aider à identifier les menaces :

  • Pour obtenir une liste des menaces classées en fonction des couches réseau, hôte et application, ainsi que des explications sur les menaces et les contre-mesures associées, reportez-vous au module 2, « Mesures et contre-mesures ».

  • Pour obtenir une liste des menaces par technologie, reportez-vous à la section « Menaces et contre-mesures » au début de chaque module « Création » dans la partie III de ce guide.

Durant cette étape, vous allez effectuer les opérations suivantes :

  • Identifier les menaces au niveau du réseau

  • Identifier les menaces au niveau de l'hôte

  • Identifier les menaces au niveau de l'application

Identifier les menaces au niveau du réseau

Cette tâche est le travail des concepteurs et des administrateurs de réseau. Analysez la topologie du réseau et le flux des paquets de données, ainsi que les configurations des routeurs, des pare-feu et des commutateurs, et recherchez les vulnérabilités potentielles. Soyez vigilants également sur les points terminaux des VPN (réseau privé virtuel). Examinez les défenses du réseau par rapport aux menaces les plus courantes qui pèsent sur lui et qui ont été identifiées dans le module 2, « Menaces et contre-mesures ».

Les principales menaces relatives au réseau qu'il convient d'examiner durant la phase de conception sont les suivantes :

  • Utilisation de mécanismes de sécurité qui s'appuient sur l'adresse IP de l'émetteur. Il est relativement facile d'envoyer des paquets IP avec de fausses adresses IP d'origine (usurpation d'adresses IP).

  • Transmission d'identificateurs de session ou de cookies sur des canaux réseau non cryptés, ce qui peut provoquer un piratage de session.

  • Transmission d'informations d'authentification en clair ou d'autres données sensibles sur des canaux de communication non cryptés. Ceci peut permettre à un pirate de surveiller le réseau, d'obtenir les informations d'identification ou de récupérer et éventuellement de falsifier d'autres éléments de données sensibles.

Vous devez également vous assurer que le réseau n'est pas vulnérable aux menaces dues à une configuration mal sécurisée du serveur ou d'un périphérique. Par exemple, les ports et les protocoles non indispensables sont-ils fermés et désactivés ? Les tables de routage et le serveur DNS sont-ils sécurisés ? Les piles réseau TCP sont-elles renforcées sur vos serveurs ? Pour plus d'informations sur la manière de lutter contre ce type de vulnérabilités, reportez-vous au module 15, « Sécurisation de votre réseau ».

Identifier les menaces au niveau de l'hôte

L'approche choisie dans ce guide pour définir la sécurité de l'hôte (c'est-à-dire, la configuration Microsoft Windows 2000 et .NET Framework) consiste à diviser la configuration en deux catégories afin de permettre l'application de paramètres sécurisés selon un mode structuré et logique. Elle est par ailleurs totalement adaptée aux processus d'examen de la sécurité, à la détection des points faibles et à l'identification des menaces. Les catégories courantes de configuration applicables à tous les rôles serveur concernent les correctifs et les mises à jour, les services, les protocoles, les comptes, les fichiers et répertoires, les partages, les ports ainsi que l'audit et la journalisation. Pour chaque catégorie, identifiez les paramètres de configuration présentant un risque de vulnérabilité. À partir de là, identifiez les menaces.

Les principales vulnérabilités à prendre en considération sont les suivantes :

  • Présence de serveurs dépourvus de correctifs, que des virus, des chevaux de Troie, des vers et bien d'autres attaques IIS connues peuvent exploiter.

  • Utilisation de ports, de protocoles et de services peu essentiels, qui augmentent le risque lié au profil d'attaque et permettent aux pirates de rassembler des informations sur votre environnement et de les exploiter.

  • Autorisation d'un accès anonyme non authentifié.

  • Utilisation de mots de passe et de stratégies de compte peu fiables qui entraînent le piratage des mots de passe, l'usurpation d'identité et le refus de service, s'il s'avère possible de verrouiller délibérément des comptes.

Identifier les menaces au niveau de l'application

Dans les étapes précédentes, vous avez défini l'architecture, le flux des données et les limites de confiance de votre application. Vous avez également créé un profil de sécurité décrivant la manière dont l'application gère les domaines de base, tels que l'authentification, l'autorisation, la gestion des configurations, etc.

À présent, vous allez utiliser les catégories de menaces STRIDE et les listes prédéfinies afin d'examiner chaque aspect du profil de sécurité de votre application. Concentrez-vous sur les menaces concernant l'application, les technologies employées et le code. Les vulnérabilités essentielles à prendre en considération sont les suivantes :

  • Utilisation d'une validation des entrées insuffisante qui autorise les attaques par script inter-site, par injection SQL et par dépassement de capacité de la mémoire tampon.

  • Transmission d'informations ou de cookies d'authentification sur des liaisons réseau non cryptées, ce qui peut entraîner la récupération des données d'identification ou le piratage de session.

  • Utilisation de mots de passe et de stratégies de compte insuffisantes, qui peut entraîner un accès non autorisé aux données.

  • Impossibilité de sécuriser les aspects liés à la gestion de configuration de votre application, y compris les interfaces d'administration.

  • Enregistrement de données secrètes de configuration, comme les chaînes de connexion et les informations d'identification des comptes de service, en texte clair.

  • Utilisation de comptes de service et de processus sur-privilégiés.

  • Utilisation de techniques de codage peu sûres pour l'accès aux données, ce qui peut accroître la menace liée à l'injection SQL.

  • Utilisation d'un cryptage peu sûr ou personnalisé et absence de sécurisation correcte des clés de cryptage.

  • Confiance dans l'intégrité des paramètres transmis par le navigateur Web, par exemple les champs de formulaire, les chaînes de requête, les données de cookie et les en-têtes HTTP.

  • Utilisation d'une mauvaise gestion des exceptions qui peut mener à un refus de service ou à la divulgation d'informations système qui seront utiles à un éventuel pirate.

  • Audit et journalisation inadaptés, susceptibles d'entraîner des menaces de répudiation.

Utilisation d'arborescences et de modèles d'attaques

Les arborescences et les modèles d'attaques sont les principaux outils utilisés par les spécialistes de la sécurité. Ce ne sont pas des composants primordiaux pour la phase d'identification de la menace, mais ils peuvent s'avérer utiles. Ils permettent d'analyser les menaces en profondeur, en allant au-delà de ce que vous savez déjà.

Remarque importante : lorsque vous utilisez des listes classées déjà établies de menaces connues, celles-ci ne contiennent que les menaces les plus courantes. D'autres approches, comme l'utilisation d'arborescences et de modèles d'attaques, peuvent vous aider à identifier des menaces supplémentaires.

Une structure d'attaque est un moyen de réunir et de documenter les attaques potentielles contre votre système selon un mode structuré et hiérarchique. L'arborescence fournit une décomposition descriptive des différentes attaques que le pirate utilise pour compromettre le système. En créant des arborescences d'attaques, vous générez une représentation réutilisable des problèmes de sécurité qui vous aidera à mieux orienter vos efforts. Votre équipe de vérificateurs peut créer des plans de tests visant à valider la conception de la sécurité. Les développeurs peuvent décider quels compromis ils adopteront pendant la mise en œuvre, et les architectes ou les responsables du développement évaluer en termes de sécurité le coût d'approches alternatives.

Les modèles d'attaques sont une méthode formalisée pour capturer des informations de piratage dans votre entreprise. Ces modèles vous aideront à identifier les techniques d'attaque courantes.

Création d'arborescences d'attaque

Concrètement, plusieurs approches sont possibles ; toutefois, la méthode généralisée consiste à identifier les objectifs et sous-objectifs d'une attaque et ce qu'il est possible d'entreprendre pour que cette attaque réussisse. Vous pouvez utiliser un schéma hiérarchique pour représenter cette arborescence, ou un simple plan. Le plus important est d'avoir un portrait du profil d'attaque qui menace votre application. Vous pouvez ensuite évaluer les risques de sécurité probables, ce qui permet de les atténuer à l'aide de contre-mesures adaptées, comme la modification d'une conception, le renforcement des paramètres de configuration ou autres.

Commencez par générer une arborescence d'attaque en créant des nœuds racine représentant les objectifs du pirate. Ajoutez ensuite des nœuds de feuille, qui sont des méthodes de piratage correspondant à des attaques uniques. La figure 3.5 illustre un exemple simple.

Représentation d'une arborescence d'attaque

Figure 3.5
Représentation d'une arborescence d'attaque

Vous pouvez intituler les nœuds de feuille à l'aide d'étiquettes AND et OR. Ainsi, dans la figure 3.5, les points 1.1 et 1.2 doivent se produire pour que la menace débouche sur une attaque.

Les arborescences d'attaque comme celle qui précède deviennent vite complexes. Elles sont également longues à créer. Une autre solution souvent privilégiée par certaines équipes consiste à structurer l'arborescence d'attaque en utilisant un plan comme celui ci-dessous.

1.  Objectif Un
    1.1 Sous-objectif un
    1.2 Sous-objectif deux
2.  Objectif Deux
    2.1 Sous-objectif un
    2.2 Sous-objectif deux

Remarque : outre les objectifs et les sous-objectifs, les arborescences d'attaque incluent des méthodologies et des conditions requises.

Voici un exemple de plan :

Menace N°1. Le pirate obtient les informations d'identification en surveillant le réseau.
  1.1. Effacement du texte des informations d'identification envoyées sur le réseau ET
  1.2 Le pirate utilise des outils de surveillance du réseau
      1.2.1. Le pirate reconnaît les données d'autorisation

Pour consulter un exemple complet, reportez-vous à « Exemples d'arborescences d'attaque » dans la section « Fiches pour tricher » de ce guide.

Modèles d'attaque

Les modèles d'attaque sont des représentations génériques d'attaques fréquentes qui peuvent se produire dans de multiples contextes. Le modèle définit l'objectif de l'attaque ainsi que les conditions qui doivent exister pour que l'attaque ait lieu, les étapes requises pour le déroulement de l'attaque et les résultats de celle-ci. Les modèles d'attaque s'attachent aux techniques de piratage, alors que la méthode STRIDE s'appuie sur les objectifs du pirate.

Un modèle d'attaque par injection de code permettant de décrire les attaques de ce type selon un mode générique en est un exemple représentatif.

Tableau 3.3 : Modèle d'attaque par injection de code

Modèle

Attaques par injection de code

Objectifs de l'attaque

Exécution de la commande ou du code

Conditions requises

Validation d'entrées insuffisante
Le code du pirate a des privilèges suffisants sur le serveur.

Technique d'attaque

1. Identifier le programme sur le système cible qui présente une vulnérabilité au niveau de la validation des entrées.
2. Créer un code à injecter et exécuter à l'aide du contexte de sécurité de l'application cible.
3. Construire une valeur d'entrée pour insérer le code dans l'espace d'adresse de l'application cible et endommager la pile afin que l'exécution de l'application passe directement au code injecté.

Résultats de l'attaque

Le code du pirate s'exécute et accomplit son activité malveillante.

Pour plus d'informations sur les modèles d'attaque, reportez-vous à la section « Informations complémentaires » située à la fin de ce module.

Étape 5 : Documentation des menaces

Pour documenter les menaces de votre application, utilisez un modèle qui montre plusieurs attributs de menace similaire à celui ci-dessous. La description de la menace et sa cible sont des attributs essentiels. À ce stade, n'indiquez pas d'évaluation du risque. Cette valeur est utilisée à la fin de la modélisation de la menace, lorsque vous dressez la liste des menaces identifiées. D'autres attributs que vous pouvez inclure sont les techniques d'attaque, qui peuvent également mettre en évidence les vulnérabilités exploitées, ainsi que les contre-mesures nécessaires pour contrer la menace.

Tableau 3.4 : Menace 1

Description de la menace

Le pirate obtient les informations d'identification en surveillant le réseau.

Cible de la menace

Authentification utilisateur de l'application Web

Risque

 

Techniques d'attaque

Utilisation d'un logiciel de surveillance du réseau

Contre-mesures

Utilisation du protocole SSL pour sécuriser le canal de communication

Tableau 3.5 : Menace 2

Description de la menace

Injection de commandes SQL

Cible de la menace

Composant d'accès aux données

Risque

 

Techniques d'attaque

Le pirate ajoute des commandes SQL au nom d'utilisateur, qui est utilisé pour constituer une requête SQL.

Contre-mesures

Utilisation d'une expression régulière pour valider le nom d'utilisateur et d'une procédure stockée qui emploie des paramètres pour accéder à la base de données.

Étape 6 : Évaluation des menaces

À ce stade du processus, vous disposez d'une liste des menaces qui s'appliquent à votre scénario applicatif spécifique. Dans la dernière phase du processus, vous allez évaluer les menaces en fonction du risque qu'elles présentent. Ceci vous permet de gérer les menaces qui présentent le plus grand risque, puis de résoudre les autres. En fait, il n'est pas toujours économiquement viable de traiter toutes les menaces identifiées et vous pouvez en ignorer certaines du fait que le changement et les éventuels dommages qu'elles entraînent sont minimes.

Risque = Probabilité * Dommages potentiels

Cette formule indique que le risque posé par une menace particulière est égal à la probabilité de la menace multipliée par les dommages potentiels, ce qui indique les conséquences pour votre système en cas d'attaque.

Vous pouvez utiliser une échelle de 1 à 10 pour noter la probabilité, 1 représentant une menace très improbable et 10 une menace quasiment certaine. De même, adoptez une échelle de 1 à 10 pour les dommages potentiels, 1 indiquant les dommages minimums et 10 la catastrophe. Si l'on suit cette approche, le risque posé par une menace peu probable mais associée à des dommages potentiels élevés est égal au risque posé par une menace sans grands dommages mais qui a toutes les chances de se produire.

Par exemple, si la Probabilité= 10 et les Dommages potentiels= 1, le Risque = 10 * 1 = 10. Si la Probabilité= 1 et si les Dommages potentiels= 10, le Risque = 1 * 10 = 10.

Cette approche donne lieu à une échelle de 1 à 100, que vous pouvez diviser en trois bandes afin de définir les degrés de risque Élevé, Moyen et Faible.

Degrés de risque : élevé, moyen et faible

Vous pouvez utiliser une simple échelle basée sur les niveaux Élevé, Moyen ou Faible pour classer les menaces. Si la menace est élevée, elle pose un risque important pour l'application et elle doit être prise en compte dès que possible. Les menaces moyennes doivent être gérées mais avec moins d'urgence. Vous pouvez ignorer les menaces faibles selon le travail et le coût qu'il faudrait engager pour les prendre en compte.

DREAD

Le problème avec un système d'évaluation simpliste est que les membres de l'équipe ne sont généralement pas d'accord sur les degrés de risque. Pour y remédier, ajoutez de nouvelles dimensions qui aident à déterminer ce que signifie réellement l'impact d'une menace contre la sécurité. Microsoft a élaboré le modèle DREAD pour faciliter le calcul du risque. Avec ce modèle, vous évaluez le risque associé à une menace en posant les questions suivantes :

  • Dommages potentiels : Quelle est l'importance des dommages si la vulnérabilité est exploitée ?

  • Reproductibilité : Dans quelle mesure l'attaque est-elle facile à reproduire ?

  • Exploitabilité : Dans quelle mesure l'attaque est-elle facile à déclencher ?

  • Action sur les utilisateurs : En pourcentage approximatif, dans quelle mesure les utilisateurs sont-ils affectés ?

  • Détectabilité : Dans quelle mesure est-il facile de détecter la vulnérabilité ?

Vous pouvez appliquer à chaque menace les éléments ci-dessous. Vous pouvez également étendre les questions en fonction de vos besoins. Ainsi, vous pouvez ajouter une question sur les dommages potentiels en termes de réputation :

Réputation : Quel est l'enjeu ? Existe-t-il un risque pour votre réputation, susceptible d'entraîner une perte de confiance chez vos clients ?

Il ne sert à rien d'utiliser une large échelle d'évaluation car celle-ci ne fait que compliquer l'évaluation des menaces les unes par rapport aux autres. Il suffit de choisir un schéma aussi simple que Élevé (1), Moyen (2) et Faible (3).

En définissant clairement ce que chaque valeur représente dans votre système d'évaluation, vous évitez les confusions. Le tableau 3.6 montre un exemple type de schéma d'évaluation utilisable par les membres d'une équipe pour classer les menaces par ordre de priorité.

Tableau 3.6 : Schéma d'évaluation des menaces

Niveau

Élevé (3)

Moyen (2)

Faible (1)

D

Dommages potentiels

Le pirate peut compromettre le système de sécurité, obtenir les autorisations de confiance complètes, agir comme administrateur, télécharger du contenu.

Fuite d'informations sensibles

Fuite d'informations peu importantes

R

Reproductibilité

L'attaque est chaque fois reproductible et n'exige aucun délai particulier.

L'attaque peut être reproduite, mais seulement dans une fenêtre de temps et des conditions particulières.

L'attaque est très difficile à reproduire, même si le pirate connaît la faille au niveau sécurité.

E

Exploitabilité

Un programmeur novice pourrait mener une attaque en un temps très court.

Un programmeur expérimenté pourrait mener une attaque puis répéter les étapes.

L'exécution de l'attaque nécessite à chaque fois une personne très expérimentée et disposant de connaissances approfondies.

A

Actions sur les utilisateurs

Affecte tous les utilisateurs, la configuration par défaut, les principaux clients

Affecte certains utilisateurs, une configuration personnalisée

Affecte un très petit pourcentage d'utilisateurs, des fonctionnalités obscures ; des utilisateurs anonymes

D

Détectabilité

Les informations publiées expliquent l'attaque. La vulnérabilité se trouve dans la fonctionnalité la plus couramment employée et elle est évidente.

La vulnérabilité se trouve dans une partie rarement utilisée du produit dont seuls se servent quelques utilisateurs. Il faut un certain temps et de la réflexion pour découvrir une utilisation malveillante possible.

Le bogue est peu évident et il est improbable que des utilisateurs envisagent des dommages potentiels.

Après vous être posé les questions suivantes, comptez les valeurs (1 à 3) pour une menace donnée. Le résultat peut tomber dans la plage de 5 à 15. Dès lors, vous pouvez traiter les menaces qui présentent un « score » global de 12 à 15 comme posant un risque élevé ; de 8 à 11, le risque est moyen et de 5 à 7, il est faible.

Par exemple, prenez les deux menaces décrites plus haut :

  • Le pirate obtient les informations d'identification en surveillant le réseau.

  • Des commandes SQL sont injectées dans l'application.

Le tableau 3.7 montre un exemple d'évaluation DREAD pour les deux menaces :

Tableau 3.7 : Schéma d'évaluation DREAD

Menace

D

R

E

A

D

Total

Niveau

Le pirate obtient les informations d'identification en surveillant le réseau.

3

3

2

2

2

12

Élevé

Des commandes SQL sont injectées dans l'application.

3

3

3

3

2

14

Élevé

Une fois que vous connaissez le niveau du risque, mettez à jour les menaces documentées et ajoutez le niveau découvert, qui ici est Élevé pour les deux menaces considérées. Le tableau 3.8 propose un exemple.

Tableau 3.8 : Menace 1

Description de la menace

Le pirate obtient les informations d'identification en surveillant le réseau.

Cible de la menace

Authentification utilisateur de l'application Web

Niveau du risque

Élevé

Techniques d'attaque

Utilisation d'un logiciel de surveillance du réseau

Contre-mesures

Utilisation du protocole SSL pour sécuriser le canal de communication

Que faire après avoir modélisé la menace ?

La modélisation de la menace permet d'établir une documentation sur les aspects de sécurité de l'architecture de votre application et une liste des menaces classées par niveau de risque. Le modèle de menace vous aide à orienter l'équipe de développeurs et à vous concentrer sur les menaces les plus graves.

Important : La modélisation de la menace est un processus interactif. Le modèle de menace établi est un document qui évolue et à partir duquel les membres des différentes équipes peuvent travailler.

Le modèle de menace est utilisable par les groupes de personnes suivants :

  • les concepteurs, pour effectuer des choix de conception sécurisée concernant les technologies et les fonctionnalités ;

  • les développeurs qui rédigent le code, pour atténuer les risques ;

  • les vérificateurs qui écrivent des cas de test pour contrôler si l'application est vulnérable aux menaces identifiées lors de l'analyse.

Génération d'un rapport des tâches

À partir du modèle de menace initial, vous pouvez créer un rapport des tâches plus formel qui inclut des attributs supplémentaires, tels qu'un ID de bogue, utilisable pour suivre la menace avec votre système de suivi des bogues. En fait, vous pouvez entrer les menaces identifiées dans votre système de suivi et créer un rapport à partir de votre système. Vous pouvez aussi incorporer une colonne État qui indique si le bogue a été résolu ou non. Veillez à ce que le rapport contienne le numéro de la menace d'origine pour la relier au document du modèle de menace.

Dans le rapport, organisez les menaces par catégories : réseau, hôte et application. Ainsi, les membres des différentes équipes auront plus de facilité à l'utiliser en fonction de leur rôle. Dans chaque catégorie, présentez les menaces par ordre de priorité, en allant du risque le plus élevé au risque le plus faible.

Résumé

Vous pouvez atténuer le risque d'une attaque, mais vous ne pouvez pas atténuer ni éliminer la menace réelle. Il existe toujours des menaces, quelles que soient les mesures de sécurité que vous prenez et les contre-mesures que vous appliquez. En réalité, vous devez admettre la présence des menaces et gérer les risques. En ce sens, la modélisation de la menace peut vous aider à prendre ces risques en compte et en faire part aux différentes équipes.

Considérez la modélisation de la menace comme un processus itératif. Votre modèle doit être un document dynamique qui évolue avec le temps afin de tenir compte des nouveaux types de menaces et d'attaques qui apparaissent. Il doit également s'adapter pour suivre l'évolution naturelle de votre application à mesure que vous l'améliorez et que vous la modifiez selon les nouveaux besoins commerciaux.

Informations complémentaires

Pour plus d'informations, reportez-vous aux ressources suivantes :

  • Pour plus d'informations sur les modèles d'attaques, reportez-vous à l'ouvrage « Attack Modeling for Information Security and Survivability » de Andrew P. Moore, Robert J. Ellison et Richard C. Linger, consultable à l'adresse http://www.cert.org/archive/pdf/01tn001.pdf.

  • Pour plus d'informations sur l'évaluation des menaces, des ressources et des vulnérabilités, reportez-vous à « Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0 » sur le site Web de Carnegie Mellon Software Engineering Institute, à l'adresse http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html.

  • Pour une découverte du processus de modélisation de la menace, reportez-vous à « Architect WebCast: Using Threat Models to Design Secure Solutions » à l'adresse http://www.microsoft.com/usa/webcasts/ondemand/1617.asp.

  • Pour plus d'informations sur la création de diagrammes DFD, reportez-vous à l'ouvrage Writing Secure Code, Second Edition, de Michael Howard, David C. LeBlanc.

Afficher:
© 2014 Microsoft