Introducción al SOC:
cómo funciona un Centro de Operaciones de Seguridad
Serie Blue Team | unfantasmaenelsistema.com
Cuando un sistema de seguridad detecta una actividad sospechosa a las 3 de la mañana de un domingo, alguien tiene que estar mirando. Alguien tiene que decidir en menos de 15 minutos si esa alerta es el inicio de un ataque real o un falso positivo más de los cientos que genera el sistema cada día. Alguien tiene que iniciar la cadena de respuesta si es real. Ese alguien trabaja en un SOC.
Un Security Operations Center es la sala de control de la ciberseguridad de una organización. No es una herramienta ni un software: es un equipo de personas con procesos definidos y herramientas especializadas, cuya misión es detectar ataques lo antes posible y contenerlos antes de que causen daño irreversible. Es la diferencia entre detectar una intrusión en horas y detectarla en semanas.
Este artículo explica cómo funciona un SOC por dentro: sus roles, sus herramientas, cómo se gestiona un incidente desde que se dispara la primera alerta hasta que se cierra el caso, y cómo entrar al sector si te interesa este lado de la ciberseguridad.
Qué aprenderás en este artículo
Qué es un SOC y los tres modelos habituales para montarlo (interno, externo, híbrido) · El sistema de tiers y qué hace cada nivel del equipo · El ciclo de vida completo de un incidente, fase a fase · Las herramientas del stack de un SOC moderno y cómo montar una versión de laboratorio gratis · Cómo entrar al sector como analista SOC junior
1. Qué es un SOC y para qué sirve
| Función del SOC | Qué implica |
|---|---|
| Monitorización continua | Vigilancia 24/7 de logs, alertas y tráfico de toda la organización |
| Detección de amenazas | Correlar eventos aparentemente sueltos para identificar patrones de ataque |
| Triaje y priorización | Separar el ruido (falsos positivos) de las alertas que requieren investigación |
| Respuesta a incidentes | Contener, erradicar y recuperar sistemas comprometidos |
| Mejora continua | Ajustar reglas de detección y playbooks con lo aprendido de cada caso |
El dato de dwell time (tiempo de permanencia del atacante) es el que mejor resume la misión del SOC. Según el informe M-Trends 2024 de Mandiant, un atacante permanece de media 24 días en una red antes de ser detectado. Con un SOC maduro, ese tiempo cae por debajo de 5 días. Cada día que un atacante pasa desapercibido es un día más de exfiltración de datos, movimiento lateral y consolidación de accesos. Reducir el dwell time es la métrica más importante que puede optimizar un SOC.
2. Modelos de SOC: interno, externo e híbrido
No todas las organizaciones pueden o necesitan tener un SOC completamente propio. La elección del modelo depende del tamaño de la organización, su presupuesto, el sector en el que opera y el nivel de madurez de seguridad que tiene. Cada modelo tiene ventajas y compromisos.
| Modelo | Ventaja principal | Compromiso principal |
|---|---|---|
| SOC interno | Conocimiento profundo del entorno y control total | Coste elevado: 24×7 requiere varios turnos de analistas |
| MSSP (externo) | Coste predecible, operativo desde el día uno | Menor contexto del negocio, alertas más genéricas |
| SOC híbrido | Combina volumen gestionado fuera con criterio interno | Requiere coordinación clara de responsabilidades entre ambos |
El modelo MSSP (Managed Security Service Provider) es especialmente relevante para empresas medianas españolas que no pueden permitirse un equipo interno de 10-20 analistas operando 24×7. El SOC híbrido es el modelo que más está creciendo: el MSSP gestiona el volumen de alertas de bajo nivel y el equipo interno se centra en los incidentes críticos y el conocimiento profundo del entorno.
3. Los roles del equipo: el sistema de tiers
La estructura de tiers es el modelo organizativo más común en SOCs. Permite escalar incidentes desde el analista de triaje que atiende el volumen de alertas hasta el analista senior que investiga los casos más complejos, con una delegación clara de responsabilidades en cada nivel.
| Tier | Rol | Responsabilidad principal |
|---|---|---|
| Tier 1 | Analista de triaje | Revisa alertas entrantes, descarta falsos positivos, escala lo sospechoso |
| Tier 2 | Analista de investigación | Investiga en profundidad los casos escalados, correlaciona fuentes |
| Tier 3 | Analista senior / threat hunter | Casos complejos, tuning del SIEM, threat hunting proactivo |
| SOC Manager | Coordinación | Gestión del equipo, métricas, comunicación con dirección |
Un detalle importante sobre el Tier 1: es el rol de entrada al sector y también el más demandante en términos de volumen de trabajo. Un analista Tier 1 puede revisar entre 50 y 200 alertas en un turno de 8 horas, dependiendo del tamaño de la organización y la madurez del SIEM. La capacidad de tomar decisiones rápidas con información incompleta es la habilidad más valorada en este rol, más que el conocimiento técnico profundo.
4. El ciclo de vida de un incidente
Todo incidente en un SOC sigue un ciclo de vida estructurado. Tener este proceso documentado y practicado es lo que permite que el equipo responda de forma eficiente bajo presión, cuando el tiempo importa y no hay margen para improvisar.
| Fase | Qué ocurre |
|---|---|
| 1. Detección | Una regla del SIEM o del EDR dispara una alerta |
| 2. Triaje | Tier 1 decide si es falso positivo o requiere investigación |
| 3. Investigación | Se reconstruye el alcance: qué sistemas, qué datos, desde cuándo |
| 4. Contención | Se aísla el sistema afectado para frenar la propagación |
| 5. Erradicación | Se elimina la causa raíz: malware, cuenta comprometida, backdoor |
| 6. Recuperación | Se restauran los sistemas a un estado limpio y verificado |
| 7. Lecciones aprendidas | Post-incident review: qué falló, qué se ajusta para la próxima vez |
La fase de lecciones aprendidas es la más frecuentemente omitida en SOCs bajo presión operativa, y es la que más valor aporta a largo plazo. Cada incidente es una oportunidad para mejorar las reglas de detección, actualizar los playbooks y reducir el tiempo de respuesta en el siguiente incidente similar. Los SOCs que no hacen post-incident reviews tienden a cometer los mismos errores repetidamente.
5. Las herramientas del SOC
Un SOC moderno opera con un stack de herramientas que se complementan entre sí. El SIEM es el centro neurálgico, pero sin EDR, threat intelligence y automatización SOAR, su efectividad está muy limitada.
| Herramienta | Qué hace | Ejemplos |
|---|---|---|
| SIEM | Centraliza y correlaciona logs de toda la organización | Splunk, Microsoft Sentinel, IBM QRadar, Wazuh |
| EDR | Detección y respuesta a nivel de endpoint (equipos, servidores) | CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne |
| SOAR | Automatiza respuestas repetitivas (bloquear IP, aislar host) | Splunk SOAR, Microsoft Sentinel Playbooks, Shuffle |
| Threat Intelligence | Alimenta al SIEM con IOCs y TTPs conocidos | MISP, Recorded Future, AlienVault OTX |
| NDR | Detección a nivel de tráfico de red | Darktrace, Corelight, Zeek |
La tendencia más importante de los últimos años es la convergencia hacia plataformas XDR (Extended Detection and Response): soluciones que integran en una sola plataforma las funciones de SIEM, EDR y NDR, con correlación automática entre eventos de endpoint, red e identidad. Microsoft Sentinel + Defender, CrowdStrike Falcon y Palo Alto Cortex XDR son los ejemplos más representativos.
6. Cómo se tría una alerta
El triaje es el arte de distinguir la señal del ruido. Es el proceso más crítico del SOC y el que define si un ataque real se detecta o pasa desapercibido. Un buen analista de triaje combina conocimiento técnico, intuición sobre el contexto del entorno y metodología para no pasar nada importante por alto.
| Pregunta de triaje | Qué te dice |
|---|---|
| ¿El activo afectado es crítico? | Determina la urgencia real, no solo la severidad técnica de la alerta |
| ¿Hay un patrón de comportamiento inusual? | Un login legítimo a las 3 AM desde un país nuevo no es lo mismo que uno habitual |
| ¿La alerta coincide con actividad programada? | Un escaneo de vulnerabilidades interno puede disparar falsos positivos |
| ¿Hay más alertas relacionadas en la misma ventana de tiempo? | Varias alertas de bajo nivel correlacionadas pueden ser un ataque real |
| ¿El indicador aparece en threat intelligence conocida? | Una IP o hash ya catalogado como malicioso eleva la prioridad de inmediato |
La paradoja del SOC: si las reglas de detección son demasiado sensibles, generan tantos falsos positivos que los analistas desarrollan fatiga de alertas y empiezan a cerrar alertas sin investigarlas. Si son demasiado específicas, los atacantes que usan técnicas ligeramente diferentes pasan desapercibidos. El tuning continuo del SIEM —ajustar umbrales, añadir excepciones para comportamiento legítimo conocido, actualizar reglas con nuevas TTPs— es uno de los trabajos más importantes del Tier 3.
7. Métricas: cómo medir la efectividad del SOC
| Métrica | Qué mide |
|---|---|
| MTTD (Mean Time To Detect) | Tiempo medio entre que ocurre un ataque y se detecta |
| MTTR (Mean Time To Respond) | Tiempo medio entre detectar un incidente y contenerlo |
| Dwell time | Tiempo total que el atacante permanece activo sin ser detectado |
| Cobertura MITRE ATT&CK | % de técnicas del framework con al menos una regla de detección activa |
| Ratio de falsos positivos | % de alertas cerradas como no accionables sobre el total |
La métrica más reveladora no es el MTTD ni el MTTR en sí, sino su evolución a lo largo del tiempo. Un SOC que reduce su MTTD de 24 horas a 2 horas en seis meses está mejorando en la dirección correcta. Un SOC con MTTD estancado en 48 horas durante años tiene un problema sistémico que ningún nuevo producto de seguridad va a resolver por sí solo.
La cobertura MITRE ATT&CK es una métrica cada vez más usada: ¿qué porcentaje de las tácticas y técnicas del framework tienen alguna regla de detección activa en el SIEM? Un SOC con 30% de cobertura ATT&CK es inherentemente ciego a las técnicas en el 70% restante. Este análisis de gaps es uno de los ejercicios más valiosos que puede hacer un equipo de Tier 3.
8. Herramientas open source para montar un SOC de laboratorio
No hace falta un presupuesto de empresa Fortune 500 para practicar habilidades de SOC. Existe un ecosistema completo de herramientas open source que permite montar un laboratorio funcional en el entorno de VirtualBox que ya describimos en artículos anteriores.
| Herramienta open source | Función | Equivalente comercial |
|---|---|---|
| Wazuh | SIEM + agente de monitorización, integración nativa con MITRE ATT&CK | Splunk, QRadar |
| TheHive | Gestión de casos e incidentes (case management) | ServiceNow SecOps, Jira Service Management |
| MISP | Plataforma de threat intelligence compartida | Recorded Future, Anomali |
| Suricata / Zeek | Detección de intrusiones a nivel de red (NIDS) | Darktrace, Corelight |
| Velociraptor | Recolección forense y respuesta a incidentes en endpoints | CrowdStrike Falcon Forensics |
La combinación más recomendada para empezar es Wazuh + TheHive: Wazuh como agente de monitorización en las VMs del laboratorio y como SIEM básico, y TheHive para gestionar los incidentes que detectes. Wazuh tiene integración nativa con MITRE ATT&CK y un dashboard de cobertura que muestra exactamente qué técnicas tienes cubiertas.
9. Cómo entrar al sector como analista SOC junior
| Paso | Qué hacer |
|---|---|
| 1. Fundamentos | Redes (TCP/IP, DNS, HTTP), sistemas operativos Windows y Linux, conceptos básicos de seguridad |
| 2. Práctica gratuita | TryHackMe (ruta SOC Analyst), LetsDefend, Blue Team Labs Online |
| 3. Certificación de entrada | CompTIA Security+ (más reconocida por RRHH) o BTL1 (más valorada técnicamente) |
| 4. Laboratorio propio | Montar Wazuh + TheHive en VirtualBox y documentar casos investigados |
| 5. Aplicar | Vacantes de Analista SOC Tier 1 / Security Analyst Junior |
Una reflexión sobre las certificaciones: CompTIA Security+ es la más reconocida por los departamentos de RRHH que no tienen criterio técnico propio, pero para alguien que quiere demostrar habilidades prácticas, BTL1 (Blue Team Labs Level 1) es más valorada por los técnicos que hacen las entrevistas. Es completamente práctica, relativamente asequible y demuestra que sabes hacer triaje, análisis forense básico y respuesta a incidentes en un entorno simulado real. TryHackMe tiene una ruta SOC Analyst que cubre exactamente las herramientas y técnicas de este artículo.
Conclusión
El SOC es el corazón operativo de la ciberseguridad defensiva. No es la parte más glamurosa del sector —detectar un ataque no tiene el mismo atractivo narrativo que ejecutarlo— pero es la que más impacto real tiene en la postura de seguridad de una organización. Un SOC bien calibrado reduce el dwell time de semanas a horas, contiene incidentes antes de que se conviertan en desastres y genera inteligencia que mejora las defensas continuamente.
Los siguientes artículos de la serie Blue Team bajan al nivel técnico de las herramientas y técnicas que usa un SOC: análisis forense en Windows para reconstruir lo que ocurrió en un sistema comprometido, threat hunting para buscar proactivamente atacantes que evadieron la detección automática, y cómo montar un SIEM desde cero con Splunk o ELK en el laboratorio de VirtualBox.