SLES 15 STIG sicher mit OpenSCAP auftragen

Verwenden Sie das von SUSE unterstützte DISA STIG-Profil für SLES 15, scannen Sie den Server mit OpenSCAP und beheben Sie Probleme erst nach Überprüfung der Baseline auf einem Testsystem. Stellen Sie sich beispielsweise einen fiktiven Administrator namens Alex vor, der einen SLES-15-Server für einen regulierten Dienst vorbereitet: Alex verwendet den unten beschriebenen Workflow, um Ergebnisse zu identifizieren, Änderungen zu testen und Nachweise zu sammeln. Ein fehlerfreier automatisierter Scan wird jedoch nicht als Konformitätsbestätigung gewertet.

Die Befehle entsprechen den aktuellen STIG-Richtlinien von SUSE für SLES 15. Der Profilinhalt kann sich mit Paketaktualisierungen und DISA-Benchmark-Releases ändern. Prüfen Sie daher vor der Anwendung dieses Verfahrens die jeweils gültige Version und die systemspezifischen Anforderungen. Die Terminalabbildungen veranschaulichen die Befehle und zeigen nicht die tatsächliche Scan-Ausgabe.

1. Zielwert und aktuellen Benchmark bestätigen.

Beginnen Sie mit der Erfassung des SLES-Service-Packs, des Zwecks, der Netzwerkrolle und der Anwendungen des Hosts. Alex notiert, welche Dienste verfügbar bleiben müssen, wie sich Administratoren verbinden und wie die Wiederherstellung erfolgt, falls eine Sicherheitsmaßnahme den Zugriff unterbricht. Dieser Umfang ist wichtig: Ein Datenbank-Host und ein Allzweckserver können unterschiedliche Ausnahmen haben, selbst wenn beide dasselbe STIG-Profil des Betriebssystems verwenden.

Prüfen Sie die installierte Version, bevor Sie Inhalte auswählen:

cat /etc/os-release
hostnamectl

Laden Sie anschließend die entsprechende SLES 15 STIG-Checkliste und die Benchmark-Revision von der offiziellen DISA STIG-Downloadseite herunter . Ordnen Sie die Checkliste Ihrer Systemfamilie zu und befolgen Sie die Anweisungen Ihrer Organisation zur Bewertung. SUSE dokumentiert die Unterstützung für das SCAP-Profil „DISA STIG for SUSE Linux Enterprise 15“, dies allein reicht jedoch nicht aus, um festzulegen, welche Version Ihre Behörde benötigt oder für die Zertifizierung eines Hosts erforderlich ist.

2. Installieren und überprüfen Sie den SCAP-Inhalt.

Installieren Sie auf einem registrierten SLES-System mit Zugriff auf die entsprechenden Repositories die OpenSCAP-Befehlszeilenprogramme und die Inhalte des SCAP Security Guide:

sudo zypper install openscap-utils scap-security-guide

Die unten aufgeführten Paketnamen und Speicherorte der SLES 15-Datenströme sind in der OpenSCAP-Härtungsanleitung von SUSE und im STIG-Verfahren von SUSE dokumentiert . Paketquellen und Profilversionen können je nach Service Pack und Update-Level variieren. Listen Sie die installierten Datenströme auf und prüfen Sie die Kandidatendatei, anstatt einen Dateinamen oder ein Profil anzunehmen.

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

Vergewissern Sie sich, dass der SLES-15-Datenstrom vorhanden ist und die Profilliste ihn enthält stig. Falls die Datei oder das Profil fehlt, beheben Sie die Paket- oder Repository-Inkompatibilität; verwenden Sie nicht den Benchmark eines anderen Betriebssystems.

3. Eine Ausgangslage erfassen und anschließend die Sanierungsmaßnahmen testen.

Erstellen Sie vor der Berichtserstellung ein Verzeichnis mit geschützten Beweismitteln. Führen Sie zunächst einen Scan durch, ohne die Systemeinstellungen zu ändern.

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

Öffnen Sie den HTML-Bericht und prüfen Sie jedes Ergebnis, insbesondere Fehler und Regeln, die nicht überprüft werden konnten. Bewahren Sie den XML-Bericht und die zugehörigen Konfigurationsdaten als sensible Informationen auf. Da diese Details zum Host und zum Sicherheitsstatus offenlegen können, dürfen sie nur über autorisierte Kanäle gespeichert oder übertragen werden.

Als Nächstes klonen oder erstellen Sie einen Snapshot des Servers in einer Nicht-Produktionsumgebung. Überprüfen Sie das Anwendungsverhalten, die Identitätszugriffe, die Netzwerkfunktionen, die Überwachung und die Wiederherstellung, bevor Sie automatisierte Änderungen anwenden. SUSE weist Administratoren darauf hin, dass Korrekturmaßnahmen zunächst außerhalb der Produktionsumgebung getestet werden sollten, da sie die Systemkonfiguration verändern. Auf dem Testhost ist die dokumentierte Vorgehensweise für die Durchführung solcher Änderungen folgende:

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

Das generierte Ergebnis kann ein Testergebnis vor und nach der Behebung der Mängel enthalten. Eine markierte Regel fixedbedeutet, dass die automatische Korrektur angewendet wurde und die Regel die Bewertung bestanden hat; ein erroranderes Zeichen bedeutet, dass die Behebung für diese Regel fehlgeschlagen ist. Keiner dieser Status ersetzt den Betriebstest oder die Überprüfung der zugrunde liegenden Anforderung.

4. Erneut scannen, Ausnahmen beheben und Nachweise aufbewahren.

Nach der Überprüfung des Testverhaltens sollte ein separater Scan mit neuen Ausgabepfaden durchgeführt werden. Eine reine Scan-Auswertung hilft, den aktuellen Zustand vom Korrekturlauf zu unterscheiden.

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

Erwarten Sie nicht, dass sich jede Regel automatisch beheben lässt. Untersuchen Sie Fehler anhand des vollständigen Prüf- und Korrekturtextes der Regel in der exakt für das System ausgewählten DISA-Checkliste. Einige Regeln erfordern eine bewusste Entscheidung des Serviceverantwortlichen, eine standortspezifische Konfiguration oder manuelle Nachweise. Ist eine Regel nicht anwendbar oder kann sie nicht erfüllt werden, dokumentieren Sie die Gründe und die kompensierenden Kontrollen im Rahmen des formalen Ausnahmeverfahrens Ihrer Organisation. Die Änderung oder Anpassung eines Profils allein reicht nicht aus, um eine Anforderung zu erfüllen.

Zur Überprüfung der Checkliste dokumentiert SUSE den Export einer XCCDF-Datei, die in den DISA STIG Viewer importiert werden kann. Generieren Sie die Datei mit der unterstützten Option und importieren Sie sie anschließend gemäß der aktuellen Benutzeranleitung in den Viewer.

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

Alex' Dokumentationspaket für den fiktiven Server enthält die Host- und Service-Pack-Identität, die Benchmark-Revision, die SCAP-Inhaltsversion, das Scan-Datum, Basis- und Abschlussberichte, Korrekturmaßnahmen, manuelle Prüfungen und genehmigte Ausnahmen. Stellen Sie sicher, dass die Dateien vorhanden sind und nur für autorisierte Prüfer lesbar bleiben.

sudo ls -l /root/stig-review

Bevor Sie die Aufgabe als abgeschlossen erklären, überprüfen Sie, ob der Abschlussbericht einen Scan nach den Änderungen widerspiegelt, ob alle verbleibenden Befunde einen Verantwortlichen und eine entsprechende Maßnahme enthalten und ob die erforderlichen Serverdienste weiterhin funktionieren. Die STIG-Konformität ist ein bewerteter Zustand, der an einen spezifischen Benchmark und Systemumfang gebunden ist; OpenSCAP unterstützt diese Bewertung, vergibt jedoch keine Akkreditierung und garantiert nicht, dass alle Standortanforderungen erfüllt wurden.

Quellen

• SUSE: SUSE Linux Enterprise mit STIG absichern
• SUSE: SLES mit OpenSCAP härten
• DISA: STIG Downloads