Tus detecciones están sin probar hasta que generas el comportamiento

Pregúntale a un equipo de seguridad cuántas de sus reglas de detección funcionan. La respuesta segura de sí misma es un porcentaje de cobertura sacado de un panel. La respuesta honesta es que nadie lo ha comprobado, porque la única evidencia de que una regla funciona es que se haya disparado, y casi ninguna regla se ha disparado nunca.

Ese es el problema que resuelve la emulación de adversario. En vez de esperar a que un atacante pruebe tus detecciones, ejecutas tú la técnica, a propósito, y ves qué pasa.

Qué es y en qué se diferencia de una prueba de penetración

Una prueba de penetración pregunta si un atacante puede entrar. Es adversaria, está acotada en el tiempo, y su salida es una lista de debilidades explotables. Valiosa, y no dice casi nada sobre si te habrías dado cuenta.

La emulación de adversario pregunta si puedes ver una técnica conocida cuando ocurre. No es adversaria, no intenta ser sigilosa, y su salida es una matriz de cobertura: para cada técnica, ¿capturó la telemetría el evento?, ¿saltó una regla?, ¿llegó una alerta a una persona?

La distinción importa porque encuentran fallos distintos. Una prueba de penetración encuentra la forma de entrar. La emulación encuentra que tienes una cobertura excelente del puesto de trabajo y ninguna visibilidad del plano de control de tu nube, que es el hueco que convierte una intrusión pequeña en una de cuatro días.

El equipo morado es la forma colaborativa: el lado ofensivo ejecuta una técnica mientras el defensivo mira, y los dos arreglan lo que encuentran en la misma sesión. Es muchísimo más productivo que un ejercicio de equipo rojo seguido de un informe tres semanas después, porque el bucle de realimentación son minutos.

Las pruebas atómicas son la entrada barata

Atomic Red Team es una biblioteca de pruebas pequeñas y autocontenidas, cada una ejecutando una técnica con un comando documentado, mapeada a un marco de ataque y con un paso de limpieza.

El atractivo es la granularidad. No estás ejecutando una cadena de ataque completa; estás ejecutando una acción, como crear una tarea programada para persistencia o volcar un almacén concreto de credenciales, y preguntando inmediatamente si algo se enteró.

El flujo es lo bastante simple como para hacerlo en una tarde: elige una técnica relevante para tu entorno, ejecuta la prueba en una máquina que controles, busca el evento en tu telemetría, comprueba si coincidió una regla, comprueba si llegó una alerta. Anota el resultado en una matriz y ejecuta la limpieza.

Existen marcos de emulación completos para encadenar técnicas en secuencias realistas, y merece la pena graduarse a ellos. Empieza con lo atómico, porque los resultados individuales son accionables y una cadena completa produce una narrativa en vez de una lista de arreglos.

Los cuatro resultados y qué significa cada uno

Cada prueba aterriza en uno de cuatro estados, y distinguirlos es el objetivo del ejercicio.

Sin telemetría. El evento no quedó registrado en ninguna parte. Es el peor resultado y la sorpresa más frecuente. Ninguna regla puede detectar lo que nunca se registró, y el arreglo es un cambio de registro y no de detección, lo que normalmente lleva un coste asociado.

Telemetría pero sin regla. El dato está y nadie está mirando. El arreglo más barato de la lista: escribe la regla, como se describe en detección como código.

La regla saltó pero la alerta no llegó a nadie. Severidad demasiado baja, encaminamiento roto, canal silenciado. Común y embarazoso, y el arreglo está en el pipeline de alertado y no en la detección, que es la disciplina de alertas que la gente atiende.

La alerta llegó a una persona que supo qué hacer. El único estado que aprueba, y exige que el runbook exista, que es el argumento de el runbook que usas a las tres de la madrugada.

Casi todos los primeros ejercicios producen una distribución que impacta al equipo: una parte grande en los dos primeros estados, concentrada exactamente en las áreas que nadie ha probado.

Prueba lo que te importa a ti, no el marco entero

Los marcos de técnicas de ataque contienen cientos de técnicas. Intentar cubrirlas todas produce un proyecto largo y una matriz que nadie lee.

Prioriza por lo que se usaría de verdad contra ti. Para una empresa nativa de la nube eso significa técnicas de identidad y de plano de control: creación de credenciales, asunción de roles desde ubicaciones inusuales, escalada de permisos, desactivación del registro, compartición de instantáneas con una cuenta externa, borrado masivo de copias de seguridad.

Esas son las que más probablemente aparecerán en un incidente real y las que menos probablemente están cubiertas, porque casi todo el contenido de detección está escrito para un parque tradicional de puestos de trabajo. Emularlas es además directo: crea una cuenta de prueba, asume un rol desde una ubicación inesperada, desactiva un rastro en un entorno de pruebas, y mira qué pasa.

Para un entorno de contenedores, añade las técnicas de tiempo de ejecución: shell en un contenedor, lectura del token de la cuenta de servicio, montaje del socket del tiempo de ejecución, conexión saliente desde una carga que no debería iniciar ninguna. Estos son los casos que Falco te dice qué hizo un contenedor pretende cubrir, y la emulación es cómo verificas que de verdad lo hace.

Ejecutarlo con seguridad

Esto es comportamiento real de atacante ejecutado sobre tus sistemas, así que los controles importan.

Consigue autorización por escrito antes de ejecutar nada, nombrando los sistemas, la ventana, las técnicas y las personas implicadas. Avisa a tu propio equipo de operaciones de seguridad salvo que estés probando deliberadamente su respuesta y, si lo estás, avisa al menos a una persona para que se pueda detener.

Ejecuta primero en un entorno de no producción, siempre. Algunas pruebas modifican el estado del sistema, y los scripts de limpieza son buenos pero no están garantizados. Lee cada prueba antes de ejecutarla en vez de lanzar un paquete entero.

Evita cualquier cosa destructiva o genuinamente disruptiva. La emulación va de cobertura de detección, no de demostrar que puedes causar daño, y casi todas las técnicas que merece probar son observables sin perjuicio.

Lleva un registro de qué se ejecutó, cuándo y quién, para que una alerta generada por el ejercicio se pueda identificar como tal y para que nadie pase una tarde investigándote.

Hazlo continuo, y entonces compensa el montaje

Un ejercicio puntual produce una foto y una lista de huecos. Repítelo dentro de seis meses y un cuarto de los resultados habrá cambiado, porque una fuente de registro se movió, una regla se ajustó hasta la inutilidad, o una actualización de plataforma cambió un formato de evento.

La versión madura ejecuta un subconjunto de forma automática y programada contra un entorno de pruebas, como prueba de regresión de la detección. Una regla que deja de coincidir debería romper una compilación, igual que lo hace una prueba de aplicación, que es la extensión natural de mantener las detecciones en un repositorio.

Sigue un número a lo largo del tiempo: el porcentaje de técnicas probadas que llegan al cuarto estado. Esa única cifra es una medida mucho más honesta de la capacidad de detección que un recuento de reglas, y es la que hay que enseñar a dirección.

Lo que se olvida

• Los porcentajes de cobertura son ficción autorreportada hasta que se prueban. Un panel que afirma un noventa por ciento de cobertura afirma que existen reglas, no que funcionen.
• La limpieza a veces falla. Verifica el estado del sistema después en vez de fiarte del script.
• La emulación genera alertas que parecen reales. Coordina, o vas a disparar una respuesta a incidentes genuina.
• La detección funciona hasta una actualización de plataforma. Los formatos de evento y los nombres de campo cambian, y las reglas dejan de coincidir en silencio.
• No prueba la respuesta. Saber que una alerta saltó es distinto de saber que el equipo podría contener la intrusión. Eso necesita un día de juego, como en los cinco primeros experimentos de caos aplicado a seguridad.

Qué hacer esta semana

Elige una técnica: crea una clave de acceso nueva para una identidad privilegiada en tu nube, en una cuenta de pruebas. Y después responde a tres preguntas. ¿Quedó registrado?, ¿coincidió una regla?, ¿se enteró alguien? Esa única prueba lleva quince minutos y en la mayoría de las organizaciones falla en la segunda o la tercera pregunta, lo que la convierte en los quince minutos más persuasivos disponibles para un equipo de seguridad. Hacemos este ejercicio en la fase de detección de un proyecto de seguridad.