Este tutorial te muestra cómo construir, de principio a fin, un dashboard público de monitoreo de amenazas para el sector OT/ICS (tecnología operativa / sistemas de control industrial), usando Claude como copiloto técnico en cada etapa: desde elegir las fuentes de datos hasta desplegar la arquitectura completa.
No es una guía de "copia y pega este código". Es el proceso real, prompt por prompt, con las decisiones técnicas explicadas para que puedas replicarlo o adaptarlo a tu propio caso.
Paso 1: Define qué necesitas antes de escribir código
Antes de pedirle nada técnico a Claude, define el alcance con una sola restricción clara. En este caso, la restricción fue: todo tiene que ser gratuito y de fuentes públicas verificables.
Prompt de arranque sugerido:
"Necesito un dashboard de threat intelligence para el sector OT/manufactura. Quiero vulnerabilidades explotadas activamente, ransomware contra manufactura, y noticias del sector. Todo debe ser gratuito y de fuentes públicas verificables."
Esa restricción es la que va a filtrar cada decisión posterior — qué fuentes usar, qué arquitectura elegir, y qué no puedes prometerle al usuario final.
Paso 2: Elige y justifica tus fuentes de datos
No cualquier fuente sirve. Antes de integrar nada, evalúa cada una con estas preguntas: ¿es pública? ¿requiere autenticación? ¿es la fuente primaria o pasa por un intermediario? ¿tiene límites de uso?
CISA KEV (Known Exploited Vulnerabilities) El catálogo oficial del gobierno de EE.UU. con vulnerabilidades confirmadas como explotadas activamente. Es JSON público, sin autenticación:
https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
Es la fuente más confiable del proyecto porque no pasa por scraping ni por interpretación de terceros — es la fuente primaria directa.
ransomware.live La única fuente pública con datos de víctimas de ransomware filtradas por sector. Aquí la justificación técnica debe ir acompañada de una honestidad importante: estos datos reflejan lo que los grupos de ransomware afirman en sus sitios de filtración, no una confirmación verificada por la víctima. Trátalo como señal direccional, nunca como hecho confirmado, y dilo explícitamente en tu producto final.
Fuentes de noticias vía RSS
Usa al menos dos fuentes distintas (por ejemplo, un medio especializado en OT/ICS y uno generalista de ciberseguridad) para reducir el sesgo editorial de una sola fuente. Filtra los artículos con un heurístico de palabras clave (scada, plc, ics, operational technology, critical infrastructure, etc.) para quedarte solo con lo relevante.
Cuando no existe una fuente pública real Si necesitas un dato para el que no hay API pública y gratuita (en este caso, un mapa de exposición por país), pregúntale directo a Claude:
"No encuentro una API gratuita de ataques por país para OT. ¿Qué opciones tengo?"
Si la respuesta confirma que no existe, tienes dos caminos: inventar datos disfrazados de reales, o construir un índice editorial declarado como tal. Elige siempre el segundo. Regla general: si no puedes citar la fuente exacta de un número, no lo presentes como dato duro.
Paso 3: Conecta la API de ransomware.live paso a paso
Esta es la integración más delicada del proyecto, así que va con detalle técnico.
3.1 — Verifica si necesitas API key. El nivel gratuito de ransomware.live no requiere autenticación. El endpoint que necesitas es:
GET https://api.ransomware.live/v2/sectorvictims/<sector>
Sustituye <sector> por el que te interese (por ejemplo, Manufacturing).
3.2 — Pide la integración a Claude con los casos límite incluidos:
"Crea una función serverless que consulte la API de ransomware.live, filtre por sector Manufacturing, y solo devuelva víctimas de los últimos 15 días. Necesito manejar el caso de que la API devuelva un array directo o un objeto con la lista adentro, porque no confío en que la forma de respuesta sea siempre igual."
Ese detalle de los "casos límite" importa: muchas APIs públicas no son perfectamente consistentes en su forma de respuesta. El código resultante debe normalizar eso:
const list = Array.isArray(raw) ? raw : raw.victims || raw.data || [];
3.3 — Lee los Términos y Condiciones antes de ir a producción. ransomware.live indica que el uso gratuito/no autenticado es "solo para uso personal"; para uso corporativo o en un dominio con marca pública, pide revisar sus T&C directamente en su sitio. Documenta esto en tu propio código como advertencia para cualquiera que reutilice el proyecto.
3.4 — Resuelve el rate limiting con caché, no con una key premium. Como es una API pública con límites de uso, la solución no es pagar por más cuota — es cachear agresivamente la respuesta (ver Paso 4) para no golpear la API más de una vez cada 24 horas, sin importar cuántas visitas reciba tu sitio.
Paso 4: Diseña la arquitectura completa
Pídele a Claude que piense en capas, no solo en código:
"Diseña la arquitectura completa: qué pasa desde que un usuario entra al navegador hasta que recibe los datos, pasando por WAF, caché y las APIs externas."
Un flujo típico para este tipo de dashboard se ve así:
Navegador del usuario
|
v
WAF (Web Application Firewall)
| <- filtra tráfico malicioso, bots y ataques antes de llegar a tu infraestructura
v
Edge Network (CDN + caché de borde)
| <- aquí vive el header Cache-Control: s-maxage=86400 (24h)
| <- esta capa absorbe casi todo el tráfico sin tocar tu backend
v
Funciones Serverless — actúan como "workers"
| <- cada función recibe la petición del navegador,
| llama a la fuente externa, transforma la respuesta, la devuelve
v
APIs / feeds externos (fuera de tu control)
Fuente oficial (ej. CISA KEV)
API de terceros (ej. ransomware.live)
Feeds RSS de noticias
Sobre el WAF: esta capa es la primera línea de defensa — filtra tráfico malicioso, intentos de scraping abusivo y patrones de ataque antes de que lleguen a tu aplicación. No todos los proveedores de hosting lo incluyen por defecto con reglas configurables; si el tuyo no lo trae, considéralo como una capa a añadir explícitamente delante de tu infraestructura, no como algo que puedas asumir resuelto.
¿Por qué serverless y no un servidor tradicional (VPS/EC2)?
- No hay tráfico constante que justifique un servidor corriendo 24/7
- Cada worker solo se ejecuta cuando el caché expira
- Cero mantenimiento de sistema operativo, parches o gestión de procesos
- Trade-off a considerar: los planes gratuitos de hosting serverless suelen limitar los cron jobs nativos a una vez al día, así que el refresco de datos depende del caché de borde, no de un job programado frecuente
¿Por qué caché de borde y no base de datos? Si tu dashboard solo necesita mostrar datos frescos periódicamente (no historial ni analítica), el caché de borde puede ser tu única capa de "persistencia". Configura el header así:
Cache-Control: s-maxage=86400, stale-while-revalidate=172800
La primera visita después de que expira el caché ejecuta tu worker real; todas las visitas siguientes durante esas 24h reciben la copia cacheada desde el Edge Network. Esto elimina por completo la necesidad de una base de datos.
Paso 5: Estructura el repositorio para despliegue automático
Mantén el proyecto simple: sin build step si no lo necesitas.
public/ -> frontend estático (HTML/CSS/JS puro)
api/ -> tus funciones serverless (workers)
config -> headers CORS y timeout de funciones
package.json -> metadata del proyecto
Pídele a Claude el flujo de despliegue:
"Explícame el flujo completo desde mi repositorio hasta un dominio custom, como si nunca lo hubiera hecho."
Con la mayoría de proveedores modernos, conectar tu repositorio configura el despliegue automático: cada cambio subido a tu rama principal dispara un deploy a través del WAF y el Edge Network sin necesidad de un pipeline de CI/CD separado.
Paso 6: Itera con prompts específicos, no con reescrituras completas
Una vez que el dashboard esté en producción, cada mejora debería ser un prompt concreto y acotado a una sola capa del sistema. Ejemplos reales de este proceso:
- "El mapa muestra un índice pero no dice de dónde sale — agrega que al hacer clic en un país se abra la fuente de esos datos."
- "Cambia la ventana de refresco de 12 a 24 horas en todo el dashboard, incluyendo el caché de los workers."
- "En la tabla de ransomware, algunas filas no tienen ningún link verificable — agrega una columna Source que siempre tenga un enlace."
Cada prompt debe tocar una sola capa (frontend, worker/caché, o integridad de datos). Esto confirma algo importante: construir un dashboard con ayuda de una IA no es un solo prompt gigante — es una conversación técnica capa por capa, igual que lo harías con un desarrollador humano.
Resumen: los principios que debes seguir
- Define primero de dónde van a salir tus datos y bajo qué términos puedes usarlos legalmente.
- Sé honesto cuando no exista una fuente real — un índice editorial declarado como tal es mejor que un dato inventado disfrazado de verificado.
- Diseña el caché antes que el diseño visual — es lo que te permite operar gratis a cualquier escala de tráfico.
- Usa serverless + edge cache si tu proyecto no necesita persistencia histórica — te ahorras infraestructura completa.
- Itera con prompts acotados a una sola capa, no con reescrituras completas cada vez que quieras un ajuste.
Puedes consultar el resultado aquí: ot.cafehacking.com Autor: Edu Quijano