Gera conteúdo de segurança SCAP, Ansible, Bash e CEL para avaliação de conformidade e hardening automatizado em hosts Linux, contêineres e Kubernetes.
O objetivo deste projeto é criar conteúdo de políticas de segurança para várias plataformas — Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, SUSE Linux Enterprise Server (SLES),... — bem como produtos — Firefox,... Nosso objetivo é tornar o mais fácil possível escrever e manter o conteúdo de segurança existente em todos os formatos comumente utilizados.
"Conteúdo SCAP" refere-se a documentos nos formatos XCCDF, OVAL e SCAP source data stream. Esses documentos podem ser apresentados de diferentes formas e por diferentes organizações para atender às suas necessidades de automação de segurança e implementação técnica. Para uso geral, recomendamos os SCAP source data streams porque eles contêm todos os dados necessários para avaliar e colocar máquinas em conformidade. Os data streams fazem parte dos nossos arquivos ZIP de lançamento.
"Conteúdo Ansible" refere-se a playbooks Ansible gerados a partir de perfis de segurança. Eles podem ser usados tanto no modo de verificação (check-mode) para avaliar a conformidade, quanto no modo de execução (run-mode) para colocar máquinas em conformidade. Publicamos esses playbooks no Ansible Galaxy e também nos arquivos ZIP de lançamento.
"Arquivos de correção Bash" refere-se a scripts Bash gerados a partir de perfis de segurança. Eles são destinados a serem executados nas máquinas para colocá-las em conformidade. Recomendamos o uso de outros formatos, mas entendemos que, para alguns cenários de implantação, o bash é a única opção.
"Conteúdo CEL" refere-se a conteúdo de conformidade que utiliza a Common Expression Language (CEL) para plataformas Kubernetes e OpenShift. O conteúdo CEL é gerado como arquivos YAML e é projetado para avaliação nativa de recursos Kubernetes por meio do compliance-operator, sem exigir acesso shell aos nós. Esse formato é usado para verificações de conformidade em nível de plataforma em sistemas de orquestração de contêineres.
Queremos que múltiplas organizações possam desenvolver conteúdo de segurança de forma eficiente. Ao aproveitar o poderoso sistema de build deste projeto, evitamos ao máximo a redundância.
O sistema de build combina os arquivos de regras YAML fáceis de editar com verificações OVAL, trechos de tarefas Ansible, correções Bash e outros arquivos. Templates são fornecidos em cada etapa para evitar código repetitivo. Os identificadores de segurança (CCE, NIST ID, STIG, ...) aparecem em todos os nossos formatos de saída, mas são todos originados dos arquivos de regras YAML.
Entendemos que, dependendo das necessidades da sua organização, você pode precisar usar um formato específico de conteúdo de segurança. Deixamos você escolher.
Utilizamos um formato de regras YAML inspirado no OpenControl como entrada. Escreva uma vez e gere conteúdo de segurança em XCCDF, Ansible e outros.
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"
Nosso conteúdo de segurança pode ser usado para varrer máquinas bare-metal, máquinas virtuais, imagens de máquinas virtuais (qcow2 e outras), contêineres (incluindo Docker) e imagens de contêineres.
Usamos verificações de plataforma para detectar se devemos ou não avaliar algumas das regras. Por exemplo: verificações de partições separadas fazem total sentido em máquinas bare-metal, mas vão contra as práticas recomendadas em contêineres.
O método preferido de instalação é por meio do gerenciador de pacotes da sua distribuição. No Red Hat Enterprise Linux e no Fedora, você pode usar:
yum install scap-security-guide
No Debian (sid), você pode usar:
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.)
Baixe o arquivo ZIP SSG pré-compilado na página de lançamentos. Cada arquivo ZIP é um pacote com SCAP source data streams prontos.
Se o ComplianceAsCode não estiver empacotado na sua distribuição (ele pode estar presente como pacote scap-security-guide), ou se a
versão empacotada for muito antiga, você precisará compilar o conteúdo você mesmo
e instalá-lo via make install. Consulte o documento Guia do Desenvolvedor
para obter mais informações. Também recomendamos abrir uma issue no rastreador de bugs
dessa distribuição para manifestar interesse.
Presumimos que você tenha instalado o ComplianceAsCode em todo o sistema, em um local padrão, a partir das fontes upstream atuais, conforme instruído na seção anterior.
Há várias maneiras de consumir o conteúdo do ComplianceAsCode; abordaremos apenas algumas delas aqui.