
Génère du contenu de sécurité SCAP, Ansible, Bash et CEL pour l'évaluation de la conformité et le durcissement automatisé sur les hôtes Linux, les conteneurs et Kubernetes.
Le but de ce projet est de créer du contenu de politique de sécurité pour diverses plateformes — Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, SUSE Linux Enterprise Server (SLES),... — ainsi que pour des produits — Firefox,... Nous visons à rendre aussi simple que possible l'écriture de nouveau contenu de sécurité et la maintenance du contenu existant dans tous les formats couramment utilisés.

"SCAP content" fait référence aux documents aux formats XCCDF, OVAL et SCAP source data stream. Ces documents peuvent être présentés sous différentes formes et par différentes organisations pour répondre à leurs besoins d'automatisation de la sécurité et de mise en œuvre technique. Pour un usage général, nous recommandons les SCAP source data streams, car ils contiennent toutes les données nécessaires pour évaluer les machines et les mettre en conformité. Les data streams font partie de nos archives ZIP de publication.
"Ansible content" fait référence aux playbooks Ansible générés à partir des profils de sécurité. Ils peuvent être utilisés à la fois en mode check-mode pour évaluer la conformité, et en mode run-mode pour mettre les machines en conformité. Nous les publions sur Ansible Galaxy ainsi que dans les archives ZIP de publication.
"Bash fix files" fait référence aux scripts Bash générés à partir des profils de sécurité. Ils sont destinés à être exécutés sur les machines pour les mettre en conformité. Nous recommandons d'utiliser d'autres formats, mais nous comprenons que pour certains scénarios de déploiement, bash est la seule option.
"CEL content" fait référence au contenu de conformité utilisant le langage d'expression commun (CEL) pour les plateformes Kubernetes et OpenShift. Le contenu CEL est généré sous forme de fichiers YAML et est conçu pour l'évaluation native des ressources Kubernetes via le compliance-operator, sans nécessiter d'accès shell aux nœuds. Ce format est utilisé pour les contrôles de conformité au niveau plateforme sur les systèmes d'orchestration de conteneurs.
Nous voulons que plusieurs organisations puissent développer efficacement du contenu de sécurité. En tirant parti du puissant système de build de ce projet, nous évitons autant de redondance que possible.
Le système de build combine les fichiers de règles YAML faciles à éditer avec les vérifications OVAL, les extraits de tâches Ansible, les correctifs Bash et d'autres fichiers. Le templating est fourni à chaque étape pour éviter le code répétitif. Les identifiants de sécurité (CCE, NIST ID, STIG, ...) apparaissent dans tous nos formats de sortie, mais proviennent tous des fichiers de règles YAML.
Nous comprenons qu'en fonction des besoins de votre organisation, vous puissiez avoir besoin d'utiliser un format de contenu de sécurité spécifique. Nous vous laissons le choix.
Nous utilisons un format de règle YAML inspiré d'OpenControl pour l'entrée. Écrivez une fois et générez du contenu de sécurité en XCCDF, Ansible et autres.
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"
Notre contenu de sécurité peut être utilisé pour analyser des machines bare-metal, des machines virtuelles, des images de machines virtuelles (qcow2 et autres), des conteneurs (y compris Docker) et des images de conteneurs.
Nous utilisons des vérifications de plateforme pour détecter si nous devons ou non évaluer certaines règles. Par exemple : les vérifications de partition séparée sont parfaitement pertinentes sur les machines bare-metal, mais vont à l'encontre des pratiques recommandées sur les conteneurs.
La méthode d'installation privilégiée est le gestionnaire de paquets de votre distribution. Sur Red Hat Enterprise Linux et Fedora, vous pouvez utiliser :
yum install scap-security-guide
Sur Debian (sid), vous pouvez utiliser :
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.)
Téléchargez l'archive ZIP SSG préconstruite depuis la page des versions. Chaque fichier ZIP est une archive contenant des SCAP source data streams prêts à l'emploi.