Baselines de sécurité¶

Une baseline de sécurité n'est pas un dogme. C'est un point de départ documenté.

Elle sert à éviter deux extrêmes. Improviser chaque réglage à la main, ou appliquer un référentiel sans comprendre ce qu'il casse.

Qu'est-ce qu'une baseline ?¶

Une baseline est un ensemble cohérent de paramètres recommandés. Elle vise à établir un niveau de configuration de référence.

Dans le monde Windows, cela prend souvent la forme de :

• sauvegardes de GPO ;
• feuilles de calcul de réglages ;
• rapports HTML ;
• règles d'audit ou de sécurité ;
• contenu exploitable par des outils de conformité.

Le rôle d'une baseline est double. Guider la configuration initiale et servir d'étalon pour la vérification continue.

Une bonne baseline répond à trois questions :

1. Quel paramètre doit être configuré ?
2. À quelle valeur exacte ?
3. Pourquoi ce choix réduit-il le risque ?

Ce qu'une baseline ne fait pas¶

Une baseline ne remplace pas l'analyse de risque. Elle ne connaît ni vos logiciels métier, ni vos contraintes d'interopérabilité.

Elle ne remplace pas non plus le maintien en condition de sécurité. Un système parfaitement aligné hier peut être obsolète demain.

Enfin, une baseline ne suffit pas à elle seule contre un attaquant déterminé. Elle réduit le risque, mais ne constitue ni détection, ni réponse à incident.

CIS Benchmarks¶

Le Center for Internet Security publie des benchmarks de configuration sécurisée, construits de manière communautaire et multi-éditeurs. Ils sont très utilisés comme base d'audit.

Leur force est la standardisation. Leur faiblesse est qu'ils restent génériques par nature.

Niveaux L1 et L2¶

Le modèle CIS distingue classiquement deux niveaux. La différence est essentielle pour éviter de tout appliquer sans discernement.

Téléchargement et structure¶

Les benchmarks CIS existent généralement en PDF. Selon le produit et l'offre, on peut aussi disposer de formats plus directement exploitables pour l'évaluation et la remédiation.

Une recommandation CIS comporte souvent :

• un identifiant ;
• un niveau L1 ou L2 ;
• une description ;
• une justification ;
• une méthode d'audit ;
• une remédiation ;
• un impact éventuel ;
• des références.

Quand CIS est le plus utile¶

CIS est très adapté si vous voulez :

• un langage commun avec les auditeurs ;
• un niveau de rigueur reproductible ;
• un référentiel indépendant de l'éditeur ;
• une base de conformité sur plusieurs technologies.

Microsoft Security Baseline¶

La baseline Microsoft est la référence la plus naturelle pour un parc Windows. Elle est publiée dans le Security Compliance Toolkit, souvent abrégé SCT ou MSCT.

Microsoft la décrit comme un ensemble de paramètres recommandés, établi à partir des équipes sécurité, des équipes produit, de partenaires et de clients. Le format est pensé pour un usage opérationnel.

Ce que contient le toolkit¶

Le téléchargement Microsoft inclut typiquement :

• des archives de baseline par version de Windows ;
• LGPO.exe ;
• Policy Analyzer ;
• SetObjectSecurity ;
• des documents d'accompagnement ;
• des sauvegardes de GPO exploitables.

Philosophie Microsoft¶

Microsoft ne cherche pas à tout verrouiller. La baseline vise plutôt les environnements bien administrés où les utilisateurs standards n'ont pas de droits d'administration.

Le principe est pragmatique : imposer un réglage seulement s'il réduit un risque actuel sans provoquer un coût opérationnel supérieur au risque traité.

Formats à retenir¶

Quand vous extrayez une baseline Microsoft, vous rencontrez souvent :

• un dossier GPOs contenant des sauvegardes de GPO ;
• des rapports HTML lisibles ;
• une feuille Excel détaillant les réglages ;
• des scripts d'import AD ou local.

Où elle excelle¶

Si votre besoin principal est de durcir Windows sans réinventer chaque valeur, c'est souvent la baseline la plus rentable. Elle est particulièrement pertinente pour les postes, les serveurs membres et les contrôleurs de domaine.

STIG¶

STIG signifie Security Technical Implementation Guide. Le corpus est publié dans l'écosystème DoD/DISA.

Le niveau de rigueur y est élevé. Le positionnement est très orienté conformité forte et environnements sensibles.

Formats et outillage¶

Dans la pratique, le monde STIG s'appuie sur plusieurs types d'artefacts :

• du contenu STIG en XCCDF ;
• des résultats importables issus de SCAP ou XCCDF ;
• des checklists ;
• l'outil STIG Viewer.

Le guide utilisateur de STIG Viewer 3.x confirme notamment :

• le chargement de fichiers STIG XCCDF ;
• l'import de résultats SCAP ou XCCDF dans une checklist ;
• l'export de données de checklist ;
• le tri par Rule ID, STIG ID, sévérité et références CCI.

CKL, CKLB et vocabulaire de terrain¶

Sur le terrain, beaucoup d'équipes parlent encore de CKL. Il s'agit du terme historique le plus répandu pour la checklist STIG.

Avec STIG Viewer 3, les mécanismes ont évolué. Vous pouvez rencontrer CKLB selon la version de l'outil, tout en conservant la logique checklist côté exploitation.

Quand STIG est pertinent¶

STIG devient intéressant quand vous devez :

• répondre à une exigence de conformité forte ;
• travailler avec des environnements très réglementés ;
• aligner un audit technique sur un corpus extrêmement prescriptif ;
• industrialiser des contrôles via des formats normalisés.

ANSSI¶

La référence ANSSI est particulière. Ce n'est pas, à ce jour, une baseline Windows monolithique exactement équivalente à CIS, MSCT ou STIG.

L'ANSSI publie surtout un corpus de guides, de notes techniques et de fiches pratiques. Pour Windows, il faut donc raisonner par assemblage de références utiles.

Comment lire la ligne ANSSI¶

Vous y trouverez notamment :

• des guides sur l'administration sécurisée ;
• des guides Windows 10 sur la virtualisation de sécurité et la confidentialité ;
• des recommandations sur les restrictions logicielles ;
• des fiches Windows Server récentes de type "Les Essentiels".

Recommandations R1 à R5¶

L'ANSSI travaille souvent par recommandations numérotées. Le guide sur l'administration sécurisée illustre bien cette approche.

Les cinq premières recommandations y portent par exemple sur :

Cette logique est très utile. Elle rappelle qu'une posture Windows robuste ne repose pas seulement sur des clés de registre.

Ce que cela change pour un administrateur Windows¶

Avec l'ANSSI, vous traduisez plus souvent les recommandations en contrôles techniques. Le travail d'implémentation est donc plus manuel.

Cela ne rend pas la référence moins sérieuse. Cela signifie simplement qu'elle est moins "packagée" sous forme d'artefacts GPO prêts à importer.

Tableau comparatif¶

Comparer les quatre familles aide à choisir le bon point de départ. Le meilleur référentiel n'est pas toujours le plus strict.

Lecture pratique du tableau¶

Si vous gérez avant tout Windows, démarrez souvent par Microsoft Security Baseline. Si l'audit ou le multi-technos dominent, CIS devient très utile.

Si la conformité impose un niveau très dur, STIG est pertinent. Si vous construisez une posture d'administration robuste et contextualisée, ANSSI complète très bien le reste.

Comment lire une baseline : exemple avec "Disable SMBv1"¶

Un bon exemple de lecture est la désactivation de SMBv1. C'est un paramètre simple en apparence, mais révélateur de la méthode.

Côté CIS¶

Dans le benchmark CIS Windows, la recommandation apparaît comme un contrôle explicite. Selon les versions, la numérotation peut bouger.

L'intention reste stable :

• Configure SMB v1 client driver doit être réglé sur Enabled: Disable driver ;
• Configure SMB v1 server doit être réglé sur Disabled.

Le benchmark vous donne ensuite :

• la justification ;
• la méthode d'audit ;
• la remédiation ;
• le niveau L1 ou L2.

Côté Microsoft Security Baseline¶

Dans la baseline Microsoft Windows 11 24H2 vérifiée pour ce chapitre, les rapports GPO montrent explicitement :

• Configure SMB v1 client driver = Enabled avec Configure MrxSmb10 driver = Disable driver (recommended) ;
• Configure SMB v1 server = Disabled.

On voit aussi d'autres réglages SMB modernes. Par exemple les versions minimales et maximales du protocole et plusieurs options d'audit.

Ce qu'il faut lire réellement¶

Quand vous lisez une baseline, ne vous arrêtez pas au seul titre. Suivez cette grille :

1. version exacte de l'OS ciblé ;
2. profil ou niveau (L1, L2, poste, serveur, DC) ;
3. valeur attendue ;
4. impact métier possible ;
5. méthode de contrôle ;
6. méthode de remédiation.

Importer une Microsoft Security Baseline via LGPO.exe¶

L'import local d'une baseline Microsoft repose sur des sauvegardes de GPO et sur LGPO.exe. Il faut distinguer le primitive unitaire et le script officiel.

Prérequis¶

• extraire l'archive de baseline correspondant exactement à votre OS ;
• disposer de LGPO.exe ;
• ouvrir une console élevée avec ++ctrl++ + ++shift++ + ++enter++ ;
• travailler sur un poste ou une VM de test.

La commande exacte d'import d'un GPO backup¶

Dans le script officiel Baseline-LocalInstall.ps1 du package Windows 11 24H2, Microsoft appelle LGPO.exe ainsi :

LGPO.exe /v /g ..\GPOs\$gpoGuid

Cette ligne importe un dossier de sauvegarde GPO unique. Dans un usage manuel, il faut donc fournir un chemin concret.

Exemple concret sur le GPO "Computer"¶

Dans le package Microsoft vérifié pour ce chapitre, le GPO MSFT Windows 11 24H2 - Computer correspond au GUID suivant :

LGPO.exe /v /g "C:\Baselines\Windows 11 v24H2 Security Baseline\GPOs\{DAD42DA1-8499-42FE-A1CD-9E39196D8B98}"

Extension côté client¶

Le même script active d'abord plusieurs extensions de traitement local :

LGPO.exe /v /e mitigation /e audit /e zone /e DGVBS

Sans cela, certains réglages ne seront pas pris en compte correctement. Il faut donc éviter un import "à moitié" improvisé.

Ce qu'il faut retenir¶

Pour importer un GPO local isolé, LGPO.exe /g suffit. Pour appliquer l'ensemble de la baseline Microsoft, le plus propre est souvent d'utiliser le script fourni par Microsoft, qui boucle sur plusieurs GPOs.

Vérifier un paramètre baseline avec PowerShell¶

Le moyen le plus rapide de contrôler un paramètre stocké dans le registre est Get-ItemProperty. L'exemple SMBv1 serveur est idéal pour cela.

Vérification simple¶

Get-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
  -Name SMB1 `
  -ErrorAction SilentlyContinue | Select-Object SMB1

Interprétation¶

• SMB1 = 0 : le protocole serveur SMBv1 est explicitement désactivé ;
• SMB1 = 1 : il est explicitement activé ;
• aucune valeur retournée : l'état par défaut n'est pas écrit explicitement dans la clé.

Variante compacte¶

(Get-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
  -Name SMB1 `
  -ErrorAction SilentlyContinue).SMB1

Ce que cette méthode ne couvre pas¶

Tous les paramètres de baseline ne vivent pas dans le registre. Pour les audits avancés, certains droits utilisateurs, des objets de sécurité ou certains réglages MDM, il faut compléter.

Les outils complémentaires sont souvent :

• rsop.msc ;
• secedit /export ;
• les rapports GPO ;
• le rapport de diagnostic MDM ;
• Policy Analyzer.

Pièges courants et gestion des exceptions¶

Le piège numéro un est simple. Confondre "plus strict" et "meilleur".

Une baseline trop agressive peut casser :

• un logiciel métier ancien ;
• un agent d'administration ;
• une intégration SMB ou RDP héritée ;
• des scripts internes ;
• des pilotes ou composants VBS incompatibles.

Exception acceptable ou dette cachée ?¶

Une exception peut être légitime. Elle devient une dette dangereuse si elle n'est ni tracée, ni revue.

Une exception sérieuse doit comporter au minimum :

• le réglage concerné ;
• le référentiel source ;
• la raison métier ;
• l'actif ou le groupe concerné ;
• la mesure compensatoire ;
• la date de prochaine revue.

Mauvaises pratiques fréquentes¶

• désactiver un contrôle "temporairement" sans ticket ni échéance ;
• modifier localement un poste de production sans reporter l'écart dans la source d'autorité ;
• mélanger GPO, MDM et corrections manuelles pour le même réglage ;
• valider une baseline sur une VM propre et conclure qu'elle est prête pour tout le parc.

Règle de discipline¶

Une exception documentée vaut mieux qu'un faux sentiment de conformité. L'audit doit montrer la réalité du risque, pas une image idéale mais fausse.

Workflow recommandé¶

Le bon workflow n'est pas "télécharger puis appliquer". Il est plus simple et plus robuste que cela.

flowchart LR
    A[Choisir une baseline] --> B[Test en laboratoire]
    B --> C[Pilote limité]
    C --> D{Écart ou casse ?}
    D -- Non --> E[Déploiement progressif]
    D -- Oui --> F[Exception documentée]
    F --> G[Mesure compensatoire]
    G --> H[Revue de l'exception]
    H --> E
    E --> I[Contrôle de conformité continu]

Séquence pratique¶

1. Choisir la baseline adaptée au rôle et à la version de l'OS.
2. Tester sur un périmètre représentatif.
3. Documenter les exceptions dès le premier écart.
4. Déployer par vagues.
5. Vérifier la conformité réelle, pas seulement l'intention.