Guardian360
Empieza la prueba gratuitaHazte partner
← Todas las publicaciones

Opinión

Yellow Teaming: ¿palabra de moda o punto de inflexión?

Por Jan Martijn Broekhof ·

Nunca había oído el término “Yellow Team” hasta que leí un artículo reciente de Dark Reading sobre IA y seguridad. Al final del segundo párrafo me di cuenta de algo ligeramente incómodo: Guardian360 ha sido uno en silencio durante años, y nadie, yo incluido, se molestó nunca en llamarlo así.

Durante mucho tiempo, eso no importó demasiado. Construir las herramientas que usan los Red Teams y los Blue Teams se veía como un trabajo de mercancía: necesario, poco glamuroso, rara vez tema de una charla de conferencia. Los atacantes se llevaban el drama. Los defensores se llevaban el mérito de aguantar la línea. Las personas que construían las plataformas sobre las que trabajaban ambos se llevaban una partida en el presupuesto. La IA está cambiando ese cálculo, y merece la pena entender por qué, y qué significa para la forma en que Guardian360 trabaja con sus socios.

¿Qué son exactamente los Red, Blue y Yellow Teams, y dónde encaja DevSecOps?

El vocabulario de colores en ciberseguridad es más antiguo de lo que la mayoría supone. Red Team se refiere a las personas que simulan ataques: pentesters, hackers éticos, los que cobran por entrar antes de que lo haga alguien con peores intenciones. Blue Team se refiere a los defensores: los analistas e ingenieros que detectan esos ataques, responden a ellos y se recuperan. El Yellow Team se sitúa por debajo de ambos. Es el grupo que diseña, construye y mantiene los sistemas, las aplicaciones y las herramientas sobre los que y con los que operan realmente el Red y el Blue.

Esta distinción se propuso por primera vez en Black Hat en 2017, cuando se introdujo una rueda de colores para mapear las distintas funciones dentro del trabajo de seguridad más allá del familiar marco de rojo contra azul, tal como han documentado desde entonces los investigadores de seguridad de Retest Security en su propia historia del marco. El amarillo se definió como los constructores: arquitectos, desarrolladores e ingenieros responsables de sistemas seguros desde su base, en lugar de las personas que los atacan o los defienden después de los hechos.

DevSecOps no es un color aparte en esa rueda. Es la práctica que los Yellow Teams usan para hacer su trabajo: integrar la seguridad en el propio proceso de desarrollo, de modo que las vulnerabilidades se detecten en el punto de creación en lugar de descubrirse más tarde por el Red o de limpiarse más tarde por el Blue. DevSecOps es el método. El Yellow Team es el grupo de personas que lo aplica.

¿Solo DevSecOps con una nueva mano de pintura?

Un escéptico razonable me detendría aquí. Si el Yellow Team es simplemente la gente que hace DevSecOps, ¿qué ha cambiado en realidad? Las organizaciones llevan una década teniendo ingenieros de desarrollo seguro. Llamarlos “amarillos” no hace que el trabajo sea nuevo.

Ese escepticismo merece una respuesta honesta, y la respuesta honesta es: por sí sola, la etiqueta sería, en efecto, vino viejo en una botella nueva. Lo que hace diferente este momento no es el nombre, es la escala de aquello para lo que ahora se pide a los Yellow Teams que construyan. Los modelos de IA de frontera como Claude Mythos y GPT-5.5 pueden encontrar y encadenar vulnerabilidades de software más rápido que casi cualquier equipo humano, y las organizaciones apenas empiezan a averiguar cómo dirigir esa capacidad en una dirección útil en lugar de caótica. Esa dirección, resulta, es trabajo de Yellow Team, y no se parece en nada a escribir listas de verificación de revisión de código seguro.

Por qué la IA acaba de cambiar las cuentas para los constructores

Según la información publicada por Dark Reading, los ingenieros de empresas como Cisco, Microsoft, Cloudflare y Netskope dedican ahora su tiempo a construir “harnesses”: constructos de software que definen exactamente qué se le permite hacer a un modelo de IA, qué permisos tiene y qué salvaguardas debe respetar mientras busca vulnerabilidades. Un harness suena restrictivo, pero es lo contrario. Sin uno, los Red Teams se ven desbordados por los falsos positivos y por hallazgos despojados de contexto de negocio; con uno, ese mismo modelo de IA se vuelve genuinamente útil tanto para la simulación de ataques como para la defensa.

James Robinson, el CISO de Netskope, describe exactamente este patrón: el modelo marcó un endpoint interno como no autenticado, técnicamente cierto, pero pasó por alto que ese endpoint nunca fue accesible desde la web en primer lugar. Pasar de la salida bruta de la IA a algo en lo que un analista humano confiaría requirió un esfuerzo de ingeniería dedicado, no un prompt.

El efecto colateral es que el Blue y el Yellow están siendo empujados a acercarse más que nunca. Como lo expresa Levi Bolourie, de Zscaler, los blue teams que no usan IA para el análisis corren el riesgo de verse desbordados por el enorme volumen de señales que produce ahora el red teaming asistido por IA, y las dos disciplinas tendrán que integrarse mucho más estrechamente como resultado. Los Yellow Teams ya no son una función de apoyo que está tranquilamente detrás del Red y el Blue. Son la razón por la que cualquiera de los dos equipos puede siquiera seguir el ritmo.

De un sistema de registro a un sistema de acción

Hay un segundo cambio que subyace a todo esto, y va mucho más allá de la seguridad. Durante dos décadas, la mayor parte del software empresarial ha sido lo que ahora se llama un “sistema de registro”: un lugar que almacena lo que ha ocurrido. Tu CRM registra que un cliente llamó. Tu plataforma de escaneo registra que existe una vulnerabilidad. Útil, necesario y completamente pasivo.

Un “sistema de acción” hace algo diferente. En lugar de limitarse a almacenar lo que ocurrió, usa esa información para decidir qué debería ocurrir a continuación y, cada vez más, para hacerlo. La propia investigación de Grammarly sobre la productividad en el trabajo descubrió que el 77 por ciento de los profesionales se sienten desbordados por el enorme volumen de información que tienen que procesar, y el 83 por ciento dice que carece de las herramientas para actuar de verdad sobre lo que sabe. Esa brecha entre tener datos y hacer algo útil con ellos es exactamente lo que un sistema de acción pretende cerrar.

Me gusta pensarlo como la diferencia entre un faro tradicional y uno que pudiera dirigir su propio haz de luz. Un faro tradicional es un sistema de registro puro: marca una posición fija y conocida, y corresponde al capitán del barco leer la luz, juzgar la distancia y elegir el rumbo. No se ajusta al barco que tiene delante. Ahora imagina un faro que pudiera rastrear una embarcación que se aproxima y redirigir activamente su haz para advertir a ese barco concreto, en ese momento concreto, sobre el peligro más cercano a él. El capitán sigue gobernando el barco. Pero el faro ha dejado de ser un marcador estático y ha empezado a ser un participante activo en mantener seguro a ese barco.

Antes entregábamos a los socios un mapa. Ahora queremos guiar la ruta.

Una breve nota sobre posicionamiento antes de seguir: Guardian360 es un proveedor de software independiente. Desarrollamos la plataforma Lighthouse: escaneo continuo, recomendaciones de cumplimiento, inventario de activos, puntuación de riesgo de negocio y técnico. No operamos un centro de operaciones de seguridad, no realizamos pruebas de penetración manuales ni respuesta ante incidentes, y no vendemos directamente a los clientes. Ese trabajo recae en nuestros socios, y siempre ha sido así.

Durante años, lo que entregábamos a los socios era, en efecto, un mapa. Lighthouse mostraba dónde estaba el riesgo, qué necesitaba atención y, aproximadamente, cómo de urgente era. Encontrar la mejor ruta desde esa información hasta un entorno de cliente concreto se dejaba enteramente al socio. Ese era el modelo adecuado cuando el propio mapa era la parte difícil de construir. Es un modelo más complicado ahora que la IA puede ayudar a generar no solo el mapa, sino un siguiente paso genuinamente útil.

En los próximos meses, queremos que Lighthouse se aleje más del mapa hacia la navegación: no solo mostrar a los socios dónde reside el riesgo, sino proponer la mejor ruta para abordarlo, una y otra vez, a medida que cambian las circunstancias. Eso es lo que significa realmente construir un sistema de acción para nosotros en la práctica.

Merece la pena ser honesto sobre esto, porque plantea una pregunta obvia para cada socio que lea esto: si la plataforma empieza a proponer la ruta, ¿qué le queda al conductor? Nuestra respuesta es que el socio sigue teniendo el control del coche. No estamos construyendo herramientas para dejar a los socios fuera del trabajo; las estamos construyendo para quitarles de las manos las partes del trabajo que no necesitan una decisión de criterio humano, de modo que las decisiones que sí necesitan un humano reciban más de su atención, no menos. Los socios se están convirtiendo, en efecto, en el Blue Team del mañana: los que deciden, actúan y asumen la responsabilidad del resultado, respaldados por un Yellow Team al que por fin se le pide que haga algo más que mantener las luces encendidas.

Entonces, ¿qué equipo has sido en silencio?

Guardian360 fue un Yellow Team mucho antes de que existiera el término, y sospecho que un buen número de organizaciones que lean esto pueden decir lo mismo sobre al menos una parte de su propia operación. La pregunta con la que merece la pena quedarse no es si el Yellow Teaming es una categoría real o solo un cambio de marca. Es cuál de tus equipos ha estado haciendo este trabajo en segundo plano durante años, sin nombre y sin reconocimiento, y si estás listo para entregarle las herramientas, y la atención, que este momento realmente exige.

Fuentes