La ciberseguridad moderna no sufre solo por falta de información. Sufre por exceso de señales mal ordenadas.
Cada día aparecen CVEs, advisories, exploits, boletines de fabricantes, publicaciones de CERTs, indicadores de compromiso, campañas activas, fallos en dependencias, anomalías de routing, infraestructura maliciosa y vulnerabilidades en tecnologías que quizá usamos, quizá no, quizá están expuestas, quizá están aisladas, quizá son críticas o quizá no importan en absoluto para nuestro entorno.
El problema no es leer más. El problema es saber qué importa hoy.
Tesis central: un Blue Team sin fuego real está cojo; un Red Team sin visión arquitectónica está ciego; una organización sin inteligencia de amenazas ordenada está expuesta al ruido.
1. La brecha: mucha formación, poco fuego real
En ciberseguridad se habla mucho de controles, marcos, cumplimiento, hardening y buenas prácticas. Todo eso importa. Pero existe una carencia incómoda: muchos perfiles defensivos no han visto ataques reales más allá de laboratorios, prácticas académicas o demostraciones controladas.
Eso genera una defensa demasiado teórica. Saben que hay que parchear, pero no siempre saben qué parche cambia realmente el riesgo. Saben que hay que monitorizar, pero no siempre saben qué señal merece despertar a alguien. Saben que hay que hacer Blue Team, pero no siempre han visto cómo una vulnerabilidad se convierte en sesión, una sesión en movimiento lateral, un endpoint en proxy, una credencial en control cloud y una mala configuración en impacto empresarial.
Al otro lado tampoco todo es luz. Muchos perfiles ofensivos saben ejecutar herramientas, CTFs y técnicas sueltas, pero no siempre entienden la arquitectura completa que dicen atacar: identidad, permisos, CI/CD, dependencias, negocio, continuidad, logs, blast radius, documentación, recuperación y decisiones humanas.
2. El problema: demasiadas tecnologías, demasiadas fuentes, demasiado ruido
Un entorno empresarial moderno, incluso pequeño o mediano, puede mezclar tecnologías de nube, web, automatización, infraestructura de Internet, sistemas legacy, endpoints y herramientas de IA.
- AWS: IAM, EC2, S3, RDS/Aurora, Lambda, CloudFront, Route 53, SSM, KMS, CloudTrail.
- Web empresarial: WordPress, WooCommerce, Elementor, PHP, nginx, Apache, MySQL, MariaDB, PostgreSQL.
- DevSecOps: Git, GitHub, GitLab, Jenkins, Docker, Kubernetes, Terraform/OpenTofu, Ansible, registries y pipelines.
- IA/RAG/automatización: n8n, Qdrant, OpenAI API, Python, Node.js, webhooks y secretos.
- Infraestructura de Internet: BGP, ASN, DNS, RPKI, Tor, proxies, URLhaus, Spamhaus y señales externas.
Fuentes como NVD, CISA KEV, FIRST EPSS, OSV.dev, GitHub Advisory Database, AWS Security Bulletins, Wordfence, Kubernetes CVE Feed, RIPE RIS Live o URLhaus aportan señales valiosas. Pero ninguna fuente por sí sola responde a la pregunta más importante:
¿Qué debo hacer hoy, en mi entorno, con mis activos, mi exposición, mis recursos y mi tolerancia al riesgo?
Ahí es donde nace la necesidad de Radar CTI.
3. Radar CTI: una capa de gobierno antes que una capa de IA
Radar CTI no debe entenderse como “un sistema que lee noticias con IA”. Esa sería una definición pobre.
Radar CTI es una capa de gobierno, correlación y priorización. Su función es conectar fuentes abiertas, inventario real, enriquecimiento de vulnerabilidades, scoring operativo, informes trazables y acciones concretas.
La arquitectura separa responsabilidades: WordPress gobierna y visualiza; n8n orquesta; Qdrant/RAG aporta memoria semántica; la IA ayuda al análisis; y el front público muestra informes ya procesados sin ejecutar IA por visita.
4. De señal a decisión
El flujo ideal no es:
Fuente → noticia → IA → informe bonito
El flujo correcto es:
Fuente → señal → deduplicación → correlación con inventario → enriquecimiento → scoring → acción → evidencia
Un radar útil debe responder cinco preguntas:
- ¿Qué ha pasado?
- ¿A qué tecnología afecta?
- ¿Lo usamos realmente?
- ¿Se está explotando o es probable que se explote?
- ¿Qué acción concreta toca?
5. El inventario es el alma del scoring
Sin inventario, no hay inteligencia. Solo hay ruido.
Una vulnerabilidad en Kubernetes no importa igual si no hay Kubernetes en producción. Una vulnerabilidad en WordPress importa mucho más si afecta a un plugin usado por clientes. Un aviso de AWS importa más si toca IAM, SSM, Aurora o un componente desplegado. Una anomalía BGP importa más si afecta a un ASN, proveedor, región o ruta relevante para el negocio.
El inventario transforma una noticia en una decisión.
6. Modelo de scoring operativo
Un scoring útil no debe ser perfecto. Debe ser accionable. Un modelo inicial puede ponderar:
El resultado no debe ser solo “riesgo alto”. Debe producir una cola de trabajo:
- Crítica: actuar hoy.
- Alta: revisar en 24-48h.
- Media: programar revisión.
- Baja: documentar u observar.
- No relevante: descartar con evidencia.
7. Automatización sí, pero no desde cualquier sitio
Hay una tentación peligrosa: conectar Radar CTI directamente a ejecución remota.
Eso puede ser útil en una fase madura, pero no debe hacerse desde una superficie pública. Las acciones críticas deben vivir en una capa privada, auditable y controlada, con aprobación humana, IAM/SSM/Lambda/SOAR y trazabilidad fuerte.
La IA puede ayudar a analizar. n8n puede orquestar. Qdrant puede recuperar contexto. WordPress puede gobernar y visualizar. Pero las acciones críticas deben seguir una arquitectura más dura que un botón visible desde Internet.
8. La parte humana: inteligencia de amenazas como antídoto contra la ceguera
La inteligencia de amenazas no es solo técnica. Es una forma de humildad.
Significa reconocer que no podemos mirarlo todo manualmente. Que no podemos leer todas las fuentes. Que no podemos confiar solo en memoria. Que no podemos defender solo con intuición. Que no basta con esperar a que un proveedor avise. Que no basta con hacer una auditoría anual.
Un buen radar no dice: “tienes 800 vulnerabilidades”. Dice: “estas 7 importan, por estas razones, afectan a estos activos, estas fuentes lo respaldan, este es el orden de actuación y esta es la evidencia”.
9. Tecnologías bajo vigilancia
El inventario inicial de Radar CTI debería cubrir al menos estas familias:
- Cloud / AWS: IAM, EC2, S3, RDS, Aurora, Lambda, API Gateway, CloudFront, Route 53, SSM, CloudFormation/CDK, CloudWatch, CloudTrail, KMS, Secrets Manager.
- Web empresarial: WordPress, WooCommerce, Elementor, PHP, nginx, Apache, MySQL/MariaDB, PostgreSQL, OpenSSL.
- DevSecOps: Git, GitHub, GitLab, Jenkins, Docker, Kubernetes, Terraform/OpenTofu, Ansible, Container Registry, GitOps, CI/CD pipelines.
- IA/RAG: n8n, Qdrant, OpenAI SDK/API, Python, Node.js, npm, PyPI, Composer, webhooks y OAuth integrations.
- Enterprise: Windows Server, Active Directory, Exchange, SharePoint, SQL Server, RDP, SMB, Kerberos.
- Internet Infrastructure Intelligence: BGP, ASN, DNS, RPKI, route leaks, hijacks, Tor, VPNs, proxies, passive DNS, URLhaus, Spamhaus and malware infrastructure.
10. Conclusión: ver antes, ordenar mejor, actuar con evidencia
La ciberseguridad no se gana por leer más noticias. Se gana por convertir información en criterio.
La inteligencia de amenazas sin inventario es ruido. El inventario sin scoring es lista. El scoring sin acción es decoración. La acción sin evidencia es improvisación. Y la automatización sin límites es otra forma de riesgo.
Radar CTI no intenta saberlo todo. Intenta saber qué importa ahora.
Porque el problema no es que falten fuentes. El problema es que sobran señales sin ordenar. Y en defensa, quien no ordena sus señales acaba obedeciendo al ruido.