Panorama#
La Parte 5 abrió el bloque azul afirmando que la defensa es un programa de funciones que interoperan y colocó a la inteligencia en el centro de ese esquema: en el modelo de seis funciones del capítulo 5.1, Intelligence es la que alimenta a todas las demás —le dice a la detección qué buscar, a la cacería qué hipótesis formular, a la respuesta contra qué adversario está peleando y a la validación qué simular—. Esa Parte dio por supuesta la existencia de esa función y se concentró en las que consumen su producto. Esta Parte la desarrolla.
La cyber threat intelligence (CTI, inteligencia de amenazas) es la disciplina que convierte información dispersa sobre adversarios en conocimiento sobre el cual se puede decidir. La definición canónica del campo —información depurada, basada en evidencia, que identifica amenazas inminentes para una organización y ayuda a reducir su exposición— es correcta pero engañosamente inocua, porque no dice lo que separa un programa real de una suscripción cara. Ese criterio es más incómodo y conviene enunciarlo desde el principio: la inteligencia no se define por el dato que contiene sino por la decisión que habilita. Un listado de dominios maliciosos que nadie carga en ningún control no es inteligencia; es un archivo. Un informe de doscientas páginas sobre un actor que no ataca al sector de la organización tampoco lo es; es lectura. Lo que convierte a un dato en inteligencia es que alguien identificado haya pedido responder a una pregunta concreta y que la respuesta cambie algo: una regla, una prioridad de parcheo, una decisión de arquitectura, una inversión.
De ahí se sigue el problema práctico que este capítulo ordena. La mayoría de los programas fracasan no por falta de datos sino por exceso: se compran flujos, se ingieren indicadores, se acumulan informes, y el equipo termina con más volumen del que puede procesar y sin nada que mostrar salvo la factura. La causa raíz casi siempre es la misma —se empezó por la colección en lugar de por los requerimientos— y el remedio también: un ciclo explícito que obliga a declarar qué se quiere saber antes de salir a recolectar, y una estratificación explícita de los productos según quién los va a usar. Este capítulo desarrolla esas dos estructuras y el criterio de madurez que emerge de ambas. Es el marco de P1 en el mismo sentido en que 5.1 lo es de la defensa, el 3.1 de la explotación y el 2.1 del reconocimiento: no enseña una técnica, enseña cómo se organiza el trabajo para que las técnicas de los capítulos siguientes produzcan algo utilizable.
Por qué la defensa reactiva obliga a la inteligencia#
El argumento fundacional del campo es una observación sobre el desfase temporal. Los controles clásicos —firmas de antivirus, reglas de IDS, listas de bloqueo— operan sobre descripciones de ataques que ya ocurrieron en otro lugar y fueron documentados. Funcionan bien contra el volumen indiscriminado, que es la mayoría del tráfico hostil, y por eso conviene no despreciarlos. Fallan de manera sistemática contra el adversario que elige un objetivo, estudia su superficie y adapta su herramienta a ese objetivo particular, porque en ese caso la descripción que la firma necesita no existe todavía: el artefacto es nuevo, la infraestructura es nueva, y el control llega tarde por construcción.
El capítulo 5.8 midió esa brecha empíricamente y encontró muestras que sobrevivían de forma permanente al escaneo bajo demanda. La conclusión que allí se sacó —la evasión gana contra la firma y no contra el comportamiento, porque el adversario controla cómo se ve su artefacto pero no lo que su operación tiene que hacer— es exactamente la puerta de entrada de la CTI. Si lo que resiste es el comportamiento, entonces el defensor necesita saber qué comportamientos esperar, y ese conocimiento no está en su propia telemetría: está en lo que ese adversario le hizo a otros antes de llegar a él. La inteligencia es el mecanismo por el cual una organización aprende de intrusiones que no sufrió.
Esto reencuadra la relación entre las dos Partes. P5 respondió a la pregunta «cómo se detecta»; P1 responde a la pregunta previa, «qué hay que detectar y por qué eso antes que otra cosa». Sin la segunda, la primera degenera en recolección indiscriminada —el error que 5.1 nombró al exigir que las tácticas del adversario decidan la ingesta y no al revés—. La inteligencia es lo que hace que esa priorización sea algo más que una corazonada del arquitecto del SIEM.
Los tres niveles: tres productos, no tres calidades#
La estratificación clásica de la CTI distingue inteligencia táctica, operativa y estratégica. El error más común al leerla es interpretarla como una escala de calidad o de profundidad, donde lo estratégico sería «más» y lo táctico «menos». No lo es. Son tres productos distintos, con tres formatos distintos, tres tiempos de vida distintos y tres consumidores distintos, y un programa que produce solo uno de los tres está incompleto aunque lo produzca excelentemente.
Táctica: lo que consume una máquina#
La inteligencia táctica es la más concreta y la de vida más corta. Su unidad es el indicador técnico —una dirección IP de mando y control, un dominio, un hash, un patrón de tráfico— y su destino natural no es un lector humano sino un control automatizado: el cortafuegos que bloquea, el proxy que corta la salida, la regla que dispara en el SIEM. Su consumidor es el analista de primera línea del centro de operaciones de seguridad (SOC), y su valor se mide en minutos: cuánto antes se bloquea, cuánto más rápido se enriquece una alerta con contexto para triarla.
Su límite es igualmente conocido: caduca. Un dominio se abandona, una dirección rota, un binario se recompila. El 5.1 desarrolló la pirámide del dolor de David Bianco precisamente para ordenar esa jerarquía de fragilidad, y este capítulo no la rehace. Lo que corresponde señalar acá es la consecuencia organizativa: la inteligencia táctica requiere un mecanismo de caducidad tanto como uno de ingesta. Un programa que ingiere indicadores y nunca los retira acumula reglas que ya no detectan nada pero siguen generando falsos positivos y consumiendo licencia de ingesta. El indicador sin fecha de vencimiento es deuda operativa, y la mitad del trabajo táctico consiste en administrarla.
Operativa: lo que consume un investigador#
La inteligencia operativa es técnica pero no atómica. Describe cómo trabaja un adversario concreto: qué vector de acceso inicial prefiere, qué herramientas reutiliza, cómo se mueve lateralmente, cómo persiste, cómo saca los datos. Su unidad no es el indicador sino la técnica, y su consumidor es el equipo de respuesta a incidentes y el de cacería.
Su valor aparece en dos momentos muy específicos. Durante un incidente activo, permite pasar de «encontramos esto» a «esto se parece a tal conjunto de actividad, que suele continuar así» —y esa proyección es lo que permite acotar el alcance antes de contener, que es la exigencia central de la regla del tempo del capítulo 5.4: contener con el alcance incompleto produce el ciclo interminable en el que el adversario reaparece por la vía que nadie miró—. Fuera del incidente, es la materia prima de la hipótesis de cacería: la cacería estructurada de 5.1 formula «si tal actor opera así y estuviera dentro, dejaría tal rastro en tal fuente», y esa premisa sale de inteligencia operativa.
Su vida es intermedia: una técnica sobrevive a muchos indicadores, pero un actor cambia de herramienta y de proveedor de infraestructura. Es el nivel donde el trabajo analítico pesa más y donde menos sirve comprar producto terminado, porque el valor depende de la correlación con el entorno propio.
Estratégica: lo que consume quien decide el presupuesto#
La inteligencia estratégica prescinde del detalle técnico y responde preguntas de otra naturaleza: qué actores tienen motivo para atacar a esta organización, qué tendencias del ecosistema cambian su exposición, qué riesgo de negocio se sigue de todo eso. Su consumidor es la dirección de seguridad y, a través de ella, la dirección general. Su formato es la prosa, no la lista. Su vida se mide en trimestres.
Es el nivel que los equipos técnicos más subestiman y el que más determina si el programa sobrevive, por una razón prosaica: es el único que traduce la actividad de seguridad al idioma en que se asignan recursos. Un informe que explique por qué el sector de la organización pasó a ser objetivo prioritario de un modelo de extorsión determinado justifica una plataforma o una contratación de un modo que ningún volumen de indicadores bloqueados consigue. El capítulo 1.6 es un producto estratégico completo y cierra esta Parte por esa razón.
El ciclo: por qué se empieza por el final#
El ciclo de inteligencia ordena el trabajo en seis fases encadenadas y realimentadas. Su rasgo importante no es la cantidad de fases sino cuál va primera.
flowchart LR REQ["1 · Requerimientos\n¿qué decisión hay que tomar?\n¿quién la toma?"] COL["2 · Colección\nfuentes internas + externas\n(1.2)"] PRO["3 · Procesamiento\nnormalizar · deduplicar\nenriquecer · traducir"] ANA["4 · Análisis\nmodelos + hipótesis\nniveles de confianza (1.3)"] DIS["5 · Diseminación\nformato por audiencia\nSTIX/TAXII · informe (1.4)"] ACC["6 · Acción\nregla · bloqueo · parcheo\ncacería · inversión (1.5)"] REQ --> COL --> PRO --> ANA --> DIS --> ACC ACC -->|"lo aprendido redefine\nlo que hace falta saber"| REQ ACC -.->|"la telemetría propia\nvuelve como fuente"| COL ANA -.->|"brecha de colección:\nfaltan datos para decidir"| COL
Uno, requerimientos. La fase que se saltea y la que determina todo lo demás. Consiste en establecer qué necesitan saber las personas y los sistemas que van a usar el producto —los priority intelligence requirements—, en función de qué decisiones penden de esa respuesta. No es burocracia: es el único filtro que impide que la colección se convierta en acumulación. Formulado como pregunta útil: ¿qué haría distinto si supiera esto? Si no hay respuesta, no hay requerimiento, y recolectar el dato es gasto.
Dos, colección. Obtener los datos que responden a esos requerimientos, de fuentes internas —la telemetría que 5.2 describió, los honeypots, los incidentes propios— y externas —OSINT, flujos comerciales, comunidades de intercambio, foros criminales—. El capítulo 1.2 desarrolla la taxonomía de fuentes y el criterio para evaluarlas, que no es el volumen sino la unicidad.
Tres, procesamiento. La fase invisible en toda presentación comercial y la que consume la mayor parte del tiempo real: normalizar formatos heterogéneos, deduplicar, traducir idiomas, descartar lo malformado, enriquecer cada observable con su contexto. Es la contraparte exacta de lo que 5.10 señaló sobre la telemetría de Linux —que la mitad del trabajo es la normalización— y por la misma razón: nadie lo publicita porque no se puede vender como capacidad, pero de su calidad depende que el análisis sea posible.
Cuatro, análisis. Convertir datos procesados en juicio: qué significa esto, con qué confianza, qué se sigue. Es donde el sesgo cognitivo hace su daño y donde los métodos estructurados existen para contenerlo. El capítulo 1.3 cubre los modelos —la kill chain, el modelo del diamante, ATT&CK— y la disciplina de hipótesis en competencia.
Cinco, diseminación. Entregar el producto a cada consumidor en el formato que ese consumidor puede usar, que es donde se materializa la estratificación en tres niveles de la sección anterior.
Seis, acción y realimentación. El producto se consume: se carga un indicador, se escribe una regla, se lanza una cacería, se prioriza un parche, se aprueba una inversión. Y lo aprendido en esa acción vuelve al inicio por dos vías distintas que el diagrama distingue: redefine los requerimientos —ahora se sabe algo nuevo, y lo que falta saber cambió— y se convierte en fuente, porque el incidente propio es materia prima de inteligencia.
Esa segunda vía merece énfasis porque es el punto donde el ciclo deja de ser un esquema de manual. Una organización que solo consume flujos externos aprende de las intrusiones de otros. Una que procesa las propias aprende de intrusiones dirigidas específicamente contra ella, que son las que mejor predicen las siguientes.
Madurez: de comprar inteligencia a producirla#
De lo anterior se sigue el criterio de madurez que la literatura del campo enuncia de manera más bien tímida y que conviene afilar. Los programas siguen una trayectoria bastante estable:
En el primer estadio la organización compra. Contrata uno o varios flujos comerciales, los conecta a los controles perimetrales y bloquea lo que la lista indica. Hay valor real en esto —bloquear infraestructura conocida es barato y evita ruido— pero no hay programa: hay una suscripción. La organización no sabe si lo que compró es pertinente para su superficie, y ninguna de las seis fases del ciclo se ejecuta salvo una versión degradada de la colección.
En el segundo estadio aparece el enriquecimiento. La inteligencia deja de ir solo al bloqueo y empieza a ir al triaje: cuando una alerta dispara, el analista cruza sus observables con lo que se sabe de ellos y decide con contexto en lugar de a ciegas. Aquí ya hay análisis, aunque sea reactivo, y el programa empieza a reducir la fatiga de alertas en lugar de aumentarla.
En el tercer estadio la organización produce. Sus propios incidentes, su propia telemetría y sus propias cacerías generan inteligencia local: perfiles de la actividad que efectivamente la ataca, indicadores que nadie más tiene, hipótesis derivadas de lo que ya le pasó. Ese es el rasgo definitorio de madurez, y no por prestigio: la inteligencia local es la única que no está disponible para el adversario, que también lee los informes públicos y sabe qué infraestructura suya fue quemada. La organización que produce inteligencia propia opera con información que su adversario no puede consultar.
En el cuarto estadio la organización comparte, y al hacerlo entra en una economía distinta: recibe de las comunidades de intercambio en proporción a lo que aporta. Esa dinámica, con sus problemas de confianza y de velocidad frente a verificación, corresponde a 1.4.
Los dos errores que este marco previene#
Conviene cerrar nombrando los dos fallos que las estructuras anteriores existen para evitar, porque son los que efectivamente se observan en programas reales.
El primero es la colección sin requerimiento. Se manifiesta como un equipo que suscribe flujos porque estaban disponibles, ingiere todo lo que llega y produce un tablero. El síntoma es que nadie puede decir qué pregunta responde ese tablero. La consecuencia es doble: costo de ingesta y de licencia por un lado, y por otro una capa adicional de falsos positivos que degrada la confianza del SOC en su propio instrumental. El caso del falso positivo heredado de 5.8 —decenas de máquinas señaladas hacia un supuesto canal de mando y control que era telemetría publicitaria, porque el proveedor había heredado una clasificación errónea de un servicio público de reputación— es este error en su forma más costosa: la reputación de terceros es señal, no veredicto, y un programa que la trata como veredicto importa los errores de toda la cadena sin que ningún analista evalúe nada.
El segundo es el producto sin consumidor. Se manifiesta como informes cuidadosamente escritos que nadie lee, o como un analista de inteligencia sentado junto al SOC sin ningún mecanismo formal por el cual su trabajo entre en una regla. El síntoma es que el programa no puede mostrar una sola decisión que haya cambiado. La consecuencia habitual es su desfinanciamiento en el siguiente recorte, casi siempre con razón.
Ambos errores tienen la misma raíz —empezar por el dato en lugar de por la decisión— y por eso el ciclo pone los requerimientos primero y la estratificación pone al consumidor antes que al formato. Todo lo que sigue en P1 es la mecánica de cada fase: de dónde se saca el material (1.2), con qué modelos se lo interpreta y cómo se contiene el sesgo (1.3), en qué formatos se lo entrega a máquinas y a personas (1.4), cómo se lo convierte en detección y en cacería dentro del SOC (1.5) y qué dice hoy el producto estratégico sobre el adversario real (1.6).
La formulación que conviene retener es simétrica de la que cerró 5.1. Allí se dijo que no se detecta lo que no se registra ni se caza lo que no se hipotetiza. Acá corresponde su premisa: no se hipotetiza lo que no se sabe del adversario, y no se sabe del adversario lo que nadie pidió averiguar.
Referencias#
blue-dfir/cti-thomas/cap-01— Cyber Threat Intelligence Basics: la definición de CTI como información depurada y basada en evidencia, la insuficiencia de los controles reactivos frente al adversario dirigido, los tres niveles de consumo y el ciclo de seis fases; el escenario de cruzar inteligencia externa con registros internos de DHCP y resolución DNS para identificar equipos comprometidos.blue-dfir/cti-thomas/cap-03— CTI – Adoption and Users: el mapeo de cada nivel a su consumidor real (SOC, respuesta a incidentes, dirección), los casos de uso fundacionales —bloqueo perimetral y enriquecimiento del triaje— y la tesis de madurez: reutilizar los datos de amenaza generados por los procesos internos es el rasgo que distingue a una organización madura.- David J. Bianco, The Pyramid of Pain (2013) — desarrollada en 5.1; acá se usa solo su consecuencia sobre la caducidad del producto táctico.
- MITRE ATT&CK — el vocabulario de tácticas y técnicas en el que se expresa la inteligencia operativa; se desarrolla como modelo analítico en 1.3.
- US Intelligence Community Directive 203: Analytic Standards (2015) — el estándar de rigor analítico y de lenguaje de probabilidad que emplean los informes de referencia del sector; se aplica en 1.3.