¿Cómo debo almacenar y mantener documentos de configuración seguros?

2

Tenemos muchos scripts que llamamos "líneas de base seguras" que permiten a nuestros usuarios de instalación de servidores / escritorios instalar sistemas operativos con las mejores prácticas de seguridad. Probamos que las líneas de base se hayan configurado correctamente mediante el uso de herramientas automáticas de verificación de cumplimiento.

El problema al que nos enfrentamos es que los documentos de Word se vuelven obsoletos rápidamente a medida que cambia la amenaza a la seguridad y los encontramos poco manejables de mantener y administrar.

Proceso actual:

  1. el administrador del servidor instala los servidores en una línea de base segura siguiendo las instrucciones en un documento de Word
  2. o escriba secuencias de comandos de inicio rápido para instalar automáticamente los sistemas operativos en una línea de base segura basada en el documento de Word.
  3. De vez en cuando, el documento de Word se actualiza cuando se reconoce una nueva amenaza.

¿Hay una mejor manera de almacenar y mantener líneas de base? para que:

  • son más fácilmente auditables
  • es más fácil mantenerse actualizado reconociendo amenazas nuevas y actuales
  • es más fácil registrar excepciones donde algunos sistemas no pueden cumplir con los mejores principios de seguridad
  • son fácilmente versionados.
pregunta Callum Wilson 09.10.2013 - 14:50
fuente

2 respuestas

3

Como algunas personas lo han recomendado, use una herramienta de administración de configuración como Puppet (recomendado), Chef, etc. Use VCS como Git para almacenar revisiones de los manifiestos de Puppet. Con Puppet, puede definir su línea de base segura y simplemente aplicarla a cualquier número de máquinas que desee. Agregue algunos comentarios al código Puppet (código Ops) y tendrá su "documento de configuración".

    
respondido por el Matrix 10.10.2013 - 10:03
fuente
2

Generalmente, una línea de base no se cambia con frecuencia. Por lo general, dura mucho tiempo con un estándar que es un enfoque más teórico y que puede ser tecnológicamente independiente. La línea de base es tecnológicamente dependiente y debe estipular cómo configurar una nueva máquina para que se endurezca adecuadamente con respecto a la seguridad.

Un paso podría ser realizar configuraciones genéricas, que ya se han fortalecido antes de implementarse.

Si comienza a involucrar fuentes de inteligencia de vulnerabilidad, está en el campo de la administración de parches, no en la línea de base. Una línea de base debe indicar la actualización de la máquina a la versión más reciente. Un estándar debe explicar que todas las máquinas deben actualizarse a intervalos regulares utilizando el método de administración de parches. El proceso de administración de parches no debe definirse dentro de la propia línea de base.

Normalmente, la auditoría se debe realizar de la siguiente manera:

  • después de la implementación final, el dispositivo se audita para ver si la configuración tiene los valores correctos
  • a ciertos intervalos, las máquinas deben seleccionarse al azar y la configuración debe extraerse, bajo la supervisión del auditor, y debe verificarse con respecto a la línea de base. Los scripts de cumplimiento pueden ejecutarse, pero deberán actualizarse en cada cambio de línea de base (que normalmente no debería ser tan frecuente).

Para los siguientes pasos:

  • es más fácil mantenerse actualizado reconociendo amenazas nuevas y actuales
  • es más fácil registrar excepciones donde algunos sistemas no pueden cumplir con los mejores principios de seguridad

En primer lugar, tenga en cuenta que, incluso cuando se reconozcan las amenazas actuales, estas no llegarán a cientos al año, tal vez diez como máximo (dependiendo del tamaño de los dispositivos de su organización, si tiene 10 dispositivos diferentes que realizan la misma tarea que usted debería revisar su aprovisionamiento de infraestructura y el proceso de diseño / toma de decisiones).

Para realizar un seguimiento de las excepciones, se debe tener en cuenta que las excepciones deben registrarse en el proceso de evaluación de riesgos. Si hay un riesgo que debe aceptarse, se debe crear un documento formal que detalle el problema, el riesgo y la solución sugerida. Un comité de auditoría / riesgo / negocio puede revisar este documento y aprobar o rechazar la solución.

Las versiones serán mejores si:

  • empiezas a usar archivos PDF versionados
  • registre cada cambio en la línea de base en su herramienta de administración de cambios

Cada actualización de un documento será el resultado de un incidente determinado. O este incidente se debió a la inteligencia de amenazas (por ejemplo, que necesita deshabilitar la compresión SSL) o debido a problemas operativos. Este incidente generará una respuesta, a partir de esta respuesta se debe generar un nuevo ticket que indique que el comité de cambios debe actualizar y validar el documento.

Si no ha estado utilizando una herramienta de gestión de riesgos / gestión de riesgos, le sugeriría encarecidamente que cree una.

    
respondido por el Lucas Kauffman 09.10.2013 - 15:33
fuente

Lea otras preguntas en las etiquetas