|9 min de lectura|Yvann Lièvre

Elegir y explotar un feed de IOC: más allá de la lista de direcciones que bloquea a tus propios clientes

Una lista bruta de IP, dominios y hashes es fácil de encontrar y casi sin valor. El valor está en elegir el feed correcto y en explotarlo: licencia, corroboración, caducidad, y la regla que evita bloquear tu propio CDN.

Threat IntelligenceIOCFeedMISP
Elegir y explotar un feed de IOC: más allá de la lista de direcciones que bloquea a tus propios clientes

Todo el mundo ofrece un «threat feed». Conseguir una lista bruta de IP, dominios y hashes maliciosos es trivial, y casi sin valor. El volumen no es seguridad: un feed de diez millones de indicadores caducados, sin correlacionar y plagados de falsos positivos te hará más daño que bien el día que lo conectes a un cortafuegos. Las dos preguntas reales no son «dónde encuentro un feed» sino «cuál elijo» y «cómo lo exploto sin pegarme un tiro en el pie».

Este artículo trata ambas: los criterios para evaluar un feed y la disciplina para operarlo, porque un feed de IOC mal explotado es un incidente en espera.

Por qué una lista bruta es una trampa

Tres maneras en que un feed bruto se vuelve en tu contra:

  • Los indicadores caducados. Una IP maliciosa el año pasado puede ser hoy un router doméstico reasignado, o peor, un servicio legítimo. Sin caducidad, bloqueas tráfico limpio.
  • Los falsos positivos que cortan. Una IP compartida de CDN o de nube acaba a menudo en los feeds. Bloquearla en el cortafuegos corta el acceso a una parte de tus propios usuarios.
  • Las trampas de licencia. Muchos feeds «gratuitos» son en realidad no comerciales, o prohíben la redistribución. Integrarlos en un producto o servicio revendido es un riesgo jurídico, no una ganga.

Elegir un feed: los criterios que cuentan

  • La licencia, primero. ¿Puedes siquiera usarlo en tu contexto? Un feed de uso no comercial es inutilizable en un servicio de pago. La etiqueta «open source» no basta: lee las condiciones reales.
  • ¿Original o reagregado? Un feed que agrega otras treinta listas hereda el ruido y las licencias de todas. Un feed de contenido original (surgido de su propia telemetría) vale más que un agregado que podrías reconstruir tú mismo.
  • La corroboración. Un indicador confirmado por varias fuentes independientes es mucho más fiable que un aviso único. Es el primer factor de confianza.
  • La frescura. Un buen feed data sus indicadores y los hace caducar. Un indicador sin fecha de vista es un indicador en el que no se puede confiar.
  • El contexto. «Esta IP es mala» vale poco; «esta IP es un C2 de tal familia, vista tal día» vale una decisión. El contexto convierte un indicador en una acción.

Explotar el feed: la disciplina

Elegir es solo la mitad del trabajo. Esto es lo que separa un feed útil de uno peligroso.

Normalizar y deduplicar. Las fuentes llegan en formatos heterogéneos (CSV, STIX, MISP, RPZ). Hay que llevarlas a un modelo común y fusionar los duplicados, si no, el mismo indicador, visto diez veces, pesa diez veces en tu scoring.

La higiene del «nunca bloquear». Es la regla que evita el incidente. Mantén listas de exclusión: los rangos privados (RFC 1918), tus propios prefijos, las IP compartidas de CDN y de nube, los dominios más populares. Un indicador que cae en una exclusión nunca debe activar un bloqueo automático, sea cual sea la fuente. Bloquear una IP de CDN porque un feed la señaló es provocar tú mismo la caída.

La caducidad. Un indicador no es malicioso para siempre. Haz caducar las IP tras un plazo, reevalúa los dominios. Un feed sin decaimiento solo crece y se equivoca cada vez más.

El scoring por corroboración. Asigna una confianza a cada indicador según cuántas fuentes independientes lo confirman. Es lo que te permite decidir: alertar ante una señal débil, bloquear ante una fuerte.

El tipo de indicador correcto en el lugar correcto

Un IOC no se aplica en cualquier sitio. La coherencia entre el tipo de indicador y el punto de aplicación marca la diferencia:

  • IP → cortafuegos, o resolución DNS. Con exclusiones, siempre.
  • Dominio → filtrado DNS (una zona RPZ es el formato natural).
  • Hash → EDR, o una regla YARA sobre los ficheros.
  • URL → proxy web.

Conectar un feed de hashes a un cortafuegos no sirve de nada; conectar un feed de IP a un cortafuegos sin exclusión sirve para provocar una caída.

Validar: medir antes de bloquear

Antes de poner un feed en aplicación automática, mide dos cosas:

  1. La tasa de falsos positivos contra tu propio tráfico conocido-bueno: ¿cuántos de tus flujos legítimos se verían afectados? Si la cifra no es casi nula, quédate en modo alerta, no en modo bloqueo.
  2. La tasa de cobertura: ¿el feed ve amenazas que tus otras fuentes se pierden? Un feed que no aporta nada nuevo no merece su sitio.

Las trampas que salen caras

  • El bloqueo de IP sin exclusión. La primera causa de autocaída. La lista «nunca bloquear» no es opcional.
  • Los hashes caducados. Un hash sigue siendo válido, pero un feed de hashes nunca limpiado se hincha sin fin y ralentiza tus correlaciones.
  • La licencia olvidada. Un feed no comercial o prohibido para la reventa no pinta nada en un servicio facturado. Verifica antes de integrar.
  • La fuente única sobrevalorada. Un indicador de una sola fuente, sin corroboración, merece una alerta, no un bloqueo ciego.

En resumen

Explotar un feed de IOC es una disciplina, no un simple conectado: elegir por la licencia, la originalidad y la corroboración; luego normalizar, excluir lo que nunca se bloquea, hacer caducar, puntuar y aplicar el tipo de indicador correcto en el punto correcto. El resto (los formatos, los contadores) es fontanería.

Es exactamente lo que proporciona el feed IOC de ThreatClaw: indicadores normalizados multiformato, puntuados por corroboración entre fuentes, con la higiene «nunca bloquear» integrada para que el valor (la detección) nunca se pague con una caída. Es lo que una simple lista bruta no puede garantizar.

Artículos relacionados