Entrevista de ciberseguridad: preguntas técnicas para perfiles junior

Respuesta rápida: qué evalúa una entrevista junior #

No existe una lista oficial de capacidades que todas las empresas evalúen igual. El peso de redes, sistemas, cloud, SOC, AppSec, pentesting o GRC depende del puesto. Como checklist editorial orientativo, una preparación sólida suele cubrir cinco dimensiones:

• Fundamentos: poder explicar qué está ocurriendo y no solo nombrar una herramienta.
• Razonamiento: separar hechos, hipótesis y datos que todavía faltan.
• Método: saber qué evidencia consultar a continuación y por qué.
• Límites: reconocer cuándo no sabes un detalle, cuándo necesitas autorización y cuándo debes escalar.
• Comunicación: explicar una decisión técnica de forma comprensible y trazable.

La entrevista empieza antes de la llamada. Si todavía estás construyendo la candidatura, separa cada problema: estrategia para conseguir el primer trabajo, CV de ciberseguridad sin experiencia y portfolio como evidencia de lo que sabes hacer. Esta URL se centra únicamente en la fase de entrevista.

PISTA: un modelo propio para ordenar escenarios técnicos #

PISTA es un modelo pedagógico propio de Achirou; no es un estándar de NIST, MITRE, ENISA ni una metodología obligatoria de entrevista. Sirve para evitar respuestas impulsivas cuando te plantean un escenario incompleto.

Una buena respuesta puede ser: «Con esa alerta todavía no concluiría compromiso. Primero validaría proceso padre, usuario, línea de comandos y conexiones; después decidiría según el contexto y el playbook». Eso muestra método sin fingir certeza.

Bloque 1: redes y protocolos de comunicación — 10 preguntas #

Redes es una base transversal, pero no existe un “filtro principal” idéntico para todas las vacantes. Si este bloque te cuesta, refuerza primero redes para ciberseguridad.

1. ¿Cuál es la diferencia entre TCP y UDP? TCP ofrece un flujo de bytes orientado a conexión con entrega fiable y ordenada; UDP envía datagramas sin establecer una conexión y no garantiza por sí mismo entrega ni orden. Que una aplicación sea “segura” no depende de elegir TCP o UDP. Referencias: TCP (RFC 9293) y UDP (RFC 768).
2. ¿Cómo funciona el three-way handshake de TCP? En el establecimiento normal de una conexión, un extremo envía SYN, el otro responde SYN-ACK y el primero confirma con ACK. Después ambos pueden intercambiar datos dentro de la conexión.
3. ¿Qué ocurre cuando escribes una URL HTTPS en el navegador? De forma simplificada: el cliente resuelve el nombre, elige una ruta y transporte, establece la conexión segura, envía la petición HTTP y procesa la respuesta. No siempre existe un handshake TCP: HTTP/1.1 y HTTP/2 suelen usar TCP, mientras HTTP/3 usa QUIC, que funciona sobre UDP e integra TLS 1.3 en QUIC.
4. ¿Qué es DNS y qué significa que “falle DNS”? DNS relaciona nombres con información como direcciones. Un fallo de resolución puede impedir acceder por nombre aunque el servicio siga funcionando; eso no implica que siempre sea accesible directamente por IP, porque TLS, virtual hosting, políticas o la propia arquitectura pueden requerir el nombre.
5. ¿Qué diferencia hay entre una IPv4 privada y una pública? RFC 1918 reserva 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 para redes privadas. Esos prefijos no tienen significado global y no deben propagarse como rutas públicas de Internet.
6. ¿Qué es NAT? Es traducción de direcciones de red. Puede modificar direcciones y, según la variante, también puertos. El patrón doméstico de muchos equipos compartiendo una dirección pública mediante traducción de puertos es común, pero no define todos los tipos de NAT.
7. ¿Qué es un puerto? En TCP y UDP es un identificador de 16 bits que ayuda a demultiplexar comunicaciones hacia aplicaciones o servicios. Memorizar listas enormes aporta menos que entender qué protocolo esperas, por qué y cómo comprobarlo.
8. ¿Switch, router y firewall son lo mismo? No. Como simplificación didáctica: un switch conecta segmentos a nivel de enlace, un router reenvía paquetes entre redes y un firewall aplica una política de control de tráfico. En equipos reales estas funciones pueden coexistir y operar en varias capas.
9. ¿IDS e IPS? IDS se usa para detectar y alertar; IPS añade capacidad de prevención o bloqueo. La implementación concreta depende del producto: no conviertas “pasivo” e “inline” en una regla absoluta para toda arquitectura.
10. ¿HTTP y HTTPS? HTTPS aplica HTTP sobre un canal protegido por TLS o, en HTTP/3, por QUIC con TLS integrado. El objetivo es proteger confidencialidad e integridad en tránsito y autenticar al servidor mediante el modelo de certificados correspondiente.

Bloque 2: sistemas operativos e identidad — 8 preguntas #

1. ¿Proceso y servicio? Un proceso es una instancia de un programa en ejecución. Un servicio es una función gestionada por el sistema para prestar una capacidad, normalmente en segundo plano; puede estar implementada por uno o varios procesos.
2. ¿Qué significan rwxr-x--- en Linux? El propietario tiene lectura, escritura y ejecución; el grupo, lectura y ejecución; otros no tienen permisos en ese conjunto de bits. Después conviene explicar que ACL, capacidades y otros mecanismos pueden añadir contexto.
3. ¿Qué es Active Directory Domain Services? AD DS es el servicio de directorio de Microsoft para almacenar y organizar objetos de red como usuarios y equipos y permitir su administración. Consulta la descripción oficial de Microsoft.
4. ¿Qué es un Domain Controller? Es un servidor que ejecuta AD DS para un dominio y participa en funciones como directorio y autenticación. Evita reducirlo a “el servidor que valida todas las contraseñas”: un entorno de identidad real incluye múltiples servicios y protocolos.
5. ¿Autenticación y autorización? Autenticación establece o verifica una identidad; autorización determina qué acciones o recursos están permitidos para esa identidad.
6. ¿MFA elimina el riesgo de compromiso? No. Añadir factores independientes reduce ciertos riesgos, pero la resistencia depende de los factores, el protocolo, la implementación y el ataque. En una entrevista es mejor explicar el modelo de amenaza que afirmar que “MFA = cuenta segura”.
7. ¿Principio de mínimo privilegio? NIST lo define como restringir autorizaciones y recursos al mínimo necesario para desempeñar la función. No implica por sí solo un tiempo concreto de concesión; el acceso temporal o JIT es una implementación adicional. Fuente: NIST Glossary.
8. ¿Qué indica el evento 4624 de Windows? Microsoft documenta el 4624 como creación de una sesión de inicio de sesión correcto en el equipo de destino. Hay que interpretar campos como usuario, tipo de logon, origen y paquete de autenticación; el ID aislado no demuestra legitimidad. Fuente: Microsoft Learn.

Bloque 3: fundamentos de seguridad, amenazas y riesgo — 7 preguntas #

1. ¿Vulnerabilidad, amenaza y riesgo? Vulnerabilidad es una debilidad; amenaza es una circunstancia o actor capaz de causar daño; riesgo combina el escenario, su probabilidad o posibilidad y sus consecuencias según la metodología empleada. No existe una fórmula universal obligatoria “probabilidad × impacto” para todos los contextos.
2. ¿CVE y CVSS? CVE proporciona identificadores para vulnerabilidades publicadas; CVSS comunica características y severidad. En CVSS v4.0 existen grupos Base, Threat, Environmental y Supplemental. Un Base score no equivale por sí solo al riesgo empresarial. Consulta la guía de CVE/CVSS y la especificación oficial de FIRST.
3. ¿Cifrado, hashing y encoding? Cifrado busca confidencialidad mediante claves y es reversible con la clave adecuada; una función hash produce un resumen no pensado para revertirse; encoding cambia representación y no aporta confidencialidad. Para contraseñas se emplean esquemas específicos de password hashing/KDF con sal y parámetros de coste, no un hash genérico sin contexto.
4. ¿Tríada CIA? Confidencialidad, integridad y disponibilidad son tres objetivos clásicos de seguridad. Úsalos para razonar impactos, no como lista decorativa.
5. ¿Falso positivo? Una detección o clasificación que señala actividad maliciosa cuando el caso investigado resulta benigno según el criterio definido.
6. ¿Falso negativo? Actividad relevante que el mecanismo de detección no identifica como tal. Su impacto depende del contexto; no existe una jerarquía universal entre tipos de fallo de detección.
7. ¿Evento, alerta e incidente? En operación suele distinguirse entre telemetría/evento, una alerta generada por lógica de detección y un incidente que requiere gestión o respuesta. Las definiciones exactas cambian entre organizaciones y marcos; no asumas que toda alerta confirmada se convierte automáticamente en “incidente”.

Bloque 4: SIEM, EDR y MITRE ATT&CK — 5 preguntas #

Si el puesto es defensivo, profundiza después en qué necesita saber un analista SOC. No existe un stack universal que todas las empresas usen.

1. ¿Qué es un SIEM? Una plataforma orientada a recopilar, consultar y correlacionar eventos de seguridad y apoyar detección e investigación. Las funciones concretas —normalización, reglas, analítica, retención o automatización— dependen del producto y del despliegue.
2. ¿Qué logs enviarías a un SIEM? La respuesta correcta empieza por el caso de uso. Identidad, endpoints, DNS, proxy, VPN, firewalls, cloud y aplicaciones son fuentes habituales, pero la prioridad depende de riesgos, activos, detecciones y capacidad de ingestión.
3. ¿EDR frente a antivirus? EDR pone énfasis en telemetría, detección, investigación y respuesta en endpoints. Los productos modernos se solapan mucho con antimalware/NGAV; evita afirmar que “antivirus solo usa firmas” como frontera universal.
4. ¿Qué es MITRE ATT&CK? ATT&CK es una base de conocimiento de comportamiento adversario. MITRE define las tácticas como el “por qué” u objetivo táctico y las técnicas como el “cómo” para alcanzar esos objetivos.
5. ¿IOC y TTP? Un IOC es un indicador observable que puede apoyar una investigación; una TTP describe patrones de comportamiento y forma de operar. Los IOC no son necesariamente “estáticos” ni todas las TTP son inmutables: la utilidad depende de contexto, vigencia y calidad de la inteligencia.

Bloque 5: escenarios de SOC y triaje — 10 preguntas #

Estos escenarios son especialmente relevantes para vacantes SOC, pero no existe un porcentaje universal de entrevista dedicado a ellos. NIST publicó SP 800-61 Rev. 3 en 2025 y plantea la respuesta a incidentes integrada en la gestión del riesgo; úsalo como referencia, no como guion literal de entrevista.

1. Múltiples intentos de inicio de sesión fallidos. Determina alcance, cuentas afectadas, origen, ventana temporal y si existe autenticación correcta posterior. Formula hipótesis como password spraying solo cuando el patrón la apoye.
2. Correo de phishing reportado. Preserva el mensaje, revisa cabeceras y autenticación, dominio, URLs y adjuntos con herramientas aprobadas y sin interactuar de forma insegura con recursos sospechosos. Busca alcance en otros buzones y eventos. Puedes ampliar con análisis técnico de phishing.
3. PowerShell con contenido codificado. Conserva la evidencia y analiza línea de comandos, proceso padre, usuario, árbol de procesos y conexiones. Decodificar Base64 no equivale a ejecutar el contenido: hazlo de forma segura y separada.
4. Conexión a una IP marcada por Threat Intelligence. Comprueba qué proceso la inició, momento, dirección del flujo, resultado de la conexión, datos asociados y calidad/vigencia del indicador. Un match de IP no prueba compromiso por sí solo.
5. “Viaje imposible”. Valida VPN/proxy, dispositivo, método de autenticación, sesión, geolocalización aproximada y actividad correlacionada. Trata la alerta como señal que requiere contexto.
6. Ransomware confirmado. Sigue el plan autorizado de respuesta y coordina contención, continuidad y preservación de evidencia. La urgencia puede exigir aislar sistemas, pero no existe una secuencia universal independiente del entorno. NIST SP 800-61r3 enfatiza integrar respuesta, detección y recuperación. Amplía en respuesta Blue Team ante ransomware.
7. Muchas alertas simultáneas. Prioriza combinando impacto potencial, criticidad del activo, confianza de la detección, alcance y evidencia de actividad en curso. Un Domain Controller no “va siempre primero” si otra alerta representa un daño activo mayor.
8. Cerrar un falso positivo. Deja evidencia suficiente para reproducir la decisión, documenta por qué el comportamiento es benigno en ese contexto y propone tuning si mejora la detección sin ocultar actividad relevante.
9. No hay telemetría suficiente. Declara la incertidumbre, busca fuentes alternativas, registra la carencia de visibilidad y escala si el riesgo o las acciones necesarias exceden tus atribuciones.
10. ¿Qué significa escalar? Transferir o involucrar a la función que tenga autoridad, experiencia o capacidad necesaria según el proceso de la organización. No siempre existe una jerarquía L1 → L2 → CSIRT idéntica.

Bloque 6: seguridad web y pentesting — 6 preguntas #

Para puestos ofensivos o AppSec, el conocimiento esperado cambia mucho. Si esa es tu meta, deriva la preparación profunda a qué aprender antes de hacking ético en lugar de intentar convertir esta guía de entrevistas en un curso de pentesting.

1. ¿Qué es SQL Injection y cómo se reduce el riesgo? Ocurre cuando datos no confiables alteran la estructura o semántica de una consulta. Las consultas parametrizadas son una defensa central; validación, diseño y mínimo privilegio complementan la protección. Un ORM no es automáticamente seguro si permite construir consultas inseguras.
2. ¿Qué es XSS? Es una clase de vulnerabilidades en la que contenido no confiable termina ejecutándose como código activo en el contexto del navegador. Reflected, stored y DOM-based describen formas comunes, pero la prevención depende de contexto de salida, APIs y diseño.
3. ¿Qué es Broken Access Control? Es una categoría de fallos donde se incumplen restricciones sobre qué puede hacer un usuario. En la edición vigente, OWASP Top 10:2025 la sitúa como A01:2025. No memorices el número sin comprender autorización horizontal, vertical y acceso a objetos.
4. ¿Una autenticación fuerte garantiza una aplicación segura? No. Autenticación es solo una parte: autorización, configuración, dependencias, lógica de negocio, validación, logging y otros controles siguen siendo necesarios.
5. ¿Qué haces antes de comenzar un pentest? Confirmar autorización, alcance, objetivos, límites y reglas de interacción. NDA, ventanas horarias o procedimientos de emergencia pueden existir, pero dependen del acuerdo; no los presentes como una secuencia universal.
6. ¿Qué haces si detectas algo fuera del alcance? No continúes probando ese activo por iniciativa propia. Registra lo mínimo necesario y sigue el canal y las Rules of Engagement acordadas para notificar y obtener instrucciones.

Bloque 7: gobernanza, riesgo y cumplimiento — 4 preguntas #

Si optas a GRC, esta sección es solo una comprobación básica; la profundidad pertenece a la guía de GRC y al roadmap GRC.

1. ¿Riesgo y control? Un riesgo describe un escenario de incertidumbre con consecuencias sobre objetivos; un control es una medida para modificar o gestionar ese riesgo. No todos los controles “eliminan” el riesgo.
2. ¿Qué es evidencia de control? Información verificable que permite evaluar diseño u operación de un control: configuraciones, registros, tickets, aprobaciones, muestras, políticas o resultados de pruebas, según el control.
3. ¿Qué es un gap assessment? Comparación estructurada entre un estado observado y un conjunto de requisitos, objetivos o criterios. El significado cambia si comparas contra ISO 27001, ENS, una política interna u otra referencia.
4. ¿Quién acepta un riesgo residual? La autoridad designada por el modelo de gobierno de la organización —por ejemplo, un risk owner o responsable autorizado—. Un analista junior no debería inventar esa autoridad ni asumir que siempre corresponde al propietario técnico del activo.

Cómo responder sobre tus proyectos y errores técnicos #

Tu portfolio tiene valor cuando puedes defender decisiones. Una estructura útil es Contexto → Decisión → Evidencia → Resultado → Aprendizaje. Es una heurística de comunicación, no un estándar de selección. Explica qué intentabas resolver, qué alternativas consideraste, qué comprobaste y qué cambiarías hoy.

Si te preguntan por un error, evita el relato perfecto. Un fallo real de laboratorio —una regla de firewall demasiado restrictiva, un servicio que dejaste inaccesible o una detección ruidosa— permite demostrar troubleshooting si puedes explicar cómo aislaste la causa y verificaste la corrección.

Qué responder cuando no sabes el dato exacto #

No inventes. Distingue lo que sabes de lo que necesitas confirmar: «No recuerdo el valor exacto. Sé que está relacionado con X; comprobaría la documentación oficial y validaría Y en los logs antes de decidir». Si la pregunta es de seguridad operativa, añade qué acción evitarías hasta tener autorización o evidencia suficiente.

Decir “no lo sé” con un siguiente paso verificable es más defendible que construir una explicación falsa con seguridad aparente.

Qué conviene memorizar y qué conviene comprender #

No necesitas recitar todos los puertos, todos los Event IDs, todos los flags de una herramienta o el Top 10 completo como una poesía. Sí conviene reconocer los conceptos y referencias que usas con frecuencia y saber cómo verificar lo que no recuerdas.

• Memoriza lo suficiente para razonar sin bloquearte: TCP/UDP, DNS, HTTP(S), identidad, permisos, CIA, riesgo, logs y tu especialidad.
• Comprende relaciones: qué evidencia confirmaría una hipótesis, qué dato falta y qué acción podría causar daño.
• Practica explicar tus propios proyectos sin documentación delante.
• Repasa la vacante concreta: una entrevista SOC no debería prepararse igual que una entrevista GRC o pentesting.

Preguntas útiles que tú puedes hacer al entrevistador #

• ¿Qué problemas o tareas ocuparán más tiempo en este puesto durante los primeros meses?
• ¿Qué fuentes de datos, herramientas o plataformas usa realmente el equipo?
• ¿Cómo se documentan y escalan los casos que superan las atribuciones de un perfil junior?
• ¿Cómo revisan el trabajo técnico y qué apoyo existe para aprender el entorno?
• ¿Qué distinguiría una buena incorporación a este puesto después del periodo inicial?

Estas preguntas sirven para entender el trabajo real; no son un guion obligatorio ni garantizan una mejor evaluación.

Plan orientativo de 7 sesiones de preparación #

El siguiente plan es un modelo pedagógico propio y flexible. “Siete sesiones” no significa siete días ni promete estar preparado en una semana. Puedes repetir, dividir o eliminar sesiones según tu base y la vacante.

Si tus lagunas están en fundamentos generales de seguridad, el CTA de esta guía apunta a Security+ porque es el curso principal definido para esta URL. Si el problema es específicamente redes, Linux o una especialidad, corrige esa brecha concreta en lugar de acumular cursos.

Fuentes primarias y conclusión: razonar vale más que recitar #

Las 50 preguntas de esta guía son una selección editorial para practicar, no un banco oficial ni una predicción de lo que preguntará una empresa. Una entrevista sólida se prepara cruzando la vacante, tus proyectos y las fuentes que definen realmente cada concepto.

Para verificar los puntos más sensibles de esta revisión se utilizaron fuentes primarias: RFC Editor para TCP, UDP, IPv4 privada y HTTP/3; Microsoft Learn para AD DS y Event 4624; NIST para mínimo privilegio e Incident Response; FIRST para CVSS v4.0; MITRE para ATT&CK; y OWASP para Top 10:2025.

• OWASP Top 10:2025
• MITRE ATT&CK — Enterprise Tactics
• NIST SP 800-61 Rev. 3
• FIRST — CVSS v4.0 Specification
• Microsoft — Event 4624

Si todavía no tienes claro qué tipo de puesto estás preparando, vuelve al mapa de trabajos y perfiles de ciberseguridad; después regresa aquí y practica únicamente los bloques que correspondan al rol.