Las configuraciones incorrectas de Schrödinger

Es jueves por la tarde y usted se prepara para salir del trabajo un poco antes porque… puede. Pero entonces ese molesto Repartidor de Notificaciones (también conocido como Slack) lanza un nuevo mensaje en su canal de alertas de seguridad:

Vaya. Alguien acaba de hacer pública una instantánea de un volumen de almacenamiento. ¿Es un ataque? ¿Un error? ¿Alguien que simplemente no sabe cuáles son las políticas?

Las configuraciones incorrectas tienen tres estados de ser

Esto es algo que he empezado a llamar las configuraciones incorrectas de Schröedinger porque tengo la mala costumbre de usar principios de la mecánica cuántica para explicar la seguridad de la información. Me sorprendería que usted no conociera ya el gato de Schröedinger, el famoso experimento mental que Erwin Shröedinger utilizó para ilustrarle a Albert Einstein la paradoja de la superposición cuántica. La versión muy resumida es que si usted encierra a un gato en una caja con un veneno activado por desintegración radiactiva, el gato no está ni vivo ni muerto, y por lo tanto se encuentra en un estado de estar vivo Y muerto, hasta que usted abre la caja y verifica.

Sí, eso es absurdo, y ese era el punto. Sobre todo para quienes tenemos gatos a los que NO LES GUSTA QUEDAR ATRAPADOS EN CAJAS. Aunque podría escribir toda una serie de blogs sobre gatos que se meten solos en cajas pero se enojan muchísimo si uno los mete en ellas y… me estoy desviando.

Volvamos a la seguridad en el cloud. El concepto fundamental detrás del experimento mental es que algo existe en múltiples estados simultáneos hasta que uno lo observa, y ese acto de observación fuerza una respuesta. Por supuesto, estoy distorsionando y simplificando para mis propios fines, así que quienes tengan formación en física, por favor no me envíen correos enojados.

La versión cloud de este concepto es que cualquier configuración incorrecta existe en un estado de ser un ataque, un error o una violación de políticas hasta que usted investiga y determina la causa.

Hay 5 características del cloud que respaldan este concepto:

• Los equipos de cloud y de desarrollo suelen tener más autonomía para administrar directamente su propia infraestructura cloud.
• El plano de administración del cloud es accesible a través de Internet.
• La fuente más común (hoy) de ataques al cloud son las credenciales robadas.
• Muchas configuraciones incorrectas crean estados idénticos a las acciones de un atacante (por ejemplo, hacer pública una instantánea).
• Es fácil crear una configuración incorrecta por accidente y, a veces, se hacen a propósito para cubrir una necesidad, pero la persona que realiza la acción no se da cuenta de que es un problema de seguridad.

Este concepto también se cumple en la infraestructura tradicional, aunque en mucho menor grado, ya que los equipos tienen menos autonomía. Un desarrollador de una aplicación normalmente no tiene la capacidad de modificar directamente las reglas de firewall y las tablas de enrutamiento. En el cloud, eso es bastante común, al menos en algunos entornos.

Asuma que es un ataque hasta que se demuestre lo contrario

Uno de los principios más importantes de la respuesta a incidentes en el cloud es que usted debe tratar las configuraciones incorrectas como eventos de seguridad y debe asumir que son ataques hasta que se demuestre lo contrario.

Esto representa un cambio de mentalidad, ya que en seguridad estamos acostumbrados a pensar en términos de vulnerabilidades y superficie de ataque, pero las vemos como algo que analizamos de forma periódica y que, en gran medida, tratamos como problemas por remediar. Lo que propongo es que en la computación en el cloud elevemos las configuraciones incorrectas detectadas al mismo nivel que una alerta de IDS o EDR. No son meros problemas de cumplimiento, son posibles indicadores de compromiso.

Y no, esto no se aplica a todas las configuraciones incorrectas en todos los entornos. Tenemos que filtrar y priorizar. Mejor aún, tenemos que comunicarnos, porque normalmente la forma más sencilla de averiguar si una configuración incorrecta es un ataque malicioso es simplemente preguntarle a la persona que hizo el cambio si tenía la intención de hacerlo.

Como tengo que resumir las cosas para las clases de capacitación, he identificado tres fuentes principales de telemetría de seguridad:

• Registros
• Eventos del proveedor de cloud (por ejemplo, eventos de Security Hub)
• Configuraciones incorrectas del cloud, que pueden provenir de su herramienta CSPM, de escáneres OSS o similares

La mayoría de las personas que trabajan en seguridad del cloud ya han interiorizado este concepto, pero no siempre lo explicamos. Si observa algunas herramientas de detección y respuesta en el cloud (CDR), verá que generan alertas para ciertas configuraciones incorrectas. Esto difiere de la modalidad predeterminada de las herramientas CSPM, que crean hallazgos en informes y tableros. Esos son importantes para el cumplimiento y la higiene general de seguridad, pero dado que los atacantes hacen cosas desagradables como compartir imágenes de disco con otras cuentas o crear puertas traseras de acceso a roles de IAM, un subconjunto de configuraciones incorrectas realmente debe tratarse como si fueran indicadores de compromiso hasta que se demuestre lo contrario.

Internamente (y en la plataforma DisruptOps) manejamos esto con un conjunto de detectores de amenazas en tiempo real que activan evaluaciones a partir de llamadas de API identificadas. Toma entre 15 y 30 segundos identificar una configuración incorrecta y enviarla a seguridad y al responsable del proyecto por Slack (o Teams), como se ve arriba. Estas alertas se tratan igual que un hallazgo de GuardDuty o cualquier otro indicador de compromiso, pero usar ChatOps para validar actividades también nos ayuda a clasificarlas muy rápido sin tener que realizar un análisis profundo cada vez.

La recomendación en resumen: atienda las configuraciones incorrectas clave del cloud casi en tiempo real y trátelas como indicadores de compromiso hasta que se demuestre lo contrario.

Ningún gato resultó herido durante la redacción de este artículo.