Sécurité
Verrouillage d'applications avec les stratégies de restriction logicielle
Chris Corio and Durga Prasad Sayana
Vue d'ensemble:
- Fonctionnement des stratégies de restriction logicielle
- Inventaire des applications de votre environnement
- Création et application de stratégies
Lorsque les informaticiens cherchent à réduire le coût total de possession de leurs ordinateurs de bureau, deux stratégies essentielles viennent souvent à l'esprit. La première consiste à enlever les
comptes d'utilisateurs d'ordinateurs de bureau du groupe Administrateurs. La seconde est la limitation des applications pouvant être exécutées par les utilisateurs. S'attaquer à ces problèmes peut constituer un défi de taille dans un environnement d'entreprise, mais Windows Vista® dispose de technologies pouvant vous aider à atteindre ces objectifs.
Windows Vista et sa fonctionnalité de Contrôle de compte d'utilisateur constituent une étape importante dans l'aide apportée aux professionnels de l'informatique pour l'affectation des utilisateurs de l'entreprise en tant que membres du groupe Utilisateurs (Utilisateurs standard). Le Contrôle de compte d'utilisateur a modifié le contexte de sécurité par défaut de toutes les applications, le faisant passer d'Administrateur à Utilisateur. Cette migration vers le groupe Utilisateurs est toujours une tâche conséquente, mais la tâche devient progressivement plus facile tandis que le secteur s'ajuste à ce nouveau paradigme.
Après avoir analysé les défis du transfert d'utilisateurs vers le groupe Utilisateurs, ou parfois pendant ce processus, de nombreux administrateurs cataloguent les applications que leurs utilisateurs ont besoin d'exécuter et examinent les étapes nécessaires pour autoriser seulement ces applications. La fonctionnalité de stratégie de restriction logicielle est conçue précisément pour aider les informaticiens à effectuer cette tâche.
Vous spécifiez simplement les applications autorisées à être exécuter et déployez ensuite la stratégie à l'aide de la Stratégie de groupe. L'application d'une telle stratégie dans l'ensemble d'une entreprise peut réduire le coût total de possession, car ce verrouillage limitera les problèmes liés aux applications non prises en charge. (Vous pouvez également utiliser des stratégies de restriction logicielle de manières extrêmes et intéressantes, comme nous l'avons décrit dans l'encadré « Stratégie de restriction logicielle réduite à sa plus simple expression ».)
Fonctionnement de la stratégie de restriction logicielle
La stratégie de restriction logicielle vise à contrôler précisément le code qu'un utilisateur peut exécuter sur un ordinateur Windows Vista. Vous, l'administrateur, créez une stratégie qui définit ce qui peut (ou ne peut pas) être exécuté dans votre environnement. Cette stratégie est ensuite évaluée à tout moment et à tout emplacement auxquels le code pourrait être exécuté. Ceci inclut la création de processus, pendant un appel à ShellExecute et l'exécution d'un script. (Nous examinerons ceci dans un instant)
Si une application est autorisée à s'exécuter, l'application démarrera. Si, cependant, une application n'est pas autorisée à s'exécuter, l'application est bloquée et l'utilisateur est averti. Par exemple, si vous aviez essayé d'exécuter le Solitaire depuis le menu Démarrer et qu'il n'était pas autorisé, une boîte de dialogue similaire à celle affichée dans la figure 1 s'afficherait.
Figure 1** Une boîte de dialogue s'affiche lorsqu'une application est bloquée **(Cliquez sur l'image pour l'agrandir)
L'interface utilisateur pour la définition d'une stratégie de restriction logicielle est exposée dans l'éditeur d'objets de stratégie de groupe (Group Policy Object Editor, GPOE), et c'est là que la stratégie de verrouillage est créée. Il existe une variété de méthodes pour définir le code pouvant ou ne pouvant pas être exécuté. Une fois la stratégie terminée et testée, vous pouvez la déployer.
Définition de la stratégie de restriction logicielle
La première décision majeure que vous prendrez, une décision qui affectera de façon spectaculaire la manière dont la stratégie de restriction logicielle fonctionnera dans votre environnement, est de choisir un type de règle par défaut. Les stratégies de restriction logicielle peuvent être déployées dans deux modes : Liste verte ou Liste de refus. Vous choisissez si vous voulez créer une stratégie qui décrit chaque application autorisée à s'exécuter dans votre environnement ou une stratégie définissant chaque application à ne pas exécuter.
En mode Liste verte, la règle par défaut dans votre stratégie est Restreint et bloquera toutes les applications que vous n'autorisez pas explicitement à s'exécuter. En mode Liste de refus, la règle par défaut est Non restreint et restreint seulement les applications que vous avez répertoriées explicitement.
Le mode Liste de refus, comme vous pouvez le deviner, est une approche peu réaliste si vous recherchez une réduction du coût total de possession importante et les avantages de sécurité résultant d'un verrouillage d'application. La création et la maintenance d'une liste complète bloquant tous les logiciels malveillants et autres applications problématiques serait presque impossible. Nous recommandons que la stratégie de restriction logicielle soit implémentée en mode Liste verte, ce qui correspond à une règle par défaut Limité.
Inventaire des applications de votre environnement
Si vous allez concevoir une stratégie qui spécifiera les applications pouvant s'exécuter, vous devez déterminer avec précision les applications que vos utilisateurs nécessitent. La fonctionnalité de stratégie de restriction logicielle offre une fonctionnalité de journalisation avancée avec une stratégie très simple pour savoir précisément quelles sont les applications qui s'exécutent dans votre environnement.
Sur un ensemble d'ordinateurs de votre environnement, déployez votre stratégie de restriction logicielle avec la règle par défaut définie sur Non restreint et veillez à supprimer toute autre règle supplémentaire. L'objectif consiste à activer la stratégie de restriction logicielle mais à ne pas l'autoriser à restreindre des applications. Vous l'utilisez plutôt pour contrôler seulement ce qui est exécuté.
Ensuite, créez la valeur de Registre suivante pour activer la fonction de journalisation avancée et définir le chemin dans lequel le fichier journal devrait être écrit :
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Maintenant, lorsqu'une application est exécutée et que la stratégie de restriction logicielle est évaluée (elle est évaluée même si elle autorise l'exécution de tout), une entrée est écrite dans le fichier journal.
Chaque entrée de journal inclut l'appelant de la stratégie de restriction logicielle et l'ID de processus (PID) du processus appelant, la cible évaluée, le type de règle de stratégie de restriction logicielle qui correspondait et un identificateur pour la règle. Voici une entrée d'exemple écrite lorsqu'un utilisateur double-clique sur notepad.exe :
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
Ce fichier journal représente chaque élément de code exécutable que cette stratégie de restriction logicielle vérifiera lorsqu'elle est activée et définie pour bloquer des applications. Ceci signifie que vous devez, pour chaque entrée du fichier journal, décider si elle devrait ou non figurer dans votre liste verte. Notez que vous verrez plusieurs fichiers binaires vérifiés faisant partie de Windows® et requis pour le fonctionnement du système.
La technique de journalisation que nous décrivons ici vous offre une méthode évidente pour connaître précisément les applications que la stratégie de restriction logicielle rencontrera dans votre environnement. Mais ce n'est pas la seule manière d'accomplir cette tâche.
Inventory Collector, inclus dans les Outils d’analyse de compatibilité des applications Microsoft® 5.0 vous donne la capacité d'effectuer l'inventaire des applications utilisées dans votre environnement. Cet outil offre plusieurs méthodes différentes vous permettant de découvrir les applications installées dans votre environnement et consolide également les résultats dans une base de données centrale.
Création de règles supplémentaires
Maintenant que vous disposez d'une liste d'applications devant être autorisées à s'exécuter dans votre environnement, vous êtes prêt à créer les véritables règles qui permettront à ces applications de s'exécuter. La fonctionnalité de stratégie de restriction logicielle utilise deux méthodes pour identifier la stratégie : l'une est basée sur les propriétés cryptographiques d'une application (comme son hachage) et l'autre définit un dossier ou chemin de confiance dans lequel les applications de confiance doivent résider.
La figure 2 montre l'emplacement auquel vous ajouteriez des règles pour autoriser les applications à s'exécuter dans le nœud Stratégies de restriction logicielle du GPOE (gpedit.msc). La façon la plus simple de définir des applications dans votre environnement est de créer une règle de hachage pour chaque fichier binaire que vous avez rencontré pendant la phase d'ouverture de session.
Figure 2** Utilisation de Gpedit.msc pour créer des stratégies de restriction logicielle **(Cliquez sur l'image pour l'agrandir)
Puisque le hachage est une valeur unique renvoyée pour un ensemble particulier de bits, chaque fichier binaire de votre stratégie possèdera un hachage différent. Cette approche est particulièrement sécurisée et permettra seulement à des binaires spécifiques de votre stratégie de s'exécuter.
Il existe bien entendu des inconvénients à cette approche. Par exemple, votre environnement pourrait facilement comporter plusieurs milliers de binaires. Il pourrait être difficile de créer toutes ces règles dans l'interface utilisateur de stratégie de restriction logicielle, et lorsque le nombre de règles devient particulièrement important, les performances peuvent être affectées. Par ailleurs, chaque mise à jour d'application dans votre environnement nécessitera le déploiement d'une ou plusieurs nouvelles règles de hachage dans l'environnement. La mise à jour d'une stratégie de taille aussi grande lorsque les applications sont mises à jour peut constituer un fardeau énorme.
Heureusement, ce fardeau peut être évité car il existe deux autres façons d'identifier des règles et permettant d'utiliser plus facilement des stratégies de restriction logicielle dans votre environnement. En plongeant davantage dans la méthode de sécurité cryptographique, vous pouvez créer une règle qui autorisera tout fichier binaire par un certificat particulier à s'exécuter.
Ceci contribue à simplifier la maintenance de la liste de la stratégie car, lorsqu'une application est mise à jour, les nouveaux fichiers binaires seront généralement signés par le même certificat que les précédents. Cependant, si vous ne voulez pas qu'une version antérieure du fichier binaire soit exécutée dans votre environnement, vous devrez ajouter une règle de hachage Restreint pour empêcher l'autorisation du fichier.
Par défaut, l'évaluation des règles de certificat est désactivée pour les stratégies de restriction logicielle. Ceci s'explique par deux raisons.
Premièrement, les règles de certificat des stratégies de restriction logicielle sont définies par ce qui se trouve dans la banque Éditeurs approuvés du système. Comme la banque Éditeurs approuvés n'est pas uniquement utilisée pour les règles de stratégie de restriction logicielle, ceci nécessite du temps et un examen supplémentaires pour l'utilisation avec la fonctionnalité de stratégies de restriction logicielle.
La deuxième raison est que pour déterminer si une signature de fichier est valide, vous devez prendre un hachage de fichier et le comparer aux informations de signature. Un hachage de fichier est une opération longue. Le fichier entier doit être lu depuis le disque et traité pour calculer ce hachage.
Pour activer les règles de certificat, naviguez jusqu'au nœud Stratégies de restriction logicielle et sélectionnez l'objet Mise en œuvre dans le volet de résultats. Double-cliquez ensuite pour ouvrir sa boîte de dialogue de propriétés et sélectionnez la case Appliquer les règles de certificat.
L'autre façon courante d'identifier le code est d'utiliser le chemin du code sur l'ordinateur local. Ceci est une technique efficace et pratique, mais elle possède un inconvénient : vous devez veiller à ce que les paramètres de sécurité soient correctement définis sur le dossier.
Si vous ajoutez une règle de chemin d'accès particulière et que ce chemin permet aux utilisateurs d'y écrire des fichiers (sur le Bureau, par exemple), ils pourraient exécuter tout ce qu'ils veulent en plaçant simplement le fichier exécutable à cet emplacement. Cependant, si vos utilisateurs ne font pas partie du groupe Administrateurs, ils n'ont généralement pas la possibilité de modifier quoi que ce soit dans les dossiers Program Files et Windows. Ceci signifie que si toutes vos applications se situent dans le répertoire Program Files et que vos utilisateurs ne sont pas Administrateurs, il est intéressant d'utiliser les règles de chemin d'accès pour avoir une stratégie très simple et efficace.
Les règles de chemin d'accès offrent d'autres fonctionnalités qui les rendent plus appropriées pour certains environnements. Elles permettent l'utilisation de caractères génériques et vous permettent d'utiliser des variables d'environnement pour définir plus facilement des règles portables dans votre environnement. Après tout, %systemdrive% peut ne pas être le c:\ pour tous les utilisateurs.
En termes de performances et de maintenance, il s'agit probablement de la manière présentant le moins de difficultés pour identifier le code. Les règles de chemin d'accès sont certainement intéressantes, mais vous devez être conscients de questions de sécurité supplémentaires.
Règles de zone réseau
La stratégie de restriction logicielle inclut un type de règle appelé Zone réseau, bien que ce type de règle ne soit pas recommandé. L'intention première de ces règles était basée sur l'idée que la source d'un code exécutable particulier pouvait être identifiée et était digne de confiance et qu'ainsi le code serait autorisé à s'exécuter. Malheureusement, ceci est particulièrement difficile à effectuer et, par conséquent, n'a jamais vraiment bien fonctionné. Actuellement, ce type de règle n'est pas appliqué dans la majorité des cas sur les points d'entrée de stratégie de restriction logicielle.
Dans les cas de figure pour lesquels la plupart des applications sont installées dans le dossier %Program Files% mais qu'il existe d'autres fichiers exécutables installés ailleurs et signés par un certificat spécifique, il est sensé d'utiliser des règles de types différents. Quelques règles de hachage, quelques règles de chemin d'accès et vous vous retrouverez avec la stratégie qui vous convient.
Gardez à l'esprit qu'il existe un ordre dans lequel les règles doivent être traitées (comme indiqué sur la figure 3). Les règles de certificat sont les plus spécifiques, les règles de hachage suivent ensuite, puis les règles de chemin d'accès et enfin les règles de chemin d'accès avec caractères génériques. Par conséquent, si un élément de code est identifié par une règle de hachage et une règle de chemin d'accès, le niveau de sécurité de la règle de hachage aura priorité.
Figure 3** Ordre de traitement des règles **(Cliquez sur l'image pour l'agrandir)
Application de stratégie
La fonctionnalité de stratégie de restriction logicielle fournit une couverture étendue du système sécurisé. Le principe est que n'importe quel emplacement depuis lequel le code peut être exécuté devrait être intégré à la stratégie de restriction logicielle et, ensuite, vérifier la stratégie pour voir si le code exécutable est autorisé à s'exécuter.
Bien qu'il existe de nombreux emplacements auxquels vérifier la stratégie de restriction logicielle, le point d'entrée le plus évident est CreateProcess. Pendant CreateProcess, la stratégie est vérifiée pour déterminer si le fichier binaire qui représente l'application est autorisé à s'exécuter. La vérification de stratégie est effectuée par l'API SaferIdentifyLevel, qui est décrite publiquement. Le processus général est illustré à la figure 4. (Nous aborderons SaferIdentifyLevel plus en détails dans un instant).
Figure 4** Utilisation de SaferIdentifyLevel pour déterminer si un fichier binaire peut être exécuté **(Cliquez sur l'image pour l'agrandir)
Après CreateProcess, l'API la plus couramment utilisée dans laquelle la stratégie de restriction logicielle est appliquée est ShellExecute. Il s'agit de l'API appelée lorsque l'utilisateur clique sur une application dans le menu Démarrer ou double-clique sur quelque chose sur le Bureau.
ShellExecute peut être appelée pour une grande variété de formats de fichier. Dans les cas tels qu'un fichier .txt, l'appel de ShellExecute pour le fichier n'a en fait pas pour résultat l'exécution du fichier : techniquement, bien sûr, le fichier est ouvert. Pour cette raison, la stratégie de restriction logicielle contient une liste de types de fichiers exécutables afin qu'elle puisse contrôler les types de fichiers vérifiés lorsque ShellExecute est appelé. Vous pouvez personnaliser cette liste de types de fichiers exécutables dans l'interface utilisateur de la stratégie de restriction logicielle.
Outre CreateProcess et ShellExecute, il existe deux autres points d'intégration essentiels : LoadLibrary et Script Host. LoadLibrary est évidemment un emplacement important pour vérifier le code exécutable, mais présente malheureusement certaines contraintes spéciales.
La plupart des applications possèdent un exécutable et plusieurs DLL qui sont chargés. De manière générale, de nombreuses applications s'exécutent sur le système. Ceci signifie que LoadLibrary nécessiterait de nombreuses vérifications de la stratégie. En fonction de votre stratégie pour l'identification de code, ceci pourrait être un point d'entrée coûteux à mettre en œuvre. Imaginez que vous ayez à vérifier le hachage de toutes les DLL chargées sur le système, ce qui inclut le hachage des bibliothèques et leur comparaison à une liste comportant peut-être des milliers de hachages.
Cette fonctionnalité est désactivée par défaut, mais peut être activée manuellement. Pour cela, naviguez jusqu'au nœud Stratégies de restriction logicielle dans gpedit.msc et double-cliquez sur Mise en œuvre. Ensuite, sélectionnez la case d'option Tous les fichiers de logiciels.
Comme nous l'avons mentionné, la stratégie de restriction logicielle est intégrée à la plupart des hôtes de script du système. Ceci inclut cmd, VBScript, Cscript et JScript®. Ces points d'entrée, de même que les autres, utilisent l'API de mise en œuvre de stratégie de restriction logicielle principale : SaferIdentifyLevel.
L'API SaferIdentifyLevel détermine si un exécutable spécifié devrait être autorisé à s'exécuter en recherchant les informations d'identification dans les stratégies de restriction logicielle pertinentes. Ceci est une API décrite publiquement. Les hôtes de script et les environnements exécutables tiers peuvent et doivent l'utiliser pour s'intégrer à la stratégie de restriction logicielle afin que la stratégie puisse déterminer si un élément de code exécutable doit être autorisé à s'exécuter.
Exécution en tant qu’utilisateur standard
Il existe une fonctionnalité peu connue de la stratégie de restriction logicielle offrant la possibilité de filtrer les privilèges de certaines applications lorsqu'elles sont lancées. Cette fonctionnalité a été introduite dans Windows XP, mais n'a pas été exposée dans l'interface utilisateur de la stratégie de restriction logicielle avant Windows Vista.
Elle était par conséquent un précurseur du Contrôle de compte d’utilisateur de Windows Vista car vous pouviez l'utiliser pour exécuter une application en tant qu'utilisateur standard même lorsque l'utilisateur était membre du groupe Administrateurs. C'est ce qui se passe lorsque vous créez une règle et définissez le niveau de sécurité sur Utilisateur normal dans l'interface utilisateur des règles supplémentaires.
La fonctionnalité de filtrage de jeton du Contrôle de compte d’utilisateur comme les règles d'utilisateur normal des stratégies de restriction logicielle tirent parti d'une API sous-jacente qui implémente le même comportement que l'API CreateRestrictedToken. Cependant, les différences architecturales générales des technologies sont très importantes. Le Contrôle de compte d’utilisateur diffère de la stratégie de restriction logicielle en quelques points essentiels.
Premièrement, dans Windows Vista avec Contrôle de compte d’utilisateur activé, chaque application est démarrée avec un jeton de sécurité similaire à un membre du groupe Utilisateurs par défaut, même lorsque l'utilisateur est administrateur. Ceci est possible avec la stratégie de restriction logicielle, mais il n'existe aucun moyen de démarrer une application avec le véritable jeton d'Administrateur de l'utilisateur, par exemple lorsque l'utilisateur doit installer une application. La modification de contexte de sécurité et l'accès facile à un jeton d'administrateur complet de l'utilisateur sont des avantages essentiels du Contrôle de compte d’utilisateur.
La deuxième différence est que, dans le cas des exécutables, le code lui-même exprime le niveau de privilège requis pour qu'il puisse fonctionner. Ceci est une distinction essentielle car les fabricants indépendants de logiciels (FIL) et les développeurs comprennent mieux les besoins de leur code. Par exemple, si une application du Panneau de configuration a besoin de modifier quelque chose nécessitant des droits d'administrateur, elle peut spécifier cette exigence dans son manifeste. Ainsi le FIL peut décrire les privilèges nécessaires par une application plutôt que de lui imposer un certain niveau de privilège sans disposer de véritables moyens de modifier ce niveau.
Pour l'instant, vous devriez éviter d'utiliser les règles d'Utilisateur normal à moins que vous ne compreniez vraiment leur fonctionnement. Le Contrôle de compte d’utilisateur est une excellente méthode pour aider à extraire les utilisateurs de bureau du groupe Administrateurs, et vous devriez sérieusement envisager de le laisser à votre environnement d'entreprise.
Stratégies de restriction logicielle utilisées aujourd'hui
Il existe plusieurs éléments à prendre en compte lorsque vous utilisez la stratégie de restriction logicielle. Mais ce n'est pas ce que vous pourriez penser et, en fait, vous utilisez peut-être même déjà des stratégies de restriction logicielle aujourd'hui, sans vous en rendre compte. Si, par exemple, vous exécutez le Contrôle parental sur un système Windows Vista, vous utilisez des stratégies de restriction logicielle pour contrôler l'exécution des applications.
La stratégie de restriction logicielle était un développement technologique important lors de son introduction initiale dans Windows XP. Mais le verrouillage d'applications commence véritablement maintenant à attirer l'attention des professionnels de l'informatique.
La fonctionnalité de stratégie de restriction logicielle dans Windows Vista nécessite d'être peaufinée, mais il est évident que les administrateurs souhaitent disposer de ce contrôle accru sur ce qui s'exécute dans leurs environnements. Heureusement pour nous tous, cette technologie continuera à évoluer et à faciliter l'administration des systèmes par les informaticiens comme la réduction du coût de l'utilisation d'un environnement Microsoft Windows.
Stratégie de restriction logicielle réduite à sa plus simple expression
Une application de la stratégie de restriction logicielle consiste à créer une stratégie verrouillant Windows dans un mode plein écran. Microsoft produit en fait un kit d'outils nommé SteadyState™, pour la création de ce mode plein écran. Cependant, si vous vous intéressez seulement au verrouillage des applications pouvant s'exécuter, ceci peut être effectué plus simplement.
Pour autoriser un ensemble minimal d'applications requises à ouvrir une session Windows Vista, créez une stratégie qui autorise logonui.exe et userinit.exe à s'exécuter à partir de %windir%\system32. La plupart des utilisateurs auront probablement également besoin des applications suivantes autorisées à s'exécuter :
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Si vous voulez le shell Windows par défaut, ajoutez alors également %windir%\explorer.exe.
Vous pourriez également choisir de démarrer directement dans une application, comme Internet Explorer®. Dans ce cas, il est nécessaire de répertorier iexplore.exe au lieu d'explorer.exe.
Un autre aspect de cette stratégie est que vos utilisateurs ne devraient pas être membres du groupe Administrateurs. Ceci est important afin qu'ils ne puissent pas contourner la stratégie. Cependant, comme ils peuvent uniquement exécuter un ensemble très simple d'applications et ne possèdent pas les autorisations d'Administrateur, les utilisateurs n'auront pas les autorisations d'installation d'applications ou de maintenance du système.
Vous devrez disposer d'un moyen d'effectuer ceci pour ces ordinateurs. Si vous prévoyez de mettre à jour et de maintenir ces ordinateurs en ouvrant une session localement avec un compte Administrateur, vous devriez sélectionner la case d'option qui applique la stratégie de restriction logicielle à tous les utilisateurs à l'exception des administrateurs locaux. La stratégie devrait également inclure consent.exe et cmd.exe. Ceci permettra à l'Administrateur de lancer toute option d'administration à partir d'une invite de commande d'Administrateur.
Notez que ce Contrôle de compte d’utilisateur limite les autorisations du jeton de sécurité de l'utilisateur par défaut pour donner l'impression que celui-ci n'est pas membre du groupe Administrateurs. Même si vous configurez le paramètre ci-dessus pour qu'il n'applique pas la stratégie aux Administrateurs, elle sera toujours appliquée aux utilisateurs. Ce n'est que lorsque vous effectuez l'élévation de Contrôle de compte d’utilisateur que l'Administrateur obtient réellement les droits d'administrateur complets et que la stratégie de restriction logicielle n'est plus appliquée.
Chris CorioChris Corio a été membre de l'équipe Windows Security chez Microsoft pendant plus de cinq ans. Ses activités principales chez Microsoft avaient trait aux technologies de sécurité des applications et aux technologies d'administration pour sécuriser Windows. Vous pouvez joindre Chris à l'adresse winsecurity@chriscorio.com
Durga Prasad SayanaDurga Prasad Sayana est ingénieur de conception logicielle (test) de l'équipe Windows Core Security. Ses centres d'intérêts principaux sont les technologies de sécurité et le test de logiciels. Vous pouvez joindre Durga à l'adresse durgas@microsoft.com.
© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..