IA en el SOC:
dónde ayuda de verdad y dónde es humo
Serie Blue Team | unfantasmaenelsistema.com
Desde 2024 no hay feria de seguridad, folleto de fabricante ni nota de prensa que no prometa un «SOC autónomo»: una inteligencia artificial que investiga, decide y responde sin que un humano toque nada. La realidad de un centro de operaciones de seguridad que funciona es más aburrida y más útil. La IA —tanto el aprendizaje automático clásico como los modelos de lenguaje— ya está haciendo trabajo real en muchos SOC, pero en tareas concretas y bajo supervisión, no sustituyendo al analista.
Este artículo separa lo que aporta valor medible de lo que es marketing, con la vista puesta en un equipo que tiene que decidir si compra una herramienta, la integra o la ignora. La pregunta de fondo no es «¿la IA sirve para el SOC?» sino «¿para qué tarea, con qué riesgo y quién sigue siendo responsable del resultado?».
Qué aprenderás en este artículo
En qué tareas del SOC la IA aporta valor real y medible · Dónde falla de forma peligrosa y por qué · La diferencia entre ML clásico y LLM aplicados a detección · Qué riesgos de privacidad introduce enviar telemetría a servicios externos · Cómo evaluar una herramienta con IA antes de confiar en ella
1. El trabajo real de un SOC, y dónde duele
Para saber dónde encaja la IA hay que recordar qué hace un SOC un día normal. No es perseguir hackers en pantalla verde: es procesar un flujo constante de alertas, la mayoría irrelevantes, buscando las pocas que importan antes de que sea tarde.
- Triaje: mirar cada alerta y decidir si es falso positivo, ruido conocido o algo que investigar
- Enriquecimiento: reunir contexto —¿de quién es esta IP?, ¿este proceso es normal en este equipo?, ¿este usuario suele conectarse desde aquí?—
- Investigación: reconstruir qué pasó, en qué orden y con qué alcance
- Respuesta: contener (aislar un equipo, bloquear una cuenta), erradicar y recuperar
- Documentación: dejar por escrito qué se vio y qué se hizo, para el informe y para la próxima vez
- Mejora continua: convertir cada incidente en una regla de detección nueva o mejor
Los dos dolores crónicos son el volumen (más alertas de las que el equipo puede mirar con calma) y la fatiga de alertas (tanto falso positivo que el de verdad se cuela sin que nadie lo mire). La IA es interesante justo donde ataca esos dos problemas sin crear otros peores.
2. Donde la IA aporta valor real
Todas estas tareas tienen algo en común: el error se detecta rápido, lo revisa un humano antes de que tenga consecuencias, y ahorran tiempo repetitivo sin tomar la decisión final.
| Tarea | Qué aporta la IA | Por qué el riesgo es asumible |
|---|---|---|
| Resumen de alertas e incidentes | Convierte 40 eventos correlacionados en un párrafo legible con la línea temporal | El analista tiene los eventos crudos al lado; el resumen es un punto de partida, no la verdad |
| Consultas en lenguaje natural | Traduce ‘procesos que han escrito en Startup esta semana’ a la sintaxis del SIEM | La consulta generada se ve y se ejecuta a mano; un error da resultados raros, no daño |
| Enriquecimiento de contexto | Reúne reputación de IP, geolocalización, histórico del usuario y del activo en una ficha | Son datos objetivos y verificables; acelera, no decide |
| Deduplicación y agrupación | Junta 300 alertas del mismo origen en un solo caso | Peor caso: dos casos que eran uno, o uno que eran dos; se reabre y ya |
| Priorización asistida | Ordena la cola por probabilidad de ser real según patrones históricos | Es una sugerencia de orden; nadie cierra una alerta solo porque el modelo la puso abajo |
| Borrador de informe | Redacta la primera versión del parte de incidente a partir de las notas del caso | Lo revisa y firma una persona; ahorra la parte mecánica de escribir |
| Detección de anomalías (ML clásico) | Marca desviaciones de la línea base: volumen, horarios, destinos inusuales | Genera una alerta más para triar, no una acción automática |
El patrón que hace segura la integración
La IA propone y explica; el humano dispone. Cualquier uso en el que el modelo actúe sin revisión sobre algo con efecto (aislar, bloquear, borrar, cerrar un caso) sale de esta zona segura y entra en la siguiente sección
3. Donde la IA falla de forma peligrosa
3.1 Decisiones de contención automática
Aislar un servidor de producción o bloquear la cuenta de un directivo en plena jornada tiene coste real. Un falso positivo que dispara una contención automática es un incidente de disponibilidad que te has autoinfligido. La contención automática puede tener sentido en casos muy acotados y muy fiables (un endpoint de usuario con ransomware confirmado por varios indicadores), pero como política general, con un modelo que a veces alucina, es una mala idea.
3.2 Falsos negativos silenciosos
Un falso positivo hace ruido y se corrige. Un falso negativo no dice nada: la alerta que el modelo clasificó como ruido y nadie volvió a mirar. Si delegas el triaje de la cola en un sistema que cierra alertas por su cuenta, estás creando un agujero que no vas a ver hasta que alguien lo aproveche. La regla prudente: la IA puede bajar la prioridad de una alerta, nunca cerrarla sola.
3.3 Alucinación en investigación e informes
Un modelo de lenguaje rellena huecos con lo que suena plausible. En un informe de incidente eso se traduce en una IP inventada, un Event ID que no existe, una cronología con el orden cambiado o una conclusión que los datos no sostienen. Si el informe va a un cliente, a un regulador o a un juzgado, cada afirmación tiene que ser trazable a una evidencia concreta.
3.4 Sesgo hacia lo conocido
Los modelos entrenados con incidentes pasados reconocen bien lo que se parece a lo de siempre y peor lo genuinamente nuevo. El atacante que innova es precisamente el que más te interesa detectar, y es el que peor se le da a un sistema estadístico.
La responsabilidad no se delega
Si un analista aprueba una acción que sugirió la IA, la decisión es del analista. Si el SOC presta servicio a terceros, el proveedor responde del resultado ante su cliente aunque una herramienta se equivocara. ‘Lo dijo el modelo’ no es una explicación válida en una revisión post-incidente ni en una auditoría
4. ML clásico y LLM no son lo mismo
Se mezclan bajo la etiqueta «IA», pero en un SOC hacen cosas distintas y fallan de forma distinta.
| ML clásico (detección de anomalías, clasificación) | LLM (modelos de lenguaje) | |
|---|---|---|
| Para qué sirve bien | Encontrar desviaciones estadísticas en grandes volúmenes de eventos | Resumir, traducir consultas, redactar, explicar en lenguaje natural |
| Cómo falla | Falsos positivos por cambios legítimos de comportamiento; deriva del modelo con el tiempo | Alucinación: inventa datos con tono seguro; sensible a cómo se formula la petición |
| Explicabilidad | Variable; algunos modelos permiten ver qué features pesaron | Baja; explica su razonamiento pero esa explicación también puede ser inventada |
| Necesita reentreno | Sí, con datos de tu entorno y de forma periódica | No lo entrenas tú; ajustas el prompt y el contexto que le das |
| Riesgo de datos | Los datos se quedan normalmente en tu infraestructura | Si el servicio es externo, la telemetría sale de tu organización |
5. El problema de la telemetría en servicios externos
Muchas herramientas con LLM procesan las peticiones en la nube del proveedor. Eso significa que logs, nombres de equipos, cuentas de usuario, rutas de ficheros, contenido de correos y a veces muestras de datos internos salen de tu perímetro para que el modelo los procese.
- Cumplimiento: si esos datos incluyen información personal, la transferencia a un tercero (y posiblemente fuera del Espacio Económico Europeo) tiene que estar cubierta por el RGPD: base jurídica, contrato de encargo de tratamiento, garantías de transferencia internacional
- Confidencialidad: la telemetría de seguridad es un mapa de tu infraestructura y de tus incidentes; concentrarla en un proveedor externo es un riesgo que hay que evaluar, no asumir
- Retención y entrenamiento: comprueba en el contrato si el proveedor conserva las peticiones y si las usa para entrenar sus modelos; para uso empresarial suele poder desactivarse, pero hay que exigirlo por escrito
- Alternativa: modelos desplegados en tu propia infraestructura o en un tenant aislado del proveedor, a cambio de más coste y mantenimiento
Antes de conectar una herramienta de IA a tu telemetría
Revisa qué datos salen exactamente y hacia dónde, con el equipo legal o el DPO · Exige contrato de encargo de tratamiento y cláusula de no uso para entrenamiento · Prohíbe subir a la herramienta datos de investigaciones con implicación de personas concretas salvo que el marco legal lo cubra · Trata la propia herramienta como un activo crítico: su compromiso expone tu operación de seguridad
6. Cómo evaluar una herramienta con IA
El fabricante te va a enseñar los aciertos. Tu trabajo en la prueba de concepto es buscar los fallos y medir el coste de convivir con ellos.
- «Enséñame los falsos positivos»: pide ver los casos en que se equivocó, no solo los que acertó. Un proveedor que no los tiene a mano es una bandera roja.
- Pruébala con tus datos, no con la demo: el rendimiento en el entorno del fabricante no predice el tuyo.
- Mide contra tu línea base actual: ¿cuántas alertas triáis hoy por analista y hora?, ¿cuántas con la herramienta?, ¿la calidad de las decisiones sube o baja?
- Comprueba la explicabilidad: ¿puedes saber por qué marcó o descartó algo?, ¿esa explicación es verificable contra los datos crudos?
- Revisa qué pasa si se cae o se equivoca: ¿el SOC sigue funcionando sin ella?, ¿o os habéis vuelto dependientes de una caja negra?
- Deja rastro de todo: cada sugerencia de la IA y cada decisión humana sobre ella debe quedar registrada para la revisión posterior
Conclusión
La IA en el SOC es a la vez menos y más de lo que promete el marketing. Menos: no hay SOC autónomo, y delegar contención o cierre de alertas en un sistema que alucina es cambiar un problema de volumen por uno de agujeros invisibles. Más: en resumen de incidentes, consultas en lenguaje natural, enriquecimiento, deduplicación y borradores de informe ya está ahorrando horas reales a equipos que la usan bien.
La línea que separa el uso sensato del temerario es siempre la misma: la IA propone y explica, el humano decide y responde. Todo lo que respete esa línea, con los datos bajo control y una forma de auditar cada paso, suma. Todo lo que la cruce —acción sin revisión, telemetría sensible fuera sin cobertura legal, dependencia de una caja negra— es deuda que se paga en el peor momento.
Referencias
MITRE ATT&CK y el proyecto ATLAS (amenazas específicas a sistemas de IA) · NIST AI Risk Management Framework (AI RMF 1.0) · ENISA — Artificial Intelligence and Cybersecurity · OWASP Top 10 for LLM Applications, para el lado de construir con LLM de forma segura · Nuestros artículos sobre threat hunting, reglas Sigma y Wazuh, para el trabajo de detección sin IA
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)