Partager via

Modélisation des menaces pour les pilotes

Les rédacteurs de pilotes logiciels et les architectes doivent faire de la modélisation des menaces une partie intégrante du processus de conception pour tout pilote logiciel. 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 n’importe quel pilote. Tout produit réussi est une cible. Si vous écrivez un pilote pour Windows, vous devez supposer que parfois, 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ées à chaque point.
  • 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 d’une ressource. Du point de vue d'un auteur de pilotes, les atouts sont le matériel, le logiciel 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 de 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 de logiciels, car elle garantit que la sécurité est intégrée au produit, plutôt que traitée comme une idée de suite. Un bon modèle de menace peut aider à trouver et à empêcher les bogues pendant le processus de conception, ce qui élimine les correctifs potentiellement coûteux ultérieurement et les dommages de réputation possibles à votre organisation.

Cette section applique les principes de modélisation des menaces à la conception des pilotes et fournit des exemples de menaces auxquelles un pilote peut être susceptible. Pour obtenir une description plus complète de la modélisation des menaces pour la conception de logiciels, reportez-vous à ces ressources.

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 auxquelles 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 la plus efficace lorsqu’elle est effectuée de manière organisée et structurée lors de 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 permet de garantir que le modèle est complet.

Une façon d’organiser un effort de modélisation des menaces consiste à suivre les étapes suivantes :

  1. 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 et la source et la destination de toutes les entrées et sorties du pilote. Un diagramme de flux de données formel, ou 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.
  2. Analysez les menaces de sécurité potentielles, en fonction du diagramme de flux de données.
  3. É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 :

Symboles de diagramme de flux de données, notamment le processus, le magasin de données, le flux de données et l’entité externe.

La figure suivante montre un exemple de diagramme de flux de données pour un pilote du modèle de pilote Windows (WDM) en mode noyau hypothétique. Quelle que soit l’architecture de votre type de pilote particulier, le modèle conceptuel est le même : affichez tous les chemins de données et identifiez chaque source de données qui entre ou quitte le pilote.

Exemple de diagramme de flux de données pour un pilote hypothétique du modèle Windows Driver Model (WDM) en mode noyau.

Note La figure précédente montre les données qui circulent directement entre un processus utilisateur et le pilote, et omettent 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 les données du système d’exploitation dans plusieurs types de requêtes :

  • Demandes d’exécution de tâches administratives pour le pilote et son appareil, via des appels à DriverEntry, DriverUnload et des routines AddDevice
  • Requêtes Plug and Play (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 sont transmises du pilote au système d’exploitation en tant qu’informations d’état. Le pilote de 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 d’état circulent du pilote vers le processus utilisateur.

Enfin, le pilote reçoit des données de l’appareil en raison d’opérations d’E/S d’appareil ou d’actions utilisateur (telles que l’ouverture de la barre d’état sur un lecteur CD) qui modifient l’état de l’appareil. De même, les données du pilote circulent vers l’appareil pendant les opérations d’E/S et modifient l’état de l’appareil.

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 de requêtes d’E/S provenant de sources différentes, vous devrez peut-être créer un ou plusieurs diagrammes supplémentaires qui affichent 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.

Diagramme de flux de données développé pour les demandes d’E/S, montrant des tâches distinctes pour chaque type de requête d’E/S.

Le deuxième diagramme montre des tâches distinctes pour chaque type de requête d’E/S dans le premier diagramme. (Par souci de simplicité, les chemins de données vers l’appareil ont été omis.)

Les entités externes et les types d’entrée et de sortie affiché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 requêtes 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 requête d’E/S comme 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 pilotes. Tout code exécuté sur l’ordinateur d’un utilisateur peut générer une demande d’E/S vers un pilote, à partir d’applications connues telles que Microsoft Office vers des logiciels gratuits, des sharewares et des téléchargements 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 fournis par votre entreprise pour prendre en charge son appareil. Les sources de données possibles sont les suivantes :

  • IRP_MJ_XXX demande que le conducteur gère
  • IOCTLs 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 autres informations fournies par l'utilisateur utilisées par le pilote

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 lus ou écrits pendant 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 auquel 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. Tenez compte des types de questions suivants :

  • Quels sont les mécanismes de sécurité en place pour protéger chaque ressource ?
  • Toutes les transitions et interfaces sont-elles correctement sécurisées ?
  • L’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 ?

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 :

  • Usurpation
  • Ampliage
  • Répudiation R
  • Information divulgation d'informations
  • Déni de service
  • Elevation des privilèges

En utilisant STRIDE comme guide, vous pouvez poser des questions détaillées sur les types d’attaques susceptibles d’être ciblées sur un pilote. L’objectif est de déterminer les types d’attaques qui pourraient être possibles à chaque point vulnérable dans le pilote, puis de créer un scénario pour chaque attaque possible.

  • L’usurpation d’identité utilise les informations d’identification d’une autre personne pour accéder aux 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 consiste à modifier des données pour mener une attaque. Par exemple, un pilote peut être vulnérable à la falsification si les fichiers de pilotes nécessaires ne sont pas adéquatement protégés par la signature numérique des pilotes et par les listes de contrôle d’accès (ACL). Dans ce cas, un utilisateur malveillant peut modifier les fichiers, ce qui enfreint 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 autrement. Un pilote peut être susceptible d’être exposé à une menace de répudiation s’il ne consigne pas les actions susceptibles de compromettre la sécurité. Par exemple, un pilote pour un appareil vidéo peut être susceptible de répudier s’il ne journalise pas les demandes de modification des caractéristiques de son appareil, telles que le focus, la zone analysée, la fréquence de capture d’images, l’emplacement cible des images capturées, etc. Les images résultantes peuvent être endommagées, mais les administrateurs système n’auraient aucun moyen de déterminer l’utilisateur qui a provoqué le problème.

  • Les menaces de divulgation d’informations sont exactement comme le nom l’implique : la divulgation d’informations à un utilisateur qui n’a pas l’autorisation de le voir. Tout pilote qui transmet des informations à ou à partir d’une mémoire tampon utilisateur est susceptible d’être exposé 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 initialiser zéro les mémoires tampons 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 aux 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 susceptible d’une attaque par déni de service si la consommation de ressources entrave la capacité d’autres utilisateurs valides à 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 dans une paire KeEnterCriticalRegion/KeLeaveCriticalRegion , qui désactive et réactive la remise des appels de procédure asynchrone (API). Si le pilote n'arrive pas à utiliser ces routines, un APC pourrait entraîner le système d'exploitation à suspendre le thread qui détient 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 d’élévation de privilèges peut se produire si un utilisateur non privilégié obtient l’état privilégié. 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 requête 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 requête. Pour éviter ces attaques, les pilotes doivent effectuer des vérifications de contrôle d’accès pour ces demandes au lieu d’utiliser simplement la valeur de RequestorMode.

Techniques d’analyse des pilotes

Une façon 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 dans le pilote. À 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 peut ê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 demandes de IRP_MJ_DEVICE_CONTROL comme indiqué dans la figure précédente. Le tableau suivant présente deux types de menaces qu’un pilote peut rencontrer lors du traitement de ces demandes :

Point vulnérable Menace potentielle (STRIDE) Scénario
demandes de IRP_MJ_DEVICE_CONTROL

Déni de service

Élévation de privilèges

Le processus utilisateur émet une séquence de IOCTLs qui provoque l’échec de l’appareil.

Le processus utilisateur émet un IOCTL qui autorise FILE_ANY_ACCESS.
Une menace est souvent liée à une autre. Par exemple, une attaque qui exploite une menace d’élévation de privilèges peut entraîner une divulgation d’informations ou un déni de service. De plus, certains types d’attaques dépendent d’une séquence d’événements. Un utilisateur malveillant peut commencer par exploiter une menace d’élévation de privilèges. Ensuite, avec les fonctionnalités ajoutées qui sont fournies avec des privilèges élevés, l’utilisateur peut trouver et exploiter des vulnérabilités supplémentaires.

Les arborescences et les contours des menaces peuvent être utiles dans la modélisation de scénarios aussi complexes.

Une arborescence des menaces est un diagramme qui montre une hiérarchie de menaces ou de vulnérabilités ; en essence, une arborescence de menaces imite les étapes de l’utilisateur malveillant dans le montage d’une attaque. L’objectif ultime de l’attaque est au sommet de l’arbre. Chaque niveau subordonné montre 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.

Diagramme d’arborescence des menaces simple illustrant une hiérarchie de menaces ou de vulnérabilités pour un scénario de déni de service.

L’arborescence des menaces affiche 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 à suivre pour attaquer une menace particulière. Par exemple:

1.0 Empêcher la réponse de l’appareil.

1.1 Émettre IOCTLS en séquence d’échec.

1.1.1 Déterminer la séquence qui provoque l’échec de l’appareil.

1.1.2 Obtenir un privilège élevé 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 des menaces en voie rapide

Si les ressources sont limitées, au lieu de créer un diagramme complet de modèle de menace, un résumé peut être créé pour aider à évaluer les risques de sécurité pour le pilote. Par exemple, le texte ci-dessous décrit certaines zones de surface 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 administratives pour le pilote et son appareil, via des appels à DriverEntry, DriverUnload et des routines AddDevice
  • Demandes plug-and-play (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 sont transmises du pilote au système d’exploitation en tant qu’informations d’état. Le pilote 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 de périphérique public (IRP_MJ_DEVICE_CONTROL)

En réponse à ces demandes, les données de sortie et les informations d’état 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 pour connaître les menaces possibles.

L’approche DREAD pour l’évaluation des menaces

Déterminer comment et où un pilote peut être attaqué n’est pas suffisant. Vous devez ensuite évaluer ces menaces potentielles, déterminer leurs priorités relatives et élaborer 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 :

  • Dommage
  • Eproducibilité R
  • Exploitabilité
  • Utilisateurs affectés
  • Découvrabilité

Pour hiérarchiser les menaces à votre pilote, placez 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. Les scores élevés indiquent des menaces graves.

  • Dommages. L’évaluation des dommages pouvant résulter d’une attaque de sécurité constitue évidemment une partie essentielle de la modélisation des menaces. Les dommages peuvent inclure la perte de données, le matériel ou la défaillance du support, les performances non standard 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 aux fonctionnalités installées par défaut ou utilisées dans chaque chemin de code potentiel sont hautement reproductibles.

  • Exploitabilité évalue l’effort et l’expertise nécessaires pour monter une attaque. Une menace qui peut être attaquée par un étudiant de collège relativement inexpérimenté est très exploitable. Une attaque qui nécessite un personnel hautement qualifié et qui coûte cher à effectuer est moins exploitable.

    Pour évaluer l’exploitabilité, envisagez également le nombre d’attaquants potentiels. Une menace qui peut être exploitée par n’importe quel utilisateur distant et anonyme est plus exploitable qu’une personne nécessitant 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 susceptible d’affecter au plus un ou deux utilisateurs serait considérée comme assez faible selon cette échelle. À l'inverse, une attaque par déni de service qui fait planter un serveur réseau pourrait affecter des milliers d'utilisateurs et aurait donc une gravité beaucoup plus élevée.

  • 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 finalement prise en compte et, par conséquent, de s’appuyer sur les autres mesures pour établir le classement relatif de la menace.

Exemple : Évaluation des menaces à l’aide de DREAD

En suivant 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 Résultat Commentaires
Endommager 8 Interrompt temporairement le travail, mais ne provoque aucun dommage permanent ni 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.
Utilisateurs affectés 10 Affecte chaque modèle de cet appareil sur le marché.
Découvrabilité 10 Suppose que chaque menace potentielle sera découverte.
Total: 9.0 L’atténuation de ce problème est prioritaire.

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, envisagez une attaque qui affecte potentiellement très peu d’utilisateurs et est peu susceptible 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 risque de trouver la vulnérabilité et de monter une attaque, puis que le pilote aura besoin d’un correctif pour le problème.

Inclusion de 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 d’organisation, 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.

Formation et fonctionnalités organisationnelles : 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 principales à la disposition du téléchargement. Cours de formation de base sur le cycle de vie du développement de la sécurité Microsoft

Pour plus d’informations sur la formation SDL, consultez ce livre blanc. Formation de sécurité logicielle essentielle pour Microsoft SDL

Exigences et conception : la meilleure opportunité de créer des logiciels approuvés est au cours des 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.

Une sortie clé dans cette phase consiste à définir des objectifs de sécurité spécifiques. Par exemple, décider que tout votre code doit passer l’analyse de code Visual Studio « Toutes les règles » avec zéro avertissement.

Implémentation : toutes les équipes de développement doivent définir et publier une liste d’outils approuvés et leurs vérifications de sécurité associées, telles que les options du compilateur/éditeur de liens et les avertissements.

Pour un développeur pilote, la plupart des travaux utiles sont effectués dans cette phase. Comme le code est écrit, il est examiné pour une faiblesse possible. Les outils tels que l’analyse du code et le vérificateur de pilote sont utilisés pour rechercher des zones dans le code qui peuvent être renforcées.

Vérification : la vérification est le point auquel le logiciel est fonctionnelment terminé et est testé par rapport aux objectifs de sécurité décrits dans les exigences et la phase de conception.

Des outils supplémentaires tels que binscope et testeurs fuzz peuvent être utilisés pour vérifier que les objectifs de conception de sécurité ont été atteints et que le code est prêt à être expédié

Mise en production et réponse : en préparation 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 comment vous allez servir le pilote une fois qu’il a été expédié. 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 les ressources supplémentaires suivantes :

Appel à l’action

Pour les développeurs de pilotes :

  • Intégrez la modélisation des menaces dans la conception des pilotes.
  • 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 type de pilote et de périphérique. Pour plus d’informations, consultez les sections spécifiques à l’appareil du Kit de pilotes de périphérique Windows (WDK).
  • Comprenez quels contrôles effectuent le système d’exploitation, le gestionnaire d’E/S et les pilotes de niveau supérieur avant que les demandes utilisateur n’atteignent votre pilote — et quels contrôles ils ne réalisent pas.
  • Utilisez des outils de 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 d’autres ressources de sécurité de pilote, consultez Liste de contrôle de sécurité des pilotes.

Ressources de sécurité logicielle

Livres

Écriture de code sécurisé, deuxième édition par Michael Howard et David LeBlanc

24 Péchés mortels de sécurité logicielle : failles de programmation et comment les corriger, Première édition de Michael Howard, David LeBlanc et John Viega

L’art de l’évaluation de la sécurité logicielle : identification et prévention des vulnérabilités logicielles, par Mark Dowd, John McDonald et Justin Schuh

Informations pour développeurs de matériels et de pilotes Microsoft

Annuler la logique dans le livre blanc des pilotes Windows

Modèle de sécurité Windows : tout ce que tout développeur de pilotes doit savoir

Kit de développement de pilotes Microsoft Windows (DDK)

Consultez les techniques de programmation de pilotes dans Kernel-Mode Architecture de pilote

Outils de test

Consultez Windows Hardware Lab Kit dans Test de performance et de compatibilité

Bases de données publiques des menaces connues et des vulnérabilités logicielles

Pour développer 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.

Voir aussi

Liste de contrôle de sécurité du pilote