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.
Si ComplianceAsCode n'est pas empaqueté dans votre distribution (il peut y être présent sous le nom de paquet scap-security-guide), ou si la
version empaquetée est trop ancienne, vous devez construire le contenu vous-même
et l'installer via make install. Veuillez consulter le document Guide du développeur
pour plus d'informations. Nous recommandons également d'ouvrir un ticket sur le bug tracker
de cette distribution pour exprimer votre intérêt.
Nous supposons que vous avez installé ComplianceAsCode à l'échelle du système dans un emplacement standard à partir des sources amont actuelles, comme indiqué dans la section précédente.
Il existe plusieurs façons d'utiliser le contenu ComplianceAsCode ; nous n'en aborderons que quelques-unes ici.
oscapL'outil oscap est une interface en ligne de commande de bas niveau issue du
projet OpenSCAP. Il peut être utilisé pour analyser la machine locale.
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
Après l'évaluation, le fichier arf.xml contiendra tous les résultats dans un format
result data stream (ARF) réutilisable, et report.html contiendra un rapport lisible
par un humain pouvant être ouvert dans un navigateur.
Remplacez le profil par un autre profil de votre choix ; vous pouvez afficher tous les choix possibles en utilisant :
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Veuillez consulter le site Web OpenSCAP pour plus d'informations.
SCAP Workbench est une interface utilisateur graphique pour l'évaluation et la personnalisation SCAP. Il convient à l'analyse d'une seule machine, locale ou distante (via SSH). Les nouvelles versions de SCAP Workbench disposent d'une intégration SSG et la proposent automatiquement au démarrage de l'application.
Veuillez consulter le site Web SCAP Workbench pour plus d'informations.
oscap-sshoscap-ssh est fourni avec OpenSCAP 1.2.3 et versions ultérieures. Il permet d'analyser
une machine distante via SSH avec une interface ressemblant à l'outil oscap.
La commande suivante évalue une machine avec l'IP 192.168.1.123 avec du contenu
stocké sur la machine locale. Gardez à l'esprit que oscap doit être installé sur la
machine distante, mais que le contenu SSG n'a pas besoin de l'être.
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
Pour voir la liste des Ansible Playbooks disponibles, exécutez :
ls /usr/share/scap-security-guide/ansible/
Ces Ansible Playbooks sont générés à partir des profils SCAP disponibles pour les produits.
Pour appliquer le playbook sur votre machine locale, exécutez : (CELA MODIFIERA LA CONFIGURATION DE LA MACHINE !)
ansible-playbook -i "localhost," -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-ospp.yml
Chacun des Ansible Playbooks contient des instructions sur la façon de les déployer. Voici un extrait des instructions :
...
# 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
...
Pour voir la liste des scripts Bash disponibles, exécutez :
# ls /usr/share/scap-security-guide/bash/
...
rhel8-script-hipaa.sh
rhel8-script-ospp.sh
rhel8-script-pci-dss.sh
...
Ces scripts Bash sont générés à partir des profils SCAP disponibles pour les produits. Comme pour les Ansible Playbooks, chacun des scripts Bash contient des instructions sur la façon de les déployer.
La liste de diffusion SSG se trouve à l'adresse https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide.
Si vous rencontrez des problèmes avec OpenSCAP ou SCAP Workbench, utilisez https://www.redhat.com/mailman/listinfo/open-scap-list
Si vous préférez un contact plus interactif avec la communauté, vous pouvez nous rejoindre sur Gitter et IRC :
#openscap sur libera.chat.Ce projet a débuté en 2011 comme une collaboration entre des agences gouvernementales des États-Unis et des vendeurs commerciaux de systèmes d'exploitation. Le nom d'origine était SCAP Security Guide, couramment abrégé en SSG. La portée initiale était de créer des SCAP data streams. Au fil du temps, il est devenu le plus grand projet open source de contenu au-delà de SCAP.
Les années suivantes ont vu l'introduction de profils de sécurité non seulement spécifiques aux gouvernements, mais aussi commerciaux, tels que PCI-DSS et CIS.
Plus tard, l'industrie a commencé à évoluer vers différents formats de contenu de sécurité,
tels que Ansible, Puppet et Chef InSpec. La communauté a réagi en faisant évoluer les
outils et a contribué à transformer SSG en un projet de contenu de sécurité plus
généraliste. Ce changement s'est produit progressivement en 2017 et 2018. En septembre 2018, nous
avons décidé de changer le nom du projet en ComplianceAsCode, afin d'éviter toute confusion.
Nous envisageons un futur indépendant du format. C'est pourquoi nous avons opté pour une abstraction plutôt que d'utiliser XCCDF comme format d'entrée.
Ce projet accueille volontiers les nouveaux contributeurs. Nous nous efforçons en permanence de supprimer les complexités afin de rendre les contributions plus faciles et plus agréables pour tous. C'est un beau projet et une communauté amicale.
Il existe de nombreuses façons de contribuer. Consultez la documentation pour plus de détails : https://complianceascode.readthedocs.io/en/latest/manual/developer/01_introduction.html
Consultez la liste mise à jour des contributeurs.