Checklist hardening par niveau¶

Ce chapitre ne réintroduit pas les concepts. Chaque contrôle est détaillé dans son chapitre dédié.

L'objectif est de fournir une vue consolidée de tous les paramètres de durcissement abordés dans ce livre, organisés en trois niveaux actionnables. Le niveau 1 doit être complet avant d'aborder le niveau 2.

1. Niveau 1 — Socle (obligatoire, faible coût)¶

Les contrôles de ce niveau sont déployables rapidement. Ils ne nécessitent pas de matériel spécifique, pas de PKI et présentent peu de risques de perturbation.

Tout poste Windows en entreprise doit les avoir. Un parc qui ne respecte pas le niveau 1 est exposé aux attaques les plus courantes et les mieux documentées.

1.1 Protection des identifiants¶

WDigest stockait les credentials en clair en mémoire. Sa désactivation empêche les outils de type Mimikatz de récupérer des mots de passe en clair depuis lsass.exe.

RunAsPPL protège le processus LSASS en tant que processus protégé. Un attaquant avec des droits administrateur ne peut plus injecter de code dans lsass.exe.

LmCompatibilityLevel = 5 force l'utilisation de NTLMv2 et refuse les réponses LM et NTLMv1, qui sont cryptographiquement faibles.

1.2 Élévation de privilèges et surface système¶

SMBv1 est le protocole exploité par EternalBlue (WannaCry, NotPetya). Sa désactivation supprime une classe entière de vulnérabilités.

SMB Signing empêche les attaques NTLM Relay en imposant la vérification d'intégrité sur chaque paquet SMB.

NLA pour RDP exige l'authentification avant l'affichage de l'écran de connexion, ce qui bloque les attaques par force brute sur le service RDP lui-même.

1.3 Pare-feu et réseau¶

Le pare-feu local est la seule protection réseau du poste lorsqu'il est hors du périmètre d'entreprise. Bloquer SMB entrant sur les profils non-Domain empêche le mouvement latéral depuis un réseau non maîtrisé.

LLMNR et NBT-NS sont les vecteurs principaux de capture de credentials via Responder. Leur désactivation supprime cette menace sans impact fonctionnel si le DNS interne est correctement configuré.

1.4 Visibilité et audit¶

Sans journalisation, une compromission peut rester invisible pendant des semaines. Script Block Logging enregistre le contenu réel des scripts PowerShell exécutés, y compris après déobfuscation.

2. Niveau 2 — Intermédiaire (recommandé, coût modéré)¶

Les contrôles de ce niveau nécessitent davantage de préparation. Certains exigent un prérequis matériel (TPM), une infrastructure (PKI, LAPS CSE) ou une phase de test.

Le gain de sécurité est significatif et justifie l'investissement pour la majorité des parcs.

2.1 Isolation et chiffrement¶

Credential Guard isole les secrets d'authentification dans un environnement matériel inaccessible au noyau Windows. Il nécessite VBS, donc un CPU avec virtualisation et SLAT.

BitLocker protège les données au repos. Un poste volé ou perdu ne révèle pas son contenu si le volume est chiffré avec un protecteur TPM.

2.2 Contrôle applicatif et réduction de surface¶

AppLocker en mode audit permet d'inventorier les exécutables utilisés avant de passer en enforcement. Cette phase est indispensable pour éviter de bloquer des applicatifs métier légitimes.

Les règles ASR (Attack Surface Reduction) bloquent des comportements offensifs spécifiques : macros Office qui créent des processus enfants, scripts obfusqués, injection de code dans des processus système.

2.3 Gestion des comptes et authentification¶

LAPS attribue un mot de passe administrateur local unique à chaque poste. Il supprime le vecteur d'attaque où un seul mot de passe local compromis donne accès à tout le parc.

WHfB remplace le mot de passe par une clé asymétrique liée au TPM. Le credential ne circule plus sur le réseau.

2.4 Journalisation avancée¶

Module Logging enregistre les appels de cmdlets PowerShell. Combiné avec Script Block Logging (niveau 1), il donne une visibilité complète sur l'activité PowerShell.

3. Niveau 3 — Avancé (haute sécurité, coût élevé)¶

Ces contrôles s'adressent aux environnements à haute sensibilité : postes d'administration, machines de direction, systèmes traitant des données classifiées ou réglementées.

Ils nécessitent du matériel spécifique (TPM 2.0, Secured-Core), des tests approfondis de compatibilité drivers ou une PKI interne opérationnelle.

3.1 Protection matérielle et noyau¶

HVCI bloque le chargement de code non signé dans le noyau. Tout driver ancien ou non conforme peut provoquer un BSOD. La phase de test est obligatoire et doit couvrir chaque modèle de matériel du parc.

Secured-Core PC est le niveau maximal. Il combine UEFI, TPM 2.0, DRTM, VBS, HVCI et Credential Guard dans une configuration certifiée par le constructeur.

3.2 Contrôle applicatif strict et réseau¶

WDAC en enforcement est le contrôle applicatif le plus strict. Seuls les exécutables explicitement autorisés peuvent s'exécuter. Un applicatif métier oublié dans la politique sera bloqué.

CLM (Constrained Language Mode) restreint PowerShell aux seules commandes approuvées par la politique WDAC. Les scripts offensifs qui utilisent .NET ou COM ne peuvent plus s'exécuter.

3.3 Conformité et baselines¶

Les baselines CIS et STIG couvrent des centaines de paramètres. Leur import en GPO nécessite un travail d'adaptation aux spécificités du parc (applicatifs, services, rôles).

4. Matrice coût / gain¶

quadrantChart
    title Quick Wins vs Efforts majeurs
    x-axis Faible coût --> Coût élevé
    y-axis Faible gain --> Gain élevé
    quadrant-1 Efforts justifiés
    quadrant-2 Quick Wins
    quadrant-3 À déprioritiser
    quadrant-4 Coûteux pour peu
    Désactiver WDigest: [0.08, 0.82]
    Désactiver SMBv1: [0.12, 0.92]
    Désactiver LLMNR: [0.06, 0.85]
    Script Block Logging: [0.05, 0.90]
    MAPS Advanced: [0.07, 0.80]
    SMB Signing: [0.15, 0.82]
    RunAsPPL: [0.10, 0.85]
    LAPS: [0.40, 0.78]
    BitLocker: [0.45, 0.75]
    Credential Guard: [0.50, 0.88]
    Règles ASR: [0.48, 0.87]
    HVCI: [0.75, 0.90]
    WDAC enforcement: [0.85, 0.92]
    Secured-Core PC: [0.92, 0.95]
    Baseline CIS-STIG: [0.80, 0.88]
    DoH interne: [0.45, 0.45]

Le quadrant supérieur gauche (Quick Wins) regroupe les contrôles à déployer en priorité absolue. Ils offrent le meilleur rapport gain/effort.

Le quadrant supérieur droit (Efforts justifiés) contient les contrôles à fort gain mais à coût élevé. Ils sont réservés aux environnements qui en ont les moyens.

Le quadrant inférieur gauche (À déprioritiser) est vide dans cette checklist — chaque contrôle du livre a été sélectionné pour son gain de sécurité.

Le quadrant inférieur droit (Coûteux pour peu) est à éviter. Un contrôle mal adapté au contexte peut y tomber (DoH interne sur un réseau sans menace DNS en transit, par exemple).

5. Comment utiliser cette checklist¶

5.1 Ce n'est pas une liste mécanique¶

L'ordre de priorité dépend de l'environnement. Les trois niveaux sont un cadre, pas un chemin unique.

Quelques exemples de contraintes qui modifient la séquence :

• Un environnement sans Entra ID ne peut pas déployer WHfB en mode Cloud.
• Un parc sans TPM 2.0 ne peut pas activer HVCI ou BitLocker avec chiffrement matériel.
• Un parc avec des applicatifs métier non signés ne peut pas passer directement à WDAC enforcement.
• Un réseau sans serveur DNS compatible DoH ne bénéficie pas de EnableAutoDoh = 2.
• Un parc avec des DC Windows Server 2012 R2 ne peut pas utiliser WHfB en mode hybrid key trust.

5.2 Démarche recommandée¶

flowchart LR
    A[Audit initial] --> B[Niveau 1 complet]
    B --> C[Pilote Niveau 2]
    C --> D[Déploiement Niveau 2]
    D --> E[Évaluation Niveau 3]
    E --> F[Déploiement ciblé Niveau 3]
    F --> G[Revue périodique]
    G --> A

1. Auditer l'état actuel : documenter quels contrôles sont déjà en place, identifier les écarts et les dépendances manquantes.
2. Déployer le niveau 1 complet : ces contrôles sont les fondations. Ils peuvent être déployés en une seule vague de GPO.
3. Évaluer le niveau 2 avec un groupe pilote : tester sur 10-20 postes pendant 2-4 semaines avant déploiement large.
4. Planifier le niveau 3 : prévoir le budget matériel, les tests de compatibilité drivers, et le calendrier de renouvellement de parc si nécessaire.
5. Revue périodique : vérifier la conformité des postes tous les trimestres. Les postes réinstallés, les nouvelles images ou les GPO modifiées peuvent réintroduire des écarts.

5.3 Vérification rapide de conformité¶

Pour chaque niveau, une commande PowerShell simple permet de vérifier quelques contrôles clés.

Niveau 1 — vérification rapide :

# WDigest
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
    -Name UseLogonCredential -ErrorAction SilentlyContinue

# LLMNR
Get-DnsClientGlobalSetting | Select-Object UseMulticast

# Pare-feu
Get-NetFirewallProfile | Select-Object Name, Enabled

# MAPS
Get-MpPreference | Select-Object MAPSReporting

Niveau 2 — vérification rapide :

# Credential Guard
Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object SecurityServicesRunning

# BitLocker
Get-BitLockerVolume -MountPoint C: | Select-Object VolumeStatus, ProtectionStatus

# Windows LAPS (moderne)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\LAPS" `
    -ErrorAction SilentlyContinue

# LAPS legacy
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft Services\AdmPwd" `
    -Name AdmPwdEnabled -ErrorAction SilentlyContinue

5.4 Mesurer le progrès¶

Un score simple permet de suivre la progression :

Un parc avec le niveau 1 complet atteint 15/66 (23%), ce qui couvre la majorité des vecteurs d'attaque courants.

Un parc avec les niveaux 1 et 2 complets atteint 39/66 (59%), ce qui correspond à une posture de sécurité solide pour la plupart des environnements d'entreprise.