Security Analyst vs Security Engineer: ¿Cuál es la diferencia real?

Los títulos se usan indistintamente en las ofertas de empleo, pero el trabajo diario es genuinamente diferente. Si estás eligiendo una dirección para estudiar, entender la diferencia te ahorrará meses persiguiendo las certificaciones y habilidades equivocadas.

Qué hace un analista realmente todo el día

Un security analyst pasa la mayoría de su tiempo observando, priorizando e investigando. Eso significa estar atento a un SIEM (Splunk, Sentinel, QRadar), trabajar colas de alertas, y decidir si un proceso marcado en una estación de trabajo es un falso positivo o el comienzo de un incidente. Una gran parte del trabajo es redactar hallazgos con claridad suficiente para que un gerente o un cliente sin experiencia en seguridad entienda qué pasó.

Los analistas Tier 1 priorizan. Los analistas Tier 2/3 profundizan: extraen árboles de procesos, revisan telemetría EDR en algo como CrowdStrike o Defender for Endpoint, correlacionan registros en firewalls y proveedores de identidad para construir una línea de tiempo. El trabajo es reactivo por naturaleza: algo sucede, descubres qué significa y qué hacer al respecto.

Una lista de tareas típica del analista: revisar alertas nocturnas, cerrar falsos positivos con razonamiento documentado, escalar una ejecución sospechosa de PowerShell, actualizar un runbook después de que aparece un nuevo patrón de phishing, y participar en una llamada de incidente. Es trabajo investigativo y que requiere mucha comunicación.

Qué construye realmente un engineer

Un security engineer construye y mantiene los sistemas en los que se basa el analista. Eso es escribir reglas de detección en Sigma o KQL, ajustar un SIEM para que no inunde la cola con ruido, implementar y configurar agentes EDR en 5,000 endpoints, o automatizar un playbook de respuesta a phishing en una plataforma SOAR como Tines o Cortex XSOAR.

Los engineers también trabajan antes de los incidentes: reforzar configuraciones en la nube en AWS o Azure, configurar segmentación de red, escribir Terraform para aplicar reglas de security groups, parchar pipelines CI/CD para que los secretos no se filtren al historial de git. Mucho del trabajo de engineering es invisible hasta que falla — nadie se fija en una regla WAF bien configurada, pero todos se dan cuenta cuando falta.

Donde un analista pregunta "¿qué pasó aquí?", un engineer pregunta "¿cómo evitamos que esta clase de cosa suceda, o al menos la detectemos más rápido la próxima vez?". Los engineers escriben código más a menudo — Python para automatización, a veces Go o Rust para herramientas, YAML y Terraform para infraestructura.

Habilidades que realmente separan a los dos

Los analistas necesitan un fuerte reconocimiento de patrones, fluidez en análisis de registros, y la capacidad de escribir reportes de incidentes bajo presión de tiempo. Herramientas: Splunk SPL, Wireshark, análisis básico de malware, mapeo MITRE ATT&CK. Las certificaciones que encajan bien: Security+, CySA+, GCIH, a veces avanzando hacia GCFA para trabajo más profundo en forensics.

Los engineers necesitan realmente construir cosas: scripting (Python, Bash), infrastructure-as-code, integración API entre herramientas de seguridad, y suficiente conocimiento de sistemas/red para saber por qué una regla rompe producción. Las certificaciones aquí se inclinan hacia GCED, certificaciones de seguridad en la nube (AWS Security Specialty, AZ-500), y eventualmente OSCP si el rol se inclina hacia lo ofensivo.

El solapamiento es real — un buen analista aprende a escribir sus propias consultas de enriquecimiento, y un buen engineer todavía necesita leer registros para saber si su detección realmente se dispara. Pero el centro de gravedad difiere: los analistas viven en la cola de alertas, los engineers viven en los archivos de configuración y repositorios de código.

Trayectorias profesionales y cómo se mueven entre ellas

La mayoría de la gente comienza como analista porque los roles de SOC contratan más posiciones de entrada y la curva de aprendizaje te enseña qué se ve "normal" en un ambiente real. Esa base es importante incluso si eventualmente quieres ser engineer.

Desde analista Tier 1, un camino común es analista Tier 2/3, luego threat hunter o detection engineer, que es un rol híbrido real que escribe detecciones basadas en lo que los analistas ven que se pierde en la cola. Desde allí, algunos se mueven completamente hacia security engineering (construir plataformas) o arquitectura (diseñar programas de seguridad completos).

Los engineers a veces vienen de una puerta completamente diferente — desarrolladores de software o sysadmins que adquieren especialización en seguridad en lugar de comenzar en un SOC. Ese camino evita la fase de fatiga de alertas pero puede dejar brechas en los instintos de respuesta a incidentes.

Cuál deberías apuntar primero

Si te gusta la investigación, la escritura, y resolver acertijos bajo presión, comienza en el lado del analista. Si prefieres escribir código y arreglar causas raíz que perseguir alertas, apunta hacia el lado del engineer, pero espera necesitar algo de experiencia adyacente al analista para ser creíble — nadie confía en una detección que construiste si nunca has tenido que trabajar una cola de alertas tú mismo.

Ambos caminos convergen eventualmente en niveles senior, donde el trabajo se vuelve menos sobre el título y más sobre entender toda la superficie de ataque. Korra Studio tiene segmentos sobre flujos de trabajo de SOC, escritura de consultas SIEM, y fundamentos de security engineering en la nube que vale la pena explorar si quieres ver el tooling diario para cualquiera de los dos caminos de cerca.