complianceascode/contentGeneriert SCAP-, Ansible-, Bash- und CEL-Sicherheitsinhalte zur Compliance-Bewertung und automatisierten Härtung von Linux-Hosts, Containern und Kubernetes.
Der Zweck dieses Projekts ist die Erstellung von Inhalten für Sicherheitsrichtlinien für verschiedene Plattformen — Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, SUSE Linux Enterprise Server (SLES),... — sowie für Produkte — Firefox,... Wir möchten das Schreiben neuer und die Pflege bestehender Sicherheitsinhalte in allen gängigen Formaten so einfach wie möglich machen.
„SCAP-Content" bezeichnet Dokumente in den Formaten XCCDF, OVAL und SCAP-Source-Data-Stream. Diese Dokumente können von verschiedenen Organisationen in unterschiedlichen Formen dargestellt werden, um deren Anforderungen an Sicherheitsautomatisierung und technische Umsetzung zu erfüllen. Für den allgemeinen Gebrauch empfehlen wir SCAP-Source-Data-Streams, da sie alle Daten enthalten, die Sie benötigen, um Maschinen zu bewerten und in Konformität zu bringen. Die Data Streams sind Teil unserer Release-ZIP-Archive.
„Ansible-Content" bezeichnet Ansible-Playbooks, die aus Sicherheitsprofilen generiert werden. Diese können sowohl im Check-Modus zur Bewertung der Konformität als auch im Run-Modus verwendet werden, um Maschinen in Konformität zu bringen. Wir veröffentlichen diese auf Ansible Galaxy sowie in Release-ZIP-Archiven.
„Bash-Fix-Dateien" beziehen sich auf Bash-Skripte, die aus Sicherheitsprofilen generiert werden. Sie sind dafür gedacht, auf Maschinen ausgeführt zu werden, um diese in Konformität zu bringen. Wir empfehlen die Verwendung anderer Formate, verstehen aber, dass Bash in einigen Bereitstellungsszenarien die einzige Option ist.
„CEL-Content" bezeichnet Konformitätsinhalte, die die Common Expression Language (CEL) für Kubernetes- und OpenShift-Plattformen verwenden. CEL-Content wird als YAML-Dateien generiert und ist für die native Bewertung von Kubernetes-Ressourcen über den compliance-operator konzipiert, ohne dass Shell-Zugriff auf die Knoten erforderlich ist. Dieses Format wird für Konformitätsprüfungen auf Plattformebene in Container-Orchestrierungssystemen verwendet.
Wir möchten, dass mehrere Organisationen Sicherheitsinhalte effizient entwickeln können. Durch die Nutzung des leistungsstarken Build-Systems dieses Projekts vermeiden wir so viel Redundanz wie möglich.
Das Build-System kombiniert die einfach zu bearbeitenden YAML-Regeldateien mit OVAL-Prüfungen, Ansible-Task-Snippets, Bash-Fixes und anderen Dateien. In jedem Schritt wird Templating bereitgestellt, um Boilerplate zu vermeiden. Sicherheitskennungen (CCE, NIST ID, STIG, ...) erscheinen in allen unseren Ausgabeformaten, stammen aber alle aus den YAML-Regeldateien.
Wir verstehen, dass Sie je nach den Anforderungen Ihrer Organisation möglicherweise ein bestimmtes Sicherheitsinhaltsformat verwenden müssen. Wir überlassen Ihnen die Wahl.
Wir verwenden ein an OpenControl angelehntes YAML-Regelformat für die Eingabe. Einmal schreiben und Sicherheitsinhalte in XCCDF, Ansible und anderen Formaten generieren.
title: 'Configure The Number of Allowed Simultaneous Requests'
description: |-
The <tt>MaxKeepAliveRequests</tt> directive should be set and configured to
<sub idref="var_max_keepalive_requests" /> or greater by setting the following
in <tt>/etc/httpd/conf/httpd.conf</tt>:
<pre>MaxKeepAliveRequests {{{ xccdf_value("var_max_keepalive_requests") }}}</pre>
rationale: |-
Resource exhaustion can occur when an unlimited number of concurrent requests
are allowed on a web site, facilitating a denial of service attack. Mitigating
this kind of attack will include limiting the number of concurrent HTTP/HTTPS
requests per IP address and may include, where feasible, limiting parameter
values associated with keepalive, (i.e., a parameter used to limit the amount of
time a connection may be inactive).
severity: medium
identifiers:
cce: "80551-5"
Unsere Sicherheitsinhalte können zum Scannen von Bare-Metal-Maschinen, virtuellen Maschinen, Images virtueller Maschinen (qcow2 und andere), Containern (einschließlich Docker) und Container-Images verwendet werden.
Wir verwenden Plattformprüfungen, um zu erkennen, ob wir einige der Regeln auswerten sollten oder nicht. Zum Beispiel: Separate Partitionsprüfungen ergeben auf Bare-Metal-Maschinen absolut Sinn, widersprechen jedoch den empfohlenen Vorgehensweisen bei Containern.
Die bevorzugte Installationsmethode ist über den Paketmanager Ihrer Distribution. Unter Red Hat Enterprise Linux und Fedora können Sie Folgendes verwenden:
yum install scap-security-guide
Unter Debian (sid) können Sie Folgendes verwenden:
apt install ssg-debian # for Debian guides
apt install ssg-debderived # for Debian-based distributions (e.g. Ubuntu) guides
apt install ssg-nondebian # for other distributions guides (RHEL, Fedora, etc.)
apt install ssg-applications # for application-oriented guides (Firefox, JBoss, etc.)
Laden Sie das vorgefertigte SSG-ZIP-Archiv von der Release-Seite herunter. Jede ZIP-Datei ist ein Archiv mit fertigen SCAP-Source-Data-Streams.
Wenn ComplianceAsCode nicht in Ihrer Distribution enthalten ist (es kann dort als Paket scap-security-guide vorhanden sein) oder wenn die enthaltene Version zu alt ist, müssen Sie den Content selbst erstellen und über make install installieren. Weitere Informationen finden Sie im Dokument Entwicklerhandbuch. Wir empfehlen außerdem, ein Issue im Bugtracker der jeweiligen Distribution zu eröffnen, um Interesse zu bekunden.
Wir gehen davon aus, dass Sie ComplianceAsCode wie im vorherigen Abschnitt beschrieben systemweit an einem Standardort aus den aktuellen Upstream-Quellen installiert haben.
Es gibt mehrere Möglichkeiten, ComplianceAsCode-Content zu nutzen; wir werden hier nur einige davon durchgehen.
oscapDas Tool oscap ist eine Low-Level-Befehlszeilenschnittstelle aus dem OpenSCAP-Projekt. Es kann zum Scannen der lokalen Maschine verwendet werden.
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_ospp --results-arf arf.xml --report report.html --oval-results /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Nach der Auswertung enthält die Datei arf.xml alle Ergebnisse in einem wiederverwendbaren Ergebnis-Data-Stream-Format (ARF); die Datei report.html enthält einen menschenlesbaren Bericht, der in einem Browser geöffnet werden kann.
Sie können das Profil durch ein beliebiges anderes Profil Ihrer Wahl ersetzen; alle möglichen Optionen lassen sich mit folgendem Befehl anzeigen:
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Weitere Informationen finden Sie auf der OpenSCAP-Website.
Die SCAP Workbench ist eine grafische Benutzeroberfläche für SCAP-Bewertung und -Anpassung. Sie eignet sich zum Scannen einer einzelnen Maschine, entweder lokal oder remote (über SSH). Neuere Versionen der SCAP Workbench verfügen über eine SSG-Integration und bieten diese automatisch an, wenn die Anwendung gestartet wird.
Weitere Informationen finden Sie auf der SCAP Workbench-Website.
oscap-sshoscap-ssh ist ab OpenSCAP 1.2.3 enthalten. Es ermöglicht das Scannen einer entfernten Maschine über SSH mit einer Oberfläche, die der des Tools oscap ähnelt.
Der folgende Befehl bewertet eine Maschine mit der IP 192.168.1.123 mit Content, der auf der lokalen Maschine gespeichert ist. Beachten Sie, dass oscap auf der entfernten Maschine installiert sein muss, der SSG-Content jedoch nicht.
oscap-ssh [email protected] 22 xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --results-arf arf.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml
Um eine Liste der verfügbaren Ansible-Playbooks anzuzeigen, führen Sie Folgendes aus:
ls /usr/share/scap-security-guide/ansible/
Diese Ansible-Playbooks werden aus den SCAP-Profilen generiert, die für die Produkte verfügbar sind.
Um das Playbook auf Ihrer lokalen Maschine anzuwenden, führen Sie Folgendes aus: (DADURCH WIRD DIE KONFIGURATION DER MASCHINE GEÄNDERT!)
ansible-playbook -i "localhost," -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-ospp.yml
Jedes der Ansible-Playbooks enthält Anweisungen zur Bereitstellung. Hier ist ein Auszug aus den Anweisungen:
...
# This file was generated by OpenSCAP 1.2.16 using:
# $ oscap xccdf generate fix --profile rht-ccp --fix-type ansible sds.xml
#
# This script is generated from an OpenSCAP profile without preliminary evaluation.
# It attempts to fix every selected rule, even if the system is already compliant.
#
# How to apply this remediation role:
# $ ansible-playbook -i "192.168.1.155," playbook.yml
# $ ansible-playbook -i inventory.ini playbook.yml
...
Um eine Liste der verfügbaren Bash-Skripte anzuzeigen, führen Sie Folgendes aus:
# ls /usr/share/scap-security-guide/bash/
...
rhel8-script-hipaa.sh
rhel8-script-ospp.sh
rhel8-script-pci-dss.sh
...
Diese Bash-Skripte werden aus den SCAP-Profilen generiert, die für die Produkte verfügbar sind. Ähnlich wie die Ansible-Playbooks enthalten auch die Bash-Skripte Anweisungen zur Bereitstellung.
Die SSG-Mailingliste finden Sie unter https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide.
Wenn Sie Probleme mit OpenSCAP oder der SCAP Workbench haben, nutzen Sie https://www.redhat.com/mailman/listinfo/open-scap-list.
Wenn Sie einen interaktiveren Kontakt mit der Community bevorzugen, können Sie uns auf Gitter und IRC beitreten:
#openscap auf libera.chat bei.Dieses Projekt startete 2011 als Zusammenarbeit zwischen Behörden der US-Regierung und kommerziellen Betriebssystemanbietern. Der ursprüngliche Name war SCAP Security Guide, üblicherweise als SSG abgekürzt. Der ursprüngliche Zweck war die Erstellung von SCAP-Data-Streams. Im Laufe der Zeit wuchs es zum größten Open-Source-Projekt für Inhalte jenseits von SCAP heran.
In den folgenden Jahren wurden nicht nur regierungsspezifische Sicherheitsprofile eingeführt, sondern auch kommerzielle wie PCI-DSS und CIS.
Später begann die Branche, sich in Richtung verschiedener Sicherheitsinhaltsformate zu bewegen, wie Ansible, Puppet und Chef InSpec. Die Community reagierte, indem sie die Werkzeuge weiterentwickelte, und trug dazu bei, SSG in ein allgemeineres Sicherheitsinhaltsprojekt zu verwandeln. Dieser Wandel vollzog sich im Laufe der Jahre 2017 und 2018. Im September 2018 entschieden wir uns, den Namen des Projekts in ComplianceAsCode zu ändern, um Verwirrung zu vermeiden.
Wir gehen davon aus, dass die Zukunft formatunabhängig sein wird. Deshalb haben wir uns für eine Abstraktion entschieden, anstatt XCCDF als Eingabeformat zu verwenden.
Dieses Projekt freut sich über neue Mitwirkende. Wir sind ständig bestrebt, die Komplexität zu reduzieren, um Beiträge für alle einfacher und angenehmer zu machen. Dies ist ein nettes Projekt und eine freundliche Community.
Es gibt viele Möglichkeiten, einen Beitrag zu leisten. Weitere Details finden Sie in der Dokumentation: https://complianceascode.readthedocs.io/en/latest/manual/developer/01_introduction.html
Schauen Sie sich die aktualisierte Liste der Mitwirkenden an.