CIS Benchmarks: o que são e por que são importantes

O que são exatamente os CIS Benchmarks

Um CIS Benchmark é um documento que informa, configuração por configuração, como configurar um sistema operacional, plataforma de nuvem, software ou dispositivo de rede específico para torná-lo mais difícil de atacar. Eles são publicados pelo Center for Internet Security (CIS), uma organização sem fins lucrativos dos EUA, e abrangem as plataformas que as organizações realmente utilizam: Windows Server e edições para desktop, as principais distribuições Linux, Amazon Web Services, Microsoft Azure, Google Cloud, Kubernetes e Docker, Microsoft 365, Google Workspace, navegadores comuns e dispositivos de rede de fornecedores como Cisco e Palo Alto Networks. Há mais de 100 Benchmarks no total, abrangendo mais de 25 famílias de produtos de fornecedores, e o CIS atualiza cada um deles à medida que novas versões das plataformas são lançadas.

As recomendações dos CIS Benchmarks passam por um processo de consenso antes da publicação. Especialistas voluntários de mercado, governo e academia propõem, revisam e votam em cada configuração, e é por isso que a orientação tem o caráter de uma recomendação prática para quem opera os sistemas, e não de uma documentação de hardening produzida pelo próprio fornecedor. Cada recomendação é marcada como "Scored", quando a conformidade pode ser medida automaticamente e incorporada a uma pontuação numérica, ou "Not Scored", quando se trata de uma boa prática que não se presta à verificação automatizada.

Os próprios Benchmarks podem ser baixados gratuitamente em PDF para todas as plataformas cobertas pelo CIS. O que custa dinheiro são as ferramentas construídas em torno deles: o CIS-CAT Pro, uma ferramenta de avaliação que verifica um sistema em relação a um Benchmark e produz uma pontuação de conformidade e um relatório de remediação, e as CIS Hardened Images, imagens de máquinas virtuais pré-configuradas para estar em conformidade com um Benchmark desde o início, vendidas nos marketplaces da AWS, Azure e GCP por meio de uma associação ao CIS SecureSuite. Também existe uma versão gratuita e limitada, chamada CIS-CAT Lite, para organizações que querem experimentar a pontuação automatizada em relação a um único Benchmark antes de contratar uma versão paga.

Anatomia de uma recomendação

Um Benchmark não é uma lista solta de sugestões. Cada recomendação dentro dele, e um único Benchmark pode conter várias centenas, segue a mesma estrutura de cinco partes. É isso que torna a orientação utilizável por um engenheiro, e não apenas legível:

• Description: o que é a configuração e o que ela controla.
• Rationale: por que a alteração é importante e que tipo de ataque ou exposição ela elimina.
• Audit procedure: as etapas exatas ou a verificação por linha de comando necessárias para confirmar se o sistema atende atualmente à recomendação.
• Remediation procedure: as etapas ou comandos exatos necessários para colocar o sistema em conformidade caso a auditoria falhe.
• Default value: o valor em que a configuração fica por padrão, antes de qualquer alteração.

Essa estrutura vem do CIS WorkBench, a plataforma colaborativa onde o processo de consenso realmente acontece. Especialistas voluntários de fornecedores, órgãos governamentais, auditores e do mercado enviam, discutem, testam e votam em cada recomendação antes de sua publicação, e os Benchmarks são revisados continuamente à medida que as plataformas mudam e novas ameaças surgem. É um processo mais lento do que um fornecedor escrever seu próprio guia de hardening, e esse é justamente o objetivo: uma recomendação que passa pela revisão de pessoas com interesses diferentes constitui uma baseline mais robusta do que uma recomendação escrita por quem desenvolveu o produto.

CIS Benchmarks vs CIS Controls: a distinção que costuma ser perdida

O CIS também publica os CIS Controls, e os dois são frequentemente confundidos, inclusive dentro de equipes de TI que utilizam ambos. Os Controls são um conjunto de 18 salvaguardas priorizadas, organizadas em três Implementation Groups de acordo com a maturidade da organização, que descrevem o que um programa de segurança precisa abranger: inventário de ativos, controle de acesso, proteção de dados, resposta a incidentes e assim por diante. Eles atuam no nível de um documento estratégico. Os Benchmarks atuam um nível abaixo, transformando uma dessas salvaguardas, a configuração segura, em configurações exatas e testáveis para uma plataforma específica.

Os dois foram projetados para trabalhar juntos, não para substituir um ao outro. O CIS Control 4, Secure Configuration of Enterprise Assets and Software, trata da configuração segura no nível do programa, e o Safeguard 4.1 exige o estabelecimento e a manutenção de um processo documentado de configuração segura. Os CIS Benchmarks são a orientação específica de cada plataforma que a maioria das organizações utiliza para colocar esse processo em prática, e não uma fonte que o próprio Control determine como obrigatória em lugar de uma baseline equivalente.

Exemplos de CIS Benchmarks por plataforma

"CIS Benchmark" não é um único documento, mas uma família de documentos, cada um direcionado a uma plataforma específica. Alguns dos mais utilizados pelas organizações são:

Cada Benchmark é versionado para uma versão específica da plataforma, e o CIS atualiza ou descontinua os guias quando os fornecedores lançam novas versões. Consulte o próprio catálogo de Benchmarks do CIS para verificar a versão atual, em vez de trabalhar com uma cópia antiga baixada há um ano.

Quem realmente precisa se preocupar com isso

A importância conceitual da configuração segura é fácil de reconhecer e igualmente fácil de deixar sem ação. Ela se torna concreta quando você identifica a sua própria situação. Um Benchmark vale a pena ser implementado quando você:

• Opera servidores Windows ou Linux, máquinas virtuais ou gerencia endpoints em escala relevante
• Opera Microsoft 365, Google Workspace ou outras plataformas SaaS que armazenam dados da empresa
• Executa workloads em AWS, Azure ou Google Cloud e quer uma baseline além das configurações padrão do provedor
• Processa dados de cartões de pagamento ou lida com outras informações regulamentadas ou sensíveis
• Precisa de evidências documentadas e prontas para auditoria de configuração segura para ISO 27001, PCI DSS, NIST CSF ou NIS2
• Provisiona infraestrutura usando Terraform, Ansible ou ferramentas semelhantes e quer que os sistemas já estejam em conformidade por padrão
• Gerencia sistemas em quantidade suficiente para que a configuração não possa mais depender de quem, por acaso, construiu cada um deles

Nada disso significa implementar todas as recomendações em todos os sistemas. A baseline adequada depende da plataforma, do requisito de negócio e do que cada sistema consegue suportar operacionalmente. É exatamente para isso que serve a implantação em fases descrita na seção de implementação abaixo.

Por que a configuração segura merece tanta atenção

As configurações padrão existem para colocar um sistema em funcionamento com o menor número possível de chamados de suporte, não para resistir a um invasor. Um servidor recém-instalado, um bucket de armazenamento em nuvem criado com as configurações padrão ou um novo tenant do Microsoft 365 normalmente vêm com configurações que favorecem a conveniência: permissões mais amplas do que a maioria dos usuários precisa, protocolos legados habilitados por compatibilidade e logging reduzido para diminuir o ruído. Nada disso é um bug. É simplesmente uma configuração que uma equipe de segurança provavelmente escolheria de outra forma, e a maioria das organizações nunca volta para fazer essa escolha de maneira deliberada.

Essa lacuna é exatamente onde se origina uma parcela significativa dos incidentes reais. Um bucket de armazenamento exposto com acesso público padrão, um servidor que ainda executa um protocolo legado que ninguém se lembra de ter habilitado ou um console administrativo acessível pela internet porque uma regra de firewall nunca foi restringida após uma migração: são falhas de configuração, não exploits de dia zero, e também são falhas que custam pouco para prevenir. A configuração incorreta continua aparecendo como uma das principais causas de incidentes em relatórios de violações, tanto em infraestrutura de nuvem quanto on-premise, porque a condição subjacente, plataformas complexas distribuídas com configurações padrão permissivas, não desapareceu.

Um Benchmark fecha essa lacuna ao fornecer uma resposta específica e testada em vez de um princípio genérico. "Faça o hardening dos seus servidores" é um conselho que ninguém consegue executar diretamente. "Desabilite SMBv1, aplique um comprimento mínimo de senha de 14 caracteres, desabilite a conta de convidado integrada e restrinja a tradução anônima de SID e nome" é algo que um engenheiro pode implementar e um auditor pode verificar. Essa especificidade, multiplicada por todas as configurações que uma plataforma oferece, é o valor real de um Benchmark em comparação com uma orientação genérica de hardening.

Level 1 e Level 2: dois níveis de hardening

Cada CIS Benchmark organiza suas recomendações em dois níveis de perfil. O Level 1 cobre o hardening fundamental: configurações que reduzem significativamente a superfície de ataque com risco mínimo de interromper a operação normal. Ele foi concebido como uma baseline adequada para praticamente qualquer sistema, inclusive sistemas que executam aplicações corporativas gerais onde a disponibilidade é mais importante do que uma defesa em profundidade. O Level 2 vai além, cobrindo configurações destinadas a ambientes de maior segurança nos quais alguma redução de funcionalidade ou desempenho é uma contrapartida aceitável para obter proteção adicional. Ambientes regulamentados, sistemas que tratam dados sensíveis e infraestrutura exposta à internet são candidatos comuns ao Level 2.

Como implementar um Benchmark sem interromper a produção

O erro mais comum é aplicar um Benchmark, especialmente o Level 2, diretamente em produção sem testá-lo primeiro. Algumas recomendações desabilitam funcionalidades das quais uma aplicação específica depende silenciosamente, um protocolo legado que um software antigo ainda utiliza ou uma permissão necessária para que um agente de monitoramento funcione corretamente. Implantar todas as recomendações de uma só vez e descobrir isso em produção é a forma de fazer com que projetos de hardening ganhem a reputação de causar indisponibilidades, o que normalmente leva a equipe a abandonar o esforço por completo.

Uma implantação em fases evita esse problema. Faça um piloto do Benchmark em um subconjunto representativo dos sistemas, idealmente incluindo pelo menos um sistema que execute cada aplicação crítica, e valide que tudo continua funcionando antes de ampliar a implantação. Quando uma recomendação realmente entrar em conflito com um requisito de negócio, documente a exceção, o motivo e qualquer controle compensatório, em vez de simplesmente ignorá-la. Um registro de exceções que um auditor possa revisar representa uma posição mais sólida do que um Benchmark aplicado de forma desigual, sem registro do motivo.

Duas abordagens funcionam melhor para realizar a implantação em escala do que fazer hardening manualmente em cada máquina. A primeira é uma Golden Image: faça o hardening de uma imagem mestre de acordo com o Benchmark, valide-a cuidadosamente e depois clone-a para cada novo sistema, em vez de reaplicar as mesmas configurações uma por uma. O CIS vende Hardened Images prontas por meio dos principais marketplaces de nuvem exatamente por esse motivo, embora muitas organizações prefiram criar e manter sua própria imagem mestre, adaptada à sua stack de aplicações. A segunda é Infrastructure as Code. Scripts de provisionamento escritos em Terraform ou Ansible podem incorporar diretamente as configurações de um Benchmark, para que cada servidor, container ou recurso de nuvem já seja criado em conformidade, em vez de depender de alguém se lembrar de executar uma etapa separada de hardening.

Nenhuma dessas abordagens elimina a necessidade de verificações contínuas. Um sistema criado a partir de uma Golden Image ou provisionado por meio de IaC em conformidade se afasta dessa baseline em poucas semanas à medida que patches são aplicados, softwares são instalados e alterações bem-intencionadas são feitas sob pressão. Os scans do CIS-CAT devem ser executados regularmente, e não apenas uma vez antes de uma auditoria, para que os desvios sejam identificados e corrigidos enquanto ainda representam uma pequena lacuna, em vez de aparecerem mais tarde como uma não conformidade.

Onde os CIS Benchmarks se encaixam em uma auditoria

A maioria dos frameworks de compliance exige uma baseline de configuração segura sem especificar o CIS, razão pela qual os CIS Benchmarks se tornaram uma das fontes de evidência mais utilizadas para esse requisito. O controle 8.9 do Annex A da ISO 27001, Configuration Management, exige configurações seguras documentadas e monitoradas para hardware, software, serviços e redes. Um CIS Benchmark, acompanhado de um relatório de conformidade do CIS-CAT, fornece evidências técnicas fortes para esse controle, no entanto o padrão de configuração que o auditor revisa ainda precisa ser o seu próprio padrão documentado, e não uma cópia sem alterações do PDF do CIS arquivada como política. O PCI DSS Requirement 2 exige padrões de configuração documentados para todos os componentes de sistema e cita padrões de hardening aceitos pelo mercado, incluindo CIS, como uma base aceitável, com a mesma ressalva: o padrão precisa ser adaptado ao seu próprio ambiente, e não apenas referenciado. A função Protect do NIST CSF espera que baselines de configuração segura sejam estabelecidas e mantidas, e as medidas técnicas do Article 21 da NIS2 abrangem segurança de sistemas e tratamento de vulnerabilidades, normalmente evidenciados por auditores de maneira semelhante.

Nosso guia de ISO 27001 e o guia de mapeamento entre NIST CSF e NIS2 cobrem onde a configuração segura se encaixa dentro desses frameworks mais amplos.

Erros comuns que vale a pena evitar

• Tratar hardening como um projeto com data de término: um Benchmark aplicado uma vez e nunca mais verificado se transforma em desvios não documentados em poucos meses.
• Aplicar Level 2 em todos os lugares por padrão: o custo operacional raramente compensa em sistemas que não precisam dele, e implantações malsucedidas prejudicam a disposição da equipe para aplicá-lo nos sistemas que realmente precisam.
• Pular o processo de exceções: ignorar silenciosamente recomendações que entram em conflito com uma necessidade de negócio deixa o auditor sem registro e o próximo engenheiro sem visibilidade sobre o motivo.
• Presumir que o Benchmark de uma versão continua válido para a próxima: o CIS publica Benchmarks separados para versões específicas das plataformas, e um guia escrito para uma versão anterior pode não contemplar configurações introduzidas posteriormente.
• Confundir Benchmarks com Controls ao falar com um auditor: os dois respondem a perguntas diferentes, e misturá-los em uma conversa de auditoria pode direcionar a coleta de evidências para o caminho errado.

Nada disso substitui um padrão de hardening documentado ou uma abordagem mais ampla de secure-by-design. É a camada específica e implementável que fica abaixo deles e, normalmente, a lacuna mais rápida de fechar quando você sabe que ela existe.

Como a Cyvra ajuda

Os serviços de Cibersegurança, Avaliação de Cibersegurança e Auditorias & Conformidade da Cyvra criam baselines de configuração segura que se sustentam durante uma auditoria, e não apenas no dia em que são criadas.

• Hardening baseado em Benchmark: implantações de Level 1 e Level 2 dimensionadas para o seu ambiente real e testadas em piloto antes de uma implantação mais ampla
• Registro de exceções: registros documentados e prontos para auditoria de qualquer recomendação que não possa ser aplicada, incluindo o motivo e controles compensatórios quando necessários
• Monitoramento de desvios: scans recorrentes de conformidade para que uma baseline protegida continue protegida, e não apenas no período da auditoria
• Mapeamento de compliance: evidências de configuração segura mapeadas diretamente aos requisitos de ISO 27001, PCI DSS, NIST CSF e NIS2

Avaliamos sua configuração atual em relação aos CIS Benchmarks adequados, documentamos exceções justificadas, priorizamos a remediação e produzimos evidências que você pode apresentar para ISO 27001, PCI DSS ou outros programas de compliance. Entre em contato com nossa equipe de Cibersegurança ou Auditorias & Conformidade para começar com uma revisão da baseline de configuração.