Security Operations Center
Un evento adquiere valor operativo cuando alguien puede relacionarlo con un activo, decidir si forma parte de un incidente y coordinar una respuesta. El Security Operations Center (SOC) concentra esa capacidad de monitorización, investigación y coordinación. Puede ser interno, externalizado, híbrido, distribuido o virtual. Su forma y horario dependen del riesgo que debe cubrir, no de la imagen de una sala llena de pantallas.
Entradas, trabajo y salidas
Sección titulada «Entradas, trabajo y salidas»| Elemento | Ejemplos |
|---|---|
| Entradas | Logs, telemetría de endpoint y red, identidad, cloud, inteligencia y contexto de activos |
| Trabajo | Triage, enriquecimiento, investigación, escalada, threat hunting y coordinación |
| Salidas | Incidentes confirmados, contención, evidencia, mejoras de detección y métricas de riesgo |
Un Security Information and Event Management (SIEM) ayuda a recopilar, correlacionar y consultar eventos, pero no constituye por sí solo un SOC. Sin fuentes fiables, contexto, procedimientos y autoridad para actuar, las alertas se convierten en una cola sin resultado.
El recorrido puede fallar antes de la alerta. Un endpoint deja de enviar eventos, un analizador pierde el campo de usuario o una regla compara una zona horaria distinta. También puede fallar después, cuando la alerta carece de propietario o el analista no puede aislar el activo. El SOC necesita medir la cadena completa desde la generación del dato hasta la decisión.
Organización del trabajo
Sección titulada «Organización del trabajo»El modelo Tier 1/Tier 2/Tier 3 es frecuente, pero no universal. Puede provocar traspasos y pérdida de contexto si cada nivel solo mueve tickets. Otras organizaciones asignan investigadores de extremo a extremo o equipos por dominio. El diseño debe responder a volumen, complejidad, cobertura horaria y habilidades reales.
Flujo mínimo de una señal
Sección titulada «Flujo mínimo de una señal»- validar que el dato y la alerta sean fiables
- identificar usuario, activo, criticidad y comportamiento relacionado
- determinar alcance y posible impacto
- decidir si cerrar, observar, escalar o contener
- preservar evidencia y documentar razonamiento
- retroalimentar reglas, fuentes, procesos y controles.
Métricas con contexto
Sección titulada «Métricas con contexto»El tiempo medio hasta la detección (MTTD) y el tiempo medio hasta la respuesta o resolución (MTTR) pueden ocultar cierres prematuros o incidentes simples. Conviene combinarlos con calidad de detección, cobertura validada, tiempo hasta contención, recurrencia, pérdida de telemetría y resultados de ejercicios.
Los promedios esconden además distribuciones muy distintas. Diez alertas triviales cerradas en segundos pueden mejorar el MTTR mientras un incidente crítico permanece abierto durante horas. Separar severidad, etapa de respuesta y percentiles permite ver qué casos dominan el riesgo.
Preguntas de repaso
Sección titulada «Preguntas de repaso»- ¿Por qué un SIEM no equivale a un SOC?
- ¿Qué riesgo introduce un modelo de tiers mal diseñado?
- ¿Qué contexto necesita una alerta antes de tomar una decisión?