Preguntas de ejemplo para tests de ciberseguridad: qué preguntar (y por qué)

Por qué la trivia genérica de seguridad falla

La mayoría de las evaluaciones de ciberseguridad preguntan por listas CVE, OWASP de memoria o comandos de herramientas. Una candidata que recita el OWASP Top 10 o describe AES-256 en detalle puede ser competente. O puede ser buena leyendo checklists. La evaluación no te dice cuál.

El trabajo real de seguridad se trata de razonamiento sobre amenazas bajo ambigüedad. Detectar la misconfiguración sutil. Decidir qué vale la pena parchear vs qué es riesgo aceptable. Explicar un trade-off a un stakeholder escéptico. Esas habilidades no vienen de memorizar.

Qué mide una pregunta fuerte de ciberseguridad

Una buena pregunta da a la candidata un escenario, no una definición. Le pide razonar a través de información incompleta, explicar trade-offs y defender una decisión. La respuesta revela si piensa como ingeniera de seguridad.

Aquí hay ejemplos reales por rol.

1. Analista SOC: triage de incidentes

Escenario: Tu SIEM marca 2,000 intentos de login fallidos a [email protected] entre 1am-3am UTC. Las IPs están distribuidas en 15 países. Mismo username, contraseñas diferentes. Tu cola de alertas tiene 47 items más. ¿Qué haces en los próximos 15 minutos?

Lo que estás midiendo:

• ¿Puede triajar por severidad (credential-stuffing vs brute-force vs falso positivo ruidoso)?
• ¿Hace preguntas clarificadoras (¿la cuenta está deshabilitada?, ¿tiene MFA?, ¿qué es normal para esta usuaria?)?
• ¿Puede priorizar bajo presión sin sobre-escalar?

Respuesta débil: "Alertar al admin inmediatamente." Respuesta fuerte: "Primero, verificar si MFA está habilitado en esta cuenta — si sí, los intentos fallidos no importan. Si no, revisar historial de cambio de contraseña y último login exitoso. Si no hay señal de compromiso reciente, documentarlo como credential-stuffing, añadir los rangos de IP a un bloqueo si tienes capacidad, sino despriorizar bajo cuentas con logins exitosos."

2. Pentester: juicio de vulnerabilidad

Escenario: Encuentras un subdominio (api-old.company.com) que devuelve respuestas API sin autenticación. Está vivo pero no documentado en sistemas actuales. La superficie API es idéntica a la API principal. ¿Cuál es la severidad? ¿Qué reportas?

Lo que estás midiendo:

• ¿Entiende riesgo dependiente del contexto (API vieja podría ser inofensiva o catastrófica)?
• ¿Puede distinguir entre vulnerabilidad y explotabilidad?
• ¿Comunica hallazgos de manera que se accione, no se desestime como ruido?

Respuesta débil: "Crítica. Acceso API sin autenticación." Respuesta fuerte: "Potencialmente alta si esta API sigue conectada a datos en vivo. Verificaría: ¿está proxyando a la BD de producción, o es una réplica? ¿Expone campos sensibles más allá de la API pública? Si es réplica fiel de la pública, la severidad baja. Recomendaría deshabilitarla por completo, sino restringirla a una subnet VPN y habilitar rate-limiting."

3. Ingeniera de seguridad: decisión de arquitectura

Escenario: Tu aplicación necesita almacenar secretos API (credenciales BD, claves de terceros). Opciones: HSM (módulo de seguridad por hardware), secret store gestionado (AWS Secrets Manager), variables de entorno cifradas, o hardcoded (para dev local). Tienes presupuesto. Recomienda y defiende.

Lo que estás midiendo:

• ¿Conoce los trade-offs (coste, complejidad operativa, fricción dev, ganancia de seguridad real)?
• ¿Puede dimensionar el threat model al rol (startup vs enterprise)?
• ¿Toma decisiones que aguantan, o sobre-ingeniera y quema credibilidad?

Respuesta débil: "Usa HSM, es lo más seguro." Respuesta fuerte: "Depende de tu threat model y restricciones. Para una startup: AWS Secrets Manager con políticas IAM least-privilege. Es gestionado (sin carga operativa), auditado, cuesta ~$0.40/secreto/mes. Para una enterprise con compliance: HSM o managed HSM si necesitas FIPS 140-2. Para dev local: archivos .env cifrados. Nunca nada hardcoded."

4. Cloud security: detección de misconfiguración

Escenario: Un dev te pide revisar su política de bucket AWS S3:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/public/*"
    }
  ]
}

Dice: "Solo hay archivos públicos ahí." ¿Está bien? ¿Por qué o por qué no?

Lo que estás midiendo:

• ¿Detecta el riesgo (wildcards, Principal: "*")?
• ¿Entiende que las políticas cambian, los buckets crecen, pasan errores?
• ¿Aplica defense-in-depth o solo confía en la estructura de directorios?

Respuesta débil: "Parece OK si siguen la convención de naming." Respuesta fuerte: "No. Una política que confía en una convención de directorios es un fallo esperando ocurrir. Usa el setting S3 Block Public Access a nivel de cuenta, y usa object tagging o partición de buckets con credenciales separadas si genuinamente necesitas objetos públicos. Así, incluso si alguien sube al prefijo equivocado, no se filtra."

Cómo usar esto en hiring

Una evaluación fuerte da a las candidatas 3-4 escenarios como estos, típicamente repartidos en 90 minutos (take-home o proctorado). Deja que expliquen su razonamiento en texto o vía vídeo corto. Puntúa en:

• Claridad de threat model: ¿Preguntan qué importa?
• Razonamiento de trade-offs: ¿Pueden explicar qué eligen y por qué?
• Realismo operativo: ¿Proponen cosas que funcionan, o ideales teóricos?
• Humildad: ¿Reconocen incertidumbre y casos borde?

Empareja esto con una entrevista de seguimiento para verificar el razonamiento. La evaluación no es sobre la respuesta — es sobre el proceso de pensamiento.

El ROI de preguntas basadas en escenarios

Si contratas para seguridad, la evaluación basada en escenarios es no negociable. Filtra candidatas que memorizaron certificaciones pero no construyeron juicio. Saca a la luz candidatas que piensan sistemáticamente sobre trade-offs. Y le da a tu equipo una oportunidad de ver cómo manejarán decisiones ambiguas y de alto stakes en la vida real.

La alternativa — tests basados en trivia y entrevistas tipo PowerPoint — no correlaciona con juicio real de seguridad. Reserva los chequeos de memorización para los fundamentos. Evalúa el juicio con escenarios.