Un système fraîchement installé n'est pas un système sûr. Les configurations par défaut privilégient la compatibilité et la facilité d'usage : services superflus, protocoles anciens, journalisation minimale, comptes trop permissifs. Les CIS Benchmarks répondent à ce problème : ce sont des guides de configuration détaillés, publiés par le Center for Internet Security, qui indiquent quoi modifier, pourquoi, et comment vérifier que c'est fait. Cet article explique ce qu'ils sont, pourquoi les adopter et comment auditer un système d'exploitation ou une application avec cette méthode.
Le CIS, c'est quoi ?
Le Center for Internet Security (CIS) est une organisation à but non lucratif consacrée à la cybersécurité. Elle publie deux familles de référentiels souvent confondues :
- les CIS Controls : un cadre de bonnes pratiques organisationnelles (inventaire des actifs, gestion des vulnérabilités, journalisation, sauvegardes, etc.), qui répond à la question « que faut-il faire ? » ;
- les CIS Benchmarks : des guides de configuration par technologie, qui répondent à la question « comment configurer ce produit précis ? ».
Les Benchmarks sont élaborés par consensus, avec des experts, des éditeurs et des praticiens. Ils couvrent des dizaines de familles de produits : systèmes d'exploitation (Windows, distributions Linux, macOS), services cloud, équipements réseau, bases de données, serveurs web, conteneurs et orchestrateurs. Les documents PDF sont téléchargeables gratuitement sur le site officiel du CIS ; certains formats destinés à l'automatisation et les outils d'évaluation avancés relèvent de l'adhésion CIS SecureSuite.
À retenir : les CIS Controls fixent la stratégie, les CIS Benchmarks fournissent les réglages concrets, produit par produit et version par version.
Pourquoi utiliser les CIS Benchmarks ?
Concevoir soi-même une configuration sécurisée pour chaque produit est long et sujet à l'erreur. Un référentiel reconnu apporte plusieurs avantages.
| Avantage | Ce que cela change |
|---|---|
| Base commune et reconnue | Un langage partagé entre exploitation, sécurité et auditeurs |
| Recommandations justifiées | Chaque point explique le risque traité et l'impact possible |
| Vérifiable | Chaque recommandation comprend une procédure d'audit et une procédure de correction |
| Mesurable | Un taux de conformité peut être suivi dans le temps |
| Utile en conformité | Un référentiel externe soutient les démarches ISO 27001, PCI DSS ou les exigences clients |
Le durcissement réduit la surface d'attaque : moins de services exposés, moins de fonctionnalités inutiles, moins de marge pour l'exploitation d'une faille. Il ne remplace pas la correction des vulnérabilités (voir la base de vulnérabilités CVE et l'article sur le score CVSS), mais il limite l'impact d'une faille encore non corrigée.
Comprendre la structure d'un Benchmark
Un Benchmark est organisé en sections thématiques (comptes et authentification, journalisation, services réseau, système de fichiers, etc.). Chaque recommandation contient en général :
- une description et sa justification (« rationale ») ;
- l'impact potentiel sur le fonctionnement ;
- une procédure d'audit ;
- une procédure de remédiation ;
- un profil d'application.
Les profils Level 1 et Level 2
- Level 1 : réglages de base, avec peu d'effets de bord, applicables à la plupart des environnements. C'est le point de départ.
- Level 2 : réglages plus stricts pour les environnements à forte exigence de sécurité. Ils peuvent réduire des fonctionnalités et demandent des tests préalables.
Selon les produits, d'autres profils existent (par exemple serveur ou poste de travail, contrôleur de domaine ou serveur membre). Le bon profil se choisit en fonction du rôle de la machine.
À retenir : commencer par le Level 1 sur un périmètre pilote, mesurer, puis étendre. Appliquer un Level 2 sans test est la meilleure façon de casser une application métier.
Comment auditer un système d'exploitation
Une démarche fiable suit toujours les mêmes étapes.
- Inventorier les systèmes et identifier la version exacte : un Benchmark est propre à un produit et à une version.
- Choisir le Benchmark et le profil correspondant au rôle de la machine.
- Mesurer l'écart : chaque recommandation est évaluée en conforme, non conforme ou non applicable.
- Documenter les exceptions : une recommandation non appliquée pour une raison métier doit être justifiée, validée et datée.
- Corriger, puis contrôler à nouveau.
Audit manuel : quelques exemples
Sous Linux, l'état de la configuration SSH peut se vérifier avec la configuration effective :
sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|x11forwarding|maxauthtries'
sysctl net.ipv4.ip_forward net.ipv4.conf.all.accept_redirects
Sous Windows, quelques commandes permettent de relever la politique de mots de passe et l'audit :
net accounts
auditpol /get /category:*
Get-SmbServerConfiguration | Select EnableSMB1Protocol, RequireSecuritySignature
Ces contrôles ponctuels sont utiles pour comprendre, mais impraticables sur un parc entier.
Audit automatisé
Pour un parc, l'évaluation doit être automatisée :
- CIS-CAT (Lite ou Pro) : l'outil d'évaluation du CIS, qui compare une machine à un Benchmark et produit un rapport de conformité ;
- OpenSCAP : un scanneur libre s'appuyant sur le standard SCAP, décrit sur le site du projet OpenSCAP, avec des profils de sécurité disponibles pour de nombreuses distributions Linux ;
- Stratégies de groupe (GPO), Intune ou outils de gestion de configuration (Ansible, Puppet, etc.) pour appliquer les réglages de façon reproductible sous Windows et Linux.
Il faut vérifier que le contenu utilisé correspond bien à la version du Benchmark visée : certains profils communautaires reprennent les recommandations sans en être la publication officielle.
Comment durcir une application
Le durcissement ne se limite pas à l'OS. Les Benchmarks couvrent aussi de nombreux composants applicatifs : serveurs web comme NGINX ou Apache, bases de données comme PostgreSQL ou MySQL, Docker, Kubernetes, ainsi que des environnements cloud et des suites bureautiques en ligne. Les grands principes se retrouvent d'un produit à l'autre :
- Réduire l'exposition : désactiver modules, fonctions et comptes par défaut inutiles, fermer les ports non nécessaires (voir la référence ports et protocoles) ;
- Chiffrer les échanges : TLS à jour, suites de chiffrement modernes, anciens protocoles désactivés ;
- Authentification et moindre privilège : pas de compte partagé, pas de mot de passe par défaut, droits limités au strict nécessaire ;
- Journaliser : traces d'authentification et d'administration envoyées vers un point central ;
- Masquer les informations inutiles : bannières de version, pages d'erreur détaillées.
Exemple simple pour NGINX, qui va dans le sens de plusieurs recommandations de ce type :
server_tokens off;
ssl_protocols TLSv1.2 TLSv1.3;
add_header X-Content-Type-Options "nosniff" always;
Attention : tester toute modification sur un environnement de préproduction. Un durcissement mal évalué peut interrompre un service ; le bon réflexe est de sauvegarder la configuration avant de corriger.
Bonnes pratiques de mise en œuvre
- Automatiser le durcissement dans les images de référence (« golden images ») et l'infrastructure as code, plutôt que de corriger machine par machine.
- Ne pas appliquer aveuglément : adapter le profil au contexte, et consigner chaque écart accepté.
- Auditer régulièrement : la dérive de configuration est inévitable (mises à jour, interventions manuelles).
- Suivre les versions : les Benchmarks évoluent avec les produits ; un référentiel périmé perd de sa valeur.
- Compléter avec d'autres sources : les référentiels d'éditeurs comme les bases de configuration de sécurité Microsoft ou les guides de l'ANSSI offrent une lecture complémentaire, utile pour arbitrer.
- Relier le durcissement à la gestion des vulnérabilités : configuration sûre et correctifs à jour vont ensemble.
En résumé
Les CIS Benchmarks transforment l'exigence vague « sécuriser ses systèmes » en une liste de réglages précis, justifiés et vérifiables. La méthode tient en quatre gestes : choisir le bon Benchmark et le bon profil, mesurer l'écart, corriger de façon contrôlée, puis auditer en continu. Commencer par un périmètre limité en Level 1, automatiser dès que possible et documenter les exceptions suffit déjà à relever nettement le niveau de sécurité d'un parc.