Preguntas técnicas y profesionales (las que separan a los preparados)
Aquí es donde un Ingeniero de Seguridad Informática se gana el puesto. No basta con nombrar herramientas: te van a pedir diseño, decisiones y cómo lo operarías en producción. Muchas de estas preguntas salen tal cual en ofertas y procesos en España, especialmente en banca/consultoría y empresas con cloud híbrida (puedes ver patrones en InfoJobs y Indeed España).
Q: Diseña un enfoque de Zero Trust para una empresa con entorno híbrido (on‑prem + cloud). ¿Por dónde empiezas?
Why they ask it: Quieren ver arquitectura, no eslóganes.
Answer framework: “Capas + quick wins” (identidad, dispositivo, red, app, datos) y un roadmap.
Example answer: “Empiezo por identidad: MFA, conditional access y roles mínimos, porque es el control que más reduce riesgo rápido. Luego segmentación: separar workloads críticos y restringir east-west con políticas y microsegmentación donde tenga sentido. En paralelo, logging centralizado y detección para validar que los controles funcionan. Y cierro con protección de datos: clasificación, cifrado y DLP en los flujos más sensibles.”
Common mistake: Hablar solo de red y olvidarse de IAM y observabilidad.
Q: ¿Qué señales buscarías en un SIEM para detectar movimiento lateral en un entorno Windows?
Why they ask it: Evalúan si sabes convertir telemetría en detección.
Answer framework: “Fuentes → hipótesis → reglas” (eventos, correlación, falsos positivos).
Example answer: “Miraría eventos de autenticación anómalos (4624/4625), uso de cuentas privilegiadas fuera de horario, y patrones de PsExec/WinRM/RDP entre hosts que no suelen hablar. Correlaciono con creación de servicios, ejecución remota y cambios en grupos de admin. Y ajusto por baseline del entorno para no inundar al SOC con ruido.”
Common mistake: Responder con nombres de herramientas sin mencionar eventos, correlación y baseline.
Q: Explícame cómo implementarías gestión de secretos en Kubernetes.
Why they ask it: Quieren saber si entiendes el “día 2” (rotación, acceso, auditoría).
Answer framework: “Modelo de amenaza → controles → operación” (cómo se filtran secretos y cómo lo evitas).
Example answer: “Evito secretos en texto plano en repositorios y variables de entorno sin control. Usaría un gestor como HashiCorp Vault o el servicio cloud equivalente, con inyección dinámica y rotación. Limito acceso con RBAC y namespaces, y activo auditoría para saber quién leyó qué y cuándo. Además, reviso que los secretos no acaben en logs y establezco un proceso de rotación periódica y ante incidentes.”
Common mistake: Decir “uso Kubernetes Secrets” sin hablar de cifrado, rotación y auditoría.
Q: ¿Cómo montarías un programa de AppSec en una empresa que ya tiene CI/CD?
Why they ask it: Buscan enfoque pragmático: seguridad integrada, no un “gate” eterno.
Answer framework: “Shift-left por etapas” (SAST, SCA, DAST, IaC scanning) + políticas de bloqueo progresivas.
Example answer: “Empiezo con SCA para dependencias y SAST en repos críticos, porque da valor rápido. Defino severidades y SLAs, y bloqueo solo high/critical al principio para no romper la adopción. Luego añado escaneo de IaC (Terraform) y contenedores, y finalmente DAST en entornos de staging con pruebas autenticadas. Lo importante: métricas de reducción de vulnerabilidades y tiempo de remediación, no solo ‘número de findings’.”
Common mistake: Querer implantar todo a la vez y que el equipo lo apague a la semana.
Q: En España, ¿qué implicaciones prácticas tiene el RGPD para tu trabajo diario como Ingeniero de Seguridad de Sistemas?
Why they ask it: Quieren ver si conectas seguridad con privacidad y evidencias.
Answer framework: “Principios → controles → pruebas” (minimización, acceso, retención, brechas).
Example answer: “RGPD me obliga a pensar en datos personales como activo crítico: limitar accesos, registrar quién accede, y aplicar cifrado en tránsito y reposo donde corresponda. También influye en retención y borrado: no vale guardar logs con PII indefinidamente. Y, si hay brecha, necesito trazabilidad para evaluar impacto y apoyar notificación en plazos. En la práctica, traduzco esto a IAM, logging, hardening y procesos de respuesta a incidentes.”
Common mistake: Responder con teoría legal sin aterrizar controles técnicos.
Q: ¿Has trabajado con ENS (Esquema Nacional de Seguridad) o ISO 27001? ¿Cómo conviertes un control en evidencia auditable?
Why they ask it: En España, ENS aparece muchísimo en proyectos con sector público y proveedores.
Answer framework: “Control → implementación → evidencia → periodicidad” (qué se muestra al auditor).
Example answer: “Sí, he trabajado con ISO 27001 y mapeos a ENS. Para mí, un control no existe si no hay evidencia: políticas versionadas, configuraciones exportables, registros de cambios y pruebas periódicas. Por ejemplo, para control de accesos: matriz de roles, logs de altas/bajas, revisiones trimestrales y evidencias de MFA. Y si puedo, automatizo la recolección con scripts o dashboards para no depender de ‘capturas’ manuales.”
Common mistake: Decir “cumplimos ENS” sin explicar cómo se demuestra.
Q: ¿Cómo diseñarías IAM en AWS/Azure para mínimo privilegio sin volver loco al equipo?
Why they ask it: IAM es donde se gana o se pierde la seguridad cloud.
Answer framework: “Principios + patrones” (roles por función, separación de cuentas/suscripciones, break-glass).
Example answer: “Separaría entornos por cuentas/suscripciones y limitaría permisos por rol, no por usuario. Uso roles asumibles con duración corta, políticas gestionadas y condiciones (por ejemplo, por tags o por origen). Defino un ‘break-glass’ controlado y auditado para emergencias. Y doy al equipo plantillas: si el camino seguro es el más fácil, lo adoptan.”
Common mistake: Crear políticas gigantes ‘admin-like’ por prisa y dejar deuda eterna.
Q: ¿Qué harías si el EDR empieza a fallar o a consumir recursos y el negocio te pide desactivarlo?
Why they ask it: Quieren ver gestión de crisis y postura de riesgo.
Answer framework: “Mitigación temporal + plan de recuperación” (mantener cobertura mínima).
Example answer: “No lo desactivo a ciegas. Primero delimito: ¿es un fallo global o por versión?, ¿afecta a servidores críticos? Si hay impacto operativo, aplico mitigación: excluir procesos específicos, ajustar políticas o hacer rollback controlado. En paralelo, refuerzo detección con SIEM y controles compensatorios (WAF, hardening, segmentación) hasta restaurar el EDR. Y documento la decisión con riesgo aceptado por el dueño del servicio.”
Common mistake: Aceptar apagar el EDR sin compensaciones ni trazabilidad.
Q: Explícame cómo harías threat modeling para una API que maneja datos personales.
Why they ask it: Buscan pensamiento estructurado y orientación a abuso real.
Answer framework: STRIDE + “abuse cases” + controles por amenaza.
Example answer: “Empiezo por el diagrama de flujo: cliente, API gateway, servicio, base de datos y terceros. Aplico STRIDE: suplantación (auth fuerte), manipulación (firmas/validación), repudio (logging), divulgación (cifrado y scopes), DoS (rate limiting) y elevación (roles). Luego bajo a casos de abuso: enumeración de IDs, scraping, token replay. Y de ahí saco controles y tests automatizables.”
Common mistake: Quedarse en un documento bonito sin acciones ni pruebas.
Q: ¿Qué métricas usarías para demostrar que tu trabajo mejora la seguridad?
Why they ask it: Quieren impacto medible, no “sensación de seguridad”.
Answer framework: “Outcome metrics” (riesgo/tiempo) + “operational metrics” (carga/eficiencia).
Example answer: “Me centro en métricas que importan: MTTD/MTTR en incidentes, porcentaje de activos con MFA, tiempo medio de parcheo para críticas, y reducción de exposición (servicios internet-facing sin necesidad). En AppSec, miro lead time de remediación y ratio de vulnerabilidades reabiertas. Y siempre las conecto con riesgo: qué se evitó o qué se redujo.”
Common mistake: Presumir de ‘número de alertas’ como si fuera éxito.