Windows Defender Configuration requise pour Credential Guard

Pour Windows Defender Credential Guard afin de fournir une protection, les ordinateurs que vous protégez doivent répondre à certaines exigences matérielles, logicielles et logicielles de base, que nous appellerons configuration matérielle et logicielle. En outre, Credential Guard bloque certaines fonctionnalités d’authentification afin d’interrompre les applications utilisant des fonctionnalités bloquées. Nous allons faire référence à ces exigences en tant qu’exigences de l’application. Au-delà de ces exigences, les ordinateurs peuvent répondre à des exigences supplémentaires en matière de matériel et de microprogramme, et bénéficier de protections supplémentaires. Ces ordinateurs seront plus résistants à certaines menaces. Pour plus d’informations sur les protections de référence, ainsi que sur les protections pour une sécurité améliorée associées aux options de matériel et de microprogramme disponibles en 2015, 2016 et 2017, consultez les tableaux dans Considérations de sécurité.

Configuration matérielle et logicielle requise

Pour fournir une protection basique contre les tentatives de lecture des informations d’identification de Credential Manager et de celles dérivées de NTLM et de Kerberos au niveau du système d’exploitation, le Gestionnaire d’informations d’identification utilise :

  • Prise en charge de la sécurité basée sur la virtualisation (obligatoire)
  • Démarrage sécurisé (obligatoire)
  • Module de plateforme sécurisée (TPM, préféré - fournit une liaison au matériel) les versions 1.2 et 2.0 sont prises en charge, discrètes ou microprogrammes
  • Verrouillage UEFI (recommandé : empêche l’intrus de le désactiver à l’aide d’un simple changement de clé de registre)

La sécurité basée sur la virtualisation requiert :

  • CPU 64 bits
  • Extensions de virtualisation du processeur + tables de pages étendues
  • Hyperviseur Windows (ne nécessite pas l’installation de la fonctionnalité Windows Hyper-V)

Déploiement de Credential Guard sur les ordinateurs virtuels

Credential Guard peut protéger les données confidentielles d’une machine virtuelle Hyper-V, comme il le ferait pour un ordinateur physique. Lorsque Credential Guard est déployé sur un ordinateur virtuel, les secrets sont protégés contre les attaques à l’intérieur de l’ordinateur virtuel. Credential Guard ne fournit pas de protection supplémentaire contre les attaques système privilégiées menées depuis l’ordinateur hôte.

Configuration requise pour l’exécution de Credential Guard sur des ordinateurs virtuels Hyper-V

  • L’hôte Hyper-V doit disposer d’un IOMMU et exécuter au minimum Windows Server 2016 ou Windows 10 version 1607.
  • L’ordinateur virtuel Hyper-V doit être de Génération 2, disposer d’un module de plateforme sécurisée (TPM) virtuel activé et exécuter au minimum Windows Server 2016 ou Windows 10.
    • Le module de plateforme sécurisée n’est pas obligatoire, mais nous vous recommandons d’implémenter le module de plateforme sécurisée.

Pour plus d’informations sur les autres plateformes hôtes, consultez Activation des fonctionnalités de sécurité basées sur Windows Server 2016 et la virtualisation Hyper-V sur d’autres plateformes.

Pour plus d’informations sur Windows Defender configuration matérielle et logicielle requise pour Remote Credential Guard, consultez Windows Defender configuration requise de Remote Credential Guard.

Configuration requise pour les applications

Lorsque Credential Guard est activé, certaines fonctionnalités d’authentification sont bloquées afin d’interrompre les applications utilisant des fonctionnalités bloquées. Les applications doivent être testées avant le déploiement pour garantir la compatibilité avec les fonctionnalités réduites.

Warning

L’activation Windows Defender Credential Guard sur les contrôleurs de domaine n’est pas recommandée pour l’instant. Windows Defender Credential Guard n’offre aucune sécurité supplémentaire aux contrôleurs de domaine et peut entraîner des problèmes de compatibilité des applications sur les contrôleurs de domaine.

Remarque

Credential Guard ne fournit pas de protections pour la base de données Active Directory ou le Gestionnaire des comptes de sécurité (SAM). Les informations d’identification protégées par Kerberos et NTLM lorsque Credential Guard est activé se trouvent également dans la base de données Active Directory (sur les contrôleurs de domaine) et le SAM (pour les comptes locaux).

Les applications sont interrompues si elles requièrent :

  • La prise en charge du chiffrement DES via Kerberos
  • Délégation Kerberos sans contraintes
  • Extraire le ticket TGT Kerberos
  • NTLMv1

Les applications demanderont des informations d’identification et exposeront celles-ci à des risques si elles requièrent :

  • Authentification Digest
  • Délégation des informations d’identification
  • MS-CHAPv2

Les applications peuvent entraîner des problèmes de performances lorsqu’elles tentent de raccorder le processus de Credential Guard isolé.

Les services ou les protocoles qui reposent sur Kerberos, tels que les partages de fichiers, le Bureau à distance ou BranchCache, continuent de fonctionner et ne sont pas affectés par Windows Defender Credential Guard.

Éléments à prendre en compte en matière de sécurité

Tous les ordinateurs qui répondent aux protections de référence pour le matériel, les microprogrammes et les logiciels peuvent utiliser Windows Defender Credential Guard. Les ordinateurs qui répondent aux qualifications supplémentaires peuvent fournir des protections supplémentaires pour réduire la surface d’attaque. Les tableaux suivants décrivent les protections de référence, ainsi que les protections de sécurité améliorée qui sont associées à des options de matériels et de microprogrammes disponibles en 2015, en 2016 et en 2017.

Remarque

À compter de Windows 10, version 1607, le module de plateforme sécurisée (TPM 2.0) doit être activé par défaut sur les nouveaux ordinateurs livrés.

Si vous êtes oem, consultez Configuration requise pour les FABRICANTs de PC pour Windows Defender Credential Guard.

Protections de référence

Protections de référence Description Avantages en matière de sécurité
Matériel : processeur 64 bits Un ordinateur 64 bits est nécessaire pour que l’hyperviseur Windows fournisse VBS.
Matériel : extensions de virtualisation du processeur, plus tables de pages étendues Configuration requise :
- Ces fonctionnalités matérielles sont requises pour VBS : l’une des extensions de virtualisation suivantes : - VT-x (Intel) ou - AMD-V And: - Tables de pages étendues, également appelées traduction d’adresses de second niveau (SLAT).
Avantages en matière de sécurité : VBS assure l’isolement du noyau sécurisé à partir du système d’exploitation normal.

Les vulnérabilités et les jour 0 dans le système d’exploitation normal ne peuvent pas être exploitées en raison de cet isolement.
Matériel : module de plateforme sécurisée (TPM) Condition requise :
- TPM 1.2 ou TPM 2.0, discret ou microprogramme. Recommandations relatives au module de plateforme sécurisée (TPM)
Avantages en matière de sécurité : un module TPM fournit une protection des clés de chiffrement VBS stockées dans le microprogramme. TPM permet de se protéger contre les attaques impliquant un utilisateur physiquement présent avec un accès AU BIOS.
Microprogramme : version du microprogramme UEFI 2.3.1.c ou supérieur avec Démarrage sécurisé UEFI Configuration requise :
- Consultez la configuration requise du programme de compatibilité matérielle Windows suivante : System.Fundamentals.Firmware.UEFISecureBoot
Le démarrage sécurisé UEFI permet de s’assurer que l’appareil démarre uniquement du code autorisé et peut empêcher les kits de démarrage et les kits racines d’installer et de persister entre les redémarrages.
Microprogramme : Processus de mise à jour de microprogramme sécurisé Configuration requise :
- Le microprogramme UEFI doit prendre en charge la mise à jour sécurisée du microprogramme dans le cadre de la configuration requise du programme de compatibilité matérielle Windows suivante : System.Fundamentals.Firmware.UEFISecureBoot.
Comme un logiciel, le microprogramme UEFI peut présenter des vulnérabilités de sécurité qui, lorsqu’elles sont trouvées, doivent être corrigées par le biais de mises à jour du microprogramme. Les correctifs permettent d’empêcher l’installation des rootkits.
Logiciel : Système d’exploitation Windows qualifié Condition requise :
- Au moins Windows 10 Entreprise, Windows 10 Éducation ou Windows Server 2016.
Avantages en matière de sécurité : prise en charge de VBS et des fonctionnalités de gestion qui simplifient la configuration de Credential Guard.

Important

Les tableaux suivants répertorient les qualifications supplémentaires pour améliorer la sécurité. Toutefois, nous vous conseillons fortement d’appliquer la configuration requise pour une sécurité améliorée afin de renforcer considérablement le niveau de sécurité fourni par Credential Guard.

Qualifications de sécurité supplémentaires 2015 à partir de Windows 10, version 1507 et Windows Server 2016, Technical Preview 4

Protections pour une sécurité améliorée Description
Matériel : IOMMU (unité de gestion de mémoire d’entrée/sortie) Condition requise :
- VT-D ou AMD Vi IOMMU

Security benefits:
- Un IOMMU peut améliorer la résilience du système contre les attaques de mémoire. Pour plus d’informations, consultez Tables de description ACPI (Advanced Configuration and Power Interface)
Microprogramme : Sécurisation de la configuration et de la gestion du démarrage Conditions requises :
- Le mot de passe BIOS ou l’authentification plus forte doit être prise en charge.
- Dans la configuration du BIOS, l’authentification BIOS doit être définie.
- Il doit y avoir prise en charge de l’option bios protégée pour configurer la liste des périphériques de démarrage autorisés (par exemple, « Démarrage uniquement à partir du disque dur interne ») et de l’ordre des appareils de démarrage, en remplaçant la modification BOOTORDER effectuée par le système d’exploitation.
- Dans la configuration du BIOS, les options du BIOS liées aux options de sécurité et de démarrage (liste des périphériques de démarrage autorisés, ordre de démarrage) doivent être sécurisées pour empêcher le démarrage d’autres systèmes d’exploitation et pour empêcher toute modification des paramètres du BIOS.
Microprogramme : implémentation MOR sécurisé, révision 2 Condition requise :
- Mor sécurisé, implémentation de révision 2

Qualifications de sécurité supplémentaires 2016 à partir de Windows 10, version 1607 et Windows Server 2016

Important

Les tableaux suivants répertorient les qualifications supplémentaires pour améliorer la sécurité. Les systèmes qui répondent à ces qualifications supplémentaires peuvent fournir davantage de protections.

Protections pour une sécurité améliorée Description Avantages en matière de sécurité :
Microprogramme : Démarrage sécurisé d’une plateforme matérielle de confiance associée à une racine Configuration requise :
- L’intégrité du démarrage (démarrage sécurisé de la plateforme) doit être prise en charge. Consultez la configuration requise du programme de compatibilité matérielle Windows sous System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby
: L’interface de test de sécurité matérielle (HSTI) doit être implémentée. Consultez Spécifications du test de sécurité du matériel.
• L’intégrité du démarrage (démarrage sécurisé de plateforme) à partir de la mise sous tension fournit une protection contre les personnes malveillantes physiquement présentes et une protection renforcée contre les programmes malveillants.
- HSTI fournit une garantie de sécurité supplémentaire pour le silicium et la plateforme correctement sécurisés.
Microprogramme : Mise à jour du microprogramme via Windows Update Configuration requise :
- Le microprogramme doit prendre en charge les mises à jour de champs via Windows Update et la mise à jour de l’encapsulation UEFI.
Permet de garantir que les mises à jour de microprogramme sont rapides, sécurisées et fiables.
Microprogramme : Sécurisation de la configuration et de la gestion du démarrage Configuration requise :
- Fonctionnalités du BIOS requises : capacité de l’OEM à ajouter un isV, un OEM ou un certificat d’entreprise dans la base de données de démarrage sécurisé au moment de la fabrication.
- Configurations requises : Microsoft’autorité de certification UEFI doit être supprimée de la base de données de démarrage sécurisé. La prise en charge des modules UEFI tiers est autorisée, mais doit tirer parti des certificats fournis par l’éditeur de logiciels indépendant ou l’OEM pour le logiciel UEFI spécifique.
- Les entreprises peuvent choisir d’autoriser l’exécution des pilotes/applications EFI propriétaires.
- La suppression Microsoft’autorité de certification UEFI de la base de données de démarrage sécurisé offre aux entreprises un contrôle total sur les logiciels qui s’exécutent avant le démarrage du système d’exploitation.

Qualifications de sécurité supplémentaires 2017 à partir de Windows 10, version 1703

Le tableau suivant répertorie les qualifications pour Windows 10, version 1703, qui s'ajoutent à toutes les qualifications précédentes.

Protections pour une sécurité améliorée Description Avantages en matière de sécurité :
Microprogramme : activation VBS de la protection No-Execute (NX) pour les services d’exécution UEFI Configuration requise :
- VBS active la protection NX sur le code du service runtime UEFI et les régions de mémoire de données. Le code de service d'exécution UEFI doit prendre en charge les protections de page en lecture seule, et le service d'exécution UEFI ne doit pas être exécutable. Le service runtime UEFI doit répondre aux exigences suivantes :
- Implémenter UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. Toute la mémoire du service d'exécution UEFI (code et données) doit être décrite dans ce tableau.
- Les sections PE doivent être alignées sur la page en mémoire (non obligatoire pour le stockage non volatile).
- La table Des attributs de mémoire doit marquer correctement le code et les données comme RO/NX pour la configuration par le système d’exploitation :
- Toutes les entrées doivent inclure des attributs EFI_MEMORY_RO, EFI_MEMORY_XP ou les deux.
- Aucune entrée ne peut être laissée avec aucun des attributs ci-dessus, ce qui indique que la mémoire est à la fois exécutable et accessible en écriture. La mémoire doit être lisible et exécutable ou accessible en écriture et non exécutable.
(CONSULTEZ LES INFORMATIONS IMPORTANTES APRÈS CE TABLEAU)
Les vulnérabilités dans le runtime UEFI, le cas échéant, seront empêchées de compromettre VBS (comme dans des fonctions telles que UpdateCapsule et SetVariable)
: réduit la surface d’attaque à VBS à partir du microprogramme système.
Microprogramme : Prise en charge du microprogramme pour la protection SMM Configuration requise :
- La spécification WSMT (Windows SMM Security Mitigations Table) contient les détails d’une table ACPI qui a été créée pour une utilisation avec les systèmes d’exploitation Windows qui prennent en charge les fonctionnalités de sécurité basée sur la virtualisation (VBS) Windows.
- Protège contre les vulnérabilités potentielles dans les services d’exécution UEFI, le cas échéant, ne peut pas compromettre VBS (comme dans des fonctions telles que UpdateCapsule et SetVariable)
: réduit la surface d’attaque à VBS à partir du microprogramme système.
- Bloque les attaques de sécurité supplémentaires contre SMM.

Important

En ce qui concerne l’activation VBS de la protection NX pour les services d’exécution UEFI :

  • Cela s’applique uniquement à la mémoire du service runtime UEFI, et non à la mémoire du service de démarrage UEFI.

  • Cette protection est appliquée par VBS sur les tables de pages du système d’exploitation.

    Notez également les points suivants :

    • N’utilisez pas de sections accessibles en écriture et exécutables

    • Ne pas essayer de modifier directement la mémoire système exécutable

    • Ne pas utiliser de code dynamique