CIS Benchmarks et CIS Controls en production

Le CIS (Center for Internet Security) est une organisation américaine à but non lucratif connue pour deux productions distinctes : les CIS Benchmarks, qui prescrivent le durcissement de produits précis, et les CIS Controls, qui priorisent les capacités de sécurité d’une organisation. Le premier répond à « quelle configuration appliquer ? », le second à « que faut-il maîtriser avant de financer le prochain outil magique ? ».

→ Lire l’explication complète de la marmotte

CIS Benchmarks : une base de durcissement, pas une architecture

Les CIS Benchmarks sont des guides de configuration détaillés pour systèmes d’exploitation, services, équipements réseau, environnements cloud et applications. Chaque recommandation identifie un paramètre, une valeur attendue, une justification, un impact opérationnel et souvent une méthode d’audit ou de correction. Ubuntu, Windows Server, Kubernetes, PostgreSQL, Microsoft 365 ou Amazon Web Services figurent parmi les cibles couvertes.

Le compromis central est net : gagner une configuration homogène et défendable, au prix d’exceptions applicatives qu’il faut recenser, arbitrer et maintenir. La recommandation est d’adopter les Benchmarks comme socle de configuration pour les plateformes standardisées, mais jamais comme un script de déploiement aveugle. Un benchmark appliqué sans qualification coupe régulièrement des flux d’administration, des mécanismes d’authentification historiques ou des fonctions applicatives. Le serveur devient conforme sur le papier et indisponible dans la vraie vie, performance rare mais pas impossible dans les présentations commerciales.

Les Benchmarks distinguent généralement deux niveaux :

Level 1 : réglages à faible impact fonctionnel, adaptés à la plupart des environnements.
Level 2 : mesures plus restrictives, pertinentes pour des systèmes exposés, sensibles ou fortement cloisonnés, mais nécessitant une validation métier et technique.

Le niveau 1 doit être le minimum d’un socle système industrialisé. Le niveau 2 doit être choisi selon l’exposition, la sensibilité des données et la capacité d’exploitation. L’appliquer indistinctement aux postes d’administration, aux nœuds de calcul éphémères et aux serveurs de base de données produit surtout des listes d’exceptions. Une exception non expirante est une désactivation déguisée, avec davantage de tableurs.

Un Benchmark ne remplace pas une analyse de menace. Il réduit la surface d’attaque liée aux configurations par défaut, aux services inutiles, aux permissions excessives et aux protocoles obsolètes. Il ne détermine ni les frontières de confiance, ni les flux réseau légitimes, ni le modèle d’identité. Pour cela, l’architecture doit rester cohérente avec les choix décrits dans les pages architecture cyber et réseaux.

CIS Controls : prioriser les capacités avant les outils

Les CIS Controls sont un ensemble de mesures de sécurité organisationnelles et techniques. La version 8 comporte 18 contrôles, couvrant notamment l’inventaire des actifs, l’inventaire logiciel, la protection des données, la gestion des vulnérabilités, les journaux, la défense contre les logiciels malveillants, la récupération et la réponse aux incidents.

Leur valeur n’est pas l’originalité. L’inventaire des actifs n’a rien de révolutionnaire, pas plus que la journalisation ou la sauvegarde. Leur valeur est la priorisation : les CIS Controls empêchent de commencer par une plateforme d’intelligence artificielle pour la sécurité alors que personne ne sait quels comptes disposent d’un accès administrateur. Cette séquence, pourtant, continue de remplir des salons professionnels.

Les contrôles sont organisés en IG (Implementation Groups), ou groupes de mise en œuvre :

IG1 vise l’hygiène minimale : inventaire, durcissement, sauvegardes, gestion des accès et mises à jour.
IG2 ajoute des capacités de supervision, de gestion structurée des vulnérabilités et de protection des données.
IG3 cible les environnements exposés à des menaces avancées, avec une détection et une réponse renforcées.

IG1 constitue le seuil minimal pour une organisation qui exploite un système d’information connecté. Sans inventaire fiable des matériels, logiciels, comptes et données, les contrôles suivants reposent sur des angles morts. Un outil de détection ne détecte pas un hôte inconnu, sauf dans les contes où les agents de supervision poussent spontanément sur les imprimantes oubliées.

Les CIS Controls complètent les référentiels de gouvernance, notamment ceux du NIST (National Institute of Standards and Technology) ou de l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Ils ne constituent pas une certification, ni une preuve de conformité réglementaire. Ils donnent une feuille de route technique. La conformité exige ensuite de relier chaque mesure à des exigences, des preuves, un propriétaire et un cycle de revue.

Déployer un Benchmark CIS sans casser l’exploitation

La mise en œuvre commence par une matrice de portée. Chaque recommandation doit être classée en quatre catégories : applicable, non applicable, différée ou exception approuvée. Une exception doit indiquer le système concerné, la justification technique, le risque accepté, la mesure compensatoire, le responsable et une date d’expiration. Sans échéance, elle devient une propriété physique du paysage informatique.

Les prérequis sont concrets :

une version précise du système ou du produit, car un Benchmark est lié à une version et parfois à un profil particulier ;
une gestion de configuration déclarative, par exemple Ansible, Puppet ou une image système immuable ;
un environnement de validation représentatif des dépendances d’authentification, de journalisation, de sauvegarde et de supervision ;
un mécanisme de retour arrière testé ;
un inventaire des services écoutant, comptes techniques, tâches planifiées et flux réseau ;
une collecte centralisée des événements avant d’exiger davantage de journalisation locale.

Le durcissement manuel ne tient pas. Une mise à jour, un remplacement de machine ou un administrateur pressé réintroduit des valeurs par défaut. Le contrôle doit être exprimé dans le code d’infrastructure, vérifié en intégration continue et mesuré après déploiement. Une dérive détectée sans propriétaire ni délai de correction n’est qu’une décoration de tableau de bord.

Les profils CIS sont particulièrement efficaces pour les images de base, les machines virtuelles standardisées et les clusters à rôle stable. Ils sont moins directs pour les plateformes managées : on ne contrôle pas le noyau d’un service de base de données opéré par un fournisseur cloud. Dans ce cas, appliquer les recommandations relevant du tenant, des identités, des journaux, du chiffrement, du réseau et des interfaces d’administration. Marquer explicitement le reste comme hors responsabilité du client, plutôt que de simuler une conformité complète avec une feuille de calcul dopée à l’optimisme.

Exemple : durcissement contrôlé de SSH selon CIS

SSH (Secure Shell) est souvent le premier accès privilégié d’un serveur Linux. Désactiver la connexion directe du superutilisateur et limiter les tentatives d’authentification réduit l’intérêt des attaques par mot de passe et des essais automatisés. Cela ne protège pas contre le vol d’une clé privée autorisée ni contre un compte d’administration compromis.

L’exemple suivant vise une distribution utilisant OpenSSH et le répertoire /etc/ssh/sshd_config.d/. Il doit être exécuté depuis une session disposant d’un second accès de secours, par exemple une console hors bande. Ne jamais recharger le démon SSH avant la validation syntaxique : verrouiller l’unique accès distant reste une méthode étonnamment populaire de réduction de surface d’attaque.

# Créer un fragment de configuration prioritaire pour le service SSH.
sudo tee /etc/ssh/sshd_config.d/99-cis-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
MaxAuthTries 4
X11Forwarding no
AllowTcpForwarding no
EOF

# Vérifier la syntaxe avant toute prise en compte.
sudo sshd -t

# Afficher la configuration effective, incluant les fichiers chargés.
sudo sshd -T | grep -E 'permitrootlogin|maxauthtries|x11forwarding|allowtcpforwarding'

# Recharger seulement après validation et test d'une nouvelle session.
sudo systemctl reload ssh

AllowTcpForwarding no n’est pas universellement applicable. Les bastions, tunnels d’administration, accès à des réseaux privés ou certains outils de déploiement en dépendent. L’exception doit alors restreindre le transfert par compte, groupe ou règle Match, et non réactiver globalement la fonction. Le paramètre global permissif est la version réseau du passe-partout attaché à la porte coupe-feu.

Surface d’attaque et limites des référentiels CIS

Un Benchmark CIS peut introduire des risques s’il est interprété comme une vérité absolue. Désactiver un protocole ancien sans cartographier ses consommateurs peut interrompre une fédération d’identité, une supervision ou une sauvegarde. Restreindre les permissions de fichiers peut empêcher un agent de journalisation de lire ses sources. Réduire les services actifs sans comprendre les dépendances peut casser un mécanisme de reprise.

Les attaques connues contre le durcissement statique suivent aussi une logique simple : contourner le périmètre plutôt que combattre le paramètre. Un poste administrateur compromis peut modifier une politique de configuration. Un compte à privilèges peut réactiver un service. Une image de conteneur conforme ne protège pas un secret injecté dans une variable d’environnement visible par un processus compromis.

Les contre-mesures doivent donc couvrir :

la séparation des comptes d’administration et des comptes nominaux ;
l’authentification multifacteur, ou MFA (Multi-Factor Authentication), pour les accès sensibles ;
la journalisation centralisée et protégée contre l’altération locale ;
la surveillance des changements de configuration ;
la restriction des droits d’écriture sur les dépôts d’infrastructure ;
la revue des exceptions et des dérogations ;
le contrôle des images, dépendances et secrets dans la chaîne de livraison.

Le CIS ne garantit ni la confidentialité des données, ni l’absence de vulnérabilités, ni la résistance à une compromission d’identité. Ces propriétés dépendent aussi du chiffrement, de la gestion des clés, du cloisonnement réseau et de la détection. Les sujets de certificats et de clés relèvent notamment de la PKI (Public Key Infrastructure) et TLS (Transport Layer Security) ; le Benchmark ne remplace pas une politique cryptographique.

Exploitation : preuves, mises à jour et reprise

Chaque version de Benchmark doit être traitée comme une dépendance de sécurité. Une nouvelle version peut retirer une recommandation, changer une valeur attendue ou couvrir une version majeure du produit. Figer un profil sans processus de révision transforme le durcissement en archive. Le rythme raisonnable consiste à réévaluer le profil à chaque évolution majeure de plateforme et à surveiller les changements de référentiel.

Les résultats d’audit doivent être conservés avec la version du Benchmark, le profil appliqué, la date, le périmètre et les exceptions. Un score global seul est insuffisant : 95 % de conformité peut masquer l’absence de chiffrement des sauvegardes ou la présence d’un accès administrateur exposé. La mesure doit rester exploitable : écart, risque, propriétaire, échéance, preuve de correction.

La sauvegarde des configurations de référence, des exceptions et des états de conformité est indispensable. Restaurer un serveur sans restaurer ses politiques de sécurité recrée une machine fonctionnelle mais indéfinissable. La reprise doit réappliquer le socle de configuration depuis une source versionnée, puis vérifier les contrôles. Une sauvegarde qui restaure uniquement les données laisse le système revenir avec ses mauvaises habitudes, ce qui est presque humain.

🐝 Ce qui arrive si on s’en passe

Sans socle de configuration de référence, aucun état attendu n’existe pour comparer une machine : un service ajouté, une tâche planifiée ou une option SSH modifiée par un intrus ne se distinguent plus d’une variation ordinaire entre serveurs, et la recherche de persistance après incident devient une enquête sans point de comparaison. Côté SSH, laisser la connexion directe du superutilisateur fait disparaître l’attribution : les journaux indiquent seulement « root », sans relier l’action à une personne nommée. Laisser le transfert TCP actif globalement permet à tout compte compromis d’ouvrir un tunnel vers des réseaux internes : le serveur devient un relais qui contourne le filtrage réseau, tandis que le trafic apparaît comme une session SSH légitime. Sans hygiène minimale de type IG1, les comptes et hôtes inconnus restent hors du périmètre de toute revue d’accès.

🦫 Explication de la marmotte 🍫

Le Center for Internet Security publie deux types de documents. Les premiers décrivent comment régler précisément un système informatique : désactiver une fonction inutile, limiter les droits d’un compte, activer des traces d’activité ou empêcher un accès trop puissant. Ces documents servent à réduire les réglages dangereux laissés par défaut. Les seconds documents indiquent dans quel ordre une organisation doit organiser sa protection : connaître ses machines et logiciels, gérer les comptes, installer les mises à jour, conserver des sauvegardes et surveiller les incidents.

Pour appliquer ces recommandations, il faut d’abord connaître la version du système et les services réellement utilisés. Chaque réglage est ensuite testé sur un environnement séparé, car une restriction peut empêcher un logiciel ou une connexion d’administration de fonctionner. Les réglages validés sont enregistrés dans des fichiers et des outils qui peuvent les remettre automatiquement sur chaque machine.

Le résultat est contrôlé régulièrement. Quand un réglage diffère, il faut savoir si c’est une erreur ou une exception nécessaire. Une exception doit être écrite, approuvée et revue plus tard. Si elle reste sans date de fin, elle devient une faiblesse permanente.

Ces documents ne bloquent pas tous les pirates. Ils ne protègent pas une personne dont le compte a été volé, ni un logiciel contenant une faille inconnue. Il faut aussi protéger les accès, surveiller les événements, sauvegarder les données et préparer la remise en service après incident.

Pages voisines

La citent

CIS Benchmarks et CIS Controls en production

Elle cite

CIS Benchmarks et CIS Controls en production

CIS Benchmarks et CIS Controls en production

CIS Benchmarks : une base de durcissement, pas une architecture

CIS Controls : prioriser les capacités avant les outils

Déployer un Benchmark CIS sans casser l’exploitation

Exemple : durcissement contrôlé de SSH selon CIS

Surface d’attaque et limites des référentiels CIS

Exploitation : preuves, mises à jour et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines