1.5 · CTI operativa: del feed a la detección en el SOC

Panorama#

El ciclo que 1.1 estableció tiene seis fases y termina en la diseminación. Ese es su defecto de diseño como modelo: sugiere que entregar es llegar. No lo es. Entre el producto correctamente entregado y el cambio efectivo en la postura defensiva hay un tramo que ningún diagrama del ciclo dibuja, y que se recorre —o no— dentro del centro de operaciones.

Ese tramo es el objeto de este capítulo, y conviene delimitarlo con precisión porque el manual ya cubrió lo que está a ambos lados. Cómo se construye una detección, cómo se itera y cómo se mide su fidelidad está en 5.1 y 5.2; cómo se acota y se contiene un incidente está en 5.4. Nada de eso se rehace acá. Lo que se trata es la interfaz: quién consume qué producto, en qué momento del turno, con qué mecanismo, y por dónde vuelve lo aprendido. Es un capítulo sobre articulación organizativa, no sobre técnica de detección.

La tesis es la que ordena todo el resto: la inteligencia que no cambia una regla, una prioridad de parcheo o una decisión de arquitectura no se consumió, por bien producida y bien entregada que estuviera. Y su corolario incómodo, que reaparecerá en la sección de métricas: la medida de un programa no es cuántos indicadores ingiere sino cuántas detecciones y cuántos hallazgos de cacería produce. Es la oposición entre métrica de efecto y métrica de actividad que 1.1 planteó en abstracto, aterrizada en el único lugar donde puede verificarse.

Los tres puntos de inyección#

El error más común al conectar un programa de inteligencia con un SOC es tratarlo como una fuente más que desemboca en un solo lugar —normalmente el SIEM— y esperar que el resto ocurra. No ocurre. Los tres niveles de 1.1 no son tres calidades del mismo producto: son tres productos que entran al centro de operaciones por puertas distintas, en momentos distintos y con destinatarios distintos.

Táctico: enriquecer el triaje, no generar alertas#

El nivel táctico entra en el momento del triaje, y su función es priorización de primer corte a velocidad de máquina: cuando una alerta ya existente coincide con inteligencia conocida, su criticidad sube y llega al analista con el contexto adjunto —de qué campaña se trata, qué se observó antes, qué se espera después—. El efecto sobre la operación es doble: reduce el tiempo que el analista gasta averiguando qué está mirando y reordena la cola por algo mejor que el orden de llegada.

Acá hay una distinción que decide el éxito o el fracaso de toda la integración, y que casi nunca se enuncia: enriquecer no es alertar. La inteligencia táctica debe modificar la prioridad y el contexto de eventos que el SOC ya estaba generando; no debe convertirse en una fuente autónoma de alertas. Un feed conectado como generador produce, el primer día, un volumen de alertas proporcional a su tamaño y no a la actividad real de la organización —cada coincidencia con una lista de decenas de miles de observables es una alerta— y el resultado previsible es que el SOC lo silencie en una semana. Conectado como enriquecedor, el mismo feed no agrega ni una alerta y mejora todas.

La excepción legítima es estrecha y vale nombrarla: indicadores de altísima confianza, de origen propio o de procedencia verificable, ligados a una campaña activa contra la organización. Esos sí justifican una alerta propia. El resto enriquece. Es la misma regla de reserva que 1.4 estableció para el bloqueo automático, aplicada un escalón más abajo.

Operativo: la cacería y el acotamiento#

El nivel operativo no entra por el SIEM sino por las personas: alimenta la formulación de hipótesis de cacería y el acotamiento durante un incidente. Su forma no es una lista sino una descripción de comportamiento —cómo opera un actor, en qué orden, con qué herramientas— y su consumo no es automático por definición: alguien tiene que leerlo y traducirlo a una consulta sobre la telemetría propia.

La cacería estructurada de 5.1 formula hipótesis a partir de tácticas de ATT&CK y de los activos críticos. La inteligencia operativa aporta la tercera entrada, y es la que hace que la hipótesis sea pertinente en lugar de genérica: no «¿hay ejecución remota por WMI en la red?» sino «¿hay ejecución remota por WMI con la secuencia que este actor usa contra este sector?». Esa diferencia es la que separa una cacería que se ejecuta una vez de una que justifica su costo.

En respuesta a incidentes, el aporte es distinto: acorta el acotamiento. Saber que un actor determinado suele establecer una segunda persistencia de otro tipo cambia dónde busca el equipo antes de contener, que es precisamente la operación que 5.4 identificó como condición para que la contención sea completa y simultánea en lugar de un juego de golpear topos.

Estratégico: parcheo, arquitectura y presupuesto#

El nivel estratégico no entra al SOC en absoluto, y confundirlo es el fallo de nivel de 1.1 en su forma más común. Entra a las decisiones que determinan qué tendrá que defender el SOC dentro de un año: qué se parchea primero, qué se segmenta, qué control se compra, dónde se pone el próximo sensor.

De los tres, es el que produce el retorno más alto y el que menos se mide, porque su efecto es diferido y contrafáctico —un incidente que no ocurrió no aparece en ninguna consola—. El caso concreto más repetible es la priorización de parcheo por señal de explotación en lugar de por severidad publicada, que 1.2 desarrolló: es una decisión estratégica cuyo efecto se mide en el SOC, en la forma de una clase entera de alertas que dejan de producirse.

flowchart TD
  PROG["Programa de inteligencia\n(producto diseminado, 1.4)"]

  PROG -->|"TÁCTICO\nformato de máquina"| TRI["Triaje del SOC\nENRIQUECE la alerta existente\n(prioridad + contexto)\n⚠ no genera alertas propias"]
  PROG -->|"OPERATIVO\ninforme técnico + ATT&CK"| CAZ["Cacería e IR\nhipótesis pertinente\nacotamiento antes de contener"]
  PROG -->|"ESTRATÉGICO\nnota breve"| DIR["Dirección y arquitectura\nparcheo por señal de explotación\nsegmentación · sensores · compras"]

  TRI --> INC["Incidente confirmado"]
  CAZ --> INC
  DIR -.->|"efecto diferido:\nalertas que dejan de existir"| TRI

  INC --> IR["Investigación (5.4)\nartefactos · infraestructura · TTP"]
  IR --> PROD["⚑ EL PASO QUE SE ROMPE\ndestilar el hallazgo:\nindicador local + regla + informe"]
  PROD --> PROG
  PROD --> EXT["Compartir (ISAC / TLP, 1.4)"]
  PROD -.->|"realimenta requerimientos (1.1)\ny retro-hunt (5.7)"| PROG

El caso canónico, y dónde falla#

El material de referencia describe un recorrido de extremo a extremo que conviene reproducir entero, porque es el modelo mental que casi todo el mundo tiene de «CTI operativa»:

Un analista extrae el hash de un adjunto malicioso de un informe externo. Lo convierte en una regla y la inyecta en el SIEM. Un usuario descarga el archivo; el EDR genera su alerta; el SIEM cruza esa alerta con la regla de inteligencia y eleva automáticamente la criticidad. El analista recibe el evento ya enriquecido, aísla el equipo de forma remota y extrae la muestra para analizarla en un entorno controlado. Del análisis surge una dirección de red de mando y control que no estaba en el informe original. El SOC exporta ese indicador nuevo hacia la plataforma de intercambio, y los pares del sector quedan protegidos antes de sufrir el mismo ataque.

Es una descripción correcta y útil de la mecánica. También es optimista en tres puntos precisos, y esos tres puntos son donde la integración real se rompe.

Primero, el indicador atómico solo funciona si el adversario no cambió nada. El recorrido empieza con un hash, que es el escalón más frágil de todos: una recompilación lo invalida. El caso funciona porque supone que la muestra que llega es idéntica a la del informe. En la práctica esa suposición falla la mayor parte de las veces contra un adversario dirigido, y lo que hay que ingerir es la descripción de comportamiento, no el resumen del archivo. La conclusión no es que el hash sea inútil —cuesta nada y a veces acierta— sino que un programa que solo hace esto tiene la ilusión de estar operando inteligencia mientras opera una lista de bloqueo.

Segundo, aislar de inmediato contradice la regla del tempo. El caso pasa de la alerta al aislamiento remoto sin escalas, y 5.4 argumentó con detalle por qué eso es peligroso: la remediación anticipada, con el alcance todavía sin acotar, alerta al adversario y garantiza que reaparezca por otra vía. Para una infección aislada de malware común, aislar rápido es correcto. Para el escenario que el propio texto invoca —un actor persistente— es exactamente el error. La velocidad es una virtud del triaje y un riesgo de la respuesta, y una integración bien diseñada distingue los dos casos en lugar de optimizar ciegamente el tiempo hasta la acción.

Tercero, y es el que importa: el último paso del caso no ocurre casi nunca. Que el indicador nuevo se destile, se documente y se exporte requiere que alguien lo haga cuando el incidente ya está contenido, el equipo agotado y la siguiente alerta esperando. Es trabajo sin urgencia, y por eso es el primero que se cae.

El bucle que se rompe#

Vale detenerse en ese tercer punto, porque es la diferencia estructural entre un consumidor de inteligencia y un programa de inteligencia.

1.2 estableció que la fuente que mejor puntúa en unicidad no se compra: es la telemetría y son los incidentes propios. Un incidente investigado produce material que ninguna suscripción puede entregar —infraestructura observada contra la organización, artefactos concretos, la secuencia real de comportamiento—, y lo produce ya validado, porque no viene de un informe ajeno sino de algo que efectivamente ocurrió. El equipo de respuesta es, sin saberlo, la mejor fuente de colección de la organización.

Ese material se pierde por razones que no son técnicas. Se pierde porque el paso no tiene dueño: está al final de un procedimiento de IR que declara el incidente cerrado cuando el servicio se restauró. Se pierde porque el formato de salida del IR es un informe en prosa y el formato de entrada del programa es estructurado, y nadie tiene asignada la traducción. Y se pierde porque destilar no produce ningún beneficio visible en el trimestre en que se hace.

Las tres tienen la misma solución, y es organizativa antes que herramental: convertir la destilación en un paso formal del cierre del incidente, con responsable nombrado y con un entregable definido —los observables con su contexto y su vigencia, la regla nueva si la hay, y la revisión de qué requerimiento de 1.1 quedó tocado—. Un incidente no está cerrado cuando el servicio volvió; está cerrado cuando lo que se aprendió está donde puede volver a usarse.

La célula de análisis y su única condición#

El material propone, como estadio maduro, una Cyber Threat Analysis Cell (CTAC): un equipo de analistas dedicado a descubrir, denegar, interrumpir, degradar y engañar al adversario persistente. Lo que la distingue de otros grupos del SOC no es el acceso a herramientas sino el conocimiento profundo de la amenaza: extrae indicadores de los artefactos, los integra con la inteligencia externa y construye lo que haga falta para contener antes de que el adversario progrese.

La descripción es correcta y conviene acompañarla de dos observaciones que el modelo idealizado omite.

La primera es de escala. La mayoría de las organizaciones no puede sostener un equipo dedicado, y presentar el CTAC como el estadio al que hay que llegar produce un efecto perverso: se concluye que sin ese equipo no hay programa, y no se hace nada. La versión mínima que funciona es una persona con tiempo protegido, no un equipo. Lo que define a la función no es la cantidad de gente sino que exista alguien cuyo trabajo sea mirar hacia adelante en lugar de atender la cola.

La segunda es la condición de existencia, y es la que decide si la función sobrevive: el tiempo protegido es la única condición no negociable. El modo de fallo característico —tan repetido que conviene anticiparlo— es que la célula se convierta en el segundo nivel de escalado del SOC. La razón es comprensible: son los analistas con más criterio de la organización, y las alertas difíciles derivan naturalmente hacia ellos. Seis meses después el equipo está enteramente ocupado en tickets, no produce inteligencia, y alguien concluye razonablemente que el programa no rendía. No es que no rindiera: es que dejó de existir sin que nadie lo decidiera. Un CTAC que participa en la respuesta a incidentes está bien —es donde aprende—; un CTAC que es la fila de escalado está muerto.

De esa distinción sale también el criterio de dotación: la célula debe estar en el circuito de los incidentes relevantes —los que involucran a un actor dirigido, los que tocan activos del centro del Skee-ball de 1.2— y fuera del circuito de los rutinarios.

Lo que tiene que existir antes#

Hay una clase de fracaso que se le atribuye al programa de inteligencia y que en realidad ocurre aguas arriba: la inteligencia llega bien y no tiene dónde aterrizar. Conviene enunciar esas condiciones previas, porque son verificables antes de gastar en una suscripción.

Medir el programa#

El material propone tres métricas: tiempo medio hasta la detección (MTTD), tiempo medio hasta la respuesta (MTTR) y reducción mensual de alertas inválidas. Son razonables y son las que la dirección entiende, de modo que conviene reportarlas. También conviene ser honesto sobre lo que miden.

MTTD y MTTR son métricas del SOC, no del programa de inteligencia. Mejoran o empeoran por muchas causas simultáneas —dotación, herramientas, cambios en el entorno, suerte— y atribuir su variación al programa exige un argumento que rara vez se puede sostener. Reportarlas como prueba del retorno de la inversión en inteligencia es una imprecisión que funciona mientras nadie la examine y que se vuelve en contra cuando alguien lo hace. La reducción de falsos positivos es más defendible, porque el mecanismo es directo y trazable: el enriquecimiento y las listas de exclusión evitan trabajo concreto.

Las métricas propias del programa son otras, y todas responden a la misma pregunta —¿cambió algo?—:

• Tasa de conversión: qué proporción de lo ingerido produjo alguna acción —una detección, una cacería, una decisión—. Suele ser humillante la primera vez que se mide, y esa es exactamente su utilidad: es la medición que 1.2 recomendaba para auditar la unicidad de los flujos, ahora aplicada a su efecto.
• Detecciones nuevas atribuibles: cuántas reglas existen hoy porque una pieza de inteligencia las originó.
• Cacerías ejecutadas y su resultado, contando explícitamente las que refutaron una hipótesis: 5.8 mostró que el hunting sirve tanto para confirmar como para descartar, y una cacería que descarta ahorra trabajo futuro.
• Retro-hunts ejecutados sobre inteligencia recibida y cuántos encontraron algo.
• Producción propia: indicadores e informes generados a partir de incidentes propios, que es la medida directa de si el bucle de la sección anterior está vivo.
• Decisiones estratégicas documentadas: qué se priorizó, se compró o se rediseñó por una razón que puede rastrearse hasta un producto de inteligencia.

Elegir socios#

La selección de proveedores y comunidades es la decisión con más consecuencias de las que aparenta, y el material aporta un criterio que suele quedar fuera de las evaluaciones: la integración nativa con el conjunto de herramientas propio. Un flujo excelente que exige construir y mantener un conector se paga dos veces, y la segunda —el mantenimiento— es la que mata la integración a los dieciocho meses, cuando quien lo escribió ya no está.

A ese criterio conviene sumar los que el resto de la Parte 1 estableció:

• Unicidad, no volumen (1.2). La pregunta de compra no es cuántos indicadores entrega sino qué proporción no aparece en lo que ya se tiene y qué proporción llegó primero por ahí.
• Pertinencia sectorial y geográfica respecto de la superficie propia.
• Riqueza de contexto y de relaciones (1.4). Un proveedor que entrega observables sueltos entrega la capa que menos vale.
• Vigencia declarada: si el flujo no expira sus indicadores, la deuda operativa la hereda el comprador.

Y uno que casi nunca se evalúa antes de firmar: la capacidad de responder a un requerimiento propio. Un proveedor que solo publica en una dirección es una fuente; uno que acepta una pregunta concreta —qué se sabe de este actor contra este sector, qué hay sobre esta infraestructura— es un socio, y esa diferencia se nota exactamente el día del incidente, que es el único día en que importa.

Las comunidades sectoriales (ISAC/ISAO) se evalúan con otro criterio, ya establecido en 1.4: su valor es la pertinencia, su moneda es la reputación, y la participación se sostiene por reciprocidad. Lo que este capítulo agrega es dónde se conecta esa reciprocidad dentro del SOC: con el bucle de destilación. Una organización que resolvió el paso de destilar sus incidentes tiene, sin costo adicional, algo que aportar a la comunidad; una que no lo resolvió solo puede consumir, y termina siendo el miembro que todos toleran y nadie prioriza.

Postura#

1. Conectar el nivel táctico como enriquecimiento y no como fuente de alertas. Es la decisión que determina si la integración sobrevive al primer mes.
2. Darle al nivel operativo un consumidor humano con tiempo asignado. Sin eso, el informe técnico no se convierte en hipótesis y el nivel entero se desperdicia.
3. Llevar el nivel estratégico fuera del SOC, a las decisiones de parcheo, arquitectura y compra, que es donde produce su retorno.
4. Formalizar la destilación como paso de cierre de incidente, con responsable y entregable. Es el punto de mayor retorno de todo el capítulo, porque activa la única fuente que el adversario no puede consultar.
5. Proteger el tiempo de la función de análisis. Un analista dedicado con tiempo protegido rinde más que tres absorbidos por la cola de tickets.
6. Verificar los tres requisitos previos antes de comprar inteligencia: telemetría, inventario y retención con capacidad de búsqueda retroactiva.
7. Medir por conversión y por producción propia, nunca por volumen ingerido.
8. Elegir socios por unicidad, contexto, integración y capacidad de responder preguntas, no por tamaño del catálogo.

Cierre#

Este capítulo es el que cierra el circuito que 1.1 abrió. El programa formula requerimientos, colecta bajo esa restricción, analiza con método, disemina en el formato del consumidor —y recién acá, en el centro de operaciones, se verifica si algo de eso cambió una decisión. Todo lo anterior es condición necesaria; nada de ello es suficiente.

Las dos formulaciones que conviene retener son simétricas y las dos apuntan al mismo lugar. Sobre el consumo: la inteligencia que no cambia una regla, una prioridad de parcheo o una decisión de arquitectura no se consumió, por bien producida que estuviera. Sobre la producción: la organización que no destila sus propios incidentes está comprando afuera una capacidad que ya tiene adentro, y comprándola peor, porque lo que compra lo tienen también todos sus pares y lo que desperdicia no lo tiene nadie más.

Con eso, el método está completo. Lo que resta de la Parte 1 es aplicarlo a su objeto: el panorama de amenazas tal como se ve en este momento, que es el producto estratégico del ciclo y el tema del capítulo 1.6 —con la advertencia, que allí se hará explícita, de que es el único capítulo del manual con fecha de vencimiento—.

Referencias#

• blue-dfir/cti-thomas/cap-06 — SOC: Cyber Threat Intelligence Program and Partners: el flujo de los tres niveles hacia el centro de operaciones, la priorización de primer corte a velocidad de máquina mediante correlación en el SIEM, los criterios de selección de socios comerciales y comunidades, y las métricas de programa (MTTD, MTTR, reducción de falsos positivos). La crítica sobre la atribución de MTTD y MTTR al programa de inteligencia es enriquecimiento propio.
• blue-dfir/cti-thomas/cap-07 — Use of Cyber Threat Intelligence in SOC CTAC: la misión de la célula de análisis —descubrir, denegar, interrumpir, degradar y engañar—, el recorrido de extremo a extremo desde el indicador de un informe externo hasta la exportación del indicador nuevo, la cacería impulsada por inteligencia y el ciclo de realimentación. El análisis de los tres puntos donde ese recorrido falla y la discusión sobre el tiempo protegido de la célula son enriquecimiento propio.
• La regla del tempo en la contención está desarrollada en 5.4; el ciclo de ingeniería de detección y la cacería basada en hipótesis, en 5.1; la búsqueda retroactiva, en 5.7. Este capítulo los referencia sin rehacerlos.