Appliquez le STIG SLES 15 en toute sécurité avec OpenSCAP

Utilisez le profil DISA STIG pris en charge par SUSE pour SLES 15, analysez le serveur avec OpenSCAP et corrigez les problèmes uniquement après avoir vérifié la configuration de référence sur un système de test. Par exemple, prenons un administrateur fictif nommé Alex qui prépare un serveur SLES 15 pour un service réglementé : Alex utilise la procédure ci-dessous pour identifier les anomalies, tester les modifications et rassembler les preuves, mais ne considère pas une analyse automatisée concluante comme une validation de conformité.

Les commandes sont conformes aux recommandations STIG actuelles de SUSE pour SLES 15. Le contenu du profil peut évoluer suite aux mises à jour des paquets et aux nouvelles versions des benchmarks DISA ; il est donc impératif de vérifier la version applicable et la configuration système requise avant d'utiliser cette procédure. Les captures d'écran du terminal illustrent les commandes et ne correspondent pas aux résultats d'analyse réels.

1. Confirmer la cible et le point de référence actuel

Commencez par consigner le Service Pack SLES de l'hôte, sa finalité, son rôle réseau et ses applications. Alex note les services qui doivent rester disponibles, le mode de connexion des administrateurs et la méthode de récupération en cas d'interruption d'accès suite à une modification de la sécurité. Cette précision est importante : un hôte de base de données et un serveur généraliste peuvent avoir des exceptions approuvées différentes, même s'ils utilisent le même profil STIG du système d'exploitation.

Vérifiez la version installée avant de sélectionner du contenu :

cat /etc/os-release
hostnamectl

Téléchargez ensuite la checklist STIG SLES 15 et la révision de référence correspondantes sur la page de téléchargement officielle DISA STIG . Assurez-vous que la checklist corresponde à votre famille de systèmes et suivez les instructions d'évaluation de votre organisation. La documentation SUSE prend en charge le profil SCAP « DISA STIG pour SUSE Linux Enterprise 15 », mais cela ne suffit pas à déterminer la version requise par votre autorité ni à certifier un système hôte.

2. Installez et vérifiez le contenu SCAP

Sur un système SLES enregistré ayant accès aux référentiels appropriés, installez les utilitaires en ligne de commande OpenSCAP et le contenu du guide de sécurité SCAP :

sudo zypper install openscap-utils scap-security-guide

Les noms des paquets et l'emplacement des flux de données SLES 15 ci-dessous sont documentés dans le guide de renforcement de la sécurité OpenSCAP de SUSE et dans la procédure STIG de SUSE . Les dépôts de paquets et les révisions de profils peuvent varier selon le Service Pack et le niveau de mise à jour. Listez les flux de données installés et examinez le fichier candidat plutôt que de supposer un nom de fichier ou un profil.

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Vérifiez que le flux de données SLES 15 est présent et que la liste des profils l'inclut stig. Si le fichier ou le profil est manquant, arrêtez l'exécution et résolvez l'incompatibilité de paquet ou de dépôt ; n'utilisez pas le benchmark d'un autre système d'exploitation.

3. Établir une situation de référence, puis tester les mesures correctives

Créez un répertoire de preuves protégé avant de générer des rapports. Effectuez d'abord une analyse, sans modifier les paramètres système :

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/baseline.xml \
  --report /root/stig-review/baseline.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Ouvrez le rapport HTML et examinez chaque résultat, en particulier les échecs, les erreurs et les règles qui n'ont pas pu être vérifiées. Conservez le fichier XML et le rapport comme preuves de configuration sensibles. Ils peuvent révéler des informations sur l'hôte et son niveau de sécurité ; par conséquent, ne les stockez ou ne les transmettez que par des canaux autorisés.

Ensuite, clonez ou créez un instantané du serveur dans un environnement hors production. Validez le comportement des applications, les accès, le réseau, la surveillance et la récupération avant d'appliquer les modifications automatisées. SUSE recommande aux administrateurs de tester la correction hors production au préalable, car elle modifie la configuration système. Sur l'hôte de test, la méthode documentée à la volée est la suivante :

sudo oscap xccdf eval --remediate \
  --profile stig \
  --results /root/stig-review/remediation.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Le résultat généré peut inclure un résultat de test avant et après correction. Une règle marquée fixedindique que sa correction automatique a été appliquée et que la règle a réussi l'évaluation ; une errorrègle marquée signifie que la correction a échoué. Aucun de ces statuts ne remplace les tests opérationnels ni l'examen de l'exigence sous-jacente.

4. Procéder à une nouvelle analyse, résoudre les exceptions et conserver les preuves.

Après avoir examiné le comportement du test, exécutez une analyse distincte avec de nouveaux chemins de sortie. Une évaluation basée uniquement sur l'analyse permet de distinguer l'état actuel de l'exécution de correction :

sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/final.xml \
  --report /root/stig-review/final.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Ne vous attendez pas à ce que toutes les règles soient automatiquement corrigibles. Analysez les défaillances en les comparant au texte complet de vérification et de correction de la règle, dans la version exacte de la liste de contrôle DISA sélectionnée pour le système. Certaines règles nécessitent une décision délibérée du responsable du service, une configuration spécifique au site ou des preuves manuelles. Si une règle est inapplicable ou impossible à respecter, documentez la justification et les mesures compensatoires via la procédure d'exception formelle de l'organisation ; la modification ou l'adaptation d'un profil ne suffit pas à elle seule à satisfaire une exigence.

Pour la vérification des listes de contrôle, SUSE indique comment exporter un fichier XCCDF importable dans DISA STIG Viewer. Générez-le avec l'option prévue à cet effet, puis importez-le dans le visualiseur en suivant les instructions d'utilisation.

sudo oscap xccdf eval \
  --profile stig \
  --stig-viewer /root/stig-review/results_stig.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Le dossier de preuves d'Alex concernant le serveur fictif contient l'identifiant de l'hôte et du Service Pack, la révision du benchmark, la version du contenu SCAP, la date d'analyse, les rapports de référence et finaux, les actions correctives, les vérifications manuelles et les exceptions approuvées. Veuillez confirmer que les fichiers existent et restent accessibles uniquement aux examinateurs autorisés.

sudo ls -l /root/stig-review

Avant de déclarer la tâche terminée, vérifiez que le rapport final reflète une analyse effectuée après les modifications, que chaque anomalie restante est associée à un responsable et à une procédure, et que les services requis du serveur fonctionnent toujours. La conformité STIG est un état évalué, lié à un référentiel et à un périmètre système spécifiques ; OpenSCAP prend en charge cette évaluation, mais n'accorde pas d'accréditation et ne garantit pas que toutes les exigences du site ont été respectées.

Sources

• SUSE : Sécurisation de SUSE Linux Enterprise avec STIG
• SUSE : Sécurisation de SLES avec OpenSCAP
• DISA : Téléchargements STIG