1.1 ¿Qué es OPSEC?

Casi cualquier curso o web de ciberseguridad resume OPSEC en cinco pasos: identificar información crítica, analizar amenazas, analizar vulnerabilidades, evaluar riesgos y aplicar contramedidas. Esa lista es correcta — es literalmente el proceso oficial descrito en la directiva presidencial NSDD-298 de 1988 — pero tratarla como toda la doctrina convierte OPSEC en un checklist estático de una sola pasada. La doctrina militar de origen dice otra cosa: OPSEC es un proceso continuo, iterativo y retroalimentado, no una lista de tareas que se marca y se archiva.

Origen del concepto

Se suele citar como antecedente remoto una carta de George Washington al coronel Elias Dayton, fechada el 26 de julio de 1777, sobre la importancia del secreto en las operaciones. Es un antecedente conceptual real — aparece citado en la propia historia oficial de la NSA sobre el programa OPSEC — pero es más folclore doctrinal que el origen del programa como tal.

El origen operativo real está en la guerra de Vietnam. El 7 de febrero de 1965, un pelotón del Viet Cong atacó la base aérea estadounidense de Pleiku, a unos 320 km al norte de Saigón, destruyendo un avión de transporte y nueve helicópteros, y dañando otros quince aviones. Entre enero y septiembre de 1966, la campaña de bombardeo Rolling Thunder perdió 228 aviones de combate y apoyo de ala fija, lo que generó preocupación al más alto nivel del mando estadounidense: el enemigo estaba anticipando los ataques con una precisión que no cuadraba con ningún fallo de cifrado conocido.

Para investigar esto se formó un equipo de análisis de operaciones que operó bajo el nombre en clave "Purple Dragon". El nombre de la disciplina resultante, "Operations Security", y el nombre en clave del equipo, "Purple Dragon", son dos cosas distintas que conviene no mezclar: el término "security" se eligió deliberadamente para diferenciar el trabajo de otros grupos de "operations analysis" y por motivos de conformidad con la NSA, mientras que "Purple Dragon" fue simplemente el nombre en clave elegido de una lista disponible para un equipo pensado en origen como temporal.

El hallazgo que confirmó la hipótesis de fondo llegó el 25 de diciembre de 1969: una unidad de la 1ª División de Infantería, en un barrido por la provincia de Binh Duong cerca de Saigón, se topó con una unidad de inteligencia de comunicaciones (COMINT) del ejército norvietnamita. Capturaron a doce de sus dieciocho integrantes junto con unos 2.000 documentos y el equipo de intercepción — el mayor hallazgo COMINT de toda la guerra. Confirmaba que el enemigo no dependía solo de criptoanálisis: explotaba masivamente señales e indicadores no clasificados, es decir, el patrón de comportamiento propio, no el contenido cifrado.

Tras el éxito de Purple Dragon mejorando la efectividad de combate de las unidades auditadas, se impulsaron programas de seguridad de operaciones basados en ese modelo, que se volvieron obligatorios para todos los mandos de EE.UU. en el mundo y que después se extendieron a agencias fuera del Departamento de Defensa. En 1983, el Departamento de Energía (DOE) participaba en el Senior Interagency Group for Intelligence (SIG-I), que propuso una política nacional de OPSEC y un Comité Asesor Nacional de OPSEC (NOAC). Esa propuesta cristalizó el 22 de enero de 1988, cuando el presidente Ronald Reagan firmó la Directiva de Decisión de Seguridad Nacional 298 (NSDD-298), que estableció la política nacional de OPSEC, fijó el proceso de cinco pasos y creó el Interagency OPSEC Support Staff (IOSS).

El propio documento desclasificado de la NSA de 1993, "Purple Dragon: The Origin and Development of the United States OPSEC Program", es la fuente histórica primaria más citada sobre este origen, y ya planteaba explícitamente que las lecciones de Purple Dragon no eran solo para lo militar, sino aplicables también al profesional civil de criptología. La adopción en el mundo corporativo y de ciberseguridad —hacktivismo, cibercrimen, red teaming— fue un proceso gradual desde los años 90-2000, sin una fecha oficial equivalente a la NSDD-298.

Definiciones formales vs. prácticas

Conviene distinguir tres niveles de definición, porque en cada uno el término "adversario" significa algo distinto.

Nivel de política presidencial (NSDD-298, 1988): OPSEC es un proceso sistemático mediante el cual el Gobierno de EE.UU. y sus contratistas pueden negar a potenciales adversarios información sobre capacidades e intenciones, identificando, controlando y protegiendo evidencia generalmente no clasificada de la planificación y ejecución de actividades sensibles. Un matiz doctrinal importante: OPSEC complementa —no sustituye— la seguridad física, de la información, de personal, de computadoras, de señales y de comunicaciones. No es "una medida de seguridad más": es una capa analítica distinta.

Nivel de doctrina militar actual (Joint Publication 3-13.3, DoD): OPSEC es una capacidad que identifica y controla información crítica, indicadores de las acciones propias inherentes a operaciones militares, e incorpora contramedidas para reducir el riesgo de que un adversario explote vulnerabilidades. Los "indicadores OPSEC" son acciones detectables por las fuerzas propias e información de fuentes abiertas que un adversario puede interpretar o correlacionar para derivar información crítica. El núcleo conceptual es la agregación: datos individuales triviales y no clasificados, al correlacionarse entre sí, pueden revelar un patrón sensible. La doctrina del Ejército (ATP 3-13.3, 2019) es explícita en que los programas de seguridad convencionales se centran en información clasificada, mientras que OPSEC se centra en proteger información no clasificada, incluyendo los llamados "elementos esenciales de información propia" (EEFI).

Nivel aplicado a red teaming / pentesting: la definición que circula en el ámbito ofensivo —identificar información crítica para determinar si las acciones propias pueden ser observadas por la "inteligencia enemiga", en este caso el equipo defensor, y ejecutar medidas que reduzcan esa exposición— no es una definición distinta inventada para el sector: es la misma definición militar de JP 3-13.3, reutilizada tal cual en un contexto distinto.

Esta tabla no es un detalle menor: es la razón por la que "traducir" OPSEC de un manual militar a un contexto de pentesting sin adaptar el marco de amenaza lleva a errores de enfoque.

Por qué el checklist de 5 fases se queda corto

El ciclo NSDD-298 (identificación → amenazas → vulnerabilidades → riesgo → contramedidas) es la paráfrasis estándar que repite casi toda fuente corporativa y educativa, y no es incorrecta. El problema es tratarla como si fuera el total de la disciplina, convirtiendo OPSEC en un checklist de un solo ciclo, ejecutado una vez al inicio de la operación.

La propia JP 3-13.3 describe medidas de efectividad (MOE) y medidas de desempeño (MOP): la reacción del adversario se monitorea para determinar si las contramedidas están funcionando, y esa reacción retroalimenta el proceso. Hay incluso un efecto contraintuitivo: si una contramedida OPSEC es identificada por el adversario, ese mismo hecho puede alertarlo de que una operación es inminente. El acto de "proteger" se convierte en un indicador nuevo — un bucle recursivo que una lista lineal de cinco casillas no representa.

Otro elemento que el checklist no transmite bien es evitar patrones de comportamiento, no solo proteger datos puntuales. La doctrina insiste en evitar cambios drásticos al implementar contramedidas, porque un cambio repentino de procedimientos es en sí mismo un indicador de que algo distinto está ocurriendo. Es pensamiento de proceso continuo, no una tarea que se ejecuta y se cierra.

Para un red team, esto tiene una consecuencia práctica directa: OPSEC no es una fase inicial del compromiso, es la base de su credibilidad durante toda la operación. Cada fase debe estar aislada, probada y registrada, y cada herramienta debe verificarse en cuanto a metadatos limpios y comportamiento realista, de forma continua.

OPSEC vs. buenas prácticas de seguridad

La cita de JP 3-13.3 — "OPSEC is an operations function, not a security function" — es la clave de esta distinción. Las buenas prácticas de seguridad protegen sistemas y datos mediante controles: cifrado, parches, contraseñas, firewalls. OPSEC obliga a pensar desde la perspectiva de un observador externo: qué se puede inferir de la suma de comportamientos a lo largo del tiempo, incluso cuando cada acción individual parece inocua o no clasificada. El foco no es "¿qué vulnerabilidad técnica tengo?", sino "¿qué puede deducir de mí un adversario que me observa con paciencia?". Es un problema de agregación y correlación, no de un fallo puntual.

El caso de Ross Ulbricht (Silk Road) ilustra bien el contraste porque combina ambos tipos de fallo en un mismo expediente: una mala configuración de la página de login de Silk Road filtró la IP real de los servidores — eso es un fallo técnico clásico de seguridad. Pero reutilizar el alias "altoid" en un foro público y usarlo después para pedir ayuda relacionada con Silk Road es un fallo puramente de proceso de pensamiento OPSEC: no separar identidades, no anticipar la correlación.

Esa cascada se puede leer como un fallo en cadena sobre los propios cinco pasos: si un operador no identifica un dato como crítico (Principio 1) —en este caso, su correo personal y su alias—, tampoco lo percibirá como una vulnerabilidad al exponerlo en un foro público (Principio 3); esa percepción errónea lleva a evaluar el riesgo de esa publicación como insignificante (Principio 4); y en consecuencia, no ve ninguna contramedida necesaria (Principio 5). Es la mejor ilustración disponible de "pensar como el adversario" frente a "aplicar un checklist de seguridad".

Casos reales de fallo de OPSEC

Los siguientes casos son fallos de proceso, no fallos criptográficos ni "hackeos" en el sentido técnico, salvo donde se indica lo contrario.

Ross Ulbricht / Silk Road ("Dread Pirate Roberts"). Usó el alias "altoid" en varios foros para anunciar que Silk Road estaba activo a principios de 2011, y volvió a usar el mismo alias para contratar desarrolladores de una supuesta "startup de bitcoin", pidiendo currículums a una dirección de correo personal identificable. A principios de 2012, un usuario de StackOverflow con el nombre "Ross Ulbricht" preguntó cómo conectar a un servicio oculto de Tor usando PHP — la misma técnica que usaba el sitio de Silk Road — y cambió el nombre de usuario en menos de un minuto, pero el nombre original quedó registrado en los servidores de StackOverflow. Cambió después a "frosty" y al correo frosty@frosty.com; el análisis forense del servidor incautado en Islandia encontró una clave pública SSH con el comentario frosty@frosty en el archivo de claves autorizadas del servidor de administración de Silk Road, creando un vínculo trazable entre esa identidad y la administración del sitio. Una publicación suya en LinkedIn a principios de 2012 sobre una visión anarquista de simulación económica no era sospechosa por sí sola, pero cobró sentido en retrospectiva una vez que los investigadores ya lo tenían en su lista — el rastro funciona en ambas direcciones, de la acción al incidente y del incidente de vuelta a acciones pasadas aparentemente inocuas. Este caso combina, en un mismo expediente, un fallo técnico clásico (fuga de IP por mala configuración del login) con varios fallos de proceso OPSEC (reutilización de alias, correo personal, patrón de comportamiento en redes profesionales).

Hector Monsegur "Sabu" (LulzSec). Sobre el mecanismo exacto de su identificación existen dos versiones que no coinciden, y no debe presentarse como un hecho cerrado. La versión más difundida (recogida por Fox News y The Register) sostiene que Sabu siempre ocultó su IP mediante proxies, pero en una ocasión inició sesión en una sala de IRC sin enmascararla, y con eso bastó para que el FBI lo ubicara. El propio Monsegur afirmó posteriormente una versión distinta: que siempre se conectaba a través de máquinas comprometidas y que nunca filtró su IP doméstica en IRC, y que el FBI lo desenmascaró a partir de datos personales suyos filtrados años antes en un "doxeo" en la red IRC Efnet, que los investigadores finalmente obtuvieron. No hay consenso sobre cuál versión es la correcta. Ambas, en cualquier caso, apuntan a fallos de compartimentación de identidad, no a un fallo criptográfico de las herramientas usadas.

Jeremy Hammond (LulzSec). Habló con Sabu por IRC y reveló indicaciones de que había cumplido condena en una prisión federal en el pasado. Ese dato, combinado con otra información sobre los grupos involucrados, ayudó a acotar el número de sospechosos posibles y facilitó que el FBI obtuviera una orden judicial para monitorear su acceso a internet. Hammond sí usaba Tor, y Tor no fue el punto de fuga — ni siquiera fue necesario vulnerarlo. Es un caso claro de perfilado por fallo conversacional/social, no técnico.

Alexandre Cazes (AlphaBay). El correo de bienvenida y de recuperación de contraseña de la plataforma llevaba en el encabezado la dirección personal pimp_alex_91@hotmail.com. Los investigadores rastrearon ese correo hasta su identidad real, vinculándolo con la administración del servidor. Es un caso mixto: descuido de proceso (usar una dirección de correo personal para algo operacional) combinado con una fuga técnica (esa dirección quedaba expuesta en el encabezado de los correos automáticos del sistema).

El patrón que se repite en todos estos casos es el mismo: el éxito genera complacencia, y la complacencia lleva al desliz. Con frecuencia se trata de individuos técnicamente competentes que, tras un exceso de confianza, cometen un error de más — del tipo que termina llevando a la policía hasta su puerta. Incluso Ross Ulbricht, consciente del riesgo, no pudo resistirse a insinuar su implicación en Silk Road en LinkedIn.

El ciclo de cinco pasos que se mencionó en el apartado anterior es real y está bien contrastado: el glosario del NIST (CSRC), citando la CNSSI 4009-2015 (derivada a su vez de la DoDD 5205.02E), reproduce el mismo proceso que la NSDD-298: identificación de información crítica, análisis de amenazas, análisis de vulnerabilidades, evaluación de riesgos y aplicación de contramedidas apropiadas. Lo que sigue no es una reformulación de esa lista, sino qué significa cada fase en la práctica, dónde se suele confundir con conceptos vecinos y cómo se conectan entre sí — porque el problema nunca ha sido la lista, sino tratarla como una secuencia de casillas independientes.

Fase 1: identificación de información crítica

Esta fase consiste en examinar la totalidad de una actividad para determinar qué evidencia explotable pero no clasificada podría ser adquirida a la luz de las capacidades de recolección conocidas de adversarios potenciales. Es el filtro que evita "proteger todo por igual", algo que diluiría los recursos disponibles.

En doctrina militar, este ejercicio se formaliza mediante las EEFI (Essential Elements of Friendly Information, elementos esenciales de información propia): los planificadores deben establecer qué preguntas haría probablemente el adversario sobre las intenciones, capacidades y actividades propias, porque las respuestas a esas preguntas pueden conducir a información crítica.

• Pregunta clave 1: ¿qué preguntas haría el adversario sobre mis intenciones, capacidades y actividades?
• Pregunta clave 2: ¿qué pasaría si esto se hiciera público o cayera en manos equivocadas?
• Pregunta clave 3: ¿esta información, combinada con otra aparentemente trivial, revela algo sensible? (agregación)

En un red team, la información crítica no son "los datos del cliente" en abstracto, sino aquello que podría exponer los planes del propio equipo ofensivo al Blue Team y permitirle tomar medidas preventivas: los programas, sistemas operativos e identificadores de máquinas virtuales usados quedan registrados en logs y pueden correlacionarse. Los datos almacenados en la infraestructura del Red Team —vulnerabilidades encontradas, exploits, datos exfiltrados del cliente durante el ejercicio— son igual de críticos de proteger.

En OPSEC personal no existe un catálogo formal de EEFI: cada individuo debe inferir qué cuenta como crítico, y es precisamente ahí donde más se falla. Para un diseñador freelance eso podría ser borradores de clientes y facturas; para un hospital, historiales de pacientes e inventario de medicamentos; para un particular, metadatos de redes sociales. Pistas pequeñas que parecen inofensivas pueden ser reveladoras: el perfil de una ciudad en una foto que señala el piso exacto de una oficina, una respuesta automática de "fuera de la oficina" que delata fechas de viaje, un anuncio de empleo que insinúa el lanzamiento próximo de un producto.

Fase 2: análisis de amenazas

El objetivo de esta fase es identificar quién podría querer la información crítica definida en la Fase 1 y qué capacidad e intención tiene para obtenerla. La definición doctrinal de "amenaza" en OPSEC es una fórmula concreta: amenaza = intención + capacidad. Es una definición distinta de "vulnerabilidad" (Fase 3), y confundir ambas es uno de los errores más frecuentes en el material divulgativo sobre el tema.

• Pregunta clave 1: ¿quiénes son mis adversarios?
• Pregunta clave 2: ¿qué capacidad de recolección tienen (técnica, humana, de fuentes abiertas)?
• Pregunta clave 3: ¿qué ganarían si obtuvieran esta información?

En un ejercicio de red team, el Blue Team se considera un adversario porque el equipo ofensivo está atacando los sistemas que ellos han sido contratados para monitorear y defender — aunque el red team actúe con autorización y dentro de un alcance legal definido, eso no cambia el hecho de que se está actuando contra sus objetivos e intentando eludir sus controles. Un segundo adversario posible es un grupo de atacantes reales ajeno al ejercicio. El análisis de amenazas en un pentest exige modelar la capacidad defensiva real del cliente (madurez de su SOC, EDR, IDS), no una amenaza genérica: asumir un Blue Team competente y activo es el punto de partida correcto.

A nivel personal, el modelo de amenaza cambia según quién sea el sujeto: un ciberacosador, un competidor laboral, un estafador de ingeniería social o, en el extremo, un actor estatal. Un periodista, activista o denunciante que investiga temas sensibles debe modelar amenazas concretas —una expareja abusiva, una corporación, un gobierno— cada una con capacidades de recolección muy distintas (OSINT básico frente a vigilancia con orden judicial).

Fase 3: análisis de vulnerabilidades

• Pregunta clave 1: ¿qué indicador concreto expone la información crítica identificada en la Fase 1?
• Pregunta clave 2: ¿el adversario definido en la Fase 2 tiene realmente capacidad de captar y correlacionar ese indicador?
• Pregunta clave 3 (doctrina JP 3-13.3): ¿qué acciones pueden ser observadas por sistemas de inteligencia adversarios, y qué indicaciones podrían recolectarse, analizarse e interpretarse a tiempo para ser útiles al adversario?

En pentesting, un ejemplo típico de vulnerabilidad OPSEC es usar la misma dirección IP para distintas fases de un ataque: facilita que el Blue Team identifique al atacante, y si esa IP se bloquea, el resto de la operación falla en cadena. El contexto es determinante: usar Firefox no es crítico, pero usar un navegador poco común basado en texto sí podría serlo; publicar la foto de un gato no es una vulnerabilidad, pero publicar una foto del equipo etiquetando a sus miembros sí lo es. Un rasgo único en una VM o un sistema —un nombre de host como "kali2021vm", un user-agent poco habitual— se convierte en un punto de pivote fácil para vincular actividades aparentemente separadas de vuelta a la operación.

A nivel personal, los ejemplos típicos son los metadatos EXIF en fotografías (geolocalización), la reutilización de un mismo nombre de usuario entre plataformas y los patrones de horario de publicación que revelan zona horaria o rutina.

Fase 4: evaluación de riesgos

Esta fase combina el análisis de amenazas (Fase 2) y el de vulnerabilidades (Fase 3) para estimar la probabilidad y el impacto de que la información crítica se vea comprometida, y prioriza los esfuerzos de protección según la criticidad para la misión u organización, los requisitos regulatorios y los recursos disponibles. Es una fase bisagra: el análisis de amenazas informa directamente qué contramedidas (Fase 5) importan más.

• Pregunta clave 1: dada esta vulnerabilidad y este adversario concreto, ¿cuál es la probabilidad real de explotación y cuál sería el impacto?
• Pregunta clave 2: ¿el coste de mitigar supera el beneficio de la mitigación?
• Pregunta clave 3: ¿se prioriza por impacto en la misión, no solo por gravedad técnica abstracta?

El ejemplo de la IP reutilizada entre fases de un engagement es el mismo que en la Fase 3, visto desde otro ángulo: cada acción de escaneo por separado puede parecer de bajo riesgo, pero usar la misma IP en fases posteriores (phishing, C2) eleva el riesgo agregado del conjunto de la operación, no solo del escaneo puntual. La geolocalización es otro caso habitual: si una empresa solo tiene oficinas en dos ciudades y aparece un inicio de sesión desde una tercera ubicación o desde la IP de un proveedor cloud, la alerta salta de inmediato — los red teams deben simular ubicaciones y comportamientos realistas de usuario, que es exactamente evaluar el riesgo de un indicador concreto frente a la capacidad de detección real del cliente.

A nivel personal, el riesgo de reutilizar un alias o un correo no es constante: depende de quién esté mirando (un curioso frente al FBI con recursos de correlación de registros de dominio o hosting, como en los casos de Ulbricht y Cazes vistos en el apartado anterior). Evaluar riesgo implica preguntarse qué adversario concreto, con qué capacidad, tiene motivo para correlacionar un dato — no tratar cada exposición como igual de grave.

Fase 5: aplicación de contramedidas

El paso final consiste en aplicar contramedidas para evitar que los adversarios detecten información crítica, para inducirles interpretaciones alternativas mediante decepción, o para negar directamente su capacidad de recolección. Cuando una vulnerabilidad persiste incluso después de aplicar medidas, la decepción —acciones específicas para impedir que la inteligencia adversaria siga y recolecte información, generando confusión y pérdida de interés— es una vía adicional de mitigación.

• Pregunta clave 1: ¿esta contramedida reduce realmente el riesgo, o solo traslada el indicador a otro lugar observable?
• Pregunta clave 2: ¿la contramedida en sí misma podría convertirse en un nuevo indicador?
• Pregunta clave 3: ¿es proporcional al riesgo evaluado en la Fase 4, o es un exceso de recursos sobre algo de bajo impacto?

El error más citado en fuentes de red team es usar la misma dirección IP o el mismo proveedor para múltiples fases de un engagement: cuando el reconocimiento, el phishing y el C2 se originan todos desde la misma fuente, los defensores pueden conectar los puntos. La contramedida correspondiente es segmentar infraestructura por fase, separando IPs y proveedores entre reconocimiento, phishing y C2.

A nivel personal, las contramedidas típicas incluyen: conocer qué considera crítico la propia organización, proteger toda información sensible no clasificada, entender el concepto de agregación de datos, mantener conciencia del entorno y usar las redes sociales con precaución limitando la información publicada. De forma más concreta: separación estricta de identidades (correo, alias, dispositivo) entre la esfera personal y la operativa, retraso deliberado en publicar contenido geolocalizado, evitar patrones repetibles de horario o ubicación, y verificar metadatos antes de publicar cualquier contenido.

Cómo se retroalimentan las fases

Presentar estas cinco fases en una lista numerada sugiere un proceso lineal, pero la propia doctrina describe algo distinto. El análisis de amenazas (Fase 2) informa directamente la selección de contramedidas (Fase 5) al aclarar qué riesgos importan más — la Fase 5 no depende solo de la Fase 4 inmediatamente anterior, sino que remite hacia atrás a la Fase 2. Y a la inversa: si una contramedida genera un nuevo comportamiento observable —cifrar de repente comunicaciones que antes iban en claro, migrar abruptamente de infraestructura—, ese cambio se convierte en un nuevo indicador candidato a analizar en la Fase 1 o la Fase 3 del ciclo siguiente. La doctrina JP 3-13.3 ya advierte de esto: un cambio drástico en los procedimientos puede, por sí solo, alertar al adversario de que algo se protege o de que una operación es inminente.

El mecanismo doctrinal formal de esta retroalimentación son las medidas de efectividad (MOE) y las medidas de desempeño (MOP): se monitorea la reacción del adversario ante las contramedidas aplicadas para determinar si funcionaron, y esa observación retroalimenta directamente una nueva vuelta de análisis de amenazas y vulnerabilidades. En un engagement de red team largo, tras aplicar una contramedida de segmentación de infraestructura (Fase 5), el equipo debe volver a la Fase 3 para verificar si las nuevas herramientas o TTPs introducidas generan nuevos indicadores —por ejemplo, un nuevo C2 con una huella TLS distintiva—. El ciclo se reinicia con cada cambio táctico dentro de la misma operación, no una sola vez al planificarla.

Errores comunes por fase

Estos cuatro términos se usan a menudo como sinónimos, pero no pesan lo mismo en cuanto a rigor documental: OPSEC y COMSEC tienen definición oficial estandarizada con fuente normativa citable directamente; INFOSEC tiene definición legal formal, pero de alcance distinto al uso popular del término; y PERSEC presenta una ambigüedad terminológica notable que conviene señalar de forma explícita en vez de resolverla por conveniencia narrativa.

Definición precisa de cada término

OPSEC (Operations Security). Origen militar en Vietnam (Purple Dragon), formalizado en la NSDD-298 de 1988 — ya documentado en el apartado 1.1.1. La CNSSI 4009-2015 recoge la misma definición: un proceso sistemático mediante el cual los adversarios potenciales pueden ser privados de información sobre capacidades e intenciones, identificando, controlando y protegiendo evidencia generalmente no clasificada de la planificación y ejecución de actividades sensibles.

INFOSEC (Information Security / Information Systems Security). Su origen no es exclusivamente militar: la base legal más citada es el United States Code. El 44 U.S.C. §3542 —recodificado tras la FISMA de 2014 como §3552(b)(3), que conserva la misma definición sustantiva y añade no repudio y autenticidad dentro de integridad— define "seguridad de la información" como proteger la información y los sistemas de información contra el acceso, uso, divulgación, interrupción, modificación o destrucción no autorizados, para proporcionar confidencialidad, integridad y disponibilidad (el llamado "CIA triad"). El glosario NIST/CSRC, citando FIPS 200 y la CNSSI 4009-2015, reproduce esta misma definición.

COMSEC (Communications Security). Más antiguo que OPSEC en su formalización, ligado a la criptografía de comunicaciones desde mediados del siglo XX. La definición del Departamento de Trabajo de EE.UU. lo describe como las medidas tomadas para negar a personas no autorizadas información derivada de las telecomunicaciones del gobierno de EE.UU. relativas a la seguridad nacional, y para asegurar la autenticidad de dichas telecomunicaciones. El glosario NIST/CSRC lo trata como un componente de la Garantía de la Información (IA) que incluye, a su vez, seguridad criptográfica, seguridad de transmisión, seguridad de emisiones y seguridad física — es decir, COMSEC es en sí mismo un término paraguas con subcomponentes propios (ver más abajo TRANSEC y EMSEC).

PERSEC (Personnel/Personal Security). Es el término con mayor ambigüedad de los cuatro, y no existe una entrada de glosario CNSSI/NIST equivalente a las de OPSEC, INFOSEC y COMSEC. Tiene dos usos prácticamente no relacionados:

• Uso informal de comunidad militar/familiar (el más habitual en internet): protección de datos personales del militar y su familia —dirección, rango, fechas de despliegue— frente a terceros que podrían usarlos para causar daño. Se describe en foros militares como un complemento de OPSEC: mientras OPSEC trata sobre las operaciones del día a día (fechas de despliegue, números de serie de armamento, movimientos de tropas), PERSEC trata sobre la seguridad personal de cada individuo y cómo resguarda su propia información, y en ocasiones se aplica con menos rigor que OPSEC.
• Uso oficial gubernamental ("Personnel Security" / programa PerSec): completamente distinto — es el proceso de vetting y habilitaciones de seguridad de empleados y contratistas (idoneidad para el puesto), no la protección de datos personales de un individuo frente a terceros.

Qué protege cada uno y dónde se solapan

El PERSEC "oficial" gubernamental (vetting de personal) no encaja en esta tabla del mismo modo que las otras tres filas: respondería más bien a la amenaza de un "insider" no confiable, y es un programa de recursos humanos/habilitaciones, no una disciplina de protección de la información personal de un individuo frente a terceros. Por eso se trata aparte y no se fuerza en la misma fila conceptual.

OPSEC e INFOSEC se complementan: mientras INFOSEC protege los activos digitales mediante controles sobre el dato o el sistema, OPSEC se asegura de que el comportamiento humano y los procesos operativos no comprometan información sensible de forma indirecta. El solape más relevante para pentesting es el de OPSEC y COMSEC: una comunicación cifrada correctamente (COMSEC correcto) puede filtrar igualmente metadatos de patrón de tráfico —a quién, cuándo y con qué frecuencia se comunica alguien— que constituyen un fallo de OPSEC aunque el contenido esté perfectamente protegido.

Fallos por disciplina en un mismo engagement

El ejemplo más claro para distinguir estas disciplinas es verlas fallar por separado dentro de la misma operación de red team:

• Fallo de COMSEC: el equipo usa un canal C2 sin cifrar o con cifrado débil, permitiendo que el Blue Team —o un tercero— intercepte el contenido de las comunicaciones entre el implante y el servidor de mando y control.
• Fallo de INFOSEC: los datos almacenados en la infraestructura del Red Team —vulnerabilidades encontradas, exploits, datos exfiltrados del cliente— quedan sin protección adecuada, por ejemplo un servidor de reportes sin control de acceso ni cifrado en reposo. Es un fallo clásico de confidencialidad/integridad de datos en reposo, no de OPSEC.
• Fallo de OPSEC: usar la misma IP o el mismo proveedor para reconocimiento, phishing y C2. El contenido de cada comunicación puede estar perfectamente protegido —COMSEC correcto, INFOSEC correcto—, pero el patrón de origen compartido permite al defensor correlacionar las fases y atribuir la operación completa. Este es el ejemplo más didáctico del contraste entre las tres disciplinas: se puede tener COMSEC e INFOSEC impecables y aun así fallar en OPSEC.
• Fallo de PERSEC personal dentro del mismo contexto: un operador de red team que publica en sus redes sociales fotos etiquetadas de la oficina del cliente, o celebra públicamente haber comprometido a tal empresa. No es un fallo del engagement técnico en sí, sino una exposición personal que puede vincular al operador —y por extensión al cliente— de forma no autorizada.

En OPSEC personal, fuera de un contexto profesional, el mismo patrón se repite: usar una app de mensajería sin cifrado extremo a extremo para coordinar algo sensible es un fallo de COMSEC; reutilizar contraseñas entre servicios o no cifrar el disco de un portátil con datos sensibles es un fallo de INFOSEC; usar Signal y tener el disco cifrado pero publicar con regularidad horaria fotos con metadatos de ubicación es un fallo de OPSEC, porque el patrón agregado revela rutina y ubicación aunque ningún mensaje individual esté comprometido; y publicar el nombre completo de familiares, la dirección del domicilio o la rutina de los hijos en redes sociales es un fallo de PERSEC —exposición directa de datos identificatorios, no un fallo técnico de ningún sistema.

Por qué se confunden estos términos

La causa raíz es histórica: el propio término INFOSEC, en su acepción más antigua ligada a la NSA, ya incluía como subcomponentes la "seguridad de personal" y la "seguridad de transmisión" —antecesores de PERSEC y COMSEC. La superposición no es un error moderno de divulgación, sino que estuvo presente desde el origen porque INFOSEC nació como paraguas de varias disciplinas que hoy se tratan como términos separados.

La causa raíz conceptual, más citada en fuentes divulgativas modernas, es confundir "proteger el contenido o el sistema" (INFOSEC/COMSEC) con "proteger lo que se puede inferir del comportamiento" (OPSEC). Es el mismo patrón estructural que separa "seguridad de la información" de "ciberseguridad": la seguridad de la información es un término paraguas que incluye todos los datos, no solo los almacenados en el ciberespacio, y la ciberseguridad es un subconjunto suyo, no un sinónimo. Ese mismo esquema de "paraguas vs. subconjunto" se repite en la confusión entre OPSEC, INFOSEC y COMSEC.

El error conceptual concreto que produce la confusión de fondo —ya documentado en el apartado 1.1.2 sobre la Fase 3 de OPSEC— es tratar una vulnerabilidad de OPSEC como si fuera una vulnerabilidad de ciberseguridad tradicional: en OPSEC, una vulnerabilidad significa que un adversario es capaz de hacer algo para contrarrestar los planes propios, un sentido distinto del habitual en ciberseguridad. Ese mismo error de traslación semántica ocurre entre disciplinas completas, no solo dentro de una fase del proceso.

Un factor de confusión adicional, específico de PERSEC, es la coexistencia de dos significados sin relación directa entre sí: cualquier intento de definir PERSEC "en general" es, en la práctica, un acto de elegir arbitrariamente una de las dos acepciones —algo que no ocurre del mismo modo con los otros tres términos.

Términos relacionados: TRANSEC, EMSEC, SIGSEC, TECHSEC

COMSEC no es un término atómico: tiene subcomponentes formales y bien documentados.

• TRANSEC (Transmission Security): subcomponente formal de COMSEC. Es el componente que resulta de aplicar medidas diseñadas para proteger las transmisiones de la interceptación y explotación por medios distintos al criptoanálisis —salto de frecuencia, espectro ensanchado. Uso activo y vigente, sobre todo en radiocomunicaciones militares y en despliegues 5G de uso militar.
• EMSEC (Emission Security): subcomponente formal de COMSEC relacionado con TEMPEST, enfocado en proteger información sensible de ser interceptada mediante emisiones electromagnéticas no intencionadas. Uso vigente pero de nicho: contramedidas TEMPEST, hardware de alta seguridad.
• SIGSEC (Signal Security): término militar más amplio que engloba tanto COMSEC como la protección frente a inteligencia de señales, incluyendo COMINT e interceptación de señales electromagnéticas no relacionadas con datos, como señales de radar. Uso histórico/doctrinal, menos citado hoy en fuentes civiles que TRANSEC o EMSEC.

La jerarquía resultante es: COMSEC como paraguas; TRANSEC y EMSEC (junto con la criptoseguridad) como sus subcomponentes formales y bien documentados; SIGSEC como término histórico/doctrinal emparentado; y TECHSEC sin respaldo documental equivalente encontrado hasta la fecha.

Es habitual tratar "ser anónimo" y "tener buen OPSEC" como sinónimos. No lo son. El anonimato es un resultado deseado —y frágil—; OPSEC es el proceso que, si se sostiene en el tiempo, puede producir ese resultado. Se puede tener una herramienta de anonimato técnicamente intachable y aun así ser identificado, y se puede tener un proceso de OPSEC sólido sin que eso implique anonimato absoluto frente a todos los observadores posibles.

Anonimato vs. OPSEC (y privacidad)

El anonimato significa aumentar el coste, el esfuerzo y la incertidumbre necesarios para atribuir una acción a una identidad real del mundo físico. Una identidad se considera "anónima" cuando la atribución se vuelve poco fiable, no imposible — y el anonimato sin un modelo de amenaza definido carece de sentido práctico.

Conviene distinguir también un tercer término con el que se confunde: la privacidad. El anonimato consiste en mantener oculta la identidad, pero no necesariamente las acciones —por ejemplo, publicar con un pseudónimo en redes sociales—; la privacidad consiste en mantener ciertas cosas reservadas, lo que puede incluir las propias acciones —por ejemplo, enviar mensajes privados a amigos que saben quién los envía, pero que solo ellos pueden leer—. La seguridad —las precauciones para mantenerse a salvo— suele ser un prerrequisito de la privacidad en línea, pero es menos determinante para el anonimato en sí.

La relación entre anonimato y OPSEC tiene una dirección concreta: lograr anonimato real requiere buena seguridad operacional para asegurar que, por ejemplo, la dirección IP real no quede revelada. El anonimato es el resultado; OPSEC es el proceso que lo sostiene o lo hace colapsar.

El modelo de capas de protección

• Capa de red/técnica: herramientas como Tor, VPN o proxies, que ocultan el origen técnico del tráfico. Es la capa más discutida en fuentes populares y también la más citada como insuficiente por sí sola.
• Capa de identidad: separación entre identidades y alter egos —correo, alias, dispositivo— para que una no pueda vincularse a la otra.
• Capa de comportamiento: patrones, horarios y estilo de escritura. El comportamiento es, según varias fuentes, el identificador más fuerte: un sistema puede ocultar de dónde viene el tráfico mientras revela quién eres a través del ritmo temporal, el lenguaje, las elecciones y la repetición.
• Capa de metadatos: información incrustada en archivos —EXIF, timestamps, cabeceras de correo, metadatos de documentos— que puede revelar ubicación, autoría o momento de creación aunque el contenido esté protegido.
• Capa humana/social: exposición a través de terceros —conversaciones informales, redes sociales personales, contactos de confianza— que puede filtrar información incluso cuando el propio operador mantiene disciplina técnica.

Casos documentados por capa

Un patrón se repite en todos los casos verificados en esta investigación: en ninguno hubo una rotura criptográfica o técnica de Tor o de una VPN. La herramienta de anonimato funcionó exactamente como se supone que debía funcionar; el colapso vino de otra capa.

Capa de red/contexto — Eldo Kim, amenaza de bomba en Harvard (2013). Kim usó Tor y Guerrilla Mail (un servicio de correo temporal) para enviar una amenaza de bomba anónima. La Universidad de Harvard pudo determinar que, en las horas previas al envío, Kim había accedido a Tor usando la red inalámbrica de Harvard, que requiere autenticación con usuario y contraseña. Los investigadores cruzaron los registros de conexión a esa red inalámbrica con las direcciones IP públicas conocidas de Tor en la franja horaria del envío, reduciendo la lista de sospechosos a un grupo muy pequeño. Bruce Schneier resumió el mecanismo con una frase ya convertida en referencia de la industria: "El FBI no tuvo que romper Tor; simplemente usaron mecanismos policiales convencionales para conseguir que Kim confesara. Tor no se rompió; Kim sí."

Capa de metadatos — John McAfee, fuga en Guatemala (2012). Un usuario de Twitter notó que una fotografía de McAfee publicada por la revista Vice contenía metadatos EXIF con las coordenadas GPS exactas de dónde se había tomado: junto a la piscina de un resort en Guatemala. El fallo de metadatos no fue de McAfee directamente, sino del fotógrafo o técnico de Vice que subió la imagen sin limpiar sus metadatos — un matiz importante: la capa de metadatos puede fallar por terceros no controlados por el propio operador, incluso cuando este mantiene buena disciplina personal.

Capa de identidad — Ross Ulbricht / Silk Road (ya documentado en el apartado 1.1.1). Silk Road operaba correctamente como servicio oculto de Tor: el fallo no fue de la capa técnica de anonimización de la red, sino de la capa de identidad y comportamiento del operador —reutilización del alias "altoid", correo personal, publicación en LinkedIn—. Una fuente reciente sobre fallos catastróficos de OPSEC describe este patrón como una acumulación de errores aparentemente menores y no correlacionados entre sí que, sumados, crean una vía innegable para la investigación forense — el colapso rara vez es un solo fallo, sino una reacción en cadena.

Capa de comportamiento/estilo — J.K. Rowling / "Robert Galbraith" (2013). Rowling publicó la novela "The Cuckoo's Calling" bajo el pseudónimo Robert Galbraith en abril de 2013. La sospecha se originó en un tuit anónimo que acusó a Rowling de ser la autora; a partir de esa acusación, el análisis estilométrico —comparando el estilo de escritura con las novelas de Harry Potter y con obras de otras autoras del mismo género, mediante el software JGAAP— confirmó la autoría en julio de 2013. Es importante no invertir esta secuencia: la estilometría confirmó una sospecha ya circulante, no fue el método que destapó el caso desde cero. Es, aun así, el ejemplo académico mejor documentado de que el estilo de escritura por sí solo puede desanonimizar a un autor sin que medie ninguna herramienta técnica de por medio.

Capa de comportamiento/patrón temporal — Jeremy Hammond (LulzSec) (ya introducido en el apartado 1.1.2). Hammond sí usaba Tor, y el anonimato de red en sí no fue vulnerado.

Estado puntual vs. proceso continuo

OPSEC no consiste en lograr el anonimato una vez, sino en mantener la incertidumbre a lo largo del tiempo. En el momento en que el comportamiento se vuelve predecible, el anonimato empieza a fallar, sin importar cuán fuerte parezca la capa técnica. El anonimato pleno exige usar de forma consistente las herramientas y hábitos de protección en todos los aspectos de la propia vida en línea, porque incluso una falta temporal y puntual de disciplina es suficiente para exponer una identidad —basta un solo momento de descuido, como el acceso a Tor desde una red autenticada o un inicio de sesión sin proxy, para colapsar retroactivamente meses de buena disciplina—.

El modelo del caso Ulbricht/FIN7 descrito antes como "acumulación de errores menores" ilustra el mismo principio desde otro ángulo: el colapso de OPSEC no suele ser un evento único, sino la acumulación de múltiples fallos a lo largo del proceso — justo lo opuesto de un estado binario de "anonimato logrado o no logrado".

Aplicación de las capas: red team vs. personal

OPSEC ofensivo vs. OPSEC defensivo

OPSEC ofensivo (aplicado por quien ataca o testea) es el conjunto de prácticas para minimizar la huella detectable de la propia operación —infraestructura, herramientas, comportamiento— de modo que el defensor no pueda atribuir, correlacionar o anticipar la actividad antes de que se cumplan los objetivos de la operación o, en un red team, antes de que se agote el tiempo de evaluación planificado. OPSEC defensivo es, desde el lado de quien protege una organización, el trabajo de detectar, correlacionar y atribuir esa huella — la disciplina del Blue Team y de threat intelligence que convierte los descuidos del operador ofensivo en indicadores accionables.

En la jerga de red teaming, ambos términos no son dos aplicaciones análogas del mismo concepto sobre objetos distintos, sino dos roles con objetivos opuestos dentro del mismo ejercicio: el objetivo del Red Team no es proteger información —esa es tarea del Blue Team— sino proteger sus propios procesos, de modo que sea difícil para el Blue Team saber qué está haciendo el Red Team en cada momento.

El nivel de rigor exigido no es el mismo en todos los ejercicios ofensivos autorizados. A diferencia de un pentest, un red team suele ser no anunciado —o conocido solo por un grupo reducido de ejecutivos—: el equipo de seguridad, los analistas del SOC y los respondedores de incidentes operan en condiciones normales, sin saber que están siendo evaluados, lo que permite una evaluación auténtica de las capacidades defensivas. Los red teams suelen operar durante semanas o meses, no días, moviéndose despacio y con cuidado para evitar la detección, imitando a una amenaza persistente avanzada (APT). En un pentest tradicional el OPSEC ofensivo importa menos, porque no hay pretensión de sigilo; en un red team es el núcleo mismo del ejercicio.

Qué huella deja el operador aunque la técnica sea correcta

El principio central de este apartado es el mismo que ya se vio en el apartado 1.1.4 aplicado al anonimato personal: se puede tener el cifrado y la infraestructura técnicamente impecables y aun así dejar una huella identificable, porque la huella no está en el contenido, sino en el patrón.

Huella en el handshake TLS. JA3 y JA3S combinan valores del Client Hello y del Server Hello —versión, cifrados aceptados, extensiones, curvas elípticas— y los reducen a un hash. Ese hash identifica la herramienta o el framework subyacente, no la IP ni el dominio de destino.

Frameworks de C2 como Cobalt Strike sin personalizar son identificables de inmediato a partir de logs de red pasivos; herramientas de escaneo como Masscan o ZMap envían mensajes ClientHello mínimamente elaborados que ningún navegador legítimo enviaría; incluso los clientes de Tor emiten un perfil TLS fijo que no ha cambiado sustancialmente entre versiones. Mientras JA3 identifica al cliente, JARM identifica al servidor: envía paquetes TLS especialmente diseñados y registra cómo responde. Muchos operadores usan configuraciones por defecto, por lo que sus servidores C2 a menudo comparten el mismo hash JARM en todo internet, lo que permite pivotar de un único indicador a toda una campaña.

Huella de comportamiento temporal (timing/beaconing). Herramientas de threat hunting como RITA están diseñadas para detectar el ritmo de beaconing incluso cuando se aplica jitter, puntuando la periodicidad estadística a través de múltiples conexiones.

El "ataque de correlación" del caso Jeremy Hammond, ya documentado en el apartado 1.1.2 —el FBI cruzando horarios de conexión IRC con presencia física en el domicilio—, es, en esencia, el mismo principio de detección por timing aplicado fuera del contexto puramente técnico. En ese caso, sin embargo, se trataba de un actor real bajo investigación criminal, no de un ejercicio autorizado.

Huella de reutilización de infraestructura entre operaciones. Es el error más citado en las guías de red teaming: usar la misma dirección IP o el mismo proveedor para múltiples fases de un engagement, ya documentado en el apartado 1.1.3 como el ejemplo que mejor separa OPSEC de COMSEC/INFOSEC.

Huella forense en disco y logs. Un análisis que examina de forma conjunta a Ross Ulbricht (ya documentado en el apartado 1.1.1, actor criminal condenado), el sindicato de cibercrimen FIN7 y actores estatales rusos —incluido el grupo conocido como Volt Typhoon— describe un patrón recurrente: malware personalizado y tácticas avanzadas son constantemente socavados por fallos rudimentarios en la gestión de identidad, el endurecimiento de infraestructura y la configuración de herramientas —fuga de identidad a través de fragmentos de código público, configuraciones inseguras por defecto en frameworks de C2 como Cobalt Strike, exposición de datos por servidores mal configurados y reutilización de huellas de infraestructura—.

Infraestructura de operación: redirectores y compartimentación

El modelo de infraestructura más repetido en las guías técnicas de red teaming sigue una arquitectura por etapas: Objetivo → Redirector Stage 0 → Servidor de Staging (phishing/acceso inicial) → Redirector Stage 1 → Servidor Long-Haul (persistencia) → Redirector Stage 2 → Servidor Interactivo (post-explotación) → Redirector Stage 3 → Servidor de Exfiltración.

Un redirector es un servidor HTTPS con un certificado SSL válido sobre un dominio categorizado y "envejecido", que reenvía el tráfico del implante al team server y sirve contenido señuelo a cualquier otra solicitud. El principio detrás de esta arquitectura es la compartimentación de fallos: si un defensor encuentra el endpoint de la CDN, aun así no puede alcanzar el team server; si el redirector se "quema", se levanta uno nuevo y se vuelve a apuntar la CDN, mientras el team server permanece intacto. Cada etapa usa infraestructura completamente aislada —dominios, proveedores de VPS, IPs y certificados distintos—, y ningún dominio se reutiliza entre payloads, tráfico de C2 y phishing: si un dominio se quema, solo se pierde esa función.

• Separación por cliente: mantener infraestructura completamente separada para cada cliente u operación es un principio básico de la configuración de infraestructura de red team, junto con la rotación regular de sus componentes.
• Envejecimiento de dominios: los sistemas de reputación ponderan mucho la edad de un dominio; uno registrado seis horas antes de su primer uso se trata de forma muy distinta a uno registrado seis meses antes y usado ligeramente durante el tiempo intermedio. La adquisición debe planificarse con semanas de antelación, y comprar dominios expirados con uso legítimo previo es una práctica común.
• Rotación de redirectores: no se ejecuta un servidor de C2 de forma indefinida sobre la misma IP; se rota cada 7 a 14 días en engagements activos.
• Segmentación por confianza según etapa: la etapa de largo alcance (post-explotación) usa la infraestructura de mayor confianza —dominios más antiguos, frecuencia de beacon más baja— y, a menudo, un framework distinto al de la etapa de acceso inicial, para evitar que el compromiso de una sola herramienta arrastre toda la cadena.

Cómo detecta el Blue Team esos fallos

El marco de referencia para entender qué indicadores importan más es la Pirámide del Dolor, desarrollada por David Bianco en 2013 durante las investigaciones de APT1 en Mandiant. Describe seis niveles de indicadores de compromiso (IOC), de menos a más costoso de cambiar para el atacante: valores hash, direcciones IP, nombres de dominio, artefactos de red y de host, herramientas, y finalmente tácticas, técnicas y procedimientos (TTP).

Un atacante puede cambiar con facilidad valores hash, IPs y dominios —los tres niveles más bajos—; las TTP, en el nivel superior, son las más difíciles de cambiar, porque en esencia se reducen a comportamientos del adversario. Por eso las TTP son el indicador en el que los defensores deben enfocarse para detecciones robustas basadas en conocimiento previo. El caso Salesforce/JA3-JA3S ya descrito es el ejemplo perfecto de "subir en la pirámide": el equipo defensor dejó de perseguir IP o dominio —niveles bajos, fáciles de rotar— y empezó a perseguir la huella de la herramienta y la infraestructura subyacente —nivel alto, difícil de cambiar sin rehacer todo el stack—.

La correlación de infraestructura vía threat intelligence sigue un patrón repetible más allá de JA3: se parte de un dominio sospechoso encontrado en un correo de phishing; se enriquece usando Shodan o Censys para obtener el hash JARM del servidor de ese dominio; se pivota buscando ese hash JARM único en todo internet; y el resultado puede ser el descubrimiento de otras direcciones IP alojando el mismo framework de C2, aunque no hayan atacado todavía al analista — inteligencia operativa proactiva, no solo reactiva.

La reutilización de TTP es, además, la base de buena parte de la atribución: los actores de amenaza reutilizan técnicas y procedimientos por familiaridad operativa, por las cadenas de herramientas disponibles o por restricciones de infraestructura, y los analistas aprovechan esa consistencia para construir firmas de comportamiento — perfiles compuestos basados en patrones de TTP.

Frameworks: MITRE ATT&CK, TIBER-EU y Rules of Engagement

MITRE ATT&CK no es un feed tradicional de inteligencia de amenazas con indicadores de compromiso en tiempo real: se centra en las TTP. Incluye "Campaigns" —operaciones específicas o series de actividad realizadas por grupos de amenaza, dirigidas a organizaciones, sectores o geografías particulares—; la versión 18 del framework (octubre de 2025) contenía 55 campañas identificadas.

El ecosistema alrededor de ATT&CK incluye ATT&CK Navigator (visualización), el MITRE Cyber Analytics Repository —CAR— (analíticas de detección), Caldera (red teaming automatizado basado en técnicas ATT&CK) y Atomic Red Team, de Red Canary (pruebas de defensas contra técnicas específicas). El uso del framework difiere según el rol: los equipos de threat intelligence lo usan para investigar técnicas empleadas por adversarios, los equipos rojos para emulación de adversarios y validación de seguridad, los equipos azules para mejorar la detección, y los equipos púrpura como puente entre ambos — no hay una única "lectura" del framework, sino usos paralelos según el rol.

TIBER-EU es el ejemplo más formal y regulatorio de que el OPSEC ofensivo de un red team no es opcional ni informal. Fue desarrollado conjuntamente por el Banco Central Europeo y los bancos centrales nacionales de la UE, aprobado por el Consejo de Gobierno del BCE y publicado en mayo de 2018, como respuesta estratégica a la creciente sofisticación de los ciberataques dirigidos a infraestructura crítica. A diferencia de las pruebas de penetración convencionales, TIBER-EU utiliza inteligencia de amenazas del mundo real para imitar las TTP empleadas por adversarios reales, sobre los sistemas críticos de producción en vivo de las entidades. Los cinco equipos que participan en una prueba TIBER-EU son:

Las Rules of Engagement (RoE) son el marco de gobernanza que autoriza y limita el OPSEC ofensivo en un engagement legítimo. Distinguen explícitamente el alcance dentro ("in-scope": redes, dominios, ubicaciones físicas y personal autorizados), el alcance fuera ("out-of-scope": sistemas, datos e individuos estrictamente prohibidos) y el "no definido" —qué hacer cuando se identifican activos del cliente que no están ni dentro ni fuera del alcance—. Incluyen también una lista detallada de TTP autorizadas y prohibidas: acciones que el cliente podría percibir como destructivas o que no quiere arriesgar.

Por qué importa en un engagement autorizado

El OPSEC ofensivo en un contexto autorizado cumple funciones que no existen para un atacante malicioso, precisamente porque el objetivo no es solo evitar la detección, sino ejecutar el ejercicio de forma segura y útil para el cliente.

• Evitar contaminar los sistemas del cliente: fijar un marco temporal preciso ayuda a los equipos SOC a diferenciar la actividad legítima de pruebas de la de un ataque real, reduciendo falsos positivos. La "planificación de supresión de alertas" consiste en informar de antemano a los equipos SOC sobre qué tráfico esperar.
• De-conflicción: las acciones del pentest deben poder identificarse frente al equipo de seguridad del cliente para evitar conflictos; las IPs o herramientas usadas pueden hacer saltar alertas, y para evitar ser bloqueado puede ser necesario incluirlas en una lista blanca durante el periodo de pruebas. Los canales de comunicación con el cliente también sirven para confirmar si un resultado extraño es un falso positivo.
• Distinguir la propia actividad de una intrusión real: los métodos de un red team pueden ser intrusivos, pero no deben ser destructivos, y se detienen si se descubre evidencia de una intrusión real en curso — el equipo es responsable de informar al contacto designado del cliente si esto ocurre. Es una función que no existe para un atacante malicioso: distinguir la propia simulación de un ataque genuino de un tercero, para poder alertar al cliente.

Por eso el primer paso de cualquier ejercicio ofensivo autorizado es decidir qué se está probando realmente: si el objetivo es comprobar si el SOC puede detectar movimiento lateral, o si un correo de phishing puede llegar a finanzas, el nivel de sigilo exigido y el momento de comunicar al Blue Team cambian por completo. Mapear la prueba contra MITRE ATT&CK da un lenguaje compartido entre el equipo ofensivo y quienes defienden la red — y es, en última instancia, lo que convierte el "OPSEC ofensivo" de una simple cuestión de no ser detectado en una herramienta al servicio de un objetivo de seguridad medible y acordado con el cliente.

Qué significa "OPSEC by design"

La base analógica es Privacy by Design, desarrollado por Ann Cavoukian —entonces Comisionada de Privacidad de Ontario, Canadá— desde los años 90 y publicado formalmente en agosto de 2009 (revisado en enero de 2011). Su idea central: el enfoque se caracteriza por adoptar medidas proactivas en vez de reactivas, anticipando y previniendo eventos invasivos de la privacidad antes de que ocurran, en vez de ofrecer remedios una vez que ya han ocurrido. Privacy by Design llega antes del hecho, no después.

Los siete principios fundacionales del marco son: proactivo, no reactivo —preventivo, no remedial—; privacidad como configuración por defecto; privacidad incorporada en el diseño; funcionalidad completa —de suma positiva, no de suma cero—; seguridad de extremo a extremo, con protección durante todo el ciclo de vida; visibilidad y transparencia; y respeto por la privacidad del usuario, manteniendo el enfoque centrado en la persona. En octubre de 2010, la Conferencia Internacional de Autoridades de Protección de Datos y Comisionados de Privacidad aprobó por unanimidad una resolución que reconoce Privacy by Design como componente esencial de la protección fundamental de la privacidad; desde entonces se ha traducido a 37 idiomas.

Trasladado al vocabulario de OPSEC, "by design" significaría aplicar esa misma lógica —anticipar y prevenir, no remediar— a la gestión de la identidad operativa (en un pentest) o de la identidad personal: separar compartimentos, aislar infraestructura y fijar hábitos de comportamiento antes de que exista cualquier vínculo entre la identidad protegida y la identidad real, en vez de intentar "limpiar" esa relación después de que ya se haya establecido.

Por qué remediar a posteriori casi nunca funciona

Ya se describió en el apartado 1.1.1 cómo un fallo en identificar un dato como crítico arrastra, en cadena, el fallo del resto de fases de OPSEC. El punto adicional aquí es estructural: una vez que un dato no protegido ha sido expuesto —indexado, cacheado, citado por terceros, archivado en un registro que no está bajo el propio control—, revertir esa exposición es, en la práctica, extremadamente difícil.

El caso de Ross Ulbricht, ya documentado en el apartado 1.1.1, ilustra bien por qué "parchear" después no basta. Ulbricht usó el alias "altoid" en varios foros para anunciar Silk Road a comienzos de 2011, y volvió a usarlo después para contratar desarrolladores, pidiendo currículums a una dirección de correo personal identificable — el alias ya llevaba tiempo existiendo como identidad pública antes de que se intentara usarlo como cobertura operativa; no hubo separación desde el minuto cero. Cuando más tarde cambió el nombre de usuario a "frosty" y el correo a frosty@frosty.com, ese cambio no rompió la cadena: la extendió. El análisis forense del servidor incautado encontró una clave pública SSH con el comentario frosty@frosty en el archivo de claves autorizadas del servidor de administración de Silk Road, creando una línea trazable desde la pregunta de StackOverflow hasta la administración del servidor. El cambio de alias, hecho después de que ya existiera un vínculo, simplemente añadió un eslabón más a la cadena.

El caso de Hector Monsegur / "Sabu", ya documentado en el apartado 1.1.1, ofrece otro ejemplo de vínculo fijo creado antes o al margen de la disciplina operativa posterior: un dominio a veces mencionado por Sabu, prvt.org, había sido registrado usando su nombre y dirección reales. Una vez creado ese registro, no había forma de "arreglarlo" después sin abandonar el dominio por completo — y aun así, el registro histórico ya existía.

Compartimentación como principio central

La compartimentación, en seguridad de la información, es la limitación del acceso según la necesidad de conocer ("need-to-know") para realizar ciertas tareas. Se originó en el manejo de información clasificada en aplicaciones militares y de inteligencia, y se remonta a la antigüedad: se usó con éxito para mantener el secreto del fuego griego, un caso documentado en una fuente académica indexada sobre secreto tecnológico y guerra en Bizancio.

La lógica de fondo es simple: si menos personas conocen los detalles de una tarea, se reduce la probabilidad de que esa información se vea comprometida o llegue al adversario. De ahí que existan distintos niveles de habilitación dentro de las organizaciones — e incluso con la habilitación más alta, cierta información compartimentada puede seguir restringida a determinados operadores.

Aplicado a OPSEC personal, es más robusto fragmentar y compartimentar la propia actividad en línea a través de múltiples identidades no vinculadas entre sí; tanto Ross Ulbricht como Hector Monsegur carecieron de esa compartimentación adecuada. Una estructura útil para entender dónde encaja la compartimentación dentro de OPSEC personal distingue cuatro grupos de contramedidas: sentido común y mentalidad de seguridad; conciencia del egocentrismo, el orgullo, la vanidad y la codicia; compartimentación mediante múltiples identidades; e implementación técnica. La compartimentación aparece como tercer pilar, después de la actitud y antes de la implementación técnica — no es "una herramienta más", sino una categoría de nivel superior a los controles técnicos.

El propio Manual OPSEC del Departamento de Defensa de EE.UU. añade un matiz relevante para "by design", ya citado en el apartado 1.1.2 bajo otro marco doctrinal: al valorar una contramedida hay que evaluar también la posibilidad de que la propia contramedida cree un nuevo indicador de OPSEC — la compartimentación mal ejecutada puede generar, en sí misma, un patrón detectable.

Decisiones desde el minuto cero

Identidades separadas antes de operar. En el tradecraft clásico de espionaje —oficiales de caso de la CIA, "ilegales" de la KGB— la compartimentación de la actividad ilícita respecto a la vida normal empieza por una regla simple: no discutir esa actividad con nadie fuera del compartimento correspondiente. En comunidades de práctica más informales, esta misma lógica se describe con el vocabulario de "identidad burner": una identidad creada como escudo antes de cualquier momento de exposición, no como recurso improvisado durante o después de ella.

Infraestructura aislada antes del primer uso. El envejecimiento de dominios, ya descrito en el apartado 1.1.5, es el ejemplo técnico más claro de "by design": los sistemas de reputación ponderan mucho la edad de un dominio, y esa antigüedad no puede fabricarse retroactivamente una vez iniciada la operación — la adquisición debe planificarse con semanas de antelación.

Hábitos de comportamiento separados desde el principio. La compartimentación como hábito diario se resume en comunidades de práctica como no poner "todos los huevos de la identidad en la misma cesta": mantener separados el trabajo, la vida personal, los alias y las tareas desde el primer día, en vez de intentar separar después actividades que ya se mezclaron.

Errores típicos al "arreglar" OPSEC después de un fallo

El patrón cognitivo de fondo, ya descrito en el apartado 1.1.5 como modelo de "acumulación de errores", explica por qué el parche suele llegar tarde: para cuando alguien percibe la necesidad de "arreglar" su OPSEC, es probable que ya existan múltiples vínculos menores acumulados, no solo uno. Arreglar el vínculo más visible no elimina los demás que ya están dispersos en registros de terceros fuera del propio control.

Aplicación práctica: red team vs. OPSEC personal

Pentest/red team. El orden de fases del checklist ya citado es explícito: Rules of Engagement → perfiles de amenaza → infraestructura de amenaza (IPs, sistemas, redirectores, PPS por nivel) → despliegue de herramientas → solo entonces comienza la fase de Execution. La infraestructura no solo se prepara antes de actuar: se prepara con la antelación suficiente para adquirir propiedades —antigüedad, reputación— que no podrían lograrse preparándola sobre la marcha.

El diseño previo tampoco es gratuito: preparar infraestructura con semanas de antelación —dominios envejecidos, certificados, VPS ya en uso ligero— tiene un coste real en tiempo y dinero que no todos los engagements pueden permitirse. Existe una tensión legítima entre el rigor de OPSEC exigido y el presupuesto o los plazos acordados con el cliente; "by design" es un ideal a perseguir, no una opción sin coste que siempre esté disponible.

OPSEC personal. El mismo principio de compartimentación se traduce en crear el compartimento —alias, correo, dispositivo o perfil de navegador separado— antes de la primera publicación, en vez de después de que la identidad real y la identidad protegida ya hayan compartido algún rastro común (IP, alias, estilo de escritura, hora de actividad). Una tarea concreta de "primer día", descrita en fuentes de comunidad, consiste en escribir el propio modelo de amenaza —qué se protege y de quién— y empezar a compartimentar separando la cuenta personal diaria de las identidades de pruebas o de trabajo.

Fuentes de todo el tema 1.1

Fuentes consultadas y citadas a lo largo de los apartados 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5 y 1.1.6 de este tema.

1.1.1 — ¿Qué es OPSEC? Más allá de las cinco fases clásicas

• NSDD-298, "National Operations Security Program", 22 enero 1988: irp.fas.org/offdocs/nsdd/nsdd-298.pdf y irp.fas.org/offdocs/nsdd298.htm
• Joint Publication 3-13.3, "Operations Security" (DoD), versiones 2006/2012: bits.de/.../JP3-13-3(12).pdf y publicintelligence.net/jcs-operations-security
• ATP 3-13.3, "Army Operations Security for Division and Below", julio 2019: usacac.army.mil
• NSA Center for Cryptologic History, "Purple Dragon: The Origin and Development of the United States OPSEC Program" (1993, desclasificado): archive.org/stream/purple_dragon-nsa
• SANS Institute, área Red Team / Offensive Operations: sans.org
• Red Team Guide (redteam.guide), sección "Definitions": redteam.guide/docs/definitions
• Hacktive Security, "Introduction to OPSEC (Part 2)": hacktivesecurity.com
• The Register, "Opsec oversights: How cybercrooks get themselves caught" (jul. 2025)
• CSO Online, "Opsec examples: 6 spectacular operational security failures" (jul. 2023)
• CoinDesk, "Silk Road fell due to a catalogue of errors by owner Ross Ulbricht" (2013)
• The Register, "The 'one tiny slip' that put LulzSec chief Sabu in the FBI's pocket" (2012)
• F5 Labs, "Profile of a Hacker: The Real Sabu, Part 2" (2017)
• BankInfoSecurity/DataBreachToday, "Poor Opsec Led to Spyware Developer's Downfall" / "No 'Invisible God': Fxmsp's Operational Security Failures"

1.1.2 — Las 5 fases clásicas de OPSEC

• NIST/CSRC Glossary, "operations security (OPSEC)", vía CNSSI 4009-2015 y DoDD 5205.02E: csrc.nist.gov/glossary/term/operations_security
• NTTP 3-13.3M / MCTP 3-32B, "Operations Security" (Marina/Cuerpo de Marines de EE.UU., 2017): media.defense.gov
• CDSE (Center for Development of Security Excellence, DoD), guía de estudiante GS130, "OPSEC Awareness for Military Members, DoD Employees": cdse.edu
• TryHackMe, sala "Red Team OPSEC" / "Red Team Frameworks" — resúmenes y walkthroughs: Medium, GitHub, InfoSecCafe, Motasem Notes
• Hacktive Security, "Introduction to OPSEC (Part 1)": hacktivesecurity.com
• Noorstream, "Top OPSEC Mistakes in Red Team Operations Explained": noorstream.com
• Splunk, "What Is OPSEC? Operations Security and How It Works": splunk.com
• CSO Online, "What is OPSEC? How operations security protects critical information": csoonline.com

1.1.3 — Diferencias entre OPSEC, INFOSEC, COMSEC y PERSEC

• CNSSI No. 4009, "Committee on National Security Systems (CNSS) Glossary" (6 abril 2015): rmf.org
• NIST CSRC Glossary — "information security": csrc.nist.gov/glossary/term/information_security e "INFOSEC": csrc.nist.gov/glossary/term/INFOSEC
• NIST CSRC Glossary — "communications security": csrc.nist.gov/glossary/term/communications_security
• 44 U.S.C. §3542 (recodificado como §3552 tras FISMA 2014), base legal de "information security": govinfo.gov
• Departamento de Comercio de EE.UU., páginas de programa COMSEC y "Personnel Security (PerSec)": commerce.gov/.../communications-security y commerce.gov/.../personnel-security — 🔍 cita textual pendiente de verificación manual
• Wikipedia (con fuentes primarias enlazadas), "Transmission security": en.wikipedia.org/wiki/Transmission_security
• Marine Parents / After The Corps, "PERSEC vs OPSEC": marineparents.com
• MilitarySpot.com, "OPSEC and PERSEC": militaryspot.com
• Urban Dictionary, entrada "PERSEC" (fuente informal, no normativa): urbandictionary.com — 🔍 cita textual pendiente de verificación manual
• OT Security Hub, "OpSec vs InfoSec: What's the Difference?": otsecurityhub.com
• IT Law Wiki, entrada "Information security" (incluye la definición histórica de INFOSEC como paraguas de PERSEC/COMSEC): itlaw.fandom.com/wiki/Information_security

1.1.4 — Por qué OPSEC no es anonimato — el modelo de capas de protección

• U.S. Attorney's Office, District of Massachusetts, comunicado sobre Eldo Kim: justice.gov/usao-ma
• Forbes, "Harvard Student Receives F For Tor Failure While Sending 'Anonymous' Bomb Threat" (18 dic. 2013): forbes.com
• Harvard Crimson, cobertura del caso Kim con cita del afidávit del FBI (17 dic. 2013): thecrimson.com
• Bruce Schneier, "Tor User Identified by FBI": schneier.com
• Scientific American, "McAfee's Rookie Mistake Gives Away His Location": scientificamerican.com
• NPR, "Betrayed By Metadata: John McAfee Admits He's Really In Guatemala": npr.org
• Graham Cluley, cobertura del caso McAfee y los metadatos EXIF: grahamcluley.com
• U.S. Attorney's Office, SDNY, comunicados sobre arresto y extradición de Roger Thomas Clark: arresto y extradición
• Hacktive Security, "Introduction to OPSEC (Part 2)" — modelo de acumulación de errores aplicado a Ulbricht: hacktivesecurity.com
• Narayanan et al., paper IEEE S&P sobre desanonimización a escala de Internet mediante estilometría, resumido por el propio autor: 33bits.wordpress.com
• Paper sobre estilometría aplicada a foros de la dark web (ACM/Springer): dl.acm.org
• State of Surveillance, artículo divulgativo sobre estilometría (menciona el caso Rowling/Galbraith): stateofsurveillance.org

1.1.5 — OPSEC ofensivo vs defensivo: el atacante también deja huella

• MITRE ATT&CK, página oficial de recursos ("Get Started"): attack.mitre.org/resources
• TIBER-EU, framework oficial del Banco Central Europeo: ecb.europa.eu/tiber-eu y documentación en tiber-eu.fr
• David J. Bianco, "The Pyramid of Pain" (2013), entrada de blog original: detect-respond.blogspot.com — 🔍 acceso directo pendiente de verificación manual
• Red Team Guide, plantilla de Rules of Engagement: redteam.guide/docs/Templates/roe_template
• Salesforce Engineering Blog, "TLS Fingerprinting with JA3 and JA3S" (incluye el caso real de pentesters detectados tras rotar infraestructura): engineering.salesforce.com
• CTI Wiki, "Infrastructure Tracking: Fingerprinting with JA3 and JARM": cyberthreatintelligence.net
• Hive Security, "Cobalt Strike Detection & Hunting: A Defender's Playbook": hivesecurity.gitlab.io
• Vectra AI, "C2 Evasion Techniques: Understanding JA3/S Randomization" (menciona la investigación de Akamai sobre aleatorización de huellas): vectra.ai — 🔍 cifras de Akamai pendientes de verificación manual
• Cobalt.io, "Red Team Rules of Engagement (RoE): A Comprehensive Checklist & Guide": cobalt.io
• ioSENTRIX, "What are the Rules of Engagement in Penetration Testing?": iosentrix.com
• Praetorian, "Red Team vs Penetration Testing: What's the Difference?": praetorian.com
• "C2 Infrastructure OPSEC for Red Team Operations": cybersecpentesting.com
• DbgMan, "Red Team Infrastructure The Full Picture: From Domain to Beacon": 0xdbgman.github.io
• Parrot CTFs, "Red Team Infrastructure: Complete Guide to Setup and Best Practices in 2025": parrot-ctfs.com

Nota: varias de las fuentes de infraestructura de red team citadas arriba (blogs de comunidad y de marketing de servicios de pentest) documentan prácticas ampliamente extendidas, pero no constituyen un estándar normativo único — no existe, hasta la fecha, un documento equivalente a la NSDD-298 para la infraestructura ofensiva de red teaming.

1.1.6 — OPSEC by design: desde el primer minuto, no como parche

• Ann Cavoukian, "Privacy by Design: The 7 Foundational Principles" (documento original, agosto 2009, revisado enero 2011): sfu.ca y student.cs.uwaterloo.ca
• Global Privacy and Security by Design Centre, resumen de los siete principios: gpsbydesigncentre.com
• Wikipedia, "Compartmentalization (information security)", con nota histórica sobre el fuego griego: en.wikipedia.org/wiki/Compartmentalization_(information_security)
• Alex Roland, "Secrecy, Technology, and War: Greek Fire and the Defense of Byzantium", Technology and Culture, vol. 33, n.º 4 (1992), pp. 655-679 — fuente académica primaria del origen histórico de la compartimentación
• IVPN, "Online Privacy Through OPSEC and Compartmentalization: Part 4" (cita explícita de los casos Ulbricht y Monsegur como fallos de compartimentación, y referencia al Manual OPSEC del DoD): ivpn.net
• Red Team Guide (Joe Vest y James Tubberville), "Red Team Checklist": redteam.guide/docs/checklists/red-team-checklist
• Cybersecurity Switzerland, guía de preparación de red team (cifras de CREST/SANS citadas indirectamente): cybersecurityswitzerland.com — 🔍 cifras pendientes de verificación manual contra el informe primario de CREST/SANS

Nota: los casos de Ross Ulbricht y Hector Monsegur reutilizados en este apartado ya fueron verificados con fuentes primarias en 1.1.1; aquí se citan con el mismo respaldo, solo con un enfoque distinto (diseño previo vs. parche posterior).