IOC Correlator: Plataforma de Correlación de Indicadores de Compromiso con Inteligencia de Amenazas Multi-fuente

1. Introducción al proyecto

En este proyecto se abordará el desarrollo e implementación de IOC Correlator, una plataforma web de inteligencia de amenazas (threat intelligence) orientada a equipos de seguridad Blue Team. Se explicarán los conceptos fundamentales sobre los indicadores de compromiso (IOC) y su importancia en la defensa activa, el diseño de una arquitectura multi-tenant robusta y el proceso de integración con cuatro fuentes OSINT de referencia: VirusTotal, AbuseIPDB, Shodan y AlienVault OTX.

También se describirá cómo se ha desarrollado el backend con FastAPI (Python 3.12) y el frontend con React + TypeScript, orquestando todos los servicios mediante Docker Compose sobre un VPS Hetzner con Debian 13. Se detallarán los mecanismos de autenticación JWT, el cifrado Fernet AES-128 para la gestión segura de claves API, el procesamiento asíncrono de análisis masivos con Celery y el seguimiento en tiempo real mediante WebSocket.

El repositorio público del proyecto está disponible en github.com/alfonsora6/ioc-correlator y el despliegue en producción es accesible desde https://ioc-correlator.duckdns.org.

2. Threat Intelligence e Indicadores de Compromiso

2.1 ¿Qué es un IOC?

Un Indicador de Compromiso (Indicator of Compromise, IOC) es un artefacto forense que, cuando se detecta en una red o sistema, indica con alta probabilidad que ese activo ha sido comprometido o está bajo ataque. Los IOC son el lenguaje común de la inteligencia de amenazas: permiten a los equipos de seguridad compartir conocimiento sobre amenazas conocidas y automatizar su detección.

Los principales tipos de IOC son:

• Direcciones IPv4: La más habitual en el análisis de incidentes. Una IP asociada a servidores de C2 (Command & Control), botnets o campañas de escaneo masivo puede identificarse rápidamente consultando bases de reputación como AbuseIPDB o Shodan.

• Dominios: Un nombre de dominio registrado para phishing, distribución de malware o exfiltración de datos. Las plataformas de threat intelligence como VirusTotal y AlienVault OTX mantienen listas curadas de dominios maliciosos.

• URLs: Una URL específica puede apuntar a un payload, un panel de C2 o una página de phishing. El análisis de URL incluye tanto la reputación del dominio base como la del recurso completo.

• Hashes de ficheros (MD5 / SHA1 / SHA256): El identificador único de un fichero. Un hash malicioso indica que ese binario concreto ha sido clasificado como malware por alguno de los motores de análisis que alimentan plataformas como VirusTotal.

2.2 El problema: fragmentación del análisis de IOCs

Los equipos de seguridad que investigan un incidente o analizan logs de tráfico necesitan contrastar rápidamente si una dirección IP, un dominio o un hash es malicioso. El flujo habitual implica acceder de forma manual y secuencial a múltiples plataformas, copiando y pegando cada indicador. Este proceso presenta problemas críticos:

• Tiempo elevado: Analizar 10-20 IOCs puede llevar entre 20 y 30 minutos por la navegación entre portales.
• Criterio subjetivo: Cada fuente utiliza escalas de riesgo diferentes, dificultando la comparación entre resultados.
• Sin contexto unificado: No existe una visión agregada del nivel de amenaza por indicador.
• Sin historial: Los análisis se realizan ad-hoc sin trazabilidad ni informes auditables.
• Sin soporte batch: El análisis de ficheros de log con cientos de IPs es inviable de forma manual.

2.3 Fuentes de inteligencia de amenazas integradas

IOC Correlator integra cuatro fuentes OSINT (Open Source Intelligence) de referencia en el sector:

1. VirusTotal: Plataforma de análisis de ficheros, URLs, IPs y dominios que agrega los resultados de más de 70 motores antivirus y escáneres de seguridad. Ofrece una visión exhaustiva del historial de detecciones de cualquier IOC y es la fuente más completa para el análisis de hashes de ficheros. Disponible en plan gratuito con límite de 4 solicitudes por minuto.

2. AbuseIPDB: Base de datos colaborativa especializada en la reputación de direcciones IP. Los usuarios reportan IPs asociadas a actividad maliciosa (spam, escaneo de puertos, ataques de fuerza bruta, etc.) y la plataforma calcula un porcentaje de confianza de abuso. Es especialmente útil para el triaje inicial de IPs sospechosas en logs de firewall o IDS.

3. Shodan: Motor de búsqueda para dispositivos conectados a Internet. A diferencia de otras fuentes centradas en la reputación, Shodan proporciona información de enriquecimiento: puertos abiertos, servicios expuestos, sistema operativo, geolocalización y banners de servicio. Su integración permite contextualizar una IP maliciosa con su superficie de exposición real.

4. AlienVault OTX: Plataforma de threat intelligence comunitaria gestionada por AT&T Cybersecurity. OTX organiza la inteligencia en pulses, que son colecciones de IOCs asociadas a campañas, actores de amenaza y malware específicos. Permite identificar si un IOC está activamente relacionado con una campaña conocida.

2.4 Sistema de puntuación unificado

Uno de los retos principales al integrar múltiples fuentes de threat intelligence es la heterogeneidad de sus escalas de riesgo: VirusTotal devuelve una ratio de detecciones (e.g. 15/72 engines), AbuseIPDB un porcentaje de confianza de abuso (0-100%), OTX un número de pulses activos, y Shodan no ofrece directamente una puntuación de riesgo.

IOC Correlator implementa una lógica de scoring agregado que normaliza y pondera los resultados de cada fuente en una puntuación unificada de 0 a 100, con cuatro niveles de severidad:

Rango	Nivel	Interpretación
0 – 25	LOW	Sin indicios relevantes de actividad maliciosa
26 – 50	MEDIUM	Actividad sospechosa o reportes aislados
51 – 75	HIGH	Indicios claros de actividad maliciosa
76 – 100	CRITICAL	Confirmado como malicioso por múltiples fuentes

2.5 Arquitectura multi-tenant

La plataforma está diseñada desde su base como un sistema multi-tenant: cada organización (tenant) tiene sus datos completamente aislados del resto. Esto incluye:

1. Aislamiento de datos: Los análisis, el historial y las claves API de cada tenant son inaccesibles para otros tenants a nivel de base de datos.

2. Autenticación por tenant: Los tokens JWT incluyen el identificador del tenant, garantizando que cada petición a la API opera exclusivamente sobre los datos de la organización autenticada.

3. Cifrado de claves API: Las claves de acceso a VirusTotal, AbuseIPDB, Shodan y OTX se almacenan cifradas con Fernet AES-128, un cifrado simétrico autenticado que impide la lectura de las claves incluso con acceso directo a la base de datos.

2.6 Ventajas frente al análisis manual

La integración de las cuatro fuentes en paralelo y la normalización de resultados en un score unificado ofrecen ventajas concretas para los equipos SOC:

1. Reducción del tiempo de análisis: Un analista puede obtener en 3-5 segundos la misma información que antes requería 10 minutos de navegación manual entre portales. Esto reduce el MTTD (Mean Time To Detect) de forma significativa, especialmente en SOCs con recursos limitados.

2. Criterio objetivo y homogéneo: Al normalizar todas las fuentes a una escala común (0-100), se elimina la ambigüedad inherente a comparar manualmente resultados de diferentes plataformas con métricas heterogéneas.

3. Trazabilidad y auditoría: Cada análisis queda registrado en el historial del tenant con su timestamp UTC, el tipo de IOC, las puntuaciones por fuente y el veredicto agregado. Esto permite generar informes PDF auditables para presentación a dirección o inclusión en expedientes de respuesta a incidentes.

4. Análisis masivo: La funcionalidad de análisis en batch permite subir ficheros .txt, .csv o .log con cientos de IOCs y procesarlos de forma automática, algo inviable con el flujo manual habitual.

3. Arquitectura Técnica

3.1 Stack tecnológico

La arquitectura de IOC Correlator sigue un patrón de microservicios orquestados con Docker Compose, con separación clara entre capa de presentación, capa de aplicación y capa de datos.

Capa	Tecnología	Versión	Función
Frontend	React + TypeScript	18 / 5	SPA responsive, modo claro/oscuro
Frontend	Vite	5	Build tool y dev server (puerto 5173)
Backend	FastAPI (Python)	0.111 / 3.12	API REST asíncrona + WebSocket
Backend	SQLAlchemy + Asyncpg	2.x	ORM async para PostgreSQL
Backend	Alembic	1.x	Migraciones de esquema de base de datos
Workers	Celery	5.x	Procesamiento asíncrono de análisis batch
Base de datos	PostgreSQL	16	Almacenamiento multi-tenant con aislamiento
Caché / Cola	Redis	7	Broker para Celery y caché de resultados
Auth	JWT (python-jose)	—	Access + Refresh tokens por tenant
Cifrado	Cryptography (Fernet)	—	AES-128 para claves API por tenant
Contenedores	Docker + Compose	24.x / 2.x	5 servicios orquestados
Infra	Hetzner VPS (Debian 13)	—	Servidor de producción en nube europea
DNS	DuckDNS	—	Subdominio gratuito HTTPS

3.2 Diagrama de arquitectura

La arquitectura se organiza en cuatro capas lógicas:

• Capa de presentación: El navegador del usuario accede a la SPA React+TypeScript servida por Nginx en modo proxy inverso.
• Capa de aplicación: El backend FastAPI gestiona la API REST y los canales WebSocket. El worker Celery procesa de forma asíncrona los análisis en batch consumiendo la cola de Redis.
• Capa de datos: PostgreSQL almacena los datos multi-tenant con aislamiento por organización. Redis actúa como broker de mensajería para Celery y como caché de resultados de análisis recientes.
• Fuentes externas (OSINT): FastAPI consulta en paralelo las APIs REST de VirusTotal, AbuseIPDB, Shodan y AlienVault OTX.

3.3 Estructura del repositorio

El repositorio sigue una estructura monorepo con separación clara entre frontend y backend:

ioc-correlator/
├── backend/               # Python · FastAPI — API REST, workers, modelos, routers
├── frontend/              # TypeScript · Vite — SPA React, componentes, hooks, vistas
├── scripts/               # Shell — verify-deploy, utilidades de mantenimiento
├── obsidian/              # Markdown — Bóveda de documentación técnica interna
├── .obsidian/             # JSON — Configuración del workspace Obsidian
├── docker-compose.yml     # Orquesta los 5 servicios Docker
├── install.sh             # Script de instalación automática en VPS Hetzner
├── MANUAL-INSTALACION.md  # Guía de despliegue manual paso a paso
├── .env.example           # Plantilla de variables de entorno para producción
├── Makefile               # Atajos de comandos frecuentes (build, up, logs...)
├── CHANGELOG.md           # Historial de versiones y cambios del proyecto
└── .gitignore             # Ficheros excluidos del control de versiones

4. Proceso de Desarrollo

4.1 Fase 1 — Ideación y diseño

La primera fase del proyecto se centró en la definición del alcance y el diseño de la arquitectura:

• Estudio de las APIs disponibles (VirusTotal, AbuseIPDB, Shodan, OTX) y análisis de sus límites de uso gratuito y planes académicos.
• Diseño del modelo de datos multi-tenant con PostgreSQL: tablas tenants, users, ioc_analyses, batch_jobs y api_keys.
• Creación del esquema de puntuación 0-100 con los niveles LOW, MEDIUM, HIGH y CRITICAL.
• Uso de Claude para generar los primeros prompts de diseño de arquitectura y de Cursor para validar la viabilidad técnica del stack elegido.

4.2 Fase 2 — Backend (FastAPI + PostgreSQL)

Con la arquitectura definida, se procedió a la implementación del backend:

• Implementación del backend con FastAPI en modo asíncrono usando asyncpg para maximizar el rendimiento en consultas concurrentes a la base de datos.
• Diseño e implementación del esquema de base de datos con SQLAlchemy (ORM async) y versionado de esquema con Alembic.
• Sistema de autenticación JWT con access token de 15 minutos y refresh token de 7 días, con aislamiento completo por tenant.
• Cifrado de claves API de terceros con Fernet AES-128 por tenant, almacenadas en la tabla api_keys de PostgreSQL.
• Cursor generó los modelos SQLAlchemy y los schemas Pydantic a partir de prompts detallados redactados con ayuda de Claude.

4.3 Fase 3 — Integración de fuentes OSINT

Con el backend estable, se implementaron los clientes HTTP asíncronos para cada fuente de inteligencia:

• VirusTotal: Análisis de IPs, dominios, URLs y hashes. Plan gratuito con límite de 4 req/min, gestionado con control de cuota en la capa de servicio.
• AbuseIPDB: Consulta de reputación de IPs con porcentaje de confianza de abuso. Respuesta directa y rápida, ideal para el triaje inicial.
• Shodan: Enriquecimiento con puertos abiertos, sistema operativo y geolocalización. Requiere plan de pago o licencia académica.
• AlienVault OTX: Pulses activos y categorías de amenaza asociadas al IOC.
• Lógica de scoring agregado con ponderación por fuente y normalización a 0-100.
• Sistema de detección automática del tipo de IOC: IPv4, dominio, URL, MD5, SHA1 y SHA256.

4.4 Fase 4 — Frontend React

El frontend se desarrolló como una SPA (Single Page Application) con React + TypeScript y Vite como build tool:

• Dashboard principal: Contadores de severidad, gráfico temporal de análisis de los últimos 30 días y tabla de IOCs recientes.
• Vista de análisis individual: Tarjetas detalladas por fuente con sus métricas específicas y score visual circular con indicador de severidad.
• Vista de análisis en batch: Drag & drop de ficheros, barra de progreso en tiempo real mediante WebSocket.
• Gestión de claves API: Registro y validación individual de la clave de cada proveedor con indicador de estado.
• Exportación de informes PDF con selección de rango de fechas desde el frontend.
• Modo claro/oscuro y diseño responsive mobile-first.

4.5 Fase 5 — Workers, WebSocket y análisis batch

La integración de Celery con Redis como broker permite el procesamiento asíncrono de grandes volúmenes de IOCs:

• Celery gestiona la cola de trabajos de análisis batch, con control de concurrencia para no exceder los rate limits de las APIs externas cuando múltiples tenants analizan en paralelo.
• WebSocket en FastAPI permite enviar el progreso del análisis batch al frontend en tiempo real, actualizando la barra de progreso conforme Celery va completando cada IOC.
• Parser de ficheros .txt, .csv y .log con extracción automática de IOCs mediante expresiones regulares.
• Manejo de errores y reintentos para APIs externas con gestión de cuotas agotadas.
• Exportación de resultados batch en CSV con todos los campos del análisis.

4.6 Fase 6 — Despliegue en producción (Hetzner)

La fase final consistió en el aprovisionamiento y configuración del entorno de producción:

• Aprovisionamiento de VPS Hetzner con Debian 13 (2 vCPU, 4 GB RAM, 40 GB NVMe).
• Instalación de Docker CE y Docker Compose v2.
• Configuración del fichero .env de producción con claves generadas de forma segura.
• Despliegue con docker compose up --build -d levantando los 5 servicios orquestados.
• Ejecución de migraciones con alembic upgrade head sobre PostgreSQL en contenedor.
• Configuración de DuckDNS para el dominio ioc-correlator.duckdns.org con certificado SSL.
• Script install.sh para reproducibilidad del despliegue en cualquier máquina nueva.
• Script verify-deploy.sh para validación automática del estado de todos los servicios.

5. Guía de Despliegue

5.1 Requisitos previos

Antes de iniciar el despliegue, el servidor o máquina destino debe cumplir los siguientes requisitos:

• Sistema operativo: Debian 11/12/13 o Ubuntu 22.04/24.04 (compatible también con macOS y Windows mediante Docker Desktop).
• Docker >= 24.x y Docker Compose >= 2.x.
• Git para clonar el repositorio.
• python3-cryptography para generar la ENCRYPTION_KEY de Fernet.
• Cuentas gratuitas en AbuseIPDB, VirusTotal y AlienVault OTX. Shodan requiere plan de pago o licencia académica.

5.2 Instalación automática (recomendado)

La forma más rápida de desplegar la aplicación es mediante el script automatizado incluido en el repositorio. El script detecta qué componentes faltan (Docker, .env, contenedores), instala solo lo necesario y al terminar muestra la IP del servidor y los puertos de acceso:

git clone https://github.com/alfonsora6/ioc-correlator.git
cd ioc-correlator
chmod +x install.sh
./install.sh

5.3 Instalación manual en Debian

En caso de preferir un control total sobre cada paso del proceso, a continuación se describe la instalación manual completa.

Paso 1 (Actualizar el sistema)

sudo apt update && sudo apt upgrade -y

Paso 2 (Instalar dependencias base)

sudo apt install -y git ca-certificates curl gnupg python3 python3-cryptography

Paso 3 (Instalar Docker CE)

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian bookworm stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Paso 4 (Añadir el usuario al grupo docker)

sudo usermod -aG docker $USER && newgrp docker

Paso 5 (Clonar el repositorio)

git clone https://github.com/alfonsora6/ioc-correlator.git
cd ioc-correlator

Paso 6 (Configurar las variables de entorno)

Copiamos la plantilla .env.example y generamos las claves de seguridad de forma aleatoria:

cp .env.example .env

# Generar SECRET_KEY y ENCRYPTION_KEY seguros
SECRET=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
ENCKEY=$(python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())")
sed -i "s|^SECRET_KEY=.*|SECRET_KEY=\"$SECRET\"|" .env
sed -i "s|^ENCRYPTION_KEY=.*|ENCRYPTION_KEY=\"$ENCKEY\"|" .env

A continuación, editamos el fichero .env para añadir las claves API de las fuentes OSINT configuradas.

Paso 7 (Construir y levantar los contenedores)

docker compose up --build -d

# Verificar que todos los servicios están Running
docker compose ps

Paso 8 (Ejecutar migraciones de base de datos)

docker compose exec backend alembic upgrade head

Paso 9 (Verificar el despliegue)

chmod +x scripts/verify-deploy.sh && ./scripts/verify-deploy.sh TU_IP_SERVIDOR

Una vez completados todos los pasos, la aplicación queda accesible en el puerto 5173 (frontend) y en el puerto 8000 (API REST con Swagger UI disponible en /docs). Para el despliegue en producción se recomienda configurar Nginx como proxy inverso con certificado SSL mediante Certbot (Let’s Encrypt).

6. Manual de Uso de la Herramienta

6.1 Registro e inicio de sesión

Al acceder por primera vez a la plataforma, el sistema solicita el registro de una nueva organización (tenant). Es necesario introducir los siguientes datos: correo electrónico, contraseña (mínimo 8 caracteres), nombre completo y nombre del tenant (organización).

Una vez registrado, el login emite un JWT de acceso (15 minutos) y un refresh token (7 días) que permiten mantener la sesión activa de forma segura sin necesidad de volver a introducir las credenciales en cada petición.

6.2 Configuración de claves API

Antes de realizar el primer análisis, es necesario configurar al menos una clave API en la sección API Keys. Las claves se almacenan cifradas con Fernet AES-128 y son específicas de cada tenant.

Proveedor	Coste	URL de registro	Funcionalidad
VirusTotal	Gratuito	virustotal.com	IPs, dominios, URLs, hashes
AbuseIPDB	Gratuito	abuseipdb.com	Reputación de IPs (confianza %)
AlienVault OTX	Gratuito	otx.alienvault.com	Threat intelligence comunitaria
Shodan	Académico / Pago	shodan.io	Puertos, servicios, geolocalización

La sección incluye un botón de validación individual por proveedor que comprueba en tiempo real si la clave introducida es válida y tiene cuota disponible.

6.3 Análisis de IOC individual

En la sección Analyze, se introduce un indicador en el campo de texto. El sistema detecta automáticamente el tipo de IOC (IPv4, dominio, URL, hash MD5/SHA1/SHA256) y lanza las consultas en paralelo a todas las fuentes configuradas. En 3-5 segundos se muestra el resultado completo:

• Score agregado 0-100 con indicador visual circular de severidad y código de color.
• Tarjeta detallada por cada fuente con sus métricas específicas (detecciones de motores, porcentaje de abuso, puertos abiertos, pulses activos).
• Veredicto en lenguaje natural indicando si el IOC es malicioso y las razones que lo justifican.
• Posibilidad de exportar el análisis individual como parte del informe PDF.

La escala de severidad es: LOW (0-25, verde) · MEDIUM (26-50, amarillo) · HIGH (51-75, naranja) · CRITICAL (76-100, rojo).

6.4 Análisis en batch

La sección Batch permite subir ficheros .txt, .csv o .log mediante drag & drop. El sistema extrae automáticamente todos los IOCs presentes en el fichero mediante expresiones regulares, los encola en Celery y muestra el progreso en tiempo real vía WebSocket.

Al finalizar, los resultados se pueden descargar en CSV con todos los campos del análisis, incluyendo el score por fuente, el score agregado y el nivel de severidad de cada IOC procesado.

6.5 Dashboard analítico

El dashboard principal ofrece una visión global de la actividad del tenant:

• Contadores de severidad: Número total de IOCs analizados por nivel (LOW, MEDIUM, HIGH, CRITICAL).
• Gráfico temporal: Evolución del número de análisis en los últimos 30 días.
• Tabla de IOCs recientes: Los últimos indicadores analizados con su puntuación y tipo.
• Distribución geográfica: Origen aproximado de las IPs maliciosas detectadas.

6.6 Exportación de informes PDF

En la sección Reports, el usuario selecciona un rango de fechas y genera un informe PDF con el nombre del tenant, el timestamp UTC y todos los análisis del período seleccionado. El informe es apto para presentación a dirección técnica o inclusión en expedientes de respuesta a incidentes y auditorías de seguridad.

7. Herramientas de IA Utilizadas

7.1 Claude (Anthropic) — Diseño y estrategia

Claude se utilizó como asistente de diseño y estrategia durante todo el proyecto, no como generador directo de código. Sus usos principales fueron:

• Diseño de la arquitectura multi-tenant: Claude propuso el modelo de datos con aislamiento por tenant y el flujo de autenticación JWT.
• Generación de prompts optimizados para Cursor: Se iteró con Claude para formular instrucciones precisas que Cursor pudiera ejecutar sin ambigüedades, aplicando técnicas de prompt engineering.
• Resolución de problemas complejos: Cuando surgían errores difíciles de diagnosticar (como el bug de crypto.subtle en HTTP o la configuración de Fernet en Docker Compose v2), Claude proponía hipótesis y soluciones con contexto técnico.
• Revisión de decisiones de diseño: Validación de la lógica de scoring agregado y del modelo de cifrado de claves API.
• Redacción de documentación: Claude ayudó a estructurar el MANUAL-INSTALACION.md y los comentarios del código.

7.2 Cursor IDE — Generación y desarrollo de código

Cursor fue la herramienta central de desarrollo de código. El flujo de trabajo habitual consistía en:

1. Prompt engineering con Claude: Antes de enviar una instrucción a Cursor, se refinaba el prompt con ayuda de Claude para maximizar la precisión y reducir iteraciones.

2. Generación de código con Cursor: Cursor generó los modelos SQLAlchemy, los schemas Pydantic, los routers FastAPI, los componentes React y la lógica de integración con las APIs externas.

3. Revisión manual: Cada bloque de código generado fue revisado manualmente para verificar su corrección y coherencia con la arquitectura definida.

4. Iteración rápida: Cuando el código generado presentaba errores, se usaba Claude para diagnosticar el problema y formular un prompt de corrección para Cursor. Cursor también gestionó el refactoring del frontend cuando se migró de JavaScript a TypeScript.

7.3 Reflexión sobre el uso de IA en el desarrollo

La combinación Claude + Cursor demostró ser especialmente efectiva en un proyecto individual con múltiples capas de complejidad. El valor diferencial de usar dos IAs complementarias radica en la separación de responsabilidades: Claude como arquitecto y estratega, Cursor como implementador.

Esta sinergia permitió a un solo desarrollador construir en pocas semanas una plataforma que en un entorno profesional habitual habría requerido un equipo de 3-4 personas. La clave está en que el prompt engineering no es un paso trivial: la calidad del código generado por Cursor dependía directamente de la precisión del prompt, e invertir tiempo en formular bien el contexto y los requisitos ahorra múltiples iteraciones de corrección.

8. Prueba práctica del proyecto

8.1 Objetivo propuesto

En este proyecto hemos desarrollado y desplegado en producción IOC Correlator, una plataforma de threat intelligence completamente funcional y accesible desde Internet en https://ioc-correlator.duckdns.org. A continuación se describen las pruebas realizadas para validar el correcto funcionamiento de las funcionalidades principales.

8.2 Registro, configuración y primer análisis

Accedemos a la plataforma y completamos el registro indicando el nombre del tenant, el correo y la contraseña. Una vez autenticados, navegamos a la sección API Keys y registramos las claves de VirusTotal y AbuseIPDB (ambas con plan gratuito), comprobando que el botón de validación devuelve estado activo para cada una.

8.3 Análisis de una IP maliciosa conocida

Para validar el funcionamiento de la plataforma, introducimos en la sección Analyze la IP 185.220.101.45, conocida por ser un nodo de salida de la red Tor y aparecer activamente en múltiples bases de reputación.

El sistema detecta automáticamente el tipo de IOC (IPv4) y lanza las consultas en paralelo. En 3 segundos se muestra el resultado:

El score agregado se sitúa en la zona CRITICAL (rojo), coherente con la reputación conocida de esta IP en las fuentes consultadas. La tarjeta de AbuseIPDB refleja un porcentaje de confianza de abuso elevado, mientras que VirusTotal confirma detecciones activas en varios motores.

8.4 Análisis en batch de un fichero de log

Subimos un fichero .log con 50 IPs extraídas de un log de firewall. El sistema extrae automáticamente todas las IPv4, las encola en Celery y muestra el progreso en tiempo real mediante WebSocket.

Al finalizar el procesamiento, descargamos el CSV de resultados y verificamos que el 100% de los IOCs han sido analizados correctamente con sus scores y niveles de severidad asignados.

8.5 Estado de los contenedores en producción

Para comprobar que todos los servicios están corriendo correctamente en el VPS de Hetzner, ejecutamos el script de verificación y el comando de estado de Docker Compose:

./scripts/verify-deploy.sh ioc-correlator.duckdns.org

docker compose ps

El comando anterior nos devuelve la siguiente salida, confirmando que los 5 servicios están en estado Running:

NAME                    IMAGE                   STATUS          PORTS
ioc-correlator-backend  ioc-correlator-backend  Up 2 hours      0.0.0.0:8000->8000/tcp
ioc-correlator-frontend ioc-correlator-frontend Up 2 hours      0.0.0.0:5173->5173/tcp
ioc-correlator-celery   ioc-correlator-celery   Up 2 hours
ioc-correlator-postgres postgres:16-alpine      Up 2 hours      5432/tcp
ioc-correlator-redis    redis:7-alpine          Up 2 hours      6379/tcp

8.6 Generación de informe PDF

Desde la sección Reports, seleccionamos el rango de fechas de los últimos 7 días y generamos el informe PDF. El informe incluye el nombre del tenant, el timestamp UTC de generación y todos los análisis del período, ordenados por nivel de severidad, listo para su uso en expedientes de auditoría o presentación a dirección.

9. Road Map de Mejoras Futuras

9.1 Mejoras planificadas por versión

Las mejoras planificadas se organizan en tres horizontes temporales, priorizadas por impacto en el usuario y viabilidad técnica:

Versión	Horizonte	Mejora	Impacto
v1.1	4 días	Soporte MISP y OpenCTI como fuentes adicionales	Alto
v1.1	6 días	Reglas de correlación configurables por tenant	Alto
v1.2	4 días	Integración con Splunk / SIEM vía syslog/API	Alto
v1.3	2 días	Alertas automáticas por email/Slack en CRITICAL	Medio
v1.3	4 días	Exportación a STIX/TAXII para intercambio de IoCs	Medio
v2.0	8 días	Motor de scoring basado en ML (XGBoost)	Alto
v2.0	3 días	Dashboard de mapa geográfico interactivo	Medio
v2.1	5 días	Soporte IPv6 completo y análisis de URLs profundo	Medio
v2.1	4 días	API pública documentada para integración de terceros	Alto
v3.0	3 días	Multi-idioma (EN, FR, DE) y panel de administración	Bajo

9.1.1 MISP y OpenCTI como fuentes adicionales (v1.1 — Alto impacto)

Integrar MISP (Malware Information Sharing Platform) y OpenCTI como fuentes adicionales permitirá enriquecer el análisis con contexto de campañas activas, actores de amenaza y TTPs (Tactics, Techniques and Procedures). Estimación: 2-3 semanas. Requiere instancias propias de MISP/OpenCTI o acceso a APIs públicas.

9.1.2 Motor de scoring ML con XGBoost (v2.0 — Alto impacto)

Sustituir el scoring heurístico actual por un modelo XGBoost entrenado con datasets históricos de IOCs maliciosos permitirá reducir los falsos positivos y negativos. Estimación: 4-6 semanas. Requiere dataset etiquetado y pipeline de entrenamiento integrado en el CI/CD del proyecto.

9.1.3 Integración con Splunk / SIEM vía syslog/API (v1.2 — Alto impacto)

Exponer un endpoint de ingestión compatible con syslog RFC5424 y con la API de Splunk HEC permitirá que IOC Correlator actúe como enriquecedor de eventos en entornos SOC reales. Estimación: 3-4 semanas. Incluye desarrollo del endpoint y documentación de integración.

9.1.4 API pública documentada (v2.1 — Alto impacto)

Publicar la API REST de IOC Correlator con documentación OpenAPI completa y claves de acceso permitirá su integración en herramientas de terceros (SOAR, scripts de analistas). Estimación: 2 semanas. Incluye portal de desarrolladores y gestión de API keys externas.

9.2 Mejoras de seguridad de la propia herramienta

Además de las mejoras funcionales, se han identificado las siguientes mejoras de seguridad para futuras iteraciones:

• HTTPS completo con Nginx + Certbot (Let’s Encrypt) para eliminar el uso de HTTP en producción.
• Rate limiting por tenant en la API para prevenir abuso y consumo excesivo de cuotas de APIs externas.
• Rotación automática de claves Fernet para los secrets almacenados en base de datos.
• Audit log de todos los accesos y análisis realizados por usuario.
• 2FA (TOTP) para cuentas de administrador de tenant.
• Análisis SAST del propio código del proyecto con Semgrep en CI/CD (GitHub Actions).

10. Conclusión

IOC Correlator ha demostrado que es posible construir una plataforma de threat intelligence de nivel profesional como proyecto individual, aprovechando la sinergia entre herramientas de IA (Claude como arquitecto estratégico y Cursor como implementador de código), un stack moderno y bien definido (FastAPI + React + PostgreSQL + Docker), y fuentes OSINT de acceso gratuito.

Los resultados son concretos y medibles: una plataforma completamente funcional y desplegada en producción, accesible desde Internet, con arquitectura multi-tenant, cifrado de datos sensibles, procesamiento asíncrono en batch y análisis en tiempo real mediante WebSocket. La reducción del tiempo de análisis de IOCs de 10-20 minutos a 3-5 segundos representa un impacto directo y cuantificable en la capacidad de respuesta de cualquier equipo SOC que adopte la herramienta.

En conclusión, este proyecto ha permitido aplicar de forma integrada conocimientos de ciberseguridad (threat intelligence, autenticación JWT, cifrado simétrico, análisis de IOCs), desarrollo backend asíncrono (FastAPI, Celery, WebSocket), infraestructura cloud (Docker Compose, VPS Hetzner, Nginx, DuckDNS) y uso estratégico de IA en el ciclo de desarrollo. El resultado es una herramienta Blue Team funcional que, con las mejoras del Road Map, tiene potencial para ser adoptada en entornos SOC reales con recursos limitados.