Miguel,
En general, existen algunas fuentes de buenas guías para reforzar la seguridad.
- Los DISTI STIG
- Los SRG de la NSA
- NIST
- Puntos de referencia de la CEI
- Guía del vendedor
- SANS
- Libros específicos para el endurecimiento
En mi trabajo, utilizamos una combinación de DISA STIG, junto con Puppet para Linux. Es más probable que diga que es inadecuado y presionaré por algunas de las recomendaciones a continuación.
Tenga en cuenta que las guías de endurecimiento anteriores se superponen y faltan algunas áreas. Una práctica recomendada es realizar un seguimiento de todas las opciones de configuración a través de una guía en una base de datos u hoja de cálculo, para que pueda tener la mayor cobertura.
Una forma alternativa de hacer lo mismo es crear secuencias de comandos de endurecimiento o auditoría basadas en lo anterior, y luego realizar auditorías de usted mismo para descubrir dónde están las brechas entre los diferentes estándares.
No creo que las guías de RHEL sean suficientes. Prefiero los resultados de NSA, DISA y NIST. Pero, las guías de Red Hat son un excelente punto de partida.
A medida que la NSA y la DISA comienzan a trabajar en el endurecimiento de los estándares con mucha anticipación, en borrador, esa puede ser una buena fuente para usted. Si tiene un amigo en DoD, también puede obtener acceso al material de prelanzamiento. Debido al estado actual de DISA STIG para Red Hat, diría que es probable que la NSA produzca algo más rápido. Puedo consultar con ellos y ver dónde están. Recomiendo comenzar ahora a avanzar a 6 en un entorno de prueba. Haga que sus scripts de refuerzo se prueben en 6.
Involucrando asistencia externa para desarrollar una guía de seguridad
Considere un compromiso con un ingeniero de seguridad enfocado específicamente en el fortalecimiento de la seguridad de Linux para producir orientación para usted. Red Hat también puede poner a disposición a sus empleados para compromisos a fin de acelerar los esfuerzos de ingeniería de seguridad.
Todo lo que ha dicho hasta ahora indica un enfoque de diligencia debida y seguridad razonable. En base a eso, creo que considerando lo anterior, está claro para avanzar a RHEL6. Sin embargo, voy a agregar algunas tareas adicionales que podría considerar ya que supongo que está trabajando en un entorno regulado que es muy consciente de la seguridad.
Aumentando su enfoque con una evaluación de riesgos
Si desea llevar su enfoque al siguiente nivel y justificarlo de una manera que pasaría incluso la revisión del auditor más retentivo, considere realizar una evaluación completa del riesgo de desarrollo utilizando NIST 800-30 junto con los conjuntos de controles particulares utilizados en su industria. Esto, respaldado por pruebas y análisis de seguridad. Tener una evaluación de riesgos formalizada permitirá una buena documentación de los riesgos presentados al seguir adelante con RHEL6, y algunos posibles controles compensatorios que podría agregar para reforzar cualquier debilidad potencial.
Agregar una prueba de penetración
Llevándolo incluso más allá de la evaluación de riesgos, podría contratar un probador de penetración con una sólida experiencia en Linux para intentar penetraciones de caja blanca o caja negra de su host RHEL6 después de algunas configuraciones seguras. Un sistema operativo base seguro podría no presentar mucha superficie de ataque, por lo que cargarlo con aplicaciones presentaría una plataforma de ataque mucho más realista que le permitiría comprender mejor los posibles vectores de ataque. Dando vueltas al final, usando el informe de prueba de la pluma, puede aumentar su trabajo anterior, cerrar cualquier brecha, agregar controles adicionales y dirigirse a las operaciones con mucho más calor y confusión.