La mejor prueba de ciberseguridad para contratar analistas SOC

Por qué fallan la mayoría de las pruebas para analistas SOC

Una persona analista SOC (Centro de Operaciones de Seguridad) pasa el día leyendo alertas de SIEM, priorizando amenazas y respondiendo a incidentes. No escribe exploits ni diseña redes. Aun así, la mayoría de las evaluaciones de ciberseguridad miden conocimiento de pentest: descubrimiento de vulnerabilidades, protocolos de red, cadenas de explotación.

Una analista SOC fuerte puede suspender un test de seguridad de red. Una pentester brillante puede tener problemas como analista SOC. Las habilidades se solapan, pero las funciones del puesto no.

Para contratar a una buena analista, necesitas una evaluación que mida: razonamiento de triaje, análisis de incidentes, gestión de la fatiga de alertas y toma de decisiones bajo presión de tiempo.

Qué hace de verdad una analista SOC

1. Triaje: Mira 500 alertas diarias. ¿Qué 5 merecen atención?
2. Investiga: Sigue logs entre sistemas. ¿Qué pasó? ¿Cómo entraron?
3. Escala: ¿Es un incidente o un falso positivo? ¿Es crítico para contención o se debugea después?
4. Comunica: Explica los hallazgos a personas ingenieras que no hablan «seguridad». Empuja contra el ruido.

Una evaluación que no mida esto está midiendo lo que no toca.

La anatomía de una evaluación SOC sólida

Parte 1: Triaje de alertas (20 minutos)

Escenario: Tu panel de SIEM muestra 47 alertas. Tienes 30 minutos antes del relevo de turno. Ordena las 5 principales por prioridad y explica por qué investigarías cada una:

1. Intento de inyección SQL (bloqueado por WAF) en /api/login
2. Inicio de sesión fallido a [email protected] desde 5 países en 2 horas
3. SSH saliente inesperado de un servidor de base de datos a una IP desconocida
4. 50 inicios de sesión fallidos a la cuenta de servicio app-runner desde la red interna
5. Un fichero sensible (/etc/passwd) copiado a una carpeta externa
6. Pico inusual de consultas DNS desde una estación de trabajo de desarrollo
7. Una cuenta reactivada por TI hace 5 minutos (activación rutinaria)
8. Aviso de caducidad de certificado en un servidor web (caduca en 30 días)

Qué se mide:

• ¿Sabe distinguir señal de ruido?
• ¿Hace preguntas aclaratorias (el contexto importa)?
• ¿Ignora ataques claramente bloqueados o sobre-escala falsos positivos?
• ¿Prioriza por impacto en negocio, no por severidad nominal?

Cómo es una buena respuesta: «Rango 1: #3 (SSH saliente de base de datos a IP desconocida). Es una emergencia de contención si la base de datos está comprometida. Rango 2: #2 (varios países, misma cuenta). Riesgo de credential stuffing, pero menos urgente si MFA está activo — lo verifico. Rango 3: #5 (copia de passwd). Solo urgente si los datos son sensibles. Rango 4: #1 (SQL injection bloqueada). Fatiga de alertas — el WAF hizo su trabajo. Salto #4, #6, #7 y #8 en los próximos 30 minutos».

Parte 2: Análisis de incidentes (40 minutos)

Escenario: Una persona desarrolladora reporta que su portátil va lento. Tu equipo forense captura:

• 200 MB de datos comprimidos subidos a Slack hace 2 horas
• El historial de Chrome muestra git clone del monorepo de la empresa
• Una clave SSH en la carpeta .ssh con fecha de modificación reciente (mismo momento que la subida)
• Sin avisos del antivirus

¿Es un incidente de seguridad? ¿Cuál es tu hipótesis? ¿Qué haces en la próxima hora?

Qué se mide:

• ¿Sabe construir línea de tiempo y narrativa?
• ¿Distingue entre «la usuaria subió datos» y «un atacante exfiltró secretos»?
• ¿Recomienda contención sin sobrerreaccionar (no formatear el portátil ante la sospecha)?
• ¿Piensa en falsos positivos (quizá la persona subió código a propósito)?

Cómo es una buena respuesta: «Huele a credenciales comprometidas o a riesgo interno, pero antes hay que descartar acción intencional. Yo: 1) Hablo con la persona — ¿clonó el monorepo y lo compartió a propósito? 2) Si no: reviso qué había en el archivo de 200 MB y quién tiene acceso al canal de Slack. 3) Asumo que la clave SSH está comprometida — la roto ya y reviso pushes o inicios de sesión no autorizados en las últimas 24 horas. 4) Si hay commits no autorizados, es crítico para contención; si no, es investigación en curso. No aíslo el portátil aún».

Parte 3: Escenario de fatiga de alertas (20 minutos)

Tu equipo de seguridad se ahoga en alertas. Las señales reales quedan enterradas bajo ruido. Propones reducir el volumen de alertas afinando el SIEM. ¿Qué alertas suprimirías?

• Alerta: «Intento de inicio de sesión fallido» (se dispara 1.000 veces al día)
• Alerta: «Cambio de contraseña por cuenta admin» (50 veces al día, todas legítimas)
• Alerta: «Transferencia grande a almacenamiento en la nube» (200 veces al día, mayormente Google Drive de trabajo)
• Alerta: «Proceso sin firma válida lanzado» (10 veces al día, 90 % son herramientas dev)

Qué se mide:

• ¿Sabe reducir ruido sin perder señal?
• ¿Entiende ajustar frente a ignorar?
• ¿Pide contexto de negocio?

Cómo es una buena respuesta: «Suprimo o ajusto #1 y #2 — no son accionables. Para #1, alerto sobre fallos desde IP nueva + misma usuaria. Para #2, no alerto en cambios de contraseña. Para #3, lista blanca para herramientas legítimas (Google Drive, Dropbox, Slack). Para #4, lista blanca por hash para herramientas dev. El objetivo: dejar a la vista las 2-3 alertas diarias que de verdad necesitan investigación».

Puntuar la evaluación

La entrevista de seguimiento

Empareja la evaluación con un cribado técnico de 30 minutos:

• «Cuéntame el último incidente SOC que llevaste. ¿Qué te hizo escalar? ¿Qué te sorprendió?»
• «Llega una alerta sobre malware. La firma tiene 6 meses. ¿Cómo investigas?»
• «Tu equipo tiene 50 % de falsos positivos. Tienes una hora para proponer ajustes. ¿Cuál es tu enfoque?»

El seguimiento revela si lo ha hecho antes y si piensa de forma pragmática sobre la fatiga de alertas.

Por qué importa

El burnout de las analistas SOC es real. Renuncian porque se ahogan en alertas y no ven incidentes reales. Contratar a alguien que sepa triar de forma efectiva es la incorporación que mejora la velocidad de todo tu equipo.

Una buena evaluación saca a flote a candidaturas que han estado en el ruido y han aprendido a encontrar la señal. Esas candidaturas son raras. La evaluación debería encontrarlas.

Próximos pasos

Cuando construyas tu evaluación SOC, céntrate en:

1. Triaje (30 %)
2. Análisis de incidentes (50 %)
3. Ajuste de alertas (20 %)

Empareja con una entrevista en vivo para confirmar el juicio bajo presión. Las mejores incorporaciones son las que saben explicar su razonamiento en tiempo real.

Las evaluaciones de ClarityHire soportan escenarios específicos de SOC, subida de archivos (para análisis de logs) y respuestas en texto (para informes abiertos de incidentes). Construye la evaluación SOC que tu equipo necesita realmente.