Evidência de benchmark CIS

CIS Benchmarks  são recomendações de configuração segura desenvolvidas por consenso. CIS descreve Level 1 como baseline amplamente utilizável e Level 2 como defesa em profundidade que pode afetar utilidade ou performance. Aplique qualquer perfil primeiro em ambiente de teste.

OpenFactory pode aplicar controles selecionados e rodar catálogo de checagens de máquina. Run passed é evidência sobre aquele artefato, versão de benchmark, perfil e momento. Não é certificação CIS, garantia sobre configurações de deployment, nem prova de conformidade com outro framework.

Limite de remediação atual

Feature cis-benchmarks tem um caminho completo fixado de remediação:

Caminho Ubuntu desabilita ou adapta de propósito regras upstream selecionadas para caber ambiente offline-first-boot e imagem. Manifest gerado registra proveniência e configurações selecionadas. Essas adaptações tornam evidência exata e exceções essenciais.

security-hardening e os.security.hardening_level são controles gerais de hardening separados. Não mapeiam automaticamente para perfil CIS Level 1 ou Level 2 completo.

Execução de benchmark

Cenários podem selecionar catálogo e level exatos:

{
  "id": "ubuntu-cis-evidence",
  "name": "Ubuntu 24.04 CIS evidence",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "cis_benchmark": "CIS_Ubuntu_Linux_24.04_LTS_Benchmark_v1.0.0",
  "cis_level": "L1"
}

Runner também tem catálogos para Debian 12 e Debian 13 e conjunto interno orientado a GxP. Nome de catálogo não prova conteúdo CIS oficial ou atualidade. Confirme proveniência, licença, versão e definições de controle do catálogo antes de usar em auditoria.

Não use benchmark OS antigo como afirmação de conformidade para release mais nova. Resolver tem atualmente fallbacks same-family aprovados para alguns alvos Ubuntu e Debian mais novos para testes rodarem, mas saída deve ser rotulada como avaliação de compatibilidade contra catálogo mais antigo, não conformidade a benchmark da OS mais nova.

Ler um resultado

Retenha pelo menos:

• IDs de artefato e build;
• digest de imagem e snapshot de origem;
• identidade e versão de base OS;
• ID de benchmark/catálogo, perfil e digest;
• controles applicable, passed, failed, skipped e not-applicable;
• saída bruta de comando e timestamps;
• proveniência de remediação;
• exceções documentadas com owner e aprovação; e
• ambiente em que checagens rodaram.

Porcentagem sozinha esconde aplicabilidade e severidade. Run com zero failed applicable ainda não diz nada sobre controles fora do catálogo, mudanças na hora do deployment, credenciais, redes, hardware físico ou drift posterior.

Fluxo seguro

1. Selecione benchmark que corresponda exatamente à release alvo.
2. Revise perfil e toda adaptação OpenFactory.
3. Construa artefato e aguarde readiness de remediação no first boot.
4. Rode conjunto completo de checagens aplicáveis em guest limpo.
5. Investigue falhas; não converta silenciosamente em not applicable.
6. Teste comportamento de aplicativo e operacional após hardening.
7. Owner de segurança responsável aprova exceções.
8. Reexecute após mudança de pacote, receita ou deployment.

Use orientação de perfil da própria CIS  como ponto normativo inicial e obtenha benchmark aplicável pelo canal de distribuição CIS autorizado.