Philosophie du hardening¶

Le hardening Windows n'est pas une collection de "tweaks". C'est une discipline d'ingénierie.

Son but est simple. Rendre la compromission plus difficile, la propagation plus coûteuse et la détection plus rapide.

Qu'est-ce que le hardening ?¶

Le hardening est l'ensemble des actions qui réduisent l'exposition inutile d'un système. On retire, limite ou encadre ce qui n'est pas requis pour le service rendu.

Sur Windows, cela touche plusieurs couches. Le firmware, le noyau, les services, le réseau, l'authentification, les applications et l'administration.

Le hardening ne remplace pas le patching. Il ne remplace pas non plus l'EDR, l'antivirus ou la supervision.

Il agit en amont. Il réduit le nombre d'occasions offertes à l'attaquant.

Le second pilier est la défense en profondeur. On n'attend pas qu'une seule mesure arrête toute l'attaque.

On empile des contrôles. Si un contrôle échoue, le suivant doit ralentir, contenir ou révéler l'activité adverse.

Les trois axes du hardening¶

Un programme de durcissement utile tient sur trois axes. Ils correspondent aux moments clés d'une compromission.

1. Réduire l'exposition¶

On cherche ici à empêcher ou décourager l'accès initial. C'est la partie la plus rentable.

Elle inclut par exemple :

• désactiver les services et rôles inutiles ;
• fermer les ports et les règles de pare-feu superflus ;
• supprimer les protocoles hérités ;
• limiter les interfaces d'administration ;
• imposer des paramètres d'authentification plus robustes.

2. Limiter la propagation¶

On part du principe qu'un poste finira tôt ou tard compromis. Le sujet devient alors le confinement.

Cette logique couvre :

• le moindre privilège ;
• la segmentation réseau ;
• la séparation des comptes d'administration ;
• la réduction des chemins de mouvement latéral ;
• le contrôle applicatif et des scripts.

3. Augmenter la détection¶

Une bonne mesure de sécurité non observable est incomplète. Il faut savoir qu'elle existe, qu'elle est encore appliquée et qu'elle est contournée ou non.

Cela implique :

• des journaux d'audit réellement utiles ;
• une centralisation des événements ;
• des règles de corrélation réalistes ;
• des contrôles de conformité réguliers ;
• une capacité de réponse sur incident.

Attaque, vecteur et défense en profondeur¶

Une attaque ne commence pas au moment où l'attaquant obtient NT AUTHORITY\SYSTEM. Elle commence bien avant.

Le plus souvent, on observe une chaîne. Vecteur initial, exécution, élévation, propagation, impact.

Le hardening casse cette chaîne à plusieurs endroits. C'est précisément l'intérêt de la défense en profondeur.

flowchart LR
    A[Objectif de l'attaquant] --> B[Vecteur initial<br/>phishing, RDP, SMB, navigateur]
    B --> C[Exécution locale]
    C --> D[Élévation de privilèges]
    D --> E[Mouvement latéral]
    E --> F[Impact<br/>vol, chiffrement, sabotage]

    subgraph L["Couches de défense en profondeur"]
        L1[Réduire l'exposition]
        L2[Durcir l'hôte]
        L3[Limiter les privilèges]
        L4[Contrôler les flux]
        L5[Auditer et détecter]
    end

    L1 -. bloque ou détourne .-> B
    L2 -. complique .-> C
    L3 -. freine .-> D
    L4 -. coupe les rebonds .-> E
    L5 -. révèle .-> C
    L5 -. révèle .-> D
    L5 -. révèle .-> E
    L5 -. révèle .-> F

Une bonne architecture de hardening n'attend pas un contrôle "miracle". Elle combine des contrôles simples, cohérents et maintenables.

Le système devient alors moins fragile. Pas parce qu'il est parfait, mais parce qu'il oblige l'attaquant à faire plus de bruit et plus d'erreurs.

Hardening et performance : trouver le bon équilibre¶

Toute mesure de sécurité a un coût. Parfois en CPU, parfois en I/O, parfois en complexité d'exploitation.

Le bon réflexe n'est pas de refuser ce coût. C'est de le mesurer et de le placer là où il produit le plus de réduction de risque.

Quelques exemples de compromis classiques sous Windows :

Le bon compromis dépend du type d'actif. Un poste bureautique, un serveur de fichiers et un contrôleur de domaine n'ont pas le même budget de risque.

Le niveau de protection doit suivre la criticité. Plus l'impact d'une compromission est élevé, plus on accepte des contraintes opérationnelles fortes.

La règle des 80/20¶

Tous les paramètres n'ont pas la même valeur. Certains donnent beaucoup de protection pour très peu d'effort.

La logique 80/20 consiste à déployer d'abord les mesures les plus rentables. Ce sont elles qui transforment rapidement la posture d'un parc.

Mesures souvent très rentables¶

Mesures utiles mais plus coûteuses¶

• déploiement de WDAC ;
• VBS sur un parc ancien hétérogène ;
• durcissement très fin de chaque rôle serveur ;
• bascules agressives vers des niveaux de conformité type STIG sans phase d'écart.

Une organisation gagne souvent plus à bien exécuter vingt réglages essentiels qu'à en définir deux cents non maintenus. Le vrai ennemi est la dérive.

Un paramètre excellent mais jamais contrôlé finit tôt ou tard par disparaître. Un paramètre simple, vérifié et documenté reste utile.

Registre, GPO et MDM : qui écrit quoi, lequel gagne ?¶

C'est une question centrale sur Windows. Le piège consiste à croire qu'il existe toujours une hiérarchie unique.

En réalité, il faut distinguer le plan de stockage et le plan de gestion. Le registre est souvent le stockage final. La GPO et le MDM sont des mécanismes de pilotage.

Le registre¶

Le registre porte énormément d'états de configuration. Beaucoup de stratégies finissent sous HKLM\Software\Policies ou HKCU\Software\Policies.

Mais pas toutes. Certaines stratégies de sécurité vivent dans la base locale de sécurité, les modèles secedit, les fichiers audit.csv, les magasins de stratégie ou des composants dédiés.

La GPO¶

Une GPO exprime une intention d'administration. Elle s'applique via des extensions côté client.

Selon le type de paramètre, elle peut :

• écrire un registry.pol ;
• appliquer un modèle de sécurité ;
• configurer l'audit avancé ;
• poser des fichiers, tâches ou préférences ;
• appeler une extension spécifique.

En environnement AD, la logique d'ordre reste celle de l'héritage des stratégies. La stratégie locale vient avant les GPO de domaine.

Le MDM¶

Le MDM pilote surtout les terminaux modernes et hybrides. Sous Windows, il passe beaucoup par les CSP et PolicyManager.

Quand un réglage MDM a un équivalent GPO dans Policy CSP, la coexistence doit être pensée explicitement. Sinon, vous introduisez de la concurrence de configuration.

Règles pratiques de lecture¶

1. Si un réglage est administré par GPO et stocké dans le registre, une modification manuelle directe du registre peut être réécrasée au prochain gpupdate.
2. Si le même réglage est administré en MDM et en GPO sans règle de priorité claire, vous créez une course de configuration.
3. Si le réglage n'est pas un simple paramètre de registre, Get-ItemProperty ne suffira pas pour l'auditer.

Exemples concrets de paramètres de hardening¶

Tous les réglages ne vivent pas au même endroit. Le tableau ci-dessous aide à raisonner correctement.

Deux conséquences pratiques suivent.

La première : plus un réglage est piloté centralement, moins une correction manuelle locale est durable.

La seconde : la méthode de vérification dépend du support réel. Registre, RSoP, secedit, rapport MDM ou journal d'événements n'offrent pas la même vérité.

Avant de commencer¶

Le hardening échoue rarement pour une raison purement technique. Il échoue surtout à cause d'un manque de préparation.

1. Faire l'inventaire¶

Recensez les versions Windows, les rôles installés, les applications critiques, les dépendances réseau et les profils d'usage. Un poste VDI, un laptop nomade et un serveur IIS ne partagent pas les mêmes contraintes.

2. Fixer une baseline de départ¶

Choisissez un référentiel. Microsoft Security Baseline, CIS, STIG ou un profil interne documenté.

L'objectif n'est pas de tout activer. L'objectif est d'avoir un point de comparaison stable.

3. Construire un environnement de test¶

Le laboratoire doit représenter le réel. Même version d'OS, mêmes agents, mêmes logiciels métiers et si possible mêmes pilotes.

Un test sur VM propre sans applicatif ne valide presque rien. Il valide surtout que Windows sait encore démarrer.

4. Déployer progressivement¶

Commencez par un pilote réduit. Puis une vague restreinte. Puis le reste du parc.

Définissez dès le départ les critères de succès. Démarrage, authentification, accès aux partages, impression, VPN, téléphonie, outils d'administration, performance perçue.

5. Préparer le retour arrière¶

Un hardening sérieux prévoit aussi son rollback. Sauvegarde de GPO, export de baseline, documentation des écarts et procédure de retrait.

6. Documenter les exceptions¶

Si un réglage casse un logiciel métier, ne le supprimez pas en silence. Documentez l'exception, sa justification, son périmètre et sa date de revue.

Le hardening est un processus. Pas un acte unique.

On mesure, on ajuste, on déploie, on surveille. Puis on recommence quand l'OS, les menaces ou les usages changent.