01. El salto desde SIEM tradicional hacia un SOC aumentado por IA
Durante las semanas anteriores hemos construido los fundamentos para comprender una arquitectura moderna de ciberseguridad y el papel que puede desempeñar la inteligencia artificial.
Ahora damos un paso importante: la IA deja de ser únicamente una herramienta de análisis y comienza a formar parte del pipeline operativo de seguridad.
Collect
Recoger logs, eventos, flujos de red, endpoints, identidad, aplicaciones y cloud.
Normalize
Convertir diferentes formatos y fuentes en una estructura común.
Detect
Identificar comportamientos sospechosos mediante reglas, estadística, ML e IA.
Investigate
Correlacionar evidencias para construir una hipótesis sobre el incidente.
Respond
Ejecutar o recomendar acciones de contención y recuperación.
02. ¿Dónde aporta realmente valor la IA?
Uno de los errores más habituales consiste en introducir un LLM simplemente delante de los logs y esperar que "encuentre ataques".
Una arquitectura profesional es mucho más sofisticada.
| Capa | Tecnología | Uso de IA |
|---|---|---|
| Ingesta | Syslog, API, agents, collectors | Clasificación y enriquecimiento |
| Normalización | JSON / ECS / CEF / OCSF | Detección de inconsistencias |
| Detección | Rules + ML | Anomaly detection |
| Correlación | SIEM / graph | Relationship reasoning |
| Investigación | LLM + RAG | Hipótesis y explicación |
| Respuesta | SOAR | Generación de playbooks y recomendaciones |
La IA no debe sustituir automáticamente las fuentes de evidencia. Debe trabajar sobre datos observables, trazables y verificables.
03. Arquitectura de un sistema SOC basado en IA
La siguiente arquitectura representa el sistema que construiremos progresivamente durante el módulo.
04. La diferencia entre detección y análisis
Es importante separar dos conceptos.
Detection
Determina que existe un comportamiento potencialmente malicioso.
Ejemplo:
User jsmith authenticated
from 185.22.10.45
after 14 failed logins
Investigation
Intenta determinar qué significa realmente ese comportamiento.
- Is the IP malicious?
- Is the user normally remote?
- Was MFA used?
- What happened afterwards?
- Were privileged resources accessed?
Las reglas pueden detectar patrones conocidos. La IA puede ayudar a contextualizar múltiples evidencias y convertirlas en una narrativa investigable.
05. Caso práctico: detección de un posible ataque
Supongamos que el sistema recibe los siguientes eventos.
2026-08-29 09:01:13 user=jsmith event=login_failed src_ip=185.22.10.45 2026-08-29 09:01:18 user=jsmith event=login_failed src_ip=185.22.10.45 2026-08-29 09:01:22 user=jsmith event=login_failed src_ip=185.22.10.45 2026-08-29 09:01:27 user=jsmith event=login_success src_ip=185.22.10.45 2026-08-29 09:03:11 user=jsmith event=privilege_escalation target=domain_admin 2026-08-29 09:04:22 user=jsmith event=ldap_query query=all_domain_users 2026-08-29 09:06:33 user=jsmith event=network_share_access target=\\fileserver\finance
Un sistema basado únicamente en reglas podría generar varios alerts.
Un sistema aumentado por IA debería intentar correlacionarlos.
- Multiple authentication failures.
- Successful authentication.
- Privilege escalation.
- Directory reconnaissance.
- Access to sensitive resources.
El conjunto presenta una probabilidad significativamente mayor de compromiso que cualquiera de los eventos aislados.
06. Construcción del contexto para la IA
Nunca deberíamos enviar únicamente el evento original al LLM.
Hay que construir un contexto estructurado.
{
"incident": {
"id": "INC-2026-00421",
"severity": "high",
"source": "identity-monitor"
},
"user": {
"username": "jsmith",
"department": "finance",
"role": "employee"
},
"source_ip": {
"address": "185.22.10.45",
"country": "unknown",
"reputation": "suspicious"
},
"timeline": [
{
"timestamp": "09:01:13",
"event": "login_failed"
},
{
"timestamp": "09:01:27",
"event": "login_success"
},
{
"timestamp": "09:03:11",
"event": "privilege_escalation"
},
{
"timestamp": "09:04:22",
"event": "ldap_query"
}
],
"assets": [
"domain-controller",
"finance-fileserver"
]
}
Esto permite que el modelo razone sobre entidades, relaciones, temporalidad y contexto.
07. Prompting de seguridad: del prompt genérico al analista especializado
Un prompt como:
"Analiza estos logs y dime si hay un ataque."
es demasiado pobre para un entorno profesional.
Un sistema avanzado debe establecer claramente:
- Rol del modelo.
- Objetivo.
- Fuentes de evidencia.
- Limitaciones.
- Formato de respuesta.
- Nivel de confianza.
- Prohibición de inventar evidencias.
Prompt recomendado
You are an experienced SOC Tier 2/3 analyst. Your task is to analyze the security incident using ONLY the evidence provided. Do not invent facts. Determine: 1. Whether the activity is suspicious. 2. Most likely attack technique. 3. Relevant MITRE ATT&CK techniques. 4. Timeline of activity. 5. Affected identities. 6. Affected assets. 7. Evidence supporting the hypothesis. 8. Evidence that contradicts the hypothesis. 9. Recommended investigation steps. 10. Recommended containment actions. For every conclusion provide: - confidence: low / medium / high - supporting evidence If evidence is insufficient, explicitly state: "INSUFFICIENT EVIDENCE" Return the answer as structured JSON.
08. Structured output: una necesidad operativa
Un SOC no puede depender de respuestas libres generadas por un modelo.
Necesitamos estructuras que puedan ser procesadas automáticamente.
{
"classification": "potential_compromise",
"severity": "high",
"confidence": 0.91,
"attack_stage": [
"initial_access",
"privilege_escalation",
"discovery"
],
"mitre": [
"T1078",
"T1068",
"T1087"
],
"evidence": [
"Multiple failed logins",
"Successful authentication",
"Privilege escalation",
"LDAP enumeration"
],
"recommended_actions": [
"Disable account",
"Revoke sessions",
"Isolate affected endpoint",
"Review domain controller logs"
],
"human_review_required": true
}
09. Confidence ≠ Probability of compromise
Este concepto es especialmente importante.
Una IA puede tener una confianza elevada en una interpretación y, sin embargo, esa interpretación no representar necesariamente la realidad.
| Concepto | Significado |
|---|---|
| Confidence | Seguridad del modelo respecto a su propia interpretación. |
| Risk | Impacto potencial del incidente. |
| Likelihood | Probabilidad estimada de que la hipótesis sea cierta. |
| Severity | Magnitud del impacto. |
10. Correlación basada en entidades
Una de las mejoras más importantes consiste en dejar de pensar únicamente en logs y comenzar a pensar en entidades.
Identity
User, service account, administrator.
Host
Endpoint, server, virtual machine.
Network
IP, subnet, domain, connection.
Application
API, database, service.
Resource
File, share, bucket, database.
Una vez identificadas las entidades podemos construir relaciones:
User | | authenticated_from ↓ IP | | connected_to ↓ Endpoint | | executed ↓ Process | | accessed ↓ File Server
Esta representación permite evolucionar posteriormente hacia un Security Knowledge Graph.
11. Anomaly Detection
No todos los ataques coinciden con patrones conocidos.
Por ello necesitamos detectar desviaciones respecto al comportamiento normal.
Ejemplo
Un usuario normalmente:
- Accede entre 08:00 y 18:00.
- Desde España.
- Desde dos dispositivos.
- Accede a cinco aplicaciones.
- Realiza unas 50 consultas diarias.
Un día aparece:
02:41 AM Country: Netherlands Device: Unknown Application: Domain Controller LDAP queries: 8,432 Data accessed: 14 GB
Sin embargo, el comportamiento es claramente anómalo.
12. UEBA: User and Entity Behavior Analytics
UEBA permite construir perfiles de comportamiento para usuarios y entidades.
| Variable | Ejemplo |
|---|---|
| Login time | 02:41 |
| Location | New country |
| Device | Unknown |
| Application | Domain Controller |
| Volume | 8,432 queries |
| Privilege | Administrator |
El sistema puede generar una puntuación:
anomaly_score = 0.94
Pero esa puntuación debe combinarse con otros factores antes de convertirse en una decisión operativa.
13. Threat Intelligence + IA
La inteligencia artificial puede enriquecer una alerta con información externa.
Por ejemplo:
IOC: 185.22.10.45
El pipeline puede consultar:
- Reputación IP.
- WHOIS.
- DNS history.
- Threat feeds.
- Malware databases.
- Previous incidents.
Posteriormente la IA puede integrar la información.
La IA no debe sustituir la fuente original de Threat Intelligence. Debe interpretar y contextualizar sus resultados.
14. RAG aplicado a ciberseguridad
Un LLM general no conoce necesariamente las políticas internas de nuestra organización.
Tampoco conoce nuestros activos, procedimientos o arquitectura.
Aquí entra RAG: Retrieval-Augmented Generation.
Knowledge Base
Documentación, procedimientos, arquitectura, políticas, playbooks.
Retriever
Recupera los documentos relevantes para cada incidente.
LLM
Interpreta el incidente utilizando el contexto recuperado.
15. Ejemplo de RAG para un SOC
Supongamos que el analista pregunta:
¿Qué procedimiento debemos seguir si una cuenta de administrador presenta indicios de compromiso?
El sistema busca en la documentación interna:
/security/playbooks/account-compromise.md /security/policies/identity-response.pdf /security/procedures/admin-account.md
El LLM utiliza esos documentos como contexto.
La respuesta no depende únicamente del conocimiento general del modelo, sino de los procedimientos reales de la organización.
16. AI Incident Copilot
El objetivo de esta semana será conceptualizar un "AI Incident Copilot".
Este componente ayudará al analista a responder:
- ¿Qué ha ocurrido?
- ¿Cuándo comenzó?
- ¿Qué usuarios están afectados?
- ¿Qué sistemas están afectados?
- ¿Qué evidencias tenemos?
- ¿Qué técnicas ATT&CK podrían estar implicadas?
- ¿Cuál es el nivel de riesgo?
- ¿Qué deberíamos investigar?
- ¿Qué acciones de contención recomendamos?
17. Diseño del Incident Copilot
18. Human-in-the-loop
En sistemas de seguridad críticos no debemos permitir que un modelo tenga libertad absoluta para ejecutar acciones destructivas.
AI recommends
El modelo recomienda bloquear una IP.
Policy validates
El motor de políticas comprueba que la acción está permitida.
Human approves
El analista confirma la acción cuando sea necesario.
SOAR executes
El sistema ejecuta el playbook autorizado.
19. Automatización segura de respuestas
No todas las acciones deben requerir aprobación humana.
| Acción | Automatización |
|---|---|
| Enriquecer IP | Automática |
| Consultar reputación | Automática |
| Agrupar eventos | Automática |
| Crear incidente | Automática |
| Bloquear IP externa | Según política |
| Deshabilitar usuario | Human approval recomendado |
| Apagar servidor | Human approval obligatorio |
20. Laboratorio práctico
Construir un mini AI SOC Analyst
En este laboratorio vamos a crear un prototipo funcional capaz de recibir eventos y generar una investigación estructurada.
Objetivos
- Crear una fuente de eventos.
- Normalizar los eventos.
- Detectar patrones sospechosos.
- Construir contexto.
- Enviar el contexto al modelo.
- Obtener respuesta estructurada.
- Asignar riesgo.
- Generar recomendaciones.
21. Dataset del laboratorio
[
{
"timestamp": "2026-08-29T09:01:13",
"user": "jsmith",
"event": "login_failed",
"source_ip": "185.22.10.45"
},
{
"timestamp": "2026-08-29T09:01:27",
"user": "jsmith",
"event": "login_success",
"source_ip": "185.22.10.45"
},
{
"timestamp": "2026-08-29T09:03:11",
"user": "jsmith",
"event": "privilege_escalation",
"target": "domain_admin"
},
{
"timestamp": "2026-08-29T09:04:22",
"user": "jsmith",
"event": "ldap_query",
"target": "domain"
},
{
"timestamp": "2026-08-29T09:06:33",
"user": "jsmith",
"event": "network_share_access",
"target": "finance"
}
]
22. Motor de reglas inicial
Antes de utilizar IA debemos construir una capa determinista.
if failed_logins >= 5:
alert("BRUTE_FORCE_SUSPECTED")
if login_success_after_failures:
alert("POSSIBLE_ACCOUNT_COMPROMISE")
if privilege_escalation:
alert("PRIVILEGE_ESCALATION")
if ldap_queries > threshold:
alert("POSSIBLE_RECONNAISSANCE")
Posteriormente podemos correlacionar las alertas.
BRUTE_FORCE
+
SUCCESSFUL_LOGIN
+
PRIVILEGE_ESCALATION
+
LDAP_RECON
=
HIGH_RISK_INCIDENT
23. Correlación temporal
El tiempo es una de las variables más importantes de una investigación.
No basta con saber que determinados eventos ocurrieron. Necesitamos conocer su secuencia.
09:01:13 Failed login 09:01:18 Failed login 09:01:22 Failed login 09:01:27 Successful login 09:03:11 Privilege escalation 09:04:22 LDAP enumeration 09:06:33 Finance share access
¿Qué evento cambia la interpretación del resto?
El login exitoso inmediatamente después de múltiples fallos convierte los eventos anteriores en una señal mucho más relevante.
24. Risk Scoring
Podemos crear inicialmente un modelo sencillo de puntuación.
risk_score =
authentication_anomaly
+ privilege_change
+ reconnaissance
+ sensitive_resource_access
+ threat_intelligence
Por ejemplo:
Authentication anomaly = 20 Privilege escalation = 30 LDAP reconnaissance = 20 Sensitive resource access = 20 Suspicious IP = 10 TOTAL = 100
El incidente debe escalarse inmediatamente.
25. ¿Por qué no utilizar solamente un LLM?
Esta es una de las preguntas fundamentales del módulo.
Hallucination
El modelo puede generar conclusiones no soportadas por evidencias.
Context Window
Un SOC puede producir millones de eventos.
Cost
Analizar cada log mediante un LLM sería económicamente ineficiente.
Latency
Algunas decisiones deben tomarse en milisegundos.
Explainability
Debemos poder justificar por qué se generó una alerta.
26. Arquitectura híbrida
La arquitectura más robusta combina diferentes mecanismos.
RULES │ ├── known attack │ ▼ DETECTION ENGINE ML │ ├── anomalous behavior │ ▼ ANOMALY ENGINE GRAPH │ ├── relationships │ ▼ CORRELATION ENGINE LLM │ ├── interpretation ├── investigation └── explanation │ ▼ AI SOC ANALYST
27. Ejercicio de razonamiento
Un usuario realiza 50 intentos fallidos de login. Posteriormente consigue autenticarse correctamente. ¿Debemos considerar automáticamente que la cuenta está comprometida?
No.
Es una señal fuerte, pero todavía necesitamos contexto: ubicación, dispositivo, MFA, comportamiento histórico, reputación de la IP, horario, aplicación utilizada, posteriores acciones y otros indicadores.
La detección debe generar una investigación, no necesariamente una conclusión definitiva.
¿Qué ventaja aporta correlacionar eventos antes de enviarlos al LLM?
Reduce ruido, disminuye costes, mejora el contexto y permite presentar al modelo una secuencia de eventos relacionada en lugar de millones de registros independientes.
¿Por qué un SOC necesita mantener las evidencias originales?
Porque la salida del modelo no constituye por sí misma evidencia forense. Las conclusiones deben poder contrastarse con los eventos originales.
28. Ejercicio avanzado
El sistema detecta un login desde un país nunca utilizado anteriormente por un usuario.
El usuario es administrador.
Cinco minutos después se realizan 4.000 consultas LDAP.
Posteriormente se accede a varios servidores.
¿Qué debería hacer el sistema?
- Crear incidente.
- Correlacionar eventos.
- Consultar Threat Intelligence.
- Consultar historial del usuario.
- Construir timeline.
- Identificar activos afectados.
- Mapear posibles técnicas ATT&CK.
- Solicitar análisis del AI Copilot.
- Calcular riesgo.
- Recomendar contención.
- Solicitar aprobación humana cuando corresponda.
29. Métricas que debemos empezar a medir
| Métrica | Objetivo |
|---|---|
| MTTD | Mean Time To Detect |
| MTTR | Mean Time To Respond |
| False Positive Rate | Reducir ruido |
| Detection Coverage | Medir cobertura de técnicas |
| AI Accuracy | Evaluar calidad de análisis |
| Human Override Rate | Medir cuántas recomendaciones son corregidas |
| Cost per Incident | Controlar eficiencia económica |
30. Proyecto de la Week 07
AI SOC Analyst v1
El alumno deberá diseñar y, cuando sea posible, implementar un primer prototipo de analista SOC aumentado por IA.
Requisitos mínimos
- Ingesta de eventos.
- Modelo normalizado de eventos.
- Motor básico de detección.
- Correlación temporal.
- Risk scoring.
- Generación de contexto.
- Integración con un LLM.
- Respuesta estructurada.
- Identificación de evidencias.
- Recomendaciones de investigación.
- Recomendaciones de respuesta.
- Registro de todas las decisiones.
31. Entregable del alumno
El alumno deberá documentar:
- Arquitectura del sistema.
- Fuentes de datos.
- Modelo de datos.
- Reglas de detección.
- Modelo de correlación.
- Estrategia de utilización de IA.
- Prompt utilizado.
- Estructura JSON de salida.
- Sistema de scoring.
- Controles de seguridad.
- Mecanismo human-in-the-loop.
- Ejemplo de incidente completo.
32. Recursos y referencias
MITRE ATT&CK
Framework fundamental para modelar técnicas y tácticas utilizadas por atacantes.
ATT&CKMITRE D3FEND
Base de conocimiento orientada a técnicas defensivas.
DefenseOCSF
Open Cybersecurity Schema Framework para normalización de eventos.
Data ModelSigma
Framework abierto para detección sobre logs.
DetectionNIST
Referencias para gestión de riesgos, detección y respuesta.
FrameworkOWASP
Especialmente importante para comprender riesgos relacionados con aplicaciones y sistemas de IA.
AI Security33. Preguntas de evaluación
¿Qué diferencia existe entre una regla de detección y un modelo de anomalías?
¿Qué función tiene RAG dentro de un SOC?
¿Por qué debemos conservar las evidencias originales?
¿Debe un LLM poder apagar automáticamente un servidor crítico?
¿Qué arquitectura es preferible: LLM-only o híbrida?
34. Conclusión de la Week 07
En esta semana hemos dado un paso fundamental en la construcción del sistema de ciberseguridad basado en IA.
La IA ya no aparece como una herramienta aislada. Forma parte de una arquitectura completa de detección, investigación y respuesta.
No queremos construir un chatbot que hable sobre ciberseguridad.
Queremos construir un sistema que observe el entorno, detecte comportamientos sospechosos, correlacione evidencias, construya contexto, razone sobre hipótesis y ayude a responder a incidentes de forma controlada y auditable.
Este concepto será la base sobre la que construiremos las siguientes semanas del módulo.