Preuves benchmark CIS

Les benchmarks CIS  sont des recommandations de configuration sécurisée élaborées par consensus. CIS décrit Level 1 comme une baseline largement utilisable et Level 2 comme défense en profondeur pouvant affecter utilité ou performance. Appliquez l’un ou l’autre profil d’abord en environnement de test.

OpenFactory peut appliquer des contrôles sélectionnés et exécuter un catalogue de vérifications machine. Une exécution réussie est une preuve sur cet artefact, cette version de benchmark, ce profil et ce moment. Ce n’est pas une certification CIS, une garantie sur les paramètres de déploiement, ni une preuve de conformité à un autre cadre.

Frontière de remédiation actuelle

La fonctionnalité cis-benchmarks a un chemin de remédiation complet et épinglé :

Le chemin Ubuntu désactive ou adapte délibérément certaines règles amont pour l’environnement first-boot offline-first et image. Le manifeste généré enregistre provenance et paramètres sélectionnés. Ces adaptations rendent preuves exactes et exceptions essentielles.

security-hardening et os.security.hardening_level sont des contrôles de durcissement général séparés. Ils ne mappent pas automatiquement vers un profil CIS Level 1 ou Level 2 complet.

Exécution benchmark

Les scénarios peuvent sélectionner un catalogue et niveau exacts :

{
  "id": "ubuntu-cis-evidence",
  "name": "Ubuntu 24.04 CIS evidence",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "cis_benchmark": "CIS_Ubuntu_Linux_24.04_LTS_Benchmark_v1.0.0",
  "cis_level": "L1"
}

Le runner a aussi des catalogues pour Debian 12 et Debian 13 et un ensemble de vérifications orienté GxP interne. Un nom de catalogue n’est pas une preuve de contenu CIS officiel ou d’actualité. Confirmez provenance, licence, version et définitions de contrôle du catalogue avant usage en audit.

N’utilisez pas un benchmark OS plus ancien comme affirmation de conformité pour une version plus récente. Le resolver a actuellement des replis même famille approuvés pour certaines cibles Ubuntu et Debian plus récentes afin que les tests puissent tourner, mais la sortie doit être étiquetée comme évaluation de compatibilité contre l’ancien catalogue, pas comme conformité à un benchmark pour le SE plus récent.

Lire un résultat

Conservez au minimum :

• ID artefact et build ;
• digest image et instantané source ;
• identité et version OS de base ;
• ID benchmark/catalogue, profil et digest ;
• contrôles applicables, réussis, en échec, ignorés et non applicables ;
• sortie commande brute et horodatages ;
• provenance remédiation ;
• exceptions documentées avec propriétaire et approbation ; et
• l’environnement dans lequel les vérifications ont tourné.

Un pourcentage seul masque applicabilité et gravité. Une exécution avec zéro contrôle applicable en échec ne dit rien sur les contrôles hors catalogue, changements au déploiement, identifiants, réseaux, matériel physique ou dérive ultérieure.

Workflow sûr

1. Sélectionnez un benchmark qui correspond exactement à la version cible.
2. Relisez le profil et chaque adaptation OpenFactory.
3. Construisez l’artefact et attendez la disponibilité remédiation first-boot.
4. Exécutez l’ensemble de vérifications applicables complet dans un invité propre.
5. Investiguez les échecs ; ne les convertissez pas silencieusement en non applicable.
6. Testez comportement applicatif et opérationnel après durcissement.
7. Faites approuver les exceptions par le propriétaire sécurité responsable.
8. Relancez après tout changement paquet, recette ou déploiement.

Utilisez le guide de profil CIS  comme point de départ normatif et obtenez le benchmark applicable via votre canal de distribution CIS autorisé.