Maintien dans le temps¶

Le hardening n'est pas un état permanent. Une image de déploiement durcie peut dériver en quelques mois.

GPO d'exception non documentées, nouvelles applications qui créent des exclusions Defender, drivers installés hors processus, réinstallations sans vérification de conformité.

Le maintien dans le temps est la partie la moins visible du hardening et souvent la première à être sacrifiée quand les équipes sont sous pression.

1. Comment le hardening se dégrade¶

1.1 Les vecteurs de régression courants¶

Chaque vecteur ci-dessous est silencieux. Il ne génère ni alerte, ni ticket, ni événement.

1.2 La dérive silencieuse¶

Contrairement à une attaque, la dérive ne génère pas d'alerte. Elle se produit par accumulation de petites décisions.

Les GPO d'exception s'accumulent sans revue. Chacune a été créée pour une raison légitime, mais personne ne vérifie si la raison est toujours valable.

Les exclusions Defender s'élargissent au fil des tickets de support. Un utilisateur signale un faux positif, l'analyste ajoute une exclusion, et personne ne la revoit trois mois plus tard.

Les postes réinstallés ou remplacés ne repassent pas toujours par le processus de durcissement. L'image de référence date de l'année précédente. Les contrôles ajoutés depuis ne sont pas inclus.

2. Gouvernance des GPO de sécurité¶

2.1 Séparer les GPO de sécurité des GPO fonctionnelles¶

Les GPO de hardening ne doivent pas être modifiées pour résoudre des problèmes applicatifs.

Si une dérogation est nécessaire, créer une GPO d'exception séparée et documentée. Cette GPO doit avoir :

• Un nom explicite : EXCEPTION - Réactivation SMBv1 - Projet X.
• Une date d'expiration prévue.
• Un propriétaire nommé.
• Un lien vers le ticket de support d'origine.

2.2 Contrôle des modifications GPO¶

Les modifications de GPO doivent être traçables.

Plusieurs mécanismes complémentaires :

• Audit AD : activer l'audit des modifications d'objets AD. L'Event ID 5136 enregistre chaque modification d'un objet GPO dans Active Directory.
• Sauvegarde GPMC : sauvegarder les GPO de sécurité avant et après chaque modification.
• Versionnement : exporter les GPO dans un dépôt Git ou un système de gestion de configuration. La comparaison entre deux versions identifie précisément ce qui a changé.

2.3 Documentation minimale obligatoire¶

3. Revue périodique¶

3.1 Fréquence recommandée¶

La revue trimestrielle est la plus importante. Elle vérifie que les quick wins du niveau 1 sont toujours en place sur un échantillon de postes.

La revue semestrielle ajoute la vérification des GPO d'exception et des exclusions Defender. C'est le moment de supprimer les exceptions obsolètes.

La revue annuelle réévalue la baseline elle-même. De nouveaux contrôles sont disponibles, de nouvelles menaces sont documentées, et la baseline doit évoluer en conséquence.

3.2 Déclencheurs exceptionnels¶

En dehors du calendrier régulier, certains événements imposent une revue immédiate :

• Vulnérabilité CVE critique sur un composant Windows durcissable (SMB, RDP, NTLM, Print Spooler).
• Incident de sécurité sur le périmètre, même sans impact direct sur le hardening.
• Déploiement d'une nouvelle application qui nécessite des exclusions ou des ouvertures de ports.
• Mise à jour majeure de Windows (nouvelle version, End of Life d'une version).
• Changement d'infrastructure AD (migration OU, fusion de domaines, ajout de sites).

3.3 Ce que la revue vérifie¶

La revue couvre cinq axes :

1. Conformité des postes : exécuter le script de vérification (chapitre 19) sur un échantillon représentatif.

2. GPO d'exception actives : chaque exception est-elle toujours nécessaire ? Le ticket d'origine est-il toujours ouvert ?

3. Exclusions Defender : chaque exclusion est-elle documentée et justifiée ? Le logiciel correspondant est-il toujours installé ?

Get-MpPreference |
    Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess

1. Comptes LAPS : rotation correcte, aucun mot de passe expiré non renouvelé.

2. BitLocker : protecteurs actifs, clés de récupération en escrow dans AD ou Entra ID.

4. Mise à jour des contrôles¶

4.1 Suivre les évolutions Microsoft¶

Microsoft publie des mises à jour de baselines (Security Compliance Toolkit) à chaque nouvelle version de Windows.

Les templates ADMX sont mis à jour avec chaque version. Les templates GPO du Central Store doivent être rafraîchis pour exposer les nouveaux paramètres dans GPMC.

De nouveaux contrôles de sécurité apparaissent régulièrement : nouvelles règles ASR, nouvelles clés WHfB, nouveaux paramètres Defender, extensions de WDAC.

4.2 Suivre les nouvelles menaces¶

Les vecteurs d'attaque évoluent. Une technique non documentée il y a deux ans peut être courante et automatisée aujourd'hui.

Sources de veille recommandées :

Mapper les nouveaux vecteurs aux contrôles existants. Si un vecteur n'est couvert par aucun contrôle, évaluer l'ajout d'un nouveau paramètre de hardening.

4.3 Processus d'ajout d'un nouveau contrôle¶

L'ajout d'un contrôle de sécurité suit une séquence précise :

1. Évaluer le gain vs le coût (matrice coût/gain du chapitre 18).
2. Tester sur un groupe pilote de 10-20 postes pendant 2-4 semaines.
3. Documenter dans la GPO ou la politique Intune (nom, description, propriétaire).
4. Déployer progressivement au parc complet.
5. Mettre à jour la checklist de conformité et le script de vérification.

5. Indicateurs de santé à surveiller¶

5.1 Indicateurs opérationnels¶

Le seuil d'alerte dépend de l'environnement. L'important est de définir une baseline et de surveiller les écarts par rapport à cette baseline.

5.2 Indicateurs de détection¶

Ces indicateurs signalent soit une attaque, soit un problème de conformité :

Un pic d'événements 4625 peut signifier une tentative de brute force ou un poste mal configuré qui tente de s'authentifier avec des credentials invalides.

Des événements 3065 récurrents signalent un driver incompatible HVCI qui serait bloqué en mode enforcement.

5.3 Tableau de bord minimal¶

Même sans SIEM, un script PowerShell hebdomadaire peut collecter les indicateurs clés.

# Indicateurs Defender
$defender = Get-MpComputerStatus
[PSCustomObject]@{
    SignatureAge    = $defender.AntivirusSignatureAge
    RealTimeActive  = $defender.RealTimeProtectionEnabled
    MAPSEnabled     = $defender.MAPSReporting   # 0 = Off, 1 = Basic, 2 = Advanced
}

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

# Indicateurs pare-feu
Get-NetFirewallProfile |
    Select-Object Name, Enabled, DefaultInboundAction

Exporter les résultats en CSV. Charger dans Excel ou Power BI pour un suivi visuel.

L'important n'est pas la sophistication du tableau de bord. C'est d'avoir une baseline pour détecter les anomalies par rapport à la semaine précédente.

6. Tableau récapitulatif et synthèse du livre¶

flowchart LR
    A[Déploiement initial\nniveaux 1-2-3] --> B[Monitoring\nhebdomadaire]
    B --> C[Revue\ntrimestrielle]
    C --> D{Écarts ?}
    D -- Oui --> E[Correction]
    E --> B
    D -- Non --> F[Revue\nsemestrielle]
    F --> G[Supprimer exceptions\nobsolètes]
    G --> H[Revue\nannuelle]
    H --> I[Mise à jour\nbaseline]
    I --> A

Ce livre a suivi une progression logique.

La philosophie du hardening (chapitre 1) pose le cadre. Les baselines (chapitre 2) fournissent le point de départ. La protection des identifiants, le contrôle applicatif, le durcissement réseau et la visibilité (chapitres 3 à 17) couvrent les surfaces d'attaque concrètes. La checklist (chapitre 18) consolide les contrôles. L'audit de conformité (chapitre 19) vérifie la réalité.

Ce dernier chapitre ferme la boucle. Le hardening est une démarche continue. Chaque contrôle est une décision qui doit être maintenue, vérifiée et actualisée au rythme des menaces et du parc.