Mike,
geralmente existem algumas fontes de bons guias para fortalecer a segurança.
- Os pontos de acesso da DISA
- Os SRGs da NSA
- NIST
- Benchmarks da CIS
- Orientação do fornecedor
- SANS
- Livros específicos para endurecimento
No meu trabalho, usamos uma combinação dos DISA STIGs, juntamente com o fantoche para Linux. Eu estaria mais propenso a dizer que isso é inadequado e insistir em algumas das recomendações abaixo.
Tenha em mente que as guias de endurecimento acima têm sobreposição 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 mais cobertura.
Uma maneira alternativa de fazer a mesma coisa é criar scripts de auditoria ou auditoria baseados em cima e depois executar auditorias de si mesmo para descobrir onde estão as lacunas entre os diferentes padrões.
Eu não acredito que os guias do RHEL sejam suficientes - eu prefiro os resultados da NSA, DISA e NIST. Mas os guias da Red Hat são um excelente ponto de partida.
À medida que a NSA e a DISA começam a trabalhar nos padrões de proteção antecipadamente, em rascunho, isso pode ser uma boa fonte para você. Se você tiver um amigo no DoD, também poderá 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 recomendaria começar a avançar para 6 em um ambiente de teste agora. Obtenha seus scripts de proteção testados em 6.
Envolvendo ajuda externa para desenvolver diretrizes de proteção de segurança
Considere um envolvimento 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 due diligence e segurança razoável. Com base nisso, acho que considerando acima, você está claro para avançar para o RHEL6. No entanto, adicionarei algumas tarefas adicionais que você poderia considerar, pois presumo que esteja trabalhando em um ambiente regulamentado que é muito consciente da segurança.
Aumentando sua abordagem com uma avaliação de risco
Se você quiser levar sua abordagem para o próximo nível e justificá-la de uma forma que passe na revisão até mesmo do auditor mais retentivo, considere a realização de uma avaliação completa do risco de desenvolvimento usando o NIST 800-30 junto com os conjuntos de controles específicos. usado em sua indústria. Isso, apoiado por testes de segurança & análise. Ter uma avaliação de risco formalizada permitirá uma boa documentação dos riscos apresentados, avançando com o RHEL6, e alguns controles de compensação em potencial que você poderia adicionar para reforçar possíveis fraquezas.
Adicionando um teste de penetração
Levando-o além da avaliação de risco, você poderia envolver um testador de penetração com um strong histórico do Linux para tentar penetrações em caixa branca ou caixa preta de seu 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á-la com aplicativos apresentaria uma plataforma muito mais realista para ataque, o que permitiria compreender melhor os possíveis vetores de ataque. Circulando no final, usando o relatório de teste da caneta, você pode aumentar seu trabalho anterior, fechar quaisquer lacunas, adicionar controles adicionais e ir em direção a operações com muito mais calor e indiferença.