¿Qué son los desvíos en configuraciones o 'configuration drift'?

Image

En una publicación anterior de mi colega Irfahn Khimji, habló sobre cómo reducir la superficie de ataque en su infraestructura de red. Organizaciones como el Centro de Seguridad de Internet (CIS) proporcionan pautas sobre cómo configurar mejor los sistemas operativos para minimizar la superficie de ataque. CIS les llama puntos de referencia o benchmark en inglés. Muchas políticas de seguridad establecen que todos los sistemas implementados deben configurarse de forma segura. Algunas políticas de seguridad van más allá al requerir que estas configuraciones seguras sean monitoreadas de manera continua y que los sistemas se mantengan con configuraciones seguras. Esto desde una perspectiva de política de seguridad, es un gran comienzo. La realidad del asunto es que, si bien es fácil implementar un sistema de forma segura con algo así como una imagen hardenizada por CIS, garantizar que esa configuración se mantiene a lo largo del tiempo puede ser un desafío.

¿Qué son los desvíos en configuraciones o configuration drift?

A medida que pasa el tiempo, los propietarios de aplicaciones deben realizar modificaciones en sus aplicaciones e infraestructura subyacente para mejorar continuamente el producto que proporcionan a sus clientes. Estos clientes pueden ser internos al negocio o externos. A medida que ocurren esas modificaciones y cambios, cambia la configuración de las aplicaciones y la infraestructura. Estos cambios pueden ser benignos o pueden sacar a los sistemas de un estado hardenizado. Esto se conoce como "desviación de configuración." Dependiendo de la gravedad de la desviación, podría haber un riesgo significativo para la organización. Examinemos algunos ejemplos de desviación de configuración para ver cuál sería el riesgo para la organización.

Ejemplo de desvío en configuración 1: un nuevo puerto en escucha

Nuestra compañía ha decidido agregar esta sección innovadora a nuestra aplicación que permitirá a nuestros clientes utilizar nuestros servicios de una manera mucho más ágil que nuestra competencia. Para lograr esto, necesitamos abrir un nuevo puerto de comunicación para nuestro protocolo propietario. El equipo de negocios creó un ticket, abrió el puerto en los servidores y firewalls y la aplicación comenzó a funcionar sin problemas. Después de seis meses, durante la auditoría anual de seguridad, los auditores se preguntan por qué este puerto está abierto cuando no está documentado como permitido en la política de seguridad. ¿Es este un riesgo aceptable para la organización? La mayoría de las veces, el equipo de seguridad pasará decenas de horas tratando de rastrear lo que sucedió para responder esta pregunta. En este escenario hipotético, es un riesgo aceptable. El problema aquí radica en el hecho de que los auditores no pudieron determinar fácilmente por qué el puerto estaba abierto y cuál podría ser el riesgo y el beneficio. Si el equipo de seguridad estuviera rastreando la desviación de la configuración y documentando modificaciones a la línea de base hardenizada ya conocida, sería una respuesta fácil.

Ejemplo de desvío en configuración 2: el uso de privilegios elevados

Un desarrollador de aplicaciones necesita iniciar sesión repetidamente en un solo servidor. A veces, solo necesita verificar algo rápidamente, y a veces necesita hacer un pequeño cambio. Puede iniciar sesión para verificar cosas usando una cuenta regular sin ningún problema, pero cuando se necesita hacer un cambio en producción, se necesita una credencial de administrador especial. Solicitar una credencial especial puede volverse muy tediosa y llevar mucho tiempo, ¡especialmente con todas las entregas y plazos que se tienen! Como tiene esta credencial de administrador, puede agregar el grupo "Usuarios" a las diferentes categorías y otorgar los privilegios necesarios. No es gran cosa, ¿cierto? Es solo un servidor. ¡No lo agregó a todo el dominio! En este escenario hipotético, una modificación como esta, incluso para un solo servidor, puede representar un riesgo significativo para la organización. El usuario puede haber pasado por el control del proceso de cambio apropiado para el cambio que el usuario pretendía hacer inicialmente, pero sin verificación del cambio exacto que realizó el usuario, el equipo de seguridad no lo sabría hasta que este servidor en particular fuera auditado manualmente.

Ejemplo de desvío en configuración 3: almacenamiento en la nube

Debido a las decenas de brechas de datos que se han producido en los últimos tiempos, Amazon actualizó su política de seguridad sobre el acceso público en los buckets de S3. Al crear un nuevo bucket, todo el acceso público se bloquea de forma predeterminada.

Image

Mantener esta configuración predeterminada implicaría lo siguiente:

• Los nuevos buckets u objetos serían privados de manera predeterminada, y cualquier nueva ACL de acceso público para los buckets y objetos existentes estaría restringida.
• Se ignorarían todas las ACL que otorgan acceso público a buckets y objetos.
• Toda nueva política de bucket y Access point que otorgue acceso público quedaría bloqueada.
• Se bloqueará todo acceso público y de cuentas cruzadas para buckets o Access points con políticas que otorguen acceso público a otros buckets y objetos.

Esta es una buena práctica de seguridad, pero podría obstaculizar ciertas operaciones de TI y, por lo tanto, la configuración de bloqueo podría estar deshabilitada. Esto podría suceder desde el principio durante la creación del bucket o incluso más tarde por un administrador, ya sea para un caso de uso temporal (y luego olvidado) o uno permanente, por ejemplo, un sitio web podría tener algunos documentos compartidos públicamente. Además, un error en un script automatizado podría cambiar la configuración de acceso al bucket, lo que llevaría a una brecha de datos. Existen configuraciones seguras y mejores prácticas que pueden establecerse inicialmente, pero es igualmente importante desde el punto de vista de seguridad monitorear cualquier desviación de las configuraciones aprobadas.

Tres formas principales de mantener la configuración de un sistema

Hay tres formas principales de mantener la configuración de un sistema. Dependiendo del nivel de madurez del programa de seguridad de una organización en particular, pueden estar haciendo esto en algún nivel u otro. El primer nivel sería monitorear manualmente las configuraciones de los sistemas (ver figura A). Esto consume mucho tiempo y, por lo tanto, no se hace de forma regular, si es que se hace. Los sistemas se dejan solos hasta que se detecta un incidente, o deban actualizarse. Un subconjunto de estos sistemas puede ser auditado debido a una regulación de cumplimiento. Si este es el caso, la organización constantemente tratará de limitar el número de sistemas dentro del alcance de la auditoría, por lo que hay menos sistemas para observar. Un auditor generalmente solicitará la confirmación de un subconjunto de dispositivos dentro de un alcance limitado para verificar su cumplimiento. Solo si se determina que ese subconjunto no cumple, la organización tomará alguna medida importante.

Image

Figura A El segundo nivel trae una solución para escanear el cumplimiento (ver figura B). Si bien no es tan tedioso como el primer nivel, esto todavía requiere un cierto nivel de interacción para crear credenciales administrativas para que la herramienta escanee, así como a alguien para programar o ejecutar los escaneos cuando sea necesario y corregir los resultados. Esto generalmente se hace una vez al mes o una vez al trimestre para tratar de adelantarse al proceso de auditoría. Nuevamente, esto se limita comúnmente a los sistemas dentro de una zona de cumplimiento. Los sistemas fuera de esta zona de cumplimiento a menudo se quedan atrás y solo se verifican cuando están comprometidos o necesitan actualizarse. El CIS Critical Security Control # 5 recomienda que todos los sistemas de la organización estén provistos de configuraciones seguras y, por lo tanto, esa configuración debe mantenerse en todos los sistemas de forma continua, incluso cuando se producen cambios.

Image

Figura B El tercer nivel y el más maduro de estos, sería monitorear todos los sistemas casi en tiempo real (ver figura C). Esto requeriría que los sistemas estén provistos de un agente liviano que pueda monitorear los sistemas sin la necesidad de credenciales para iniciar sesión ni de la habilitación de Auditoría del SO. El agente debería implementarse en todos los sistemas, ya sea agregándolo en las imágenes que se implementan o asegurándose de que esté incluido en el proceso de implementación de una herramienta automatizada, como Puppet o Chef. Una vez que están activados y monitoreados, en el momento que se realice un cambio que deje al sistema fuera de cumplimiento, se puede iniciar un proceso de remediación. Por ejemplo, esto se puede hacer creando automáticamente un ticket, enviando un correo electrónico o alertando al Centro de Operaciones de Seguridad (SOC) a través de una alerta en la herramienta de Gestión de Incidentes y Eventos de Seguridad (SIEM) de la organización.

Image

Figura C Para medir la efectividad de esto, CIS recomienda rastrear las siguientes métricas:

1. ¿Cuál es el porcentaje de sistemas del negocio que actualmente no están configurados con una configuración de seguridad que coincida con el estándar de configuración aprobado por la organización (por unidad de negocio)?
2. ¿Cuál es el porcentaje de sistemas del negocio cuya configuración de seguridad no es reforzada por las aplicaciones de manejo de configuración de la organización (por unidad de negocio)?
3. ¿Cuál es el porcentaje de sistemas del negocio que no están actualizados con los últimos parches de seguridad de software del sistema operativo disponibles por unidad de negocio?
4. ¿Cuál es el porcentaje de sistemas del negocio que no están actualizados con los últimos parches de seguridad de aplicaciones de software empresarial disponibles (por unidad de negocio)?
5. ¿Cuál es el porcentaje de sistemas comerciales no protegidos por aplicaciones de software de evaluación de integridad de archivos (por unidad comercial)?
6. ¿Cuál es el porcentaje de cambios no autorizados o indocumentados con impacto en la seguridad (por unidad de negocio)?

Una vez que se establecen estas métricas, utilizando el proceso de mejora continua, los equipos de seguridad y de negocios deben trabajar juntos para aumentar el porcentaje de sistemas que se monitorean y luego deben remediar los sistemas donde ocurre la desviación de la configuración. Mantener resultados mínimos de desviación ayuda a mantener el estado seguro de los sistemas comerciales, lo que ayuda directamente con la postura general de riesgo de la organización. Para obtener más información sobre cómo la Administración de configuración de seguridad ayudará a mantener su negocio seguro, haga clic aquí. Alternativamente, puede encontrar más información sobre las soluciones SCM de Tripwire aquí.

Nota del editor: este blog fue traducido del inglés: (https://www.tripwire.com/state-of-security/security-data-protection/what-is-configuration-drift/)