Genera contenuti di sicurezza SCAP, Ansible, Bash e CEL per la valutazione della conformità e l'hardening automatizzato su host Linux, container e Kubernetes.
Lo scopo di questo progetto è creare contenuti di policy di sicurezza per varie piattaforme — Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, SUSE Linux Enterprise Server (SLES),... — e prodotti — Firefox,... Il nostro obiettivo è rendere il più semplice possibile scrivere nuovi contenuti di sicurezza e mantenere quelli esistenti in tutti i formati comunemente usati.
"Contenuti SCAP" si riferisce ai documenti nei formati XCCDF, OVAL e flusso di dati sorgente SCAP. Questi documenti possono essere presentati in forme diverse e da diverse organizzazioni per soddisfare le proprie esigenze di automazione della sicurezza e implementazione tecnica. Per un uso generale, consigliamo i flussi di dati sorgente SCAP perché contengono tutti i dati necessari per valutare e mettere in conformità le macchine. I flussi di dati fanno parte degli archivi ZIP delle nostre release.
"Contenuti Ansible" si riferisce ai playbook Ansible generati dai profili di sicurezza. Questi possono essere utilizzati sia in modalità check per valutare la conformità, sia in modalità run per portare le macchine in conformità. Li pubblichiamo su Ansible Galaxy e negli archivi ZIP delle release.
"File di fix Bash" si riferisce a script Bash generati dai profili di sicurezza. Questi sono pensati per essere eseguiti sulle macchine per portarle in conformità. Consigliamo di usare altri formati, ma comprendiamo che per alcuni scenari di distribuzione bash è l'unica opzione.
"Contenuti CEL" si riferisce a contenuti di conformità che utilizzano il Common Expression Language (CEL) per le piattaforme Kubernetes e OpenShift. I contenuti CEL vengono generati come file YAML e sono progettati per la valutazione nativa delle risorse Kubernetes tramite compliance-operator, senza richiedere accesso shell ai nodi. Questo formato viene utilizzato per i controlli di conformità a livello di piattaforma sui sistemi di orchestrazione dei container.
Vogliamo che più organizzazioni possano sviluppare in modo efficiente contenuti di sicurezza. Sfruttando il potente sistema di build di questo progetto, evitiamo il più possibile la ridondanza.
Il sistema di build combina i file di regole YAML facilmente modificabili con controlli OVAL, snippet di task Ansible, fix Bash e altri file. Il templating è fornito in ogni fase per evitare codice ripetitivo. Gli identificatori di sicurezza (CCE, NIST ID, STIG, ...) compaiono in tutti i nostri formati di output, ma provengono tutti dai file di regole YAML.
Comprendiamo che, a seconda delle esigenze della tua organizzazione, potresti avere bisogno di utilizzare un formato specifico di contenuti di sicurezza. Lasciamo a te la scelta.
Utilizziamo un formato di regole YAML ispirato a OpenControl per l'input. Scrivi una volta e genera contenuti di sicurezza in XCCDF, Ansible e altri.
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"
I nostri contenuti di sicurezza possono essere utilizzati per scansionare macchine bare-metal, macchine virtuali, immagini di macchine virtuali (qcow2 e altre), container (incluso Docker) e immagini container.
Utilizziamo controlli di piattaforma per determinare se valutare o meno alcune regole. Ad esempio: i controlli sulle partizioni separate hanno perfettamente senso sulle macchine bare-metal, ma vanno contro le pratiche consigliate per i container.
Il metodo di installazione preferito è tramite il gestore dei pacchetti della tua distribuzione. Su Red Hat Enterprise Linux e Fedora puoi usare:
yum install scap-security-guide
Su Debian (sid), puoi usare:
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.)
Scarica l'archivio ZIP SSG precompilato da la pagina delle release. Ogni file ZIP è un archivio con flussi di dati sorgente SCAP già pronti.
Se ComplianceAsCode non è pacchettizzato nella tua distribuzione (potrebbe essere presente come pacchetto scap-security-guide), o se la versione
pacchettizzata è troppo vecchia, devi compilare i contenuti da solo
e installarli tramite make install. Consulta il documento Developer Guide
per maggiori informazioni. Ti consigliamo anche di aprire una segnalazione sul bug tracker di quella distribuzione per manifestare il tuo interesse.
Presumiamo che tu abbia installato ComplianceAsCode a livello di sistema in una posizione standard dai sorgenti upstream correnti, come indicato nella sezione precedente.
Ci sono diversi modi per utilizzare i contenuti di ComplianceAsCode; qui ne esamineremo solo alcuni.