SOC Analyst: qué hace y cuándo necesita tu empresa este especialista

Una empresa puede disponer de firewall, protección de endpoints, sistemas de identidad, herramientas Cloud y diferentes controles de seguridad y continuar teniendo dificultades para detectar un incidente a tiempo. A medida que crece la infraestructura también aumenta la cantidad de eventos que deben analizarse para distinguir actividad normal de comportamientos potencialmente maliciosos.Ese trabajo forma parte de las operaciones de un Security Operations Center (SOC). Dentro de esta función, el SOC Analyst participa en la monitorización, investigación y clasificación de señales procedentes de diferentes componentes tecnológicos para determinar cuáles requieren una respuesta.

La necesidad de esta capacidad suele aumentar cuando la infraestructura genera más alertas de las que un equipo generalista de IT puede investigar con suficiente profundidad. También aparece cuando los sistemas son críticos, existe operación continua o una organización necesita reducir el tiempo transcurrido entre el inicio de una actividad maliciosa y su detección.

Incorporar un SOC Analyst debe responder a ese nivel de exposición y complejidad. Para algunas empresas será necesario contar con especialistas internos; otras podrán apoyarse en servicios externos o construir un modelo híbrido que combine monitorización especializada con conocimiento interno del negocio.

Qué hace un SOC Analyst dentro de las operaciones de seguridad

Un SOC Analyst trabaja con información procedente de endpoints, identidades, redes, servidores, aplicaciones, infraestructura Cloud y herramientas de seguridad. Su función consiste en investigar señales y determinar si corresponden a actividad legítima, un falso positivo o un comportamiento que requiere una respuesta.

NIST describe el trabajo de Defensive Cybersecurity como el análisis de información recopilada mediante diferentes herramientas defensivas para mitigar riesgos, mientras que Incident Response comprende la investigación, análisis y respuesta frente a incidentes de ciberseguridad. Estas dos capacidades se encuentran estrechamente relacionadas con el trabajo diario de un SOC.

El analista necesita combinar información técnica con contexto. Un inicio de sesión desde una nueva ubicación puede ser completamente legítimo. El mismo evento adquiere otra relevancia si aparece junto con múltiples intentos de autenticación, elevación de privilegios o acceso anómalo a información sensible.

De una alerta a un incidente de seguridad

Las herramientas de seguridad pueden generar alertas a partir de reglas, indicadores, anomalías o comportamientos detectados. Una alerta representa una señal que necesita interpretación; su existencia por sí sola no demuestra que se esté produciendo un ataque.

El SOC Analyst realiza el triage inicial, recopila información adicional y determina la severidad. Puede revisar el usuario afectado, endpoint, dirección IP, procesos ejecutados, conexiones, cambios realizados y otros eventos relacionados.Cuando la investigación confirma actividad potencialmente maliciosa, el caso puede escalarse y activar procedimientos de incident response. NIST establece precisamente que una capacidad de respuesta debe contemplar preparación, detección y análisis, contención, erradicación y recuperación.

El valor del SOC se encuentra tanto en detectar amenazas como en reducir el ruido generado por eventos que finalmente no requieren intervención.

Tier 1, Tier 2 y Tier 3 representan diferentes niveles de análisis

Algunos SOC organizan sus analistas por niveles. La estructura exacta cambia entre organizaciones y no todos los equipos necesitan utilizar este modelo.

Tier 1 suele asumir monitorización y triage inicial. Los casos que necesitan mayor profundidad pueden pasar a Tier 2, donde se realiza una investigación más detallada y pueden iniciarse determinadas acciones de respuesta. Tier 3 suele asociarse con investigaciones avanzadas, threat hunting, análisis de amenazas y soporte sobre incidentes complejos.Una empresa pequeña puede combinar estas funciones en pocas personas. Una operación de mayor escala puede separarlas para gestionar mejor volumen, especialización y cobertura.

SIEM, EDR y XDR necesitan una capacidad que interprete sus señales

Una parte importante de las operaciones SOC depende de herramientas capaces de recopilar telemetría y detectar comportamientos relevantes.

Un SIEM puede centralizar logs procedentes de diferentes fuentes, normalizar eventos, correlacionar información y generar alertas. NIST describe precisamente este tipo de arquitectura: sensores y sistemas generan eventos que llegan al SIEM, donde pueden analizarse para identificar situaciones sospechosas y potenciales incidentes. EDR concentra capacidades de detección y respuesta sobre endpoints, mientras que XDR puede ampliar la correlación entre diferentes dominios de seguridad dependiendo de la plataforma utilizada. SOAR añade automatización para determinados workflows y acciones.Estas tecnologías reducen parte del trabajo manual, pero la organización continúa necesitando definir qué señales son relevantes, cómo se investigan y qué acciones corresponden cuando aparece un posible incidente.

Los Cybersecurity Specialists pueden participar en la configuración de estas capacidades y en la operación necesaria para convertir la telemetría disponible en detecciones e investigaciones útiles.

Más alertas no significan necesariamente mejor detección

Una organización puede aumentar la sensibilidad de sus herramientas y terminar generando cientos o miles de alertas adicionales sin mejorar proporcionalmente su seguridad.

Cuando el volumen supera la capacidad de análisis, aparecen colas de investigación y señales importantes pueden quedar mezcladas con eventos de baja relevancia. El resultado es una operación reactiva donde el equipo dedica demasiado tiempo a descartar falsos positivos.La madurez del SOC implica mejorar progresivamente la calidad de las detecciones, incorporar contexto y priorizar aquello que representa mayor riesgo para la organización.

Cuándo necesita una empresa capacidad SOC

No existe un número específico de empleados o dispositivos a partir del cual una organización necesite un SOC Analyst. La decisión depende de la combinación entre superficie de ataque, criticidad de los sistemas, volumen de telemetría y capacidad actual para investigar incidentes.

Algunas señales indican que las operaciones de seguridad necesitan mayor especialización:

• El volumen de alertas supera la capacidad del equipo de IT: existen eventos pendientes o las investigaciones se realizan de manera superficial.

• La infraestructura necesita protección continua: aplicaciones, servicios o procesos críticos operan fuera del horario habitual.

• La superficie tecnológica ha crecido: endpoints, identidades, aplicaciones SaaS, infraestructura Cloud y redes generan múltiples fuentes de telemetría.

• Los incidentes se detectan demasiado tarde: la organización descubre actividad maliciosa después de que haya producido un impacto.

• Existe SIEM, EDR o XDR, pero falta capacidad de análisis: se ha invertido en herramientas sin dimensionar quién operará sus alertas.

• Existen requisitos regulatorios o contractuales: determinados entornos requieren controles más estrictos de monitorización, registro y respuesta.

• La respuesta depende de pocas personas: ausencias o sobrecarga pueden dejar incidentes sin una investigación suficientemente rápida.

Estas condiciones indican una necesidad de capacidad SOC, aunque no determinan automáticamente que la empresa deba construir un Security Operations Center interno.

SOC interno, servicio externo o modelo híbrido

Una vez identificada la necesidad de monitorización especializada, la siguiente decisión consiste en determinar cómo proporcionar esa capacidad.

Un SOC interno ofrece mayor control sobre personas, procesos y tecnología. Los analistas pueden desarrollar conocimiento profundo de la infraestructura y comprender con mayor rapidez qué comportamientos son normales dentro de cada sistema. El modelo también exige inversión en especialistas, herramientas, procesos, liderazgo y cobertura. Un servicio externo puede proporcionar monitorización especializada sin construir toda la operación internamente. Esta alternativa puede ser especialmente relevante cuando la empresa necesita ampliar cobertura o todavía no tiene escala suficiente para mantener varios turnos de analistas.

El modelo híbrido combina ambas aproximaciones. Un proveedor puede asumir parte de la monitorización y triage, mientras el equipo interno mantiene ownership sobre arquitectura, contexto empresarial, decisiones críticas y coordinación de incidentes.

La elección también depende de cuánto contexto necesita el analista para interpretar correctamente las señales. Cuanto más particular sea la infraestructura o el negocio, mayor importancia adquieren la documentación, los procedimientos de escalamiento y la colaboración entre especialistas internos y externos.

La infraestructura Cloud amplía las fuentes que debe vigilar el SOC

La migración hacia Cloud cambia parte de la telemetría disponible. Además de endpoints y redes tradicionales aparecen identidades, APIs, workloads, contenedores, servicios administrados y diferentes registros proporcionados por los proveedores.

Esto obliga a integrar nuevas fuentes dentro de los procesos de detección.

Los Ingenieros Cloud pueden colaborar con seguridad para garantizar que la infraestructura genera la telemetría necesaria y que los controles se integran correctamente con la arquitectura. El SOC Analyst necesita comprender ese contexto para investigar una alerta. Una modificación de permisos en una identidad Cloud puede ser más relevante que una conexión de red aislada si proporciona acceso a recursos críticos.

Identidad se ha convertido en una fuente esencial de contexto

Una parte importante de las investigaciones necesita reconstruir qué identidad realizó una acción, desde qué dispositivo y con qué privilegios. Por eso, logs de autenticación, cambios de permisos, MFA y accesos a aplicaciones pueden ser tan importantes como la telemetría de red.

Los equipos de IT Infrastructure y seguridad necesitan coordinar estas fuentes para que el SOC pueda relacionar eventos procedentes de diferentes componentes y reconstruir una secuencia cuando aparece actividad sospechosa.

MITRE ATT&CK ayuda a analizar comportamientos de los atacantes

Un SOC necesita algo más que listas de indicadores conocidos. También debe comprender los comportamientos que pueden aparecer durante las diferentes etapas de un ataque.

MITRE ATT&CK proporciona una base de conocimiento sobre tácticas y técnicas utilizadas por adversarios y un lenguaje común para describirlas. MITRE también propone ATT&CK como referencia para evaluar capacidades SOC y desarrollar, probar y mejorar analíticas de detección. Esto permite analizar la cobertura desde una perspectiva diferente. En lugar de preguntar únicamente cuántas reglas tiene el SIEM, puede evaluarse qué comportamientos relevantes para la organización tienen mecanismos de detección.

Detection Engineering mejora la calidad de las alertas

Conforme madura la operación, parte del trabajo pasa de reaccionar ante alertas hacia diseñar mejores detecciones. Detection Engineering utiliza conocimiento sobre amenazas, telemetría disponible y comportamiento de los sistemas para construir analíticas capaces de identificar actividades relevantes con un nivel razonable de precisión.

Los resultados de investigaciones anteriores pueden alimentar este proceso. Si un incidente demuestra que determinada secuencia de eventos es importante, el equipo puede desarrollar o mejorar una detección para identificarla antes en el futuro. Esta retroalimentación permite que el SOC evolucione a partir de la experiencia operacional.

La IA está modificando parte del trabajo del SOC Analyst

Los equipos de seguridad gestionan grandes cantidades de información, por lo que existen oportunidades claras para aplicar automatización e Inteligencia Artificial en tareas como enriquecimiento de alertas, correlación, búsqueda y preparación de resúmenes. Esto puede reducir tiempo dedicado a determinadas actividades repetitivas y proporcionar contexto inicial para una investigación. También puede ayudar a que un analista navegue grandes volúmenes de telemetría con mayor rapidez.

El impacto ya está alcanzando la organización de los equipos. En un webinar de NICE de marzo de 2026 se recogieron datos de SANS según los cuales el 74% de los equipos de ciberseguridad encuestados estaban modificando tamaño o estructura de roles por el impacto de la IA, con SOC/Security Analyst entre los puestos más afectados.

La incorporación de Inteligencia Artificial en operaciones de seguridad debe acompañarse de controles y validación. Una explicación generada automáticamente puede acelerar el triage, pero una decisión sobre aislamiento, bloqueo o escalamiento puede tener consecuencias operacionales que requieren contexto adicional. La evolución del perfil apunta así hacia una combinación de análisis humano y automatización, especialmente cuando el volumen de señales hace inviable investigar manualmente cada evento desde cero.

Qué evaluar al contratar un SOC Analyst

El perfil adecuado depende del entorno que deberá proteger. Una empresa con infraestructura principalmente Cloud puede valorar conocimientos diferentes a una organización con centros de datos, redes corporativas y sistemas legacy.

Entre las capacidades que conviene evaluar se encuentran:

• SIEM y análisis de logs: capacidad para investigar eventos procedentes de múltiples fuentes.

• EDR/XDR: comprensión de telemetría de endpoints y procesos de investigación.

• Redes e infraestructura: conocimiento de protocolos, tráfico, sistemas y arquitectura empresarial.

• Identidad y Cloud: capacidad para interpretar autenticaciones, permisos y eventos de servicios Cloud.

• Incident response: experiencia determinando severidad, escalando y documentando incidentes.

• MITRE ATT&CK: comprensión de tácticas y técnicas para contextualizar comportamientos observados.

• Comunicación: capacidad para documentar hallazgos y explicar riesgos a otros equipos técnicos y responsables.

Las certificaciones pueden complementar esta evaluación, pero el trabajo práctico requiere interpretar información incompleta, construir hipótesis y relacionar eventos procedentes de diferentes sistemas.

Un candidato capaz de explicar cómo investigaría una alerta, qué información buscaría y bajo qué condiciones escalaría el caso puede aportar una señal más útil que memorizar únicamente conceptos o herramientas.

El SOC Analyst forma parte de una capacidad más amplia de respuesta

Detectar un incidente solo genera valor cuando la organización puede responder.

El SOC necesita procedimientos que definan cómo escalar situaciones, quién puede tomar decisiones y qué equipos participan cuando el incidente afecta sistemas críticos. NIST destaca precisamente que incident response requiere coordinación entre diferentes funciones organizativas y debe