Comprar un SIEM no crea un SOC. Un centro de monitoreo de seguridad requiere un mapa de activos críticos y de amenazas, telemetría de calidad, escenarios que ayuden a detectar amenazas, analistas, reglamentos y capacidades para reaccionar ante incidentes. Sin esa combinación, el SIEM se convierte en un costoso almacén de registros y en una cola de alertas.
La lógica de implementación es sencilla: activos y amenazas, fuentes de eventos, SIEM, control de dispositivos finales y de la red, escenarios de detección, equipo, respuesta, automatización y solo entonces 24/7. GOST R 59547-2021 describe el monitoreo de seguridad, pero no regula cómo responder a los incidentes. Cómo gestionar los incidentes lo aclara la serie GOST R 59709–59712-2022.
Arquitectura del SOC: desde los activos hasta la respuesta
El primer nivel del SOC lo constituyen los activos. La empresa debe conocer los servidores críticos, las estaciones de trabajo, las cuentas, los recursos en la nube y los sistemas de negocio. Para cada activo se define un responsable, su criticidad y las amenazas principales. De lo contrario, el SOC vigilará con la misma atención un servidor de pruebas y un sistema que paralizaría el negocio si se detuviera.
A continuación se conectan las fuentes de eventos. Al SIEM suelen enviarse los registros de autenticación, directorios de usuarios, cortafuegos, acceso remoto, servidores, servicios en la nube, correo, EDR y aplicaciones clave. No conviene recopilarlo todo. Cada flujo debe participar en un escenario que ayude a detectar amenazas o servir para investigar un incidente.
Antes de comprar un SIEM, conviene medir el flujo de eventos. A menudo se usa EPS, es decir, el número de eventos por segundo, aunque el proveedor también puede tener en cuenta el volumen de datos diario u otros parámetros. Por ejemplo, la versión comercial de RuSIEM se licencia por EPS. En la documentación de MaxPatrol SIEM, el rendimiento de las configuraciones también está vinculado al flujo de eventos. Es mejor solicitar la tarifa mínima concreta al proveedor para la propia carga, y no trasladar cifras de otro proyecto.
El SIEM se complementa con EDR, que controla los dispositivos finales, y con NDR, que analiza la red. Datos adicionales aportan las soluciones de protección de correo, las herramientas de gestión de vulnerabilidades y la infraestructura en la nube. El conjunto de herramientas se selecciona en función de las amenazas reales, no por la cantidad de productos.
Tras conectar las fuentes, se crean escenarios que ayudan a detectar amenazas. Es preferible afinar con calidad unas pocas decenas de situaciones peligrosas que cargar cientos de reglas y generar un flujo de falsos positivos. Las prioridades suelen incluir la compromisión de cuentas privilegiadas, accesos inusuales, procesos sospechosos, movimiento lateral y grandes transferencias de datos.
Cada escenario debe concluir con una acción clara. El analista debe saber cómo verificar una alerta, cuándo escalar un caso y quién tiene la autoridad para bloquear una cuenta o aislar un equipo. SOAR se integra después de depurar el proceso manual; de lo contrario, la automatización solo acelerará un error.
La madurez del SOC se evalúa mejor por resultados. Son útiles el tiempo medio de detección MTTD, el tiempo medio de respuesta MTTR, la proporción de falsos positivos FPR y la carga sobre el analista. El aumento del número de registros y de reglas por sí solo no indica una mejora de la calidad.
Cuántas personas se necesitan realmente para un SOC 24/7 y cuánto cuesta
Un puesto operativo 24 horas requiere 168 horas de trabajo a la semana. Con una jornada de 40 horas, el mínimo matemático es de 4,2 puestos. No se consideran vacaciones, bajas, formación, rotación ni traspaso de turnos. Por eso, para un puesto permanente L1 es razonable planificar 5–6 analistas.
| Rol | Composición | Comentario |
|---|---|---|
| L1 | 5–6 personas | Un puesto 24/7 con reserva |
| L2 | 2–5 personas | 2–3 en caso de raras escaladas nocturnas, 4–5 para una rotación sostenida |
| Ingeniero SIEM | 1–2 personas | Fuentes, reglas, rendimiento, almacenamiento |
| Jefe del SOC | 1 persona | Prioridades, procesos y métricas |
Dos o tres especialistas L2 son suficientes solo si las llamadas nocturnas son raras y L1 cierra por sí mismo la mayoría de eventos. Si de noche se investigan casos complejos con regularidad, la segunda línea no será suficiente para una rotación completa. Entonces se necesitan 4–5 especialistas o un grupo de guardia común con un equipo que se ocupe de las respuestas a incidentes.
GOST R 59547-2021 permite combinar funciones, pero eso no elimina la aritmética de los turnos. El ingeniero SIEM puede ayudar con los escenarios, y el responsable puede participar en las investigaciones; sin embargo, una sola persona no cubrirá varios puestos 24/7. También se necesita reserva porque la primera línea se agota.
| Modelo | Orientación para el primer año | Gastos principales |
|---|---|---|
| SOC piloto 8/5 | 8–20 millones de rublos | SIEM, conjunto limitado de fuentes, equipo pequeño |
| SOC híbrido | 15–35 millones de rublos | L1 externo 24/7, L2 interno, licencias e integraciones |
| SOC propio 24/7 | 35–70 millones de rublos | Plantilla, SIEM, infraestructura, EDR/NDR, soporte |
| SOC distribuido de gran tamaño | 70–100 millones de rublos y más | Alto flujo de eventos, varios puestos, redundancia |
Los rangos son una referencia estimada de la redacción, no una estadística del mercado. Para una empresa concreta es mejor calcular el presupuesto de abajo arriba: medir EPS y el volumen de almacenamiento, determinar el número de dispositivos finales y segmentos de red, solicitar precios de licencias y luego añadir infraestructura, implementación, soporte, formación y la nómina.
La regulación se revisa antes de diseñar el SOC. Para objetos significativos de infraestructura crítica (KII) existe el esquema GOSOPKA. La orden del FSB nº 547 entra en vigor el 30 de enero de 2026 y reemplazó la orden nº 282 de 2019. La orden nº 548 regula cómo los sujetos pertinentes interactúan de forma continua con GOSOPKA.
Para los sistemas de información estatales rige otra base. Desde el 1 de marzo de 2026 la orden del FSTEC nº 117 sustituyó a la orden nº 17, y el 1 de septiembre de 2026 entran en vigor las modificaciones según la orden nº 137. La orden nº 21 se refiere a los sistemas de información de datos personales. Por ello, la arquitectura del SOC se contrasta con el tipo de sistema y los requisitos aplicables.
Es más práctico comenzar con un piloto. Conecte las fuentes críticas, ponga en marcha los escenarios prioritarios, compruebe la calidad de los registros, mida los falsos positivos y practique las acciones del equipo. Una vez estabilizados los procesos, se pueden ampliar las fuentes, aumentar la plantilla, añadir automatización y pasar a 24/7.
Preguntas y respuestas
¿Se puede construir un SOC sin SIEM?
Una empresa pequeña puede empezar con EDR, registros de servidores y herramientas de red. A medida que crece la infraestructura, el SIEM suele convertirse en un elemento central, pero no sustituye al equipo ni a los procesos.
¿Cuántos empleados se necesitan para un puesto SOC 24/7?
El mínimo matemático es de 4,2 plazas, pero para cubrir vacaciones, bajas, formación y rotación es más práctico planificar 5–6 empleados L1.
¿Por dónde empezar a crear un SOC?
Es mejor empezar por el inventario de activos críticos y la definición de las amenazas principales. Después se eligen las fuentes de eventos que ayuden a detectar esas amenazas y solo entonces se diseña el SIEM, los escenarios de monitorización y los procesos de respuesta.
¿En qué se diferencia un SIEM de un SOC?
El SIEM es una plataforma tecnológica para la recopilación, almacenamiento y análisis de eventos. El SOC incluye el SIEM, otras herramientas de protección, analistas, escenarios de detección, reglamentos, procesos de investigación y respuesta. La compra de un SIEM por sí sola no crea un SOC.
¿Por qué necesita el SOC EDR y NDR si ya hay SIEM?
El SIEM analiza los eventos recibidos, pero no genera toda la telemetría necesaria. EDR aporta datos detallados sobre acciones en estaciones de trabajo y servidores, y NDR ayuda a detectar actividad de red sospechosa. Juntas, estas herramientas reducen los puntos ciegos en una investigación.
¿Qué es EPS y por qué influye en el coste del SOC?
EPS indica cuántos eventos por segundo envía la infraestructura al SIEM. El flujo de eventos determina los requisitos de rendimiento, almacenamiento y, para algunos proveedores, el coste de la licencia. Por eso es recomendable medir EPS antes de comprar un SIEM.
¿Hay que enviar todos los registros de la infraestructura al SIEM?
No. La recopilación excesiva aumenta el coste de almacenamiento y la carga sobre los analistas. Hay que priorizar las fuentes que participan en los escenarios de detección o que ayudan a investigar incidentes.
¿Cuándo necesita el SOC un SOAR?
SOAR resulta útil cuando el equipo ha depurado los procesos manuales y sabe qué acciones se repiten con regularidad. Entonces se puede automatizar el enriquecimiento de alertas, las comprobaciones y acciones permitidas concretas. Automatizar un proceso mal descrito es arriesgado.
¿Qué métricas conviene medir en el SOC?
Es útil medir el tiempo medio de detección MTTD, el tiempo medio de respuesta MTTR, la proporción de falsos positivos FPR y la carga de trabajo de los analistas. Estos indicadores reflejan mejor la calidad del trabajo que el simple número de fuentes conectadas o de reglas.
¿Se puede dejar L2 solo en horario laboral?
Sí, si L1 puede cerrar por sí mismo la mayor parte de las alertas durante la noche y las escaladas complejas son raras. Si las investigaciones nocturnas son frecuentes, la segunda línea necesitará una rotación completa con más personal o un grupo de guardia separado.
¿Qué conviene más: un SOC propio o uno híbrido?
El modelo híbrido conviene a empresas que necesitan monitorización 24/7 pero todavía no pueden asumir el coste de mantener un gran equipo por turnos. Un proveedor externo puede cubrir L1, mientras que los especialistas internos conservan las investigaciones, la toma de decisiones y el conocimiento de los sistemas de negocio. Un SOC propio ofrece más control, pero exige un presupuesto recurrente mayor.
¿De qué se compone el presupuesto del SOC?
El presupuesto incluye SIEM y otras herramientas de protección, infraestructura de cálculo, almacenamiento de registros, implementación, integraciones, soporte técnico, formación y la nómina. Para un SOC propio 24/7, los salarios del equipo suelen ser una de las partidas recurrentes más importantes.
¿Es imprescindible lanzar el SOC de inmediato en modo 24/7?
No. Es más práctico empezar con un piloto en un alcance limitado, comprobar las fuentes de datos, los escenarios y la carga sobre los analistas. El paso a 24/7 está justificado cuando los procesos funcionan de forma estable y la empresa entiende la necesidad real de monitorización continua.
¿Cómo afecta GOSOPKA a la arquitectura del SOC para KII?
Para las organizaciones sujetas a los requisitos de KII, los procesos del SOC deben alinearse con el procedimiento establecido de notificación sobre ataques informáticos e incidentes y la interacción con GOSOPKA. El conjunto concreto de obligaciones depende del estatus de la organización y de los activos protegidos.
¿Son iguales los requisitos para SOC en KII, sistemas estatales y sistemas de datos personales?
No. Para KII, para los sistemas de información estatales y para los sistemas de información de datos personales aplican distintos requisitos normativos. Por eso, antes de diseñar el SOC hay que identificar el tipo de sistemas protegidos y las normas aplicables del FSB, FSTEC y otros reguladores.
Conclusión
El SOC se construye alrededor de los riesgos y las acciones, no alrededor de la interfaz del SIEM. Primero la empresa define activos y amenazas, luego obtiene la telemetría necesaria, crea escenarios, forma el equipo y establece el procedimiento para responder a incidentes. Si el presupuesto alcanza para la licencia pero no para las personas y los procesos, elegir un SOC propio 24/7 es prematuro.
El material tiene carácter informativo y no sustituye el análisis de los requisitos normativos para la organización. Al crear un centro de monitoreo de seguridad, considérese la legislación rusa y los requisitos de los reguladores aplicables. Las pruebas de los escenarios de detección y de respuesta deben realizarse solo en la propia infraestructura o con el permiso del propietario.
