5 principes clés pour implémenter des benchmarks CIS sans stress

La sécurisation des infrastructures IT est devenue une priorité incontournable, aussi bien pour les DSI que pour les RSSI. Face à la pression réglementaire, aux exigences internes, ou simplement par volonté de structurer leur approche sécurité, les entreprises s’appuient de plus en plus sur des benchmarks reconnus. Pour rappel, un benchmark est un guide de bonnes pratiques à suivre pour sécuriser un système (OS, base de données, navigateur…). Il liste des paramètres concrets à appliquer pour réduire les risques.

Les benchmarks CIS (Center for Internet Security) sont les plus connus, organisés par catégorie (authentification, journalisation, services, cloud, serveurs…). Ils servent de référence partout. Le CIS est une organisation à but non lucratif qui publie ces guides de configuration sécurisée, largement reconnus et même repris dans certains standards du NIST ou de l’ANSSI.

La conformité et les audits ne devraient pas alourdir le maintien en condition opérationnelle

Configurer des benchmarks sans méthode ni bon outil peut vite tourner au casse-tête. Pour les équipes opérationnelles, c’est même souvent un chantier colossal, parfois perçu comme insurmontable.

Les ops ne dramatisent pas, commencer ce genre de chantier signifie souvent :

  • Gérer des infrastructures hétérogènes obligeant à cumuler plusieurs benchmarks (Linux, Windows, par version, etc.)
  • Traiter 300 à 500 points de contrôle par benchmark
  • Travailler à la main sur des milliers de machines tout en gérant des exceptions
  • Essayer de prioriser un flot massif de non-conformités remontées d’un bloc avec des solutions comme CIS-CAT. En effet, avec des outils de scan comme CIS‑CAT, le rapport généré peut devenir massif dès lors qu’un grand nombre de systèmes est visé, ce qui rend la priorisation des non-conformités chronophages. 

Pendant ce temps, les équipes doivent assurer le maintien en condition opérationnelle sans casser la prod. Dans ce contexte, la conformité devient une charge de plus, et les benchmarks finissent perçus comme une contrainte plutôt qu’un levier. Trop souvent, l’implémentation de ces benchmarks se traduit par  une avalanche de tickets et des heures passées en réunion à justifier les écarts de conformité, (autrement dit, tout ce qui s’affiche en rouge) au lieu de consacrer ce temps au renforcement concret de la sécurité.

Réussir l’implémentation de vos benchmarks CIS passe d’abord par la méthode

La stratégie choisie pour implémenter des benchmarks sera décisive dans la mise en conformité de vos infrastructures et dans l’adoption de vos équipes de l’outil utilisé. Alors, avant de configurer des benchmarks CIS, il y a une méthodologie pour ne pas foncer dans le mur :

On vous propose cinq  principes clés à retenir pour une implémentation personnalisée et maîtrisée de CIS. Ces principes sont issus de l’élaboration d’une nouvelle solution arrivant prochainement dans Rudder, notre solution Policy and benchmark compliance. Elle permettra de déployer CIS Benchmarks™ itérativement pour RHEL 9, avec flexibilité et granularité. Promis, notre solution n’ira pas à l’encontre de votre méthodologie, elle la portera.

Dashboard CIS
Tableau de bord Policy & Benchmark Compliance : un aperçu clair des résultats catégorie par catégorie. Certaines sont activées (ex : Services, Host Based Firewall), d’autres partiellement (ex : Logging and Auditing), et le reste sont désactivées.

1. Adapter la sécurité à vos environnements, pas l’inverse

Les politiques de sécurité doivent être spécifiques à un groupe de machines homogènes.
Cela signifie que chaque groupe est composé de machines partageant les mêmes cycles de vie, les mêmes usages, le même degré de criticité, OS, contraintes de mise à jour, etc.

Appliquer les mêmes règles à des serveurs critiques et à des machines aux usages très différents, c’est risqué et souvent contre-productif. 

2. L’audit, première étape obligatoire pour éviter de tout casser

L’application de benchmarks CIS ne doit jamais être brutale ou faite à l’aveugle. On commence toujours par implémenter les politiques en mode audit, c’est-à-dire en évaluant sans faire de changement. C’est parfait, ce mode vous permet de complexifier les politiques de sécurité sans risquer de casser votre prod.

Cela permet aussi d’évaluer les impacts des changements avant de corriger et d’impacter votre environnement de production.

3. Pas de Big Bang : avancer de manière itérative, par catégorie et étendre progressivement

On ne déploie pas 400 points de contrôle d’un coup. On part d’un groupe restreint de machines test puis on procède catégorie par catégorie : authentification, permissions, services réseau, etc. Cela permet d’isoler et d’identifier les effets de chaque règle, et de corriger sans impact global en cas de problème. Et surtout, on priorise selon le contexte : la gestion des firewalls sera critique dans une zone réseau exposée, les logs seront prioritaires sur les machines qui traitent des données sensibles, les autres règles pourront attendre.

Une fois validées sur les machines de test, les règles peuvent être déployées progressivement à d’autres groupes de machines.

4. Documenter les choix, c’est garder la main sur la sécuritél

Chaque infra est différente, chaque équipe a ses méthodes. Pour que la conformité reste compatible avec vos réalités terrain, il est primordial de documenter vos choix au fil du déploiement du benchmark CIS : ce qui a été appliqué, ajusté, désactivé, et pourquoi.

Ce suivi est essentiel pour évaluer si une politique de sécurité a du sens pour votre infrastructure cible, et pour documenter vos décisions.

5. Permettre les exceptions car la sécurité devrait s’adapter aux usages métiers

De manière générale, conformité ne veut pas dire rigidité. Il est normal de devoir désactiver ou adapter une/ des politiques pour des raisons métiers. Ces exceptions ne sont pas des cas particuliers : elles sont normales, attendues, et souvent indispensables pour que vos systèmes remplissent leur rôle, elles ne devraient pas causer de découragement pour vos équipes Ops.

Par exemple, dans notre solution, la gestion des exceptions est traçable, documentée et surtout, elle n’est pas un obstacle. Il ne vous suffira que de désactiver les politiques de sécurité à exclure en surchargeant au niveau du groupe ou même de la machine l’activation des politiques de sécurité ou le mode de votre souhait. 

un exemple simple de gestion exceptions web serveurs + légende
Gestion de l’exception pour un serveur web: les services web doivent rester activés. Ainsi, on désactive la politique de sécurité seulement pour ce nœud. Elle reste activée pour tous les autres nœuds.

Vers une gestion automatisée des benchmarks de sécurité

Vous avez les grandes lignes, il est temps d’agir ! Vous pouvez bien sûr utiliser les outils que vous possédez actuellement pour automatiser votre production. Bon nombre de nos utilisateurs le font déjà avec notre solution de gestion des configurations de sécurité.

Mais pour aller plus vite, de façon contrôlée, nous avons décidé d’y dédier une nouvelle solution qui arrivera dans quelques semaines : Policy and benchmark compliance

Vous souhaitez vous tenir informé de l’arrivée de la solution ?
Inscrivez-vous à notre newsletter

Partager ce post

Retour en haut
Rudder robot named Ruddy makes an announcement.

Rudder 9.0 est là ! Découvrez les nouveautés lors de notre webinar CIS Benchmarks™

Détails du module Security management

Ce module a pour objectif de garantir une sécurité et une conformité optimales pour la gestion de votre infrastructure, avec des fonctionnalités pour les entreprises telles que :

Pour en savoir plus sur ce module, consultez la page gestion de la sécurité.

Détails du module configuration & patch management

Ce module vise une performance et une fiabilité optimales pour la gestion de votre infrastructure et de vos patchs, avec des fonctionnalités pour les entreprises telles que :

Pour en savoir plus sur ce module, consultez la page gestion des configurations et des patchs.