Modélisation des menaces pour les pilotes
Les rédacteurs de pilotes et les architectes doivent faire de la modélisation des menaces une partie intégrante du processus de conception pour n’importe quel pilote. Cette rubrique fournit des instructions pour la création de modèles de menace pour les pilotes Windows.
La sécurité doit être un point de conception fondamental pour tout pilote. Tout produit réussi est une cible. Si vous écrivez un pilote pour Windows, vous devez supposer que quelque part, quelqu’un essaiera d’utiliser votre pilote pour compromettre la sécurité du système.
La conception d’un pilote sécurisé implique :
- Identification des points auxquels le conducteur pourrait être vulnérable à une attaque.
- Analyse des types d’attaques pouvant être montés à chaque point de ce type.
- S’assurer que le pilote est conçu de manière à contrecarrer ces attaques.
La modélisation des menaces est une approche structurée de ces tâches de conception importantes. Un modèle de menace est un moyen de catégoriser et d’analyser les menaces pesant sur une ressource. Du point de vue d’un enregistreur de pilotes, les ressources sont le matériel, les logiciels et les données sur l’ordinateur ou le réseau.
Un modèle de menace répond aux questions suivantes :
- Quelles ressources ont besoin d’une protection ?
- À quelles menaces les ressources sont-elles vulnérables ?
- Quelle est l’importance ou la probabilité de chaque menace ?
- Comment pouvez-vous atténuer les menaces ?
La modélisation des menaces est une partie importante de la conception logicielle, car elle garantit que la sécurité est intégrée au produit, plutôt qu’traitée comme une idée après coup. Un bon modèle de menace peut aider à rechercher et à prévenir les bogues pendant le processus de conception, éliminant ainsi les correctifs potentiellement coûteux par la suite et les éventuels dommages à la réputation de votre organization.
Cette section applique les principes de modélisation des menaces à la conception du pilote et fournit des exemples de menaces auxquelles un pilote peut être sensible. Pour obtenir une description plus complète de la modélisation des menaces pour la conception de logiciels, reportez-vous à ces ressources.
Le site web Microsoft SDL :
Implémentation simplifiée de Microsoft SDL :
Cette entrée de blog explique comment télécharger une copie gratuite de The Security Development Lifecycle : SDL, par Michael Howard et Steve Lipner :
Créer des modèles de menace pour les pilotes
La création d’un modèle de menace nécessite une compréhension approfondie de la conception du pilote, des types de menaces auxquels le pilote peut être exposé et des conséquences d’une attaque de sécurité qui exploite une menace particulière. Après avoir créé le modèle de menace pour un pilote, vous pouvez déterminer comment atténuer les menaces potentielles.
La modélisation des menaces est plus efficace lorsqu’elle est effectuée de manière organisée et structurée pendant la conception du pilote, plutôt que de manière aléatoire pendant le codage. Une approche structurée augmente la probabilité que vous découvriez des vulnérabilités dans la conception, ce qui vous permet de garantir que le modèle est complet.
Pour organiser un effort de modélisation des menaces, procédez comme suit :
- Créez un diagramme structuré montrant le flux de données via le pilote. Incluez toutes les tâches possibles effectuées par le pilote, ainsi que la source et la destination de toutes les entrées et sorties du pilote. Un diagramme de flux de données formel, ou un diagramme structuré similaire, peut vous aider à analyser le chemin des données via votre pilote et à identifier les interfaces externes, les limites et les interactions du pilote.
- Analysez les menaces de sécurité potentielles, en fonction du diagramme de flux de données.
- Évaluez les menaces que vous avez identifiées à l’étape précédente et déterminez comment les atténuer.
Créer un diagramme de flux de données
Un diagramme de flux de données montre sous forme conceptuelle le flux de données entre le pilote et les entités externes avec lesquelles il interagit ( généralement le système d’exploitation, un processus utilisateur et l’appareil). Un diagramme de flux de données formel utilise les symboles suivants :
La figure suivante montre un exemple de diagramme de flux de données pour un pilote wdM (Windows Driver Model) hypothétique en mode noyau. Quelle que soit l’architecture de votre type particulier de pilote, le modèle conceptuel est le même : afficher tous les chemins de données et identifier chaque source de données qui entre ou quitte le pilote.
Note La figure précédente montre les données qui circulent directement entre un processus utilisateur et le pilote, et omet tous les pilotes intermédiaires. Toutefois, en réalité, toutes les demandes passent par le gestionnaire d’E/S et peuvent traverser un ou plusieurs pilotes de niveau supérieur avant d’atteindre un pilote particulier. La figure omet ces étapes intermédiaires pour souligner l’importance de la source d’origine des données et du contexte du thread qui a fourni les données. Les pilotes en mode noyau doivent valider les données qui proviennent du mode utilisateur.
Les informations entrent dans le pilote en raison des demandes du système d’exploitation, des demandes d’un processus utilisateur ou des demandes (généralement des interruptions) de l’appareil.
Le pilote de la figure précédente reçoit des données du système d’exploitation dans plusieurs types de requêtes :
- Demandes d’exécution de tâches d’administration pour le pilote et son périphérique, par le biais d’appels aux routines DriverEntry, DriverUnload et AddDevice
- Plug-and-Play demandes (IRP_MJ_PNP)
- Demandes de gestion de l’alimentation (IRP_MJ_POWER)
- Demandes de contrôle d’E/S internes d’appareil (IRP_MJ_INTERNAL_DEVICE_CONTROL)
En réponse à ces demandes, les données circulent du pilote vers le système d’exploitation sous forme d’informations status. Le pilote dans la figure reçoit des données d’un processus utilisateur dans les types de requêtes suivants :
- Créer, lire et écrire des demandes (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
- Demandes de contrôle d’E/S d’appareil public (IRP_MJ_DEVICE_ CONTROL)
En réponse à ces demandes, les données de sortie et les informations status sont transmises du pilote au processus utilisateur.
Enfin, le pilote reçoit des données de l’appareil en raison d’opérations d’E/S de l’appareil ou d’actions de l’utilisateur (telles que l’ouverture de la barre d’état sur un lecteur DE CD) qui modifient l’status de l’appareil. De même, les données du pilote sont transmises à l’appareil pendant les opérations d’E/S et les modifications apportées au status du périphérique.
La figure précédente montre le flux de données du pilote à un niveau conceptuel large. Chaque cercle représente une tâche relativement volumineuse et manque de détails. Dans certains cas, un diagramme à un niveau tel que l’exemple est adéquat pour comprendre les sources de données et les chemins d’accès. Si votre pilote gère de nombreux types différents de demandes d’E/S provenant de différentes sources, vous devrez peut-être créer un ou plusieurs diagrammes supplémentaires qui montrent plus de détails. Par exemple, le cercle intitulé « Gérer les demandes d’E/S » peut être développé dans un diagramme distinct, semblable à la figure suivante.
Le deuxième diagramme montre des tâches distinctes pour chaque type de demande d’E/S dans le premier diagramme. (Par souci de simplicité, les chemins d’accès aux données de l’appareil ont été omis.)
Les entités externes et les types d’entrée et de sortie indiqués dans le diagramme peuvent varier en fonction du type d’appareil. Par exemple, Windows fournit des pilotes de classe pour de nombreux types d’appareils courants. Un pilote de classe fourni par le système fonctionne avec un minidriver fourni par le fournisseur, qui est généralement une bibliothèque de liens dynamiques (DLL) qui contient un ensemble de routines de rappel. Les demandes d’E/S utilisateur sont dirigées vers le pilote de classe, qui appelle ensuite les routines dans le minidriver pour effectuer des tâches spécifiques. Le minidriver ne reçoit généralement pas l’intégralité du paquet de demande d’E/S en tant qu’entrée ; au lieu de cela, chaque routine de rappel reçoit uniquement les données requises pour sa tâche spécifique.
Lorsque vous créez les diagrammes de flux de données, n’oubliez pas la variété de sources pour les demandes de pilote. Tout code exécuté sur l’ordinateur d’un utilisateur peut générer une demande d’E/S à un pilote, des applications connues telles que Microsoft Office aux téléchargements de logiciels gratuits, de shareware et web d’origine potentiellement douteuse. Selon votre appareil spécifique, vous devrez peut-être également prendre en compte les codecs multimédias ou les filtres tiers que votre entreprise fournit pour prendre en charge son appareil. Les sources de données possibles sont les suivantes :
- IRP_MJ_XXX demandes que le pilote gère
- IOCTL que le pilote définit ou gère
- API que le pilote appelle
- Routines de rappel
- Toutes les autres interfaces exposées par le pilote
- Fichiers que le pilote lit ou écrit, y compris ceux utilisés pendant l’installation
- Clés de Registre que le pilote lit ou écrit
- Pages de propriétés de configuration et toute autre information fournie par l’utilisateur que le pilote utilise
Votre modèle doit également couvrir les procédures d’installation et de mise à jour du pilote. Incluez tous les fichiers, répertoires et entrées de Registre qui sont lus ou écrits lors de l’installation du pilote. Considérez également les interfaces exposées dans les programmes d’installation d’appareils, les co-programmes d’installation et les pages de propriétés.
Tout point où le pilote échange des données avec une entité externe est potentiellement vulnérable aux attaques.
Analyser les menaces potentielles
Après avoir identifié les points auxquels un pilote peut être vulnérable, vous pouvez déterminer quels types de menaces peuvent se produire à chaque point. Considérez les types de questions suivants :
- Quels sont les mécanismes de sécurité en place pour protéger chaque ressource ?
- Toutes les transitions et toutes les interfaces sont-elles correctement sécurisées ?
- Une utilisation incorrecte d’une fonctionnalité peut-elle compromettre involontairement la sécurité ?
- L’utilisation malveillante d’une fonctionnalité peut-elle compromettre la sécurité ?
- Les paramètres par défaut fournissent-ils une sécurité adéquate ?
L’approche STRIDE de la catégorisation des menaces
L’acronyme STRIDE décrit six catégories de menaces pour les logiciels. Cet acronyme est dérivé de :
- Spoofing
- Tampérage
- Epudiation R
- Divulgation dei nformation
- Denial du service
- Elevation des privilèges
En utilisant STRIDE comme guide, vous pouvez poser des questions détaillées sur les types d’attaques qui pourraient être ciblées sur un conducteur. L’objectif est de déterminer les types d’attaques qui pourraient être possibles à chaque point vulnérable du pilote, puis de créer un scénario pour chaque attaque possible.
L’usurpation utilise les informations d’identification d’une autre personne pour accéder à des ressources autrement inaccessibles. Un processus monte une attaque d’usurpation d’identité en transmettant des informations d’identification falsifiées ou volées.
La falsification modifie les données pour monter une attaque. Par exemple, un pilote peut être susceptible d’être falsifié si les fichiers de pilotes requis ne sont pas correctement protégés par des listes de signature de pilotes et de contrôle d’accès (ACL). Dans ce cas, un utilisateur malveillant peut modifier les fichiers, violant ainsi la sécurité du système.
La répudiation se produit lorsqu’un utilisateur refuse d’effectuer une action, mais que la cible de l’action n’a aucun moyen de prouver le contraire. Un pilote peut être vulnérable à une menace de répudiation s’il ne consigne pas d’actions susceptibles de compromettre la sécurité. Par exemple, un pilote d’un appareil vidéo peut être répudié s’il ne consigne pas les demandes de modification des caractéristiques de son appareil, telles que le focus, la zone analysée, la fréquence de la capture d’image, l’emplacement cible des images capturées, etc. Les images obtenues peuvent être endommagées, mais les administrateurs système n’ont aucun moyen de déterminer l’utilisateur à l’origine du problème.
Les menaces de divulgation d’informations sont exactement comme son nom l’indique : la divulgation d’informations à un utilisateur qui n’a pas l’autorisation de les voir. Tout pilote qui transmet des informations à ou à partir d’une mémoire tampon utilisateur est sensible aux menaces de divulgation d’informations. Pour éviter les menaces de divulgation d’informations, les pilotes doivent valider la longueur de chaque mémoire tampon utilisateur et les initialiser zéro avant d’écrire des données.
Les attaques par déni de service menacent la capacité des utilisateurs valides à accéder aux ressources. Les ressources peuvent être de l’espace disque, des connexions réseau ou un appareil physique. Les attaques qui ralentissent les performances à des niveaux inacceptables sont également considérées comme des attaques par déni de service. Un pilote qui permet à un processus utilisateur de monopoliser inutilement une ressource système peut être vulnérable à une attaque par déni de service si la consommation de ressources empêche d’autres utilisateurs valides d’effectuer leurs tâches.
Par exemple, un pilote peut utiliser un sémaphore pour protéger une structure de données lors de l’exécution à IRQL = PASSIVE_LEVEL. Toutefois, le pilote doit acquérir et libérer le sémaphore au sein d’une paire KeEnterCriticalRegion/KeLeaveCriticalRegion , ce qui désactive et réactive la remise d’appels de procédure asynchrone (API). Si le pilote ne parvient pas à utiliser ces routines, un APC peut entraîner la suspension du système d’exploitation du thread qui contient le sémaphore. Par conséquent, d’autres processus (y compris ceux créés par un administrateur) ne peuvent pas accéder à la structure.
Une attaque par élévation de privilèges peut se produire si un utilisateur non privilégié obtient des status privilégiés. Un pilote en mode noyau qui passe un handle en mode utilisateur à une routine ZwXxx est vulnérable aux attaques d’élévation de privilèges, car les routines ZwXxx contournent les vérifications de sécurité. Les pilotes en mode noyau doivent valider chaque handle qu’ils reçoivent des appelants en mode utilisateur.
Les attaques par élévation de privilèges peuvent également se produire si un pilote en mode noyau s’appuie sur la valeur RequestorMode dans l’en-tête IRP pour déterminer si une demande d’E/S provient d’un appelant en mode noyau ou en mode utilisateur. Dans les IRP qui arrivent du réseau ou du service serveur (SRVSVC), la valeur de RequestorMode est KernelMode, quelle que soit l’origine de la demande. Pour éviter de telles attaques, les pilotes doivent effectuer des vérifications de contrôle d’accès pour de telles demandes au lieu d’utiliser simplement la valeur de RequestorMode.
Techniques d’analyse des pilotes
Un moyen simple d’organiser l’analyse consiste à répertorier les zones vulnérables ainsi que les menaces potentielles et un ou plusieurs scénarios pour chaque type de menace.
Pour effectuer une analyse approfondie, vous devez explorer la possibilité de menaces à chaque point potentiellement vulnérable du conducteur. À chaque point vulnérable, déterminez chaque catégorie de menace (usurpation, falsification, répudiation, divulgation d’informations, déni de service et élévation de privilèges) qui pourrait être possible. Créez ensuite un ou plusieurs scénarios d’attaque pour chaque menace plausible.
Par exemple, considérez le flux de données pour les requêtes IRP_MJ_DEVICE_CONTROL comme indiqué dans la figure précédente. Le tableau suivant montre deux types de menaces qu’un pilote peut rencontrer lors du traitement de telles demandes :
| Point vulnérable | Menace potentielle (STRIDE) | Scénario |
|---|---|---|
| IRP_MJ_DEVICE_CONTROL demandes | Déni de service Élévation de privilège |
Le processus utilisateur émet une séquence de IOCTL qui provoque l’échec de l’appareil. Le processus utilisateur émet un IOCTL qui autorise FILE_ANY_ACCESS. |
Les arborescences et les contours des menaces peuvent être utiles pour modéliser de tels scénarios complexes.
Une arborescence des menaces est un diagramme qui montre une hiérarchie de menaces ou de vulnérabilités ; en substance, une arborescence des menaces imite les étapes de l’utilisateur malveillant lors du montage d’une attaque. Le but ultime de l’attaque est au sommet de l’arbre. Chaque niveau subordonné affiche les étapes requises pour effectuer l’attaque. La figure suivante est une arborescence de menaces simple pour le scénario de déni de service dans l’exemple précédent.
L’arborescence des menaces indique les étapes requises pour monter une attaque particulière et les relations entre les étapes. Un plan est une alternative à une arborescence de menaces.
Un plan répertorie simplement dans l’ordre hiérarchique les étapes d’attaque d’une menace particulière. Par exemple :
1.0 Provoquer l’arrêt de la réponse de l’appareil.
1.1 Émettre IOCTLS dans la séquence d’échecs.
1.1.1 Déterminer la séquence qui provoque l’échec de l’appareil.
1.1.2 Obtenez des privilèges élevés pour émettre des IOCTL internes.
L’une ou l’autre technique peut vous aider à comprendre quelles menaces sont les plus dangereuses et quelles vulnérabilités dans votre conception sont les plus critiques.
Modélisation rapide des menaces
Si les ressources sont limitées, au lieu de créer un diagramme complet de modèle de menace, un plan récapitulatif peut être créé pour aider à évaluer les risques de sécurité pour le pilote. Par exemple, le texte ci-dessous décrit certaines des surfaces représentées dans l’exemple de pilote décrit dans l’exemple précédent.
Le pilote reçoit des données du système d’exploitation dans plusieurs types de requêtes :
- Demandes d’exécution de tâches d’administration pour le pilote et son appareil, par le biais d’appels aux routines DriverEntry, DriverUnload et AddDevice
- Plug-and-Play demandes (IRP_MJ_PNP)
- Demandes de gestion de l’alimentation (IRP_MJ_POWER)
- Demandes de contrôle d’E/S d’appareil interne (IRP_MJ_INTERNAL_DEVICE_CONTROL)
En réponse à ces demandes, les données circulent du pilote vers le système d’exploitation en tant que status informations. Le pilote reçoit les données d’un processus utilisateur dans les types de requêtes suivants :
- Créer, lire et écrire des requêtes (IRP_MJ_CREATE, IRP_MJ_READ ou IRP_MJ_WRITE)
- Demandes de contrôle d’E/S d’appareil public (IRP_MJ_DEVICE_ CONTROL)
En réponse à ces demandes, les données de sortie et les informations status circulent du pilote vers le processus utilisateur.
À l’aide de cette compréhension de base du flux de données vers votre pilote, vous pouvez examiner chaque zone d’entrée et de sortie à la recherche de menaces possibles.
L’approche DREAD pour l’évaluation des menaces
Il ne suffit pas de déterminer comment et où un pilote peut être attaqué. Vous devez ensuite évaluer ces menaces potentielles, déterminer leurs priorités relatives et concevoir une stratégie d’atténuation.
DREAD est un acronyme qui décrit cinq critères d’évaluation des menaces pour les logiciels. DREAD signifie :
- Damage
- Reproducibilité
- Exploitabilité
- Unutilisateur infecté
- Discoverability
Pour hiérarchiser les menaces pour votre pilote, classez chaque menace de 1 à 10 sur les 5 critères d’évaluation DREAD, puis ajoutez les scores et divisez par 5 (le nombre de critères). Le résultat est un score numérique compris entre 1 et 10 pour chaque menace. Des scores élevés indiquent des menaces graves.
Dégâts. L’évaluation des dommages qui pourraient résulter d’une attaque de sécurité est évidemment un élément essentiel de la modélisation des menaces. Les dommages peuvent inclure une perte de données, une défaillance matérielle ou multimédia, des performances inférieures aux normes ou toute mesure similaire qui s’applique à votre appareil et à son environnement d’exploitation.
La reproductibilité est une mesure de la fréquence à laquelle un type d’attaque spécifié réussit. Une menace facilement reproductible est plus susceptible d’être exploitée qu’une vulnérabilité qui se produit rarement ou imprévisible. Par exemple, les menaces contre les fonctionnalités installées par défaut ou utilisées dans chaque chemin de code potentiel sont hautement reproductibles.
L’exploitabilité évalue les efforts et l’expertise nécessaires pour monter une attaque. Une menace qui peut être attaquée par un étudiant relativement inexpérimenté est hautement exploitable. Une attaque qui nécessite du personnel hautement qualifié et est coûteuse à effectuer est moins exploitable.
Pour évaluer l’exploitabilité, tenez également compte du nombre d’attaquants potentiels. Une menace qui peut être exploitée par n’importe quel utilisateur distant et anonyme est plus exploitable qu’une menace qui nécessite un utilisateur sur site hautement autorisé.
Utilisateurs affectés. Le nombre d’utilisateurs susceptibles d’être affectés par une attaque est un autre facteur important dans l’évaluation d’une menace. Une attaque qui pourrait toucher au plus un ou deux utilisateurs serait relativement faible pour cette mesure. À l’inverse, une attaque par déni de service qui bloque un serveur réseau pourrait affecter des milliers d’utilisateurs et donc un taux beaucoup plus élevé.
La détectabilité est la probabilité qu’une menace soit exploitée. La détectabilité est difficile à estimer avec précision. L’approche la plus sûre consiste à supposer que toute vulnérabilité sera éventuellement mise à profit et, par conséquent, à s’appuyer sur les autres mesures pour établir le classement relatif de la menace.
Exemple : Évaluation des menaces à l’aide de DREAD
Dans la continuité de l’exemple décrit ci-dessus, le tableau suivant montre comment un concepteur peut évaluer l’attaque hypothétique par déni de service :
| Critère DREAD | Score | Commentaires |
|---|---|---|
| Dommage | 8 | Interrompt temporairement le travail, mais n’entraîne aucun dommage permanent ou perte de données. |
| Reproductibilité | 10 | Provoque l’échec de l’appareil à chaque fois. |
| Exploitabilité | 7 | Nécessite un effort ciblé pour déterminer la séquence de commandes. |
| Atteinte des utilisateurs | 10 | Affecte chaque modèle de cet appareil sur le marché. |
| Détectabilité | 10 | Suppose que chaque menace potentielle sera découverte. |
| Total: | 9.0 | L’atténuation de ce problème est une priorité élevée. |
Atténuation des menaces
La conception de votre pilote doit atténuer toutes les menaces exposées par votre modèle. Toutefois, dans certains cas, l’atténuation peut ne pas être pratique. Par exemple, considérez une attaque qui affecte potentiellement très peu d’utilisateurs et qui ne risque pas d’entraîner une perte de données ou de facilité d’utilisation du système. Si l’atténuation d’une telle menace nécessite plusieurs mois d’efforts supplémentaires, vous pouvez raisonnablement choisir de passer du temps supplémentaire à tester le pilote à la place. Néanmoins, n’oubliez pas qu’un utilisateur malveillant est susceptible de trouver la vulnérabilité et de monter une attaque, puis que le pilote aura besoin d’un correctif pour le problème.
Inclure la modélisation des menaces dans un processus de cycle de vie de développement de sécurité plus large
Envisagez d’inclure le processus de modélisation des menaces dans un cycle de vie de développement sécurisé plus large - SDL.
Le processus Microsoft SDL fournit un certain nombre de processus de développement logiciel recommandés qui peuvent être modifiés pour s’adapter à n’importe quelle taille de organization, y compris un seul développeur. Envisagez d’ajouter des composants des recommandations SDL à votre processus de développement logiciel.
Pour plus d’informations, consultez Microsoft Security Development Lifecycle (SDL) – Guide de processus.
Fonctionnalités de formation et d’organisation : poursuivez la formation sur la sécurité du développement logiciel pour développer votre capacité à reconnaître et à corriger les vulnérabilités logicielles.
Microsoft met ses quatre classes de formation SDL de base disponibles en téléchargement. Cours de formation de base sur le développement de la sécurité Microsoft
Pour plus d’informations sur la formation SDL, consultez ce livre blanc. Formation essentielle sur la sécurité logicielle pour Microsoft SDL
Exigences et conception : la meilleure occasion de créer un logiciel fiable est pendant les phases de planification initiales d’une nouvelle version ou d’une nouvelle version, car les équipes de développement peuvent identifier les objets clés et intégrer la sécurité et la confidentialité, ce qui réduit les interruptions des plans et des planifications.
L’une des principales sorties de cette phase consiste à définir des objectifs de sécurité spécifiques. Par exemple, décider que tout votre code doit passer l’analyse du code Visual Studio « Toutes les règles » sans avertissement.
Implémentation : toutes les équipes de développement doivent définir et publier une liste d’outils approuvés et les vérifications de sécurité associées, telles que les options de compilateur/éditeur de liens et les avertissements.
Pour un développeur de pilotes, la plupart du travail utile est effectué dans cette phase. Au fur et à mesure que le code est écrit, il est examiné pour les faiblesses possibles. Des outils tels que l’analyse du code et le vérificateur de pilote sont utilisés pour rechercher les zones du code qui peuvent être renforcées.
Vérification : la vérification est le moment où le logiciel est fonctionnelment complet et testé par rapport aux objectifs de sécurité décrits dans la phase des exigences et de la conception.
Des outils supplémentaires tels que binscope et fuzz tester peuvent être utilisés pour vérifier que les objectifs de conception de la sécurité ont été atteints et que le code est prêt à être expédié
Mise en production et réponse : en vue de la publication d’un produit, il est souhaitable de créer un plan de réponse aux incidents qui décrit ce que vous allez faire pour répondre aux nouvelles menaces et la façon dont vous allez traiter le pilote après son expédition. Effectuer ce travail à l’avance signifie que vous serez en mesure de répondre plus rapidement si des problèmes de sécurité sont identifiés dans le code qui a été expédié.
Pour plus d’informations sur le processus SDL, consultez ces ressources supplémentaires :
Il s’agit du site Microsoft SDL principal et fournit une vue d’ensemble de SDL. https://www.microsoft.com/sdl
Ce blog explique comment télécharger une copie gratuite de The Security Development Lifecycle : SDL, par Michael Howard et Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/
Cette page fournit des liens vers d’autres publications SDL. https://www.microsoft.com/SDL/Resources/publications.aspx
Appel à l’action
Pour les développeurs de pilotes :
- Intégrer la modélisation des menaces à la conception du pilote.
- Prenez des mesures pour atténuer efficacement les menaces dans votre code de pilote.
- Familiarisez-vous avec les problèmes de sécurité et de fiabilité qui s’appliquent à votre pilote et à votre type d’appareil. Pour plus d’informations, consultez les sections spécifiques à l’appareil du Kit de pilotes de périphérique Windows (WDK).
- Découvrez les vérifications effectuées par le système d’exploitation, le gestionnaire d’E/S et les pilotes de niveau supérieur avant que les demandes des utilisateurs n’atteignent votre pilote, et les vérifications qu’ils n’effectuent pas.
- Utilisez des outils du WDK, tels que le vérificateur de pilote pour tester et vérifier votre pilote.
- Passez en revue les bases de données publiques des menaces connues et des vulnérabilités logicielles.
Pour obtenir des ressources supplémentaires sur la sécurité des pilotes, consultez Liste de contrôle de sécurité des pilotes.
Ressources de sécurité logicielle
Livres
Writing Secure Code, Second Edition par Michael Howard et David LeBlanc
24 Péchés mortels de la sécurité logicielle : les failles de programmation et la façon de les corriger, Première édition de Michael Howard, David LeBlanc et John Viega
L’art de l’évaluation de la sécurité logicielle : identifier et prévenir les vulnérabilités logicielles, par Mark Dowd, John McDonald et Justin Schuh
Informations sur les développeurs de pilotes et de matériel Microsoft
Livre blanc Annuler la logique dans les pilotes Windows
Modèle de sécurité Windows : ce que chaque enregistreur de pilotes doit savoir
Kit de développement de pilotes Microsoft Windows (DDK)
Consultez Techniques de programmation de pilotes dans l’architecture de pilote en mode noyau
Outils de test
Pour plus d’informations sur les performances et la compatibilité, consultez Kit De laboratoire matériel Windows dans Test
Bases de données publiques des menaces et vulnérabilités logicielles connues
Pour approfondir vos connaissances sur les menaces logicielles, passez en revue les bases de données publiques disponibles des menaces connues et des vulnérabilités logicielles.
- Vulnérabilités et expositions courantes (CVE) : https://cve.mitre.org/
- Common Weakness, énumération : https://cwe.mitre.org/
- Énumération et classification courantes du modèle d’attaque : https://capec.mitre.org/index.html
- NIST gère un site qui décrit comment les vulnérabilités sont catalogues : https://samate.nist.gov/BF/