Qué es un SOC: funciones, herramientas y trabajo de un analista
Descubre qué hace un SOC, cómo se investiga una alerta, qué herramientas utiliza y qué conocimientos necesita un analista de ciberseguridad.
Un SOC —Security Operations Center o centro de operaciones de seguridad— es la función que vigila, analiza y coordina la respuesta ante señales de ciberseguridad. Su trabajo no consiste en contemplar pantallas llenas de alertas: consiste en convertir datos dispersos en decisiones con contexto.
Puede ser un equipo interno, un servicio externalizado o un modelo híbrido. Lo importante no es la sala física, sino que existan personas, procesos y tecnología capaces de detectar actividad anómala, determinar su alcance y actuar dentro de un tiempo razonable.
Qué hace realmente un SOC
Un SOC mantiene observación continuada sobre los activos que la organización necesita proteger. Recibe registros y alertas, los relaciona con información del entorno, investiga aquello que merece atención y coordina la contención cuando confirma un incidente.
La guía de ENISA para establecer un SOC o CSIRT insiste en una idea útil: la capacidad debe construirse alrededor de objetivos, servicios, procesos y mejora continua. Comprar una plataforma no crea por sí solo una operación de seguridad.
Entre sus funciones habituales aparecen:
- mantener visibilidad sobre sistemas, identidades, red y servicios cloud;
- recibir y priorizar alertas;
- investigar comportamientos sospechosos;
- documentar una línea temporal y conservar evidencias;
- coordinar la contención, erradicación y recuperación;
- comunicar el impacto a responsables técnicos y de negocio;
- mejorar reglas, procedimientos y cobertura tras cada caso.
De dónde obtiene información
Para decidir bien, el SOC necesita datos fiables. Las fuentes dependen del entorno, pero suelen incluir:
- inicios de sesión y cambios en el directorio de identidades;
- eventos de equipos y servidores;
- telemetría de EDR o protección de endpoints;
- registros de firewall, DNS, proxy y correo;
- actividad de aplicaciones y servicios cloud;
- alertas de vulnerabilidades y cambios de configuración;
- información de amenazas relevante para la organización.
Más datos no significan automáticamente más seguridad. Una fuente debe tener propósito, calidad, propietario y un periodo de conservación adecuado. Acumular millones de eventos sin casos de uso solo aumenta coste y ruido.
El ciclo de una alerta
1. Detección y contexto
Una regla o herramienta señala algo: varios fallos de autenticación, una ejecución poco habitual o una conexión con un destino sospechoso. El analista comprueba qué activo y qué usuario están implicados, su criticidad y qué ocurrió alrededor.
2. Triage
El triage separa falsos positivos, actividad legítima y situaciones que requieren investigación. La prioridad combina probabilidad, impacto y urgencia; no depende únicamente de una severidad asignada por la herramienta.
3. Investigación
El analista formula hipótesis y busca evidencias. Reconstruye una línea temporal, consulta otras fuentes y determina si la actividad se limita a un equipo o forma parte de un movimiento más amplio.
4. Contención y escalado
Si existe riesgo real, el SOC puede aislar un dispositivo, bloquear una credencial, impedir una comunicación o solicitar una acción a otro equipo. Cada medida debe estar autorizada y ser proporcional: contener deprisa sin destruir evidencias ni interrumpir innecesariamente el negocio.
5. Cierre y aprendizaje
El caso se documenta con evidencias, decisiones y resultado. Si la alerta era falsa, se ajusta la detección. Si era un incidente, se revisan causas, controles y oportunidades de prevención.
Qué hace un analista SOC
El analista combina razonamiento técnico, método y comunicación. Revisa alertas, consulta telemetría, plantea hipótesis, registra lo comprobado y sabe cuándo escalar. No necesita conocer de memoria todas las amenazas; necesita distinguir hechos de suposiciones y avanzar de forma reproducible.
Muchas organizaciones hablan de niveles o tiers, pero no existe una división universal:
- Nivel inicial: monitorización, triage, enriquecimiento y aplicación de procedimientos.
- Nivel intermedio: investigaciones profundas, correlación, contención y mejora de detecciones.
- Nivel avanzado: threat hunting, análisis especializado, ingeniería de detección y apoyo a incidentes complejos.
Un equipo pequeño puede repartir esas funciones de otra manera. El nombre importa menos que la claridad de responsabilidades y del escalado.
SIEM, EDR y otras herramientas
Un SIEM centraliza y correlaciona eventos. Un EDR aporta visibilidad y capacidad de respuesta en los equipos. A ellos pueden sumarse plataformas de casos, automatización, inteligencia de amenazas y herramientas de análisis de red.
Ninguna sustituye al criterio. Una regla sin contexto genera ruido; una automatización mal diseñada puede bloquear actividad legítima; una alerta sin procedimiento puede quedarse abierta. La tecnología debe apoyar casos de uso concretos.
Ejemplo: inicio de sesión imposible
Una identidad inicia sesión desde España y pocos minutos después desde una ubicación incompatible. El SOC no debería concluir automáticamente que existe una intrusión. Comprueba si hay VPN corporativa, si el segundo acceso procede de infraestructura cloud, qué dispositivo se utilizó, si hubo MFA, qué aplicaciones se abrieron y si se realizaron cambios sensibles.
Si aparecen un dispositivo desconocido, una aprobación MFA inesperada y reglas nuevas en el correo, la hipótesis de compromiso gana fuerza. El equipo puede revocar sesiones, bloquear temporalmente la cuenta, conservar registros y coordinar el restablecimiento seguro.
Métricas que sí ayudan
- tiempo hasta detectar y hasta contener;
- alertas pendientes y antigüedad de los casos;
- porcentaje de falsos positivos por caso de uso;
- cobertura de activos y fuentes críticas;
- incidentes repetidos por una causa no corregida;
- calidad de la documentación y de los traspasos.
Contar alertas cerradas puede premiar la velocidad equivocada. Una métrica debe ayudar a mejorar el servicio, no a ocultar problemas.
Qué debe aprender un analista junior
- fundamentos de redes, sistemas Windows y Linux;
- identidades, permisos y autenticación;
- lectura de registros y construcción de líneas temporales;
- técnicas habituales de phishing, malware y abuso de credenciales;
- principios de respuesta a incidentes y preservación de evidencias;
- redacción clara de hallazgos, hipótesis y acciones.
El objetivo inicial no es usar todas las herramientas, sino aprender un proceso de análisis que pueda repetirse y explicarse.
Preguntas frecuentes
¿Un SOC trabaja las 24 horas?
No siempre. La cobertura debe responder al riesgo y a las necesidades del negocio. Puede ser continua, ampliada, bajo guardia o compartida con un proveedor.
¿SOC y CSIRT son lo mismo?
Pueden colaborar o integrarse, pero el SOC suele centrarse en monitorización, detección y análisis continuo, mientras que un CSIRT se orienta a coordinar la respuesta ante incidentes. La estructura varía según la organización.
¿Hace falta saber programar?
No para comenzar, aunque automatizar consultas y comprender scripts resulta cada vez más útil. Pesan más la base técnica, la curiosidad y la capacidad de documentar.
Una alerta no es un incidente hasta que se investiga con contexto. Aprende a construir hipótesis, líneas temporales y decisiones defendibles.