- Terence Tao menciona la importancia lógica de distinguir entre el equipo azul y el equipo rojo en el campo de la ciberseguridad
- La lógica constructiva representa los principios del equipo azul, mientras que la lógica co-constructiva representa los principios del equipo rojo
- Mike Shulman está investigando una nueva lógica que combina ambas bases lógicas
- La interpretación de Brouwer–Heyting–Kolmogorov (BHK) está centrada en las pruebas, pero también subraya la importancia de la refutación
- Esta línea de investigación podría aplicarse a diversos campos, incluida la seguridad de la IA
Debate sobre la distinción y combinación de lógicas para LLM del equipo azul y el equipo rojo
- Terence Tao señaló recientemente que, en los campos de la seguridad y los algoritmos, los lógicos están reflexionando con mayor profundidad sobre la diferencia entre el equipo azul (defensa) y el equipo rojo (ataque)
- La lógica constructiva se centra en el proceso de verificación, es decir, en cómo demostrar una afirmación, y define los principios del equipo azul
- En cambio, la lógica co-constructiva se enfoca en el proceso de refutación, es decir, en la lógica de la impugnación o el ataque; ha recibido atención recientemente y recoge los principios del equipo rojo
La investigación de Mike Shulman para combinar ambas lógicas
- Mike Shulman está investigando una forma de lógica que combine estos dos sistemas lógicos
- Según una cita de su artículo, la interpretación de Brouwer–Heyting–Kolmogorov (BHK) tradicional tiende a centrarse solo en los criterios de prueba, pero los matemáticos prácticos consideran igual de importante la refutación, es decir, los criterios para identificar que una proposición es falsa
- Con ello, señala los límites de un enfoque centrado exclusivamente en la prueba dentro de las interpretaciones lógicas existentes
La necesidad de ampliar la interpretación lógica
- Se plantea la necesidad de explicar, desde ambas perspectivas, qué significan la prueba y la refutación para cada conectivo lógico
- La investigación en curso de Mike Shulman explora qué tipo de estructura podría tener en la práctica esta interpretación ampliada
Implicaciones y posibles aplicaciones
- Si avanza esta investigación sobre lógica combinada, podría tener aplicaciones prácticas importantes en el diseño de seguridad de la IA y en el desarrollo de sistemas de verificación y refutación de algoritmos en ciberseguridad
- Los detalles del artículo relacionado pueden consultarse en el enlace de arXiv
1 comentarios
Opinión de Hacker News
Tengo algunas ideas
(a) La IA es útil tanto del lado del equipo "rojo" como del "azul"
El equipo azul cumple una especie de rol de lluvia de ideas
(b) AlphaEvolve es, en ese sentido, un caso que aplica claramente el enfoque de 'equipo rojo/azul'. Solo que no usa esa terminología
Terence Tao también fue asesor de ese paper
(c) Esto me recuerda la división de roles de 'verificador/refutador' en la semántica de juegos
El propio Tao también ha hablado públicamente de esta forma de pensar, así que probablemente de verdad lo ve desde esa perspectiva
La expresión "azul/rojo" tal vez sea más bien una forma de presentarlo pensada para programadores
(d) Como agregado, no siempre se puede decir que un sistema de seguridad es tan fuerte como su eslabón más débil
Depende de si la seguridad está organizada en capas o en una estructura paralela
Si fuera un pasillo con varias puertas fuertes y débiles en fila, la resistencia total estaría determinada por la puerta más fuerte
Y si combinas varios clasificadores débiles para construir un algoritmo de detección de fraude, puede terminar siendo mucho más potente que el clasificador más débil por sí solo
Paper de AlphaEvolve
Q&A sobre la forma de pensar de Tao
Ahí lo que hace el LLM es simplemente generar código nuevo a partir de ejemplos, y no evalúa el código en sí
Sentí que la idea de rojo vs azul es un buen marco para entender hasta qué punto los LLM sirven para trabajo de nivel experto
Casi sin dudar delegaría a un LLM la tarea de agregar tests
Porque los tests suelen ser baratos, si están mal se pueden borrar o corregir fácilmente, y si están bien agregan valor
Aun así, como los LLM a menudo no prueban la funcionalidad central, los tests más importantes hay que escribirlos uno mismo para poder confiar en ellos
En cambio, arreglar bugs o agregar funciones con un LLM es más riesgoso
Porque puede hacer trampas, o escribir código que solo pase los tests sin resolver el problema de fondo
Trabajando con una base de código legacy sentí con mucha claridad que la idea de "si el test está mal, después lo arreglamos" es peligrosa
A veces los tests son una evidencia más cercana a la verdad que el propio código, así que un test incorrecto puede ser más grave que código incorrecto
Sobre todo, si se mezclan tests inútiles o de significado ambiguo, se vuelve pésimo distinguir si de verdad están garantizando una funcionalidad importante
Creo que la IA es parecida a una calculadora
Así como una calculadora hace bien cálculos que la mayoría de la gente no puede hacer, la IA también es una nueva clase de inteligencia que fortalece a las personas como herramienta auxiliar
Mucha gente piensa que "la IA reemplaza a los humanos", pero en realidad su verdadero valor está en complementar el trabajo humano
Yo tengo la postura contraria
Pienso que hay que escribir los tests uno mismo y entenderlos por completo para establecer un criterio real, y solo entonces uno puede sentirse tranquilo aunque la IA cambie el código a su antojo
Si los tests también los hizo un LLM, la ansiedad por dejar el resto del código en manos de la IA es todavía mayor
Probé generar tests con un LLM para código Rust, y en la práctica hizo más daño que bien
Había muchos tests, pero era fácil que faltaran coberturas importantes
Como la cantidad de código era demasiada, era difícil ver qué partes no estaban cubiertas
Y cuando después había que cambiar la lógica del código, me tocaba retocar todos esos muchos tests generados
Hay una frase que dice: "nadie verifica los tests, así que se asume que están bien"
Por eso apareció el patrón Arrange-Act-Assert
Los unit tests que más me gustan hoy son los que guardan los valores de entrada y la salida esperada, y con eso validan el resultado del código
Como es fácil verificar incluso los casos límite, resulta sencillo confirmar si realmente se comporta como uno quiere
Según entiendo, el algoritmo RSA también se creó de esta manera
Según "The Code Book" de Simon Singh (lo tengo por ahí, pero no lo encuentro), Rivest y Shamir proponían ideas y Adleman se encargaba de encontrar los defectos
Ver Wikipedia sobre RSA
También es un ejemplo de colaboración azul/rojo en matemáticas
Uno tiene muchas ideas, habla mucho y es desordenado
El otro es lógico y preciso, así que cuando uno redacta el borrador del paper, el otro le borra todo lo innecesario
En líneas generales estoy de acuerdo, pero el encuadre desde la infosec me parece un poco raro
La idea de que "la seguridad es tan fuerte como su parte más débil" es demasiado simplista y peligrosa
La estrategia de seguridad tiene que diseñarse en capas
Como no se puede esperar perfección en una sola capa, hacen falta varias capas de defensa
Ataque y defensa no son tan distintos, pero muchos atacantes tienen poca responsabilidad si se equivocan, mientras que los defensores, sobre todo en grandes empresas, cargan con mucha responsabilidad por los resultados
Aun así, los defensores tienen la ventaja de pelear en casa. Perder eso de vista puede traer problemas
El ejemplo de que no sirve de nada cerrar la puerta si la ventana está abierta sí es una buena analogía
La defensa en capas tiene sentido cuando hay varios elementos apilados que un atacante necesariamente debe atravesar para llegar a su objetivo
Pero si los elementos están en el mismo nivel, como una puerta y una ventana, entonces la parte más débil define el conjunto
Como ejemplo web: aunque el login principal sea perfecto, si un endpoint viejo como
/v1/legacy/external_backofficepermite acceso a la red interna sin ninguna autenticación, toda la defensa se caeAun así, si internamente hay más mecanismos de contención, el daño puede limitarse, así que al final las capas defensivas sí importan
Yo usé la frase "la defensa es tan fuerte como su eslabón más débil" en un sentido más amplio
Más allá de la formulación del post original, agregué la idea de "el esfuerzo defensivo total", pero en realidad ambas posturas tienen algo de razón
Como dice Terence, el eslabón más débil sí puede ser explotado, y por eso hacen falta varias capas de defensa
Un caso real reciente fue el problema de un empleado de help desk que restablecía contraseñas de clientes sin validación
Aunque hubiera tecnologías de seguridad sólidas como VPN y 2FA, un solo eslabón débil llamado "recuperación de cuenta" derrumbó todo el conjunto
Internamente había capas adicionales que detectaron y bloquearon al intruso en 3 horas, pero eso fue "minimización del daño", no "prevención previa"
Al final, hacen falta varias capas para evitar el daño
Últimamente la propia industria de infosec ha cambiado el foco de la "prevención al 100%" hacia la "mitigación del daño"
Como es difícil prevenir todos los riesgos, la estrategia se está orientando más a reducirlos, minimizar la superficie y bajar el nivel de confianza
No soy para nada experto en seguridad, pero he oído que "una superficie de ataque extremadamente reducida y el uso de protocolos open source verificados" es la mejor defensa
Me da curiosidad qué diferencia habría entre eso y lo que se está discutiendo aquí
Simplemente se eligió una analogía poco adecuada
La idea de "eslabón más débil" aplica cuando hay que atravesar varias etapas en serie
Si hay varias capas en un mismo nivel, entonces lo correcto es apuntar a la parte más débil de entre ellas
Igual, como te preocupa, sí deja espacio para interpretaciones ambiguas
También veo el ataque como otra capa de defensa
Como dice el dicho, "la mejor ofensiva es la mejor defensa"
En ciberseguridad, el equipo rojo y el equipo azul son dos equipos con fuerza equivalente
Pero en desarrollo de software, siento que la analogía está un poco exagerada
Los tests también son código, y también tienen bugs
Aparece una paradoja como la de "Who polices the police?"
Una oración en inglés repetitiva y llena de significado, como la de Buffalo
Esto me recuerda la idea mental de John Cleese sobre el "modo abierto vs modo cerrado"
Las ideas se generan con la mayor apertura posible
Y después, en modo cerrado, se filtran las malas y se desarrollan las buenas
Los escritores de todas las áreas también suelen tener editores
El diseño del juego de cartas Magic: the Gathering también funciona de forma parecida: el equipo de diseño hace un borrador del set y luego se lo pasa a un equipo de desarrollo completamente separado para validarlo
Me gustaría escuchar más ejemplos de colaboraciones así
En realidad, yo lo veo al revés de lo que dice este post
Los LLM son excelentes para hacer borradores rápidos, y los humanos bien entrenados son más aptos para revisar críticamente lo que produce el LLM
O sea, el LLM encaja más como equipo azul y el humano como equipo rojo
Parece que Tao está hablando justamente de ese tipo de situación extrema
Últimamente he estado usando modelos y flujos basados en agentes, y esto es lo que sentí
Estos agentes brillan más no solo escribiendo código, sino también en testing, gestión e incluso tareas de management
El desarrollador pasa a convertirse en una especie de manager, es decir, un supervisor
Queda en una posición de supervisar toda la planificación de tareas (escribir prompts, definir el alcance del trabajo), la escritura de tests y la escritura del código
Sí, hay muchísimo más review, pero al hacer yo mismo el papel de equipo rojo para ver si se rompe menos, sentí que en realidad tenía más control
Esta perspectiva me parece interesante
Incluso en los negocios se podría dividir entre un ‘equipo azul’ (industrias de infraestructura social: electricidad, petróleo, telecomunicaciones, software, finanzas, etc.) y un ‘equipo rojo’ (industrias de valor agregado: gastronomía, retail especializado, lujo, turismo, etc.)
En términos económicos, el lado azul es mucho más importante, porque estas industrias sostienen toda la economía, tienen mucha demanda y deben minimizar errores
En cambio, las industrias del lado rojo no son indispensables para que la economía funcione, pero mientras más haya, más mejora la calidad general
En el ejemplo de Tao pasa lo mismo: que un ingeniero de software gane más que alguien de QA, o que escribir una demostración se considere económicamente más valioso que verificarla, responde a la misma estructura
Cuando Sam Altman recauda fondos para entrenar LLM, le resulta más fácil conseguir inversión si insiste en que "somos útiles como equipo azul", y eso termina moldeando toda la narrativa mediática
En realidad son más aptos para usos de equipo rojo, pero como hay que prometer retorno de inversión, las empresas van a empujar los LLM solo para usos de equipo azul
Google Glasses, VR y los wearables siguen un patrón parecido
Son tecnologías de equipo rojo útiles en industrias de nicho, pero como no pueden generar un ecosistema enorme ni grandes ingresos, el capital las deja de lado
(Trabajo en Microsoft)
Yo mismo opero validación automática de red team para muestras de RAG con el SDK
azure-ai-evaluationAhí se combina un LLM adversarial que se sale de los rieles con el paquete
pyrit, y se generan automáticamente preguntas extrañas para arrojárselas a la app, además de transformar las preguntas mismas con base64, cifrado César, urldecode y demásLos resultados reales son interesantes, y estoy de acuerdo en que los LLM son bastante útiles para actividades de red team
Demo en YouTube
(Perdón si el tono de voz suena fuerte, lo grabé en un lugar peculiar)