Red teaming

El ojo que protege y el ojo que ataca ven cosas distintas

Quien construye el sistema lo revisa siguiendo el flujo que él mismo diseñó: si se pulsa este botón, pasa esto; si llega esta petición, se bloquea así. Pero el problema suele estar fuera de ese orden. Un uso que nadie imaginó se convierte en el canal de entrada.

El ojo que ataca ignora el orden previsto. Pregunta qué pasa si se salta de un punto a otro sin seguir la ruta esperada, qué pasa si se combinan dos funciones en un orden extraño, qué pasa al final de una conversación muy larga. Es el mismo sistema, pero lo que se ve cambia.

Por eso el red teaming se mantiene separado de la revisión que hace por su cuenta quien construyó el sistema. Esa persona también participa, pero hace falta mezclar gente que no conoce el diseño y que viene de trasfondos distintos, para que salgan a la luz huecos diferentes.

El alcance se acuerda antes de empezar

Antes de comenzar se acuerdan varias cosas: hasta qué sistema llega la revisión, si se puede tocar material real de usuarios, hasta dónde se comprueba, y a quién se avisa de lo que se encuentre. Es como dar la vuelta a la casa sin llegar a romper la puerta.

También se acuerda cómo registrar todo. Si no queda anotado qué se intentó y bajo qué condiciones funcionó, quien corrige no puede reproducirlo, y solo probando varias veces se sabe si algo funcionó por casualidad o de forma estable.

Sin este acuerdo previo, la revisión se convierte en un incidente. Dejar el alcance por escrito no es un trámite, sino una medida de seguridad.

Qué se pone a prueba

Lo que se pone a prueba no es solo la seguridad en un sentido estrecho. Se mira si salen respuestas fuera de las reglas, si se filtra información de un usuario o de la empresa, si el sistema afirma con seguridad algo sin confirmar, si sigue una instrucción escondida en un documento leído, si el resultado cambia según el grupo, y si las herramientas se usan de forma indebida.

Cada frente necesita gente distinta. Para revisar el tono del lenguaje hace falta alguien que conozca el idioma y la cultura; para revisar el mal uso de una herramienta, alguien que conozca ese sistema. Un solo equipo no puede verlo todo, así que se mezclan personas con distintos trasfondos.

Se combina el trabajo manual de personas con sistemas automáticos que generan muchos intentos a la vez. La parte automática cubre en amplitud; la parte humana busca ángulos que lo automático no llega a imaginar.

El resultado es una lista de cosas por corregir

Al terminar la revisión, lo que queda es una colección de casos donde el sistema falló. Lo importante ahí no es la cantidad, sino la variedad. Vale más encontrar diez tipos distintos de fallo que cien casos parecidos entre sí: eso es una revisión más amplia.

Cada caso pasa al lado que corrige. Algunos terminan como una regla de comprobación, otros como material de entrenamiento, otros como la decisión de quitar una función. Los casos corregidos entran en la lista que se vuelve a revisar, porque es habitual que un punto ya cerrado se abra de nuevo al arreglar otra parte.

No termina en una sola vez

Cuando se cambia de modelo, se añade una función nueva o cambia el material de referencia, hay que volver a comprobar las conclusiones de la revisión anterior. Es como una casa: arreglarla una vez no significa que no haya que volver a darle una vuelta al año siguiente.

Y por muchas vueltas que se den, no se puede comprobar todo. El objetivo no es reducir los huecos a cero, sino saber cuánto riesgo queda antes de lanzar el sistema. Lanzarlo sin saberlo y lanzarlo sabiéndolo son dos estados distintos.