Un SOC (Security Operations Center, o centro de operaciones de seguridad) es la estructura de personas, procesos y tecnología que vigila el entorno de una empresa de forma continua para detectar ataques y responder a ellos a tiempo. Esta guía explica qué hace un SOC, quién trabaja en él, qué herramientas usa, cómo se puede contratar y cómo saber si su empresa necesita uno.
Qué es un SOC, en una frase
Un SOC es el lugar, físico o no, donde los eventos de seguridad se convierten en decisiones. Firewalls, servidores, estaciones de trabajo, nube y sistemas de identidad generan registros todo el tiempo. El SOC recoge esos registros, identifica lo que indica un ataque y coordina la respuesta antes de que el problema crezca.
En el NIST Cybersecurity Framework 2.0, el trabajo del SOC se concentra en dos de las seis funciones: Detect (encontrar y analizar posibles ataques y compromisos) y Respond (actuar sobre un incidente detectado).
Qué hace un SOC en el día a día
La rutina sigue un ciclo que empieza en el dato y termina en una acción, y luego vuelve al inicio con lo aprendido:
- Monitoreo. Recibir continuamente eventos de las fuentes del entorno y asegurarse de que sigan enviando datos. Una fuente que dejó de enviar logs es un punto ciego.
- Detección. Aplicar reglas y análisis que convierten eventos en alertas: un inicio de sesión imposible, un proceso extraño en un servidor, un volumen anormal de datos saliendo.
- Triaje. Decidir rápidamente si la alerta es real, cuál es su gravedad y quién debe saberlo.
- Investigación. Reconstruir lo ocurrido: por dónde entró el atacante, qué cuentas y máquinas tocó, hasta dónde llegó.
- Respuesta. Contener (aislar una máquina, bloquear una cuenta), activar a los responsables y acompañar hasta el cierre, según el plan de respuesta a incidentes.
- Threat hunting. Buscar activamente señales de compromiso que todavía no generaron alerta, a partir de hipótesis sobre cómo actuaría un adversario.
- Threat intelligence. Incorporar información sobre campañas, técnicas e indicadores en uso a las reglas de detección y al hunting.
MITRE ATT&CK, base pública de tácticas y técnicas observadas en ataques reales, es el lenguaje común de este ciclo: las detecciones se mapean contra él y las brechas quedan a la vista. La diferencia entre un SOC que solo reenvía alertas y uno que reduce el riesgo está detallada en SOC tradicional vs. SOC moderno.
Personas y roles
Un SOC suele organizarse en niveles, con nombres que varían entre empresas:
- Analista N1. Primera línea. Atiende la cola de alertas, hace el triaje inicial, descarta el ruido y escala lo que es real.
- Analista N2. Recibe los casos escalados, investiga con más profundidad, correlaciona fuentes y conduce la contención.
- Analista N3. Especialista para incidentes complejos: análisis forense, malware, ataques en curso. Suele liderar la respuesta en los casos graves.
- Ingeniería de detección. Crea, prueba y ajusta las reglas de detección y los playbooks. Es quien reduce los falsos positivos y cierra brechas de cobertura.
- Threat hunter. Conduce las búsquedas proactivas y convierte lo que encuentra en nuevas detecciones.
- Gestor del SOC. Responde por los procesos, los turnos, los indicadores y la comunicación con la dirección y las áreas de negocio.
Como los ataques no respetan el horario laboral, estos roles deben estar cubiertos en turnos 24×7, uno de los principales costos de un SOC. La relación del SOC (Blue Team) con los equipos que simulan ataques está en Red Team, Blue Team y Purple Team.
Tecnologías y cómo se conectan
Las herramientas de un SOC forman una cadena, no una lista de compras:
- EDR/XDR. El EDR monitorea estaciones y servidores y permite actuar sobre ellos, por ejemplo aislando una máquina. El XDR amplía esa visión a otras capas (identidad, correo, nube, red) en una misma plataforma.
- NDR. Analiza el tráfico de red para ver lo que no pasa por un endpoint monitoreado, como el movimiento lateral y la comunicación con servidores de comando y control.
- SIEM. Centraliza y correlaciona los eventos de todas las fuentes, guarda el historial para la investigación y dispara las alertas.
- SOAR. Automatiza las etapas repetitivas mediante playbooks: enriquecer la alerta, consultar reputación, abrir un ticket, ejecutar la contención aprobada.
El flujo típico es: EDR, NDR y demás fuentes alimentan el SIEM; el SIEM correlaciona y alerta; el SOAR enriquece y ejecuta; el analista decide lo que tiene consecuencias. Para elegir la plataforma central, vea cómo elegir un SIEM; para automatizar con seguridad, el checklist del CISO para SOAR y playbooks; y para el papel de la inteligencia artificial, IA en el SOC: lo que funciona.
Modelos: interno, tercerizado o híbrido
La guía del NCSC británico sobre la construcción de un SOC trata las tres opciones:
- Interno. La empresa contrata el equipo, compra las herramientas y opera todo. Da control total y conocimiento profundo del entorno, pero exige personal por turnos, presupuesto continuo y tiempo para madurar.
- Tercerizado. Un proveedor entrega la operación, ya sea como MDR (enfocado en detectar y contener amenazas) o como SOC as a Service (la operación completa, con indicadores y gobernanza).
- Híbrido. Combinaciones como un equipo interno en horario laboral y el proveedor fuera de él, o el proveedor en el triaje y la empresa en las decisiones de mayor impacto.
En cualquier modelo, tercerizar la ejecución no terceriza la responsabilidad por el riesgo. La comparación detallada, con lo que cada modelo deja dentro de la empresa, está en SIEM como servicio, MDR o SOC as a Service.
Indicadores: cómo medir un SOC
Los dos indicadores centrales miden tiempo, porque es el tiempo lo que le da espacio al atacante para actuar:
- MTTD (tiempo medio de detección). Desde el inicio de la actividad maliciosa hasta la detección.
- MTTR (tiempo medio de respuesta). Desde la detección hasta la contención o resolución.
Sumados, muestran cuánto tiempo estuvo libre el intruso en el entorno. Deben ir acompañados de la tasa de falsos positivos y de la cobertura de fuentes y técnicas de ATT&CK. Para saber en qué etapa está la operación y qué priorizar, vea madurez de SOC: cómo evaluarla.
Cuidado con el promedio. Un MTTR bajo puede ocultar pocos incidentes graves resueltos con lentitud. Pida los indicadores separados por severidad y siga la tendencia a lo largo de los meses, no un número aislado.
¿Su empresa necesita un SOC?
La pregunta más útil no es "¿necesito un SOC?", sino "¿quién ve y responde a un ataque a las tres de la mañana de un domingo?". Algunas señales de que la respuesta actual no alcanza:
- Nadie sigue las alertas fuera del horario laboral. Las herramientas generan avisos que solo se leen el siguiente día hábil.
- Hay logs, pero no hay análisis. Los eventos se guardan y solo se consultan después de que algo sale mal.
- No existe un proceso de respuesta definido. No está claro quién puede aislar una máquina, quién avisa a la dirección y quién habla con clientes y reguladores.
- La empresa está regulada o guarda datos sensibles. Sectores como el financiero, y cualquier organización sujeta a la LGPD brasileña, necesitan demostrar capacidad para detectar y tratar incidentes.
- El equipo de TI acumula la seguridad. Quien mantiene los sistemas funcionando también debería investigar ataques.
Si aparecen dos o más de estas señales, conviene evaluar qué modelo cubre la brecha. Para la mayoría de las empresas medianas, montar turnos 24×7 internamente es costoso y lento, y un SOC 24×7 con MDR tercerizado o híbrido suele ser el camino más viable.
Preguntas frecuentes
¿Cuál es la diferencia entre SOC y SIEM?
El SIEM es una herramienta que recoge y correlaciona eventos. El SOC es la operación completa: las personas que analizan las alertas, los procesos de triaje y respuesta y las herramientas, entre ellas el SIEM. Tener un SIEM sin nadie que lo siga no es tener un SOC.
¿Cuál es la diferencia entre SOC y MDR?
El SOC es la estructura de detección y respuesta, interna o contratada. El MDR es un modelo de servicio gestionado enfocado en detectar, investigar y contener amenazas, que puede ser una de las entregas de un SOC tercerizado.
¿Un SOC reemplaza al equipo de TI?
No. El SOC detecta, investiga y contiene. La remediación de fondo, como corregir la falla o reconstruir un servidor, y las decisiones de negocio durante un incidente siguen en manos de la empresa, con el apoyo del SOC.
Fuentes consultadas: NIST Cybersecurity Framework 2.0 (CSWP 29), funciones Detect y Respond; NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025); NCSC (Reino Unido), Building a Security Operations Centre; MITRE ATT&CK. Los nombres de roles y niveles varían entre organizaciones. Este artículo es educativo y no sustituye una evaluación técnica de su entorno.