Mike,
geralmente existem algumas fontes de bons guias disponíveis para proteção de segurança.
- Os DISA STIGs
- Os SRGs da NSA
- NIST
- Referências CIS
- Orientação do fornecedor
- SANS
- Livros específicos para proteção
No meu trabalho, usamos uma combinação dos STIGs da DISA, juntamente com o fantoche para Linux. Eu seria mais provável dizer que isso é inadequado e pressionar por algumas das recomendações abaixo.
Lembre-se de que as guias de proteção acima se sobrepõem e algumas áreas ausentes. Uma prática recomendada é rastrear todas as opções de configuração por meio de guia em um banco de dados ou planilha, para que você possa ter a maior cobertura.
Uma maneira alternativa de fazer a mesma coisa é criar scripts de proteção ou auditoria com base no descrito acima e, em seguida, executar auditorias para descobrir onde estão as lacunas entre os diferentes padrões.
Não acredito que os guias do RHEL sejam suficientes - prefiro as saídas da NSA, DISA e NIST. Mas, os guias da Red Hat são um ótimo ponto de partida.
Como a NSA e a DISA começam a trabalhar nos padrões de proteção com antecedência, no rascunho, isso pode ser uma boa fonte para você. Se você tem um amigo no Departamento de Defesa, também pode acessar o material de pré-lançamento. Devido ao estado atual do DISA STIG para Red Hat, eu diria que a NSA provavelmente produzirá algo mais rápido. Eu posso verificar com eles e ver onde eles estão. Eu recomendo começar a avançar para 6 em um ambiente de teste agora. Teste seus scripts de proteção em 6.
Envolver assistência externa para desenvolver diretrizes de proteção da segurança
Considere um compromisso com um engenheiro de segurança focado especificamente no fortalecimento da segurança do Linux para produzir orientações para você. A Red Hat também pode disponibilizar seus funcionários para compromissos, a fim de acelerar os esforços de engenharia de segurança.
Tudo o que você disse até agora indica uma abordagem de devida diligência e segurança razoável. Com base nisso, acho que, considerando o exposto acima, você pode avançar para o RHEL6. No entanto, adicionarei algumas tarefas adicionais que você poderia considerar, pois presumo que você esteja trabalhando em um ambiente regulamentado com muita consciência de segurança.
Aumentando sua abordagem com uma avaliação de risco
Se você quisesse levar sua abordagem para o próximo nível e justificá-la de uma maneira que passasse na revisão até mesmo pelo auditor mais retentivo, considere executar uma avaliação completa dos riscos de desenvolvimento usando o NIST 800-30, juntamente com os conjuntos de controles específicos usados no seu indústria. Isso, suportado por testes e análises de segurança. A formalização de uma avaliação de riscos permitirá uma boa documentação dos riscos apresentados com o RHEL6 e alguns controles compensatórios em potencial que você pode adicionar para reforçar eventuais pontos fracos.
Adicionando um teste de penetração
Levando isso além da avaliação de risco, você pode contratar um testador de penetração com forte experiência em Linux para tentar penetrações de caixa branca ou caixa preta do host RHEL6 após algumas configurações seguras. Um sistema operacional de base segura pode não apresentar muita superfície de ataque, portanto, carregá-lo com aplicativos apresentaria uma plataforma de ataque muito mais realista, que permitiria melhor entender possíveis vetores de ataque. Ao circular no final, usando o relatório de teste da caneta, você pode aumentar seu trabalho anterior, fechar lacunas, adicionar controles adicionais e seguir em direção às operações com muito mais calor e distorção.