Panorama#
El capítulo 1.1 estableció que el ciclo empieza por los requerimientos y no por los datos, y que el error más frecuente del campo consiste en invertir ese orden. Este capítulo desarrolla la fase siguiente —la colección— con esa restricción encima: no se colecta lo que está disponible, se colecta lo que responde a una pregunta que alguien hizo. Todo lo demás es acumulación, y la acumulación tiene un costo que se paga tres veces: en licencia de ingesta, en tiempo de procesamiento y en falsos positivos que erosionan la confianza del centro de operaciones en su propio instrumental.
La colección es también la fase donde el mercado es más ruidoso. Existe una industria completa dedicada a vender flujos de datos sobre amenazas, y su argumento de venta habitual es el volumen: millones de indicadores, decenas de fuentes agregadas, actualización continua. Ese argumento es engañoso, y conviene enunciar desde el principio el criterio que este capítulo defiende, porque contradice al folleto: el valor de una fuente no es su volumen sino su unicidad y su latencia respecto de la decisión. Un flujo que compran las mil organizaciones del sector no otorga ventaja a ninguna de ellas —el adversario también sabe qué infraestructura suya fue publicada— y un dato que llega después de que la decisión se tomó no vale nada por correcto que sea.
De ese criterio se sigue el corolario incómodo que estructura el capítulo. La fuente que mejor puntúa en unicidad no se compra: es la telemetría y los incidentes propios, porque es la única a la que nadie más tiene acceso y la única que describe al adversario que efectivamente está atacando a esta organización y no al promedio del sector. El 1.1 presentó eso como criterio de madurez; acá se convierte en criterio de diseño de la colección.
El eje interno / externo#
La primera partición de las fuentes es por origen, y su asimetría es más pronunciada de lo que la literatura suele admitir.
Las fuentes internas son la telemetría que el bloque azul ya describió: los registros de eventos, el proxy, el cortafuegos, el DNS, el SIEM que 5.2 desarrolló, más los sensores desplegados a propósito —honeypots, señuelos, credenciales trampa como las que 5.11 usó en contenedores— y, sobre todo, el producto de los incidentes ya vividos: los indicadores, las técnicas y las lecciones que quedaron de cada investigación. Su ventaja es doble. Son estructuralmente únicas, en el sentido preciso de que ninguna otra organización las tiene. Y son pertinentes por construcción, porque describen lo que pasó en la superficie propia y no en una superficie ajena que puede no parecerse en nada.
El escenario canónico del campo ilustra bien cómo se combinan ambos ejes: el equipo cruza inteligencia externa sobre infraestructura maliciosa con sus propios registros de asignación de direcciones y de resolución de nombres, y en esa intersección aparece qué equipo interno concreto está hablando con esa infraestructura. Ni la fuente externa sola ni el registro interno solo producen esa respuesta. El valor está en el cruce, y el cruce solo es posible si la telemetría interna se conserva con suficiente retención y con suficiente calidad —que es el argumento de 5.2 visto desde la otra punta del ciclo—.
Las fuentes externas aportan lo que la organización no puede ver desde adentro: qué está haciendo el adversario antes de llegar, contra quién más lo está haciendo, con qué herramientas y por qué. Su límite es simétrico al de las internas: describen un promedio que puede no aplicar. Un flujo excelente sobre extorsión industrial es ruido puro para una organización cuyo perfil de riesgo es el espionaje o el fraude interno.
Las seis familias de fuente externa#
La taxonomía operativa más útil del campo clasifica la colección externa en seis familias según cómo se obtiene el dato, no según quién lo vende. Cada una tiene un perfil distinto de unicidad, de latencia y de esfuerzo.
flowchart TD REQ["Requerimientos (1.1)\n¿qué decisión hay que tomar?"] REQ --> INT["INTERNAS\ntelemetría (5.2) · honeypots\nincidentes propios · cacerías"] REQ --> EXT["EXTERNAS"] EXT --> H["honeynets / darknets\ntráfico hostil no dirigido"] EXT --> S["sinkholes\nvíctimas reales de una familia"] EXT --> V["informes de proveedor\ncontexto rico · latencia alta"] EXT --> E["escaneo y crawling\nsuperficie expuesta propia y ajena"] EXT --> M["procesamiento de malware\nmuestras a escala · YARA"] EXT --> C["closed source / HUMINT\nforos · comunidades · ISAC"] INT --> EV["Evaluación\nunicidad · latencia · fiabilidad\n(Admiralty)"] H --> EV S --> EV V --> EV E --> EV M --> EV C --> EV EV --> PRI["Priorización concéntrica\nhacia los activos estratégicos"] PRI --> ANA["Procesamiento y análisis (1.3)"]
Honeynets y darknets. Una honeynet es una red de señuelos instrumentada, sin propósito productivo, cuya única función es que la ataquen. Una darknet es un espacio de direccionamiento sin activos legítimos, de modo que cualquier paquete entrante es sospechoso por definición. Su virtud es la limpieza de la señal: como no hay actividad legítima, no hay falsos positivos que separar. Su límite es que capturan sobre todo lo indiscriminado —escaneo masivo, botnets, explotación oportunista de vulnerabilidades viejas— y muy poco de lo dirigido, porque el adversario que elige objetivo no llega ahí por azar. Sirven para medir el ruido de fondo y para detectar campañas nuevas de volumen, no para perfilar al actor que persigue a la organización.
Sinkholes. Un sinkhole es un servidor controlado al que se redirige el tráfico destinado a dominios maliciosos, habitualmente tras una acción coordinada o una incautación. Lo que se observa allí no son atacantes sino víctimas reales: los equipos que siguen intentando hablar con una infraestructura ya neutralizada. Es la fuente de mayor valor para responder «¿quién está infectado?» y, si la propia organización aparece en esos datos, la señal es de una fidelidad difícil de igualar. Su límite es que solo cubre familias ya conocidas y ya intervenidas.
Informes de proveedor. El producto terminado de la industria: el análisis de una campaña, un actor o una familia. Aporta el contexto más rico y es la materia prima natural de la inteligencia operativa. Sus dos límites son estructurales y conviene tenerlos presentes. El primero es la latencia: cuando el informe se publica, la campaña lleva meses corriendo y la infraestructura descrita suele estar quemada. El segundo es la no unicidad: es público o semipúblico, de modo que el adversario lo lee también y sabe exactamente qué de su operación quedó expuesto. Su valor durable no está en los indicadores que trae —esos caducan— sino en las técnicas, que son lo que 5.1 identificó como el nivel donde el adversario paga caro por cambiar.
Escaneo y crawling. La indexación activa de servicios expuestos en internet, con la que se construye tanto el conocimiento de la superficie ajena como —y esto importa más— la propia. Es literalmente la misma actividad que 2.5 describió del lado ofensivo y que 2.4 usó para mapear infraestructura: la organización que se escanea a sí misma con las herramientas del adversario ve lo que el adversario ve. Su límite es que informa sobre exposición, no sobre intención.
Procesamiento de malware a escala. El análisis automatizado de grandes volúmenes de muestras, del que se extraen metadatos, cadenas, configuraciones e infraestructura de mando y control. Es la fuente que mejor se combina con la alerta programática: una regla YARA desplegada sobre el flujo entrante convierte un caudal pasivo en una alerta accionable en el momento en que aparece una variante de una familia que interesa. El 5.8 desarrolló la mecánica del análisis; acá lo que importa es su uso como sensor de colección, no como investigación puntual.
Fuentes cerradas y relaciones humanas. Foros criminales, canales de mensajería, comunidades de acceso restringido, contactos personales, y en su versión institucional los centros sectoriales de intercambio (ISAC) y las comunidades de confianza. Es la familia de mayor unicidad y la única que informa sobre intención antes de que haya un artefacto que analizar. También es la más cara en esfuerzo, la más lenta de construir —el acceso depende de reputación acumulada, no de una suscripción— y la que plantea los problemas legales y de seguridad operativa más serios. El capítulo 2.6 recorrió una porción de este terreno desde el lado del dato filtrado: los registros de robo de credenciales que circulan en esos canales son, a la vez, una fuente de inteligencia sobre el ecosistema y una advertencia directa sobre la exposición propia.
Construir o comprar#
El dilema arquitectónico habitual —adquirir flujos comerciales o desarrollar capacidad propia de colección— no tiene respuesta general, pero sí tiene un criterio de decisión que se enuncia con precisión.
La fuente comercial compra tiempo: entrega desde el primer día un volumen de datos que construir internamente llevaría trimestres. Su costo oculto es la duplicación. Los proveedores agregan fuentes públicas y se agregan entre sí, de modo que es enteramente posible pagar tres suscripciones que entregan mayoritariamente el mismo material reempaquetado. De ahí la práctica que conviene institucionalizar: auditar la unicidad de cada flujo, midiendo qué proporción de sus indicadores no aparece en ninguno de los otros y qué proporción de los que sí importaron llegó primero por ese flujo. Es una medición barata que suele producir cancelaciones.
La fuente propietaria —un colector propio, una honeynet propia, una capacidad de procesamiento de muestras propia— entrega alineación exacta con los requerimientos y unicidad real, a cambio de ingeniería permanente. No es una decisión que se toma una vez: se degrada silenciosamente si nadie la mantiene, y una honeynet abandonada es peor que ninguna porque produce datos que ya no describen nada.
La composición razonable en la mayoría de las organizaciones es asimétrica y sigue el criterio de unicidad: comprar lo commodity —listas de infraestructura conocida, reputación, enriquecimiento— y construir lo que da ventaja, que es la explotación sistemática de la telemetría y los incidentes propios. Invertir esa asignación es el patrón de gasto más común y el menos rentable.
Evaluar la fuente: fiabilidad, credibilidad y latencia#
Ningún dato entra al análisis sin una etiqueta de confianza. La disciplina de inteligencia clásica aporta acá un instrumento simple y sorprendentemente poco usado en seguridad: el código del Almirantazgo, que califica cada elemento con dos dimensiones independientes —la fiabilidad de la fuente, de A (completamente fiable) a F (no evaluable), y la credibilidad de la información, de 1 (confirmada por otras fuentes) a 6 (no evaluable)—.
Lo valioso no es la escala sino la separación que impone. Una fuente históricamente fiable puede transmitir un dato sin confirmar; una fuente dudosa puede aportar un dato que otras tres confirman. Colapsar ambas dimensiones en un único «grado de confianza» —que es lo que hace la mayoría de las plataformas comerciales con su puntaje numérico único— destruye precisamente la distinción que permite razonar. Y hay un modo de fallo específico que esta separación previene: la confirmación circular, cuando tres fuentes aparentemente independientes repiten el mismo origen y el analista lee coincidencia donde solo hay propagación.
Ese modo de fallo no es teórico. El falso positivo heredado del capítulo 5.8 —decenas de máquinas señaladas hacia un supuesto canal de mando y control que en realidad era telemetría publicitaria, porque el proveedor había heredado una mala clasificación de un servicio público de reputación— es exactamente esto: un error en el origen que se propaga por la cadena de confianza sin que ningún analista intermedio lo evalúe. La regla que 1.1 enunció como consecuencia se aplica en esta fase y no en otra: la reputación de terceros es señal, no veredicto, y el lugar donde esa distinción tiene que materializarse es la etiqueta con la que el dato entra.
A las dos dimensiones clásicas conviene sumar dos criterios propios de este dominio. La unicidad, ya discutida. Y la latencia respecto de la decisión, que es la pregunta operativa decisiva: ¿este dato llega a tiempo de cambiar algo? Un indicador de mando y control que llega tres semanas después de que la campaña terminó es históricamente interesante y operativamente inútil, salvo para una función específica —la búsqueda retrospectiva sobre telemetría archivada, el retro-hunt que 5.7 usó para reconstruir alcance— que es justamente la manera de extraerle valor a la inteligencia que llegó tarde.
Priorización: el juego concéntrico#
Aun colectando bien, el volumen excede la capacidad de análisis. La priorización no es un lujo de programas maduros: es la condición para que el análisis exista.
La analogía que mejor la comunica es la del skee-ball, el juego de rampa con anillos concéntricos. Los anillos exteriores son grandes, fáciles de acertar y valen poco: son el ruido macro del cibercrimen indiscriminado, las campañas de volumen, el escaneo masivo, las tendencias de la industria. Acertarlos es trivial y aporta poco, porque esa actividad se detiene con controles genéricos que ya deberían estar puestos. El centro es pequeño, difícil y vale cien puntos: las amenazas dirigidas a los activos estratégicos. Y la definición de «activo estratégico» que la fuente propone es más amplia de lo que un inventario técnico suele reconocer: no solo los sistemas críticos, sino los proveedores, los clientes y los empleados de la organización, porque son las vías por las que se llega a ella.
La consecuencia operativa es que la priorización se hace en la colección y no solo en el análisis: la colección se afina hacia el centro. Si los requerimientos de 1.1 identificaron qué decisiones importan y sobre qué activos, la selección de fuentes se sigue de ahí. Un programa que dedica su capacidad analítica al anillo exterior porque ahí es donde hay más datos está optimizando el volumen de trabajo en lugar del valor defensivo.
Esa priorización, además, es la que conecta con la cacería. La cacería estructurada de 5.1 combinaba tácticas del adversario con los activos más valiosos —las crown jewels— para formular hipótesis. La colección concéntrica es la misma idea aplicada una fase antes: se colecta sobre lo que amenaza al centro, y de esa colección salen las hipótesis que se cazan.
La señal de explotación#
Hay una aplicación de la colección en canales adversariales que merece sección propia porque corrige un error de priorización muy extendido y muy caro: la existencia de una vulnerabilidad no equivale a su explotación. Que un fallo esté publicado, y aun que su severidad sea alta, no dice nada sobre si algún actor tiene la capacidad, la herramienta y la intención de usarlo contra esta organización.
La exploit signal es la evidencia observable, en canales adversariales, de que esa capacidad existe y está circulando: discusiones técnicas sobre el fallo, tutoriales de explotación, código de prueba de concepto compartido, escaneo dirigido buscando instancias expuestas. El caso documentado que mejor lo muestra transcurre en foros de habla china en marzo de 2015: tras el anuncio de un fallo en un motor de búsqueda ampliamente desplegado, los analistas observaron primero la aparición de tutoriales para localizar instancias expuestas y después la distribución de scripts de conexión inversa. En paralelo, un script ofensivo contra un protocolo de autenticación de equipamiento de red, publicado tiempo antes en un repositorio público, fue adoptado operativamente por varias comunidades. En ambos casos la señal precede al incidente y, decisivamente, precede al momento en que el defensor habría reaccionado si hubiera priorizado por severidad publicada.
Esto tiene una consecuencia directa sobre la gestión de parches, que es donde más se nota el retorno de la CTI: priorizar por la puntuación de severidad trata a todas las vulnerabilidades como igualmente probables, cuando la probabilidad de explotación real está distribuida de manera extremadamente desigual. El ecosistema moderno institucionalizó parcialmente esta corrección —los catálogos de vulnerabilidades explotadas activamente y los modelos que estiman probabilidad de explotación son, en el fondo, señal de explotación empaquetada como servicio— pero el principio es anterior a esas herramientas y las excede: lo que decide la prioridad no es la gravedad del fallo sino la evidencia de que alguien lo está usando.
Hay un segundo hallazgo de la misma familia que conviene retener, porque es un ejemplo temprano de razonamiento por técnica y no por artefacto. La observación de que ciertos actores reutilizan de manera consistente una misma herramienta de empaquetado convierte a ese empaquetador en un punto de estrangulamiento: un elemento que aparece en muchas operaciones distintas y cuyo reemplazo le cuesta trabajo al adversario. Detectarlo rinde más que perseguir las muestras individuales que produce. Es el argumento de la pirámide del dolor de 5.1 aplicado a la colección: buscar en la fuente aquello que el adversario no cambia gratis.
Alertar sobre la colección#
Una fuente sin mecanismo de alerta es una fuente que nadie lee. El caudal de muestras, de publicaciones en foros y de indicadores excede cualquier revisión manual, de modo que la colección madura incluye siempre su capa de disparo automático.
El patrón canónico sobre el flujo de muestras es la regla YARA desplegada como sensor permanente: en lugar de analizar lo que llega, se declara qué estructura interesa y se recibe aviso cuando aparece. El caso de referencia —una regla que intercepta variantes modificadas de un webshell muy reutilizado— muestra el efecto exacto: un flujo pasivo masivo se convierte en un puñado de alertas accionables. La misma lógica se aplica a los canales de discusión —alertar sobre la mención de tecnologías que la organización efectivamente usa, de sus dominios, de sus marcas— y es donde la colección deja de ser una biblioteca y pasa a ser un sensor.
# Un patrón mínimo de sensor sobre el flujo de muestras: la regla declara la
# estructura que interesa, no el hash de una variante concreta.
rule webshell_generico_reutilizado
{
meta:
descripcion = "Familia de webshell con alta reutilizacion entre actores"
referencia = "requerimiento CTI-014: exposicion de servidores web publicos"
strings:
$eval = "eval" nocase
$req = "Request.Item" nocase
$page = "<%@ Page Language=" nocase
condition:
filesize < 20KB and all of them
}
Ese matiz —declarar la estructura y no el artefacto— es el mismo que 5.8 defendió para la detección: la regla que apunta a un hash muere con la primera recompilación; la que apunta a la forma sobrevive a la familia. Y como allí, la regla no está terminada cuando se escribe sino cuando se verificó que dispara sobre lo que debe y no sobre lo que no.
Lo que la colección determina sin que nadie lo note#
Cierro con la advertencia que más se paga después. La colección fija los límites de lo que el análisis puede concluir. Un analista solo puede razonar sobre lo que tiene delante, de modo que un sesgo en la selección de fuentes se transforma, sin que nadie lo perciba, en un sesgo en las conclusiones. Si todas las fuentes son occidentales y de habla inglesa, el panorama resultante describirá bien a los actores que esas fuentes cubren y callará sobre el resto —y ese silencio se leerá como ausencia de amenaza, no como ausencia de datos—. Si la colección es mayoritariamente comercial, el panorama se parecerá al catálogo del proveedor. Si es mayoritariamente sobre extorsión, se verá extorsión en todas partes.
La contramedida no es colectar más sino hacer explícita la cobertura: qué requerimientos están cubiertos por qué fuentes, y —lo que casi nunca se documenta— cuáles no lo están por ninguna. Esa segunda lista es el producto más valioso de una revisión de colección, porque es la única forma de que una brecha de conocimiento se comporte como una brecha reconocida en lugar de como una falsa tranquilidad. Es la versión de inteligencia del principio que atravesó toda la Parte 5: no se detecta lo que no se registra. Acá: no se analiza lo que no se colectó, y no se sabe que falta lo que nunca se declaró que hacía falta.
El material así reunido todavía no es inteligencia. Es materia prima etiquetada, priorizada y con su cobertura documentada. Convertirla en juicio —con qué modelos se interpreta, cómo se contiene el sesgo del analista, con qué lenguaje se expresa la incertidumbre— es el trabajo del capítulo 1.3; los formatos en que ese juicio se entrega a máquinas y a personas, el del 1.4; y su conversión efectiva en detección y cacería dentro del centro de operaciones, el del 1.5.
Referencias#
blue-dfir/cti-thomas/cap-05— Threat Intelligence Collection and Analysis: la clasificación de fuentes en internas (telemetría perimetral, honeypots) y externas (OSINT, foros de la dark web, flujos comerciales, ISAC), la calificación de credibilidad mediante el código del Almirantazgo y la exigencia de validar la fuente antes de razonar sobre el dato. Las secciones de análisis estructurado (ACH, modelo del diamante) y de plataformas de agregación de este mismo capítulo se desarrollan en 1.3 y 1.4.blue-dfir/understand-attackers-rf/cap-01— Levi Gundert, Understand Your Attacker (Recorded Future): la taxonomía de las seis familias de fuente, el dilema entre fuentes propietarias y comerciales con la auditoría de originalidad, la priorización concéntrica del skee-ball con los activos estratégicos en el centro —incluidos proveedores, clientes y empleados—, la exploit signal con los casos de 2015 en foros de habla china, el empaquetador como punto de estrangulamiento y el despliegue de YARA como sensor sobre el flujo de muestras.- MISP — la plataforma abierta de agregación e intercambio con la que se operacionaliza buena parte de lo anterior; su papel en la diseminación y los formatos se trata en 1.4.
- Admiralty Code / NATO STANAG 2511 — el esquema de doble dimensión (fiabilidad de la fuente, credibilidad de la información) que la disciplina de inteligencia clásica aporta a la evaluación de fuentes.
- CISA Known Exploited Vulnerabilities Catalog y EPSS — la institucionalización contemporánea de la señal de explotación como criterio de priorización de parcheo; enriquecimiento nativo, posterior a la fuente.