Référentiels de sécurité Windows : SCT, CIS et STIG

L'inventaire des stratégies de groupe Windows compte des milliers de paramètres. Les choisir un par un est lent, source d'erreurs et difficile à défendre lors d'un audit. Les référentiels de sécurité (security baselines) résolvent ce problème : des ensembles de paramètres sélectionnés et versionnés, produits par des personnes qui les ont testés dans des milliers d'environnements. Votre travail consiste à en choisir un, à l'appliquer sans rien casser et à gérer les exceptions.

Les trois principaux référentiels

Les référentiels Microsoft sont volontairement sobres. CIS configure explicitement davantage de paramètres, ce qui aide les auditeurs mais produit plus de bruit dans les GPO. Les STIG sont les plus stricts et supposent un contexte gouvernemental.

Vous pouvez aussi vous appuyer sur des recommandations nationales, comme celles de l'ANSSI pour Active Directory et Windows, ou le modèle de maturité australien Essential Eight, qui recoupent bon nombre des mêmes paramètres.

Étape 1 : récupérer le Microsoft Security Compliance Toolkit

Le Security Compliance Toolkit (SCT), disponible sur le Centre de téléchargement Microsoft, contient pour chaque version de produit :

• Les paquets de référentiel : sauvegardes de GPO (par exemple MSFT Windows 11 24H2 - Computer, MSFT Windows Server 2025 - Member Server, - Domain Controller), tableurs de documentation listant chaque paramètre et sa justification, et scripts d'installation locale.
• Policy Analyzer : compare des ensembles de GPO et la stratégie locale, met en évidence les conflits et les différences.
• LGPO.exe : importe, exporte et applique la stratégie de groupe locale, pour les systèmes hors domaine et les tests.

Il existe des référentiels distincts pour Microsoft 365 Apps et Microsoft Edge, qui comptent tout autant que le référentiel de l'OS : les paramètres de macros et de compléments Office figurent parmi les contrôles les plus efficaces que vous puissiez appliquer.

Étape 2 : comparer avec l'existant

Avant d'importer quoi que ce soit, mesurez l'écart entre vos GPO actuelles et le référentiel. Sauvegardez vos GPO existantes (Backup-GPO -All -Path C:\GPOBackup), puis dans Policy Analyzer :

1. Ajoutez vos sauvegardes de GPO comme un premier ensemble de règles de stratégie.
2. Ajoutez les GPO du référentiel comme un second ensemble.
3. View / Compare : la grille affiche chaque paramètre, sa valeur dans chaque ensemble, et met en évidence les conflits (même paramètre, valeurs différentes).

Exportez la comparaison vers Excel. C'est votre liste d'écarts, et elle réserve généralement quelques surprises : d'anciennes GPO qui affaiblissent la valeur par défaut (par exemple en réactivant les hachages LM ou SMBv1), des paramètres contradictoires venant d'équipes différentes, et des paramètres que personne ne sait expliquer.

Vous pouvez aussi comparer la stratégie locale effective d'une machine en service au référentiel, ce qui révèle la dérive provoquée par des scripts, des modifications locales ou des programmes d'installation.

Étape 3 : importer et lier par anneaux

Créez de nouvelles GPO à partir des sauvegardes du référentiel plutôt que de les fusionner dans des GPO existantes, afin que le référentiel reste identifiable et puisse être mis à niveau :

Import-GPO -BackupGpoName "MSFT Windows 11 24H2 - Computer" `
  -Path "C:\SCT\Windows 11 24H2 Security Baseline\GPOs" `
  -TargetName "BL - Win11 24H2 - Computer" -CreateIfNeeded

Ensuite :

• Liez d'abord à une UO pilote, avec du matériel et des utilisateurs représentatifs.
• Gardez les GPO du référentiel non modifiées. Placez vos écarts dans une GPO distincte, de priorité supérieure, nommée d'après ce qu'elle fait, par exemple BL-Exceptions - Win11 - Legacy scanner SMB.
• Liez aux UO de production anneau par anneau, comme pour les anneaux de mise à jour.

Pour les appareils gérés par Intune, utilisez Endpoint security > Security baselines (Windows, Defender for Endpoint, Edge, Microsoft 365 Apps). Le même principe s'applique : gardez le profil de référentiel proche de la valeur par défaut et placez les exceptions dans des profils séparés.

Étape 4 : tester les paramètres qui cassent le plus souvent

La plupart des paramètres d'un référentiel passent sans incident. Ceux qui génèrent le plus souvent des tickets :

Les guides détaillés de ce site couvrent l'étape de mesure pour chacun : protocoles hérités, Credential Guard, règles ASR.

Étape 5 : ajouter ce que les référentiels vous laissent

Les référentiels sont un socle, pas l'édifice entier. Les contrôles qu'il faut généralement ajouter par-dessus :

• Windows LAPS et les restrictions d'ouverture de session du tiering d'administration (propres à la conception de vos UO et de vos groupes).
• Les règles ASR au-delà des quelques-unes incluses, et les stratégies App Control.
• Des règles de pare-feu limitées à vos réseaux d'administration.
• Les paramètres d'audit et de Sysmon et un transfert des journaux ajusté à votre SIEM.
• Les paramètres LLMNR / NetBIOS / WPAD, selon la version du référentiel.

Étape 6 : documenter les écarts et mesurer la dérive

Pour chaque paramètre que vous n'appliquez pas, ou que vous appliquez différemment, consignez : le paramètre, la valeur du référentiel, votre valeur, la raison, le risque, le contrôle compensatoire, le responsable et la date de revue. Les auditeurs le demandent, et cela oblige à se poser chaque année la question « avons-nous encore besoin de cette exception ? ».

Pour mesurer la conformité des postes :

• Policy Analyzer comparé à la stratégie locale sur un échantillon de machines.
• CIS-CAT (Lite gratuit, Pro pour les membres) pour la notation par rapport aux CIS Benchmarks.
• Des outils open source comme HardeningKitty, qui audite une machine par rapport aux listes de contrôle CIS, Microsoft et autres, et signale chaque écart.
• OSConfig sur Windows Server 2025 : appliquer et maintenir un référentiel en place, avec correction de la dérive, depuis PowerShell :

Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Default
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Format-Table Name, @{n='Status';e={$_.Compliance.Status}}, @{n='Reason';e={$_.Compliance.Reason}}

Étape 7 : suivre les nouvelles versions

Microsoft publie un nouveau référentiel à chaque version de fonctionnalités de Windows (et plus fréquemment pour Office et Edge), généralement annoncé sur le blog Microsoft Security Baselines avec la liste des changements. CIS publie de nouvelles versions de ses benchmarks à son propre rythme. Traitez chaque publication comme un petit projet : comparez-la avec la version précédente dans Policy Analyzer, lisez ce qui a changé et pourquoi, menez un pilote, puis déployez.

Liste de contrôle

• Référentiel choisi (Microsoft, CIS Level 1 ou STIG) pour l'OS, Office et Edge
• GPO actuelles comparées avec Policy Analyzer ; paramètres affaiblissants supprimés
• GPO du référentiel importées sans modification, exceptions dans des GPO séparées
• Déploiement anneau par anneau, paramètres connus pour casser mesurés en premier
• Contrôles au-delà du référentiel (LAPS, tiering, ASR, App Control, pare-feu, journalisation) ajoutés par-dessus
• Registre des écarts avec responsables et dates de revue
• Conformité mesurée (Policy Analyzer, CIS-CAT, HardeningKitty, OSConfig)
• Nouvelles versions des référentiels examinées dès leur publication

Un référentiel transforme le durcissement d'une collection d'opinions en une configuration versionnée et vérifiable. Le reste de ce site explique les contrôles individuels qui comptent le plus, et pourquoi ils valent le travail que représentent les exceptions.