Analista de ciberseguridad Preguntas de entrevista & Respuestas

Respuesta modelo

Detecté tráfico saliente anómalo desde una estación de trabajo a las 2 de la madrugada a través de las alertas de nuestro SIEM: 500 MB enviados a una IP desconocida por un canal cifrado. Aislé la estación de trabajo de la red de inmediato y comencé la investigación. El análisis forense de memoria reveló un beacon de Cobalt Strike activo desde hacía 3 días, probablemente entregado mediante un correo de spear-phishing con una macro maliciosa. Rastreé el movimiento lateral hasta 2 estaciones de trabajo adicionales; ninguna había accedido a almacenes de datos sensibles. Contuve todos los sistemas afectados, restablecí las credenciales de las cuentas comprometidas y coordiné con el equipo de seguridad del correo para bloquear el dominio de phishing. El tiempo total de contención fue de 4,5 horas. Tras el incidente, implementé políticas de bloqueo de macros en Office, añadí reglas de detección de comportamiento para patrones de beaconing C2 y realicé formación específica de concienciación sobre phishing. No hubo más incidentes de ese actor de amenazas.

Respuesta modelo

Durante una revisión rutinaria de nuestra aplicación web, observé que el flujo de restablecimiento de contraseña enviaba un token por correo electrónico, pero ese token no expiraba tras su uso. Lo verifiqué y confirmé: el mismo token de restablecimiento podía usarse varias veces durante hasta 24 horas. El equipo de desarrollo se había centrado en implementar la expiración del token por tiempo, pero omitió el requisito de uso único. Redacté el hallazgo con una prueba de concepto clara que mostraba cómo un atacante con acceso al correo de alguien podría usar un token caducado días después. La valoré como gravedad media, ya que requería acceso al correo, pero de urgencia alta porque la corrección era sencilla. El equipo desplegó la corrección en una sola línea (invalidar el token tras su uso) en 2 horas. Después revisé todos los demás flujos basados en tokens y encontré un problema similar en el flujo de verificación de correo electrónico, que corregimos en el mismo sprint.

Respuesta modelo

Quería implementar una solución de gestión de accesos privilegiados (PAM) porque teníamos más de 40 cuentas de administrador compartidas sin ningún registro de auditoría. La dirección lo veía como un gasto de 60.000 $ sin un retorno visible. Reformulé la conversación: calculé el coste de una brecha por escalada de privilegios usando datos del sector (una media de 4,5 millones de dólares para el tamaño de nuestra empresa), lo multipliqué por la probabilidad estimada en función de nuestros controles actuales y presenté la pérdida esperada. También mostré 3 hallazgos recientes de auditoría que citaban las credenciales compartidas como riesgo, algo que podría afectar a nuestra certificación SOC 2, un requisito del 70% de nuestros clientes empresariales. Por último, mostré el coste operativo: 15 horas mensuales dedicadas a rotar manualmente las credenciales compartidas. La solución PAM se amortizaría en ahorros de tiempo de gestión de credenciales en 14 meses. La dirección la aprobó. La conclusión: las inversiones en seguridad deben enmarcarse en términos de riesgo empresarial y eficiencia operativa, no de miedo técnico.

Respuesta modelo

Sigo un enfoque estructurado de inteligencia de amenazas. A diario: reviso fuentes curadas de CISA, Krebs on Security y The Record. Semanalmente: dedico 2 horas a laboratorios prácticos, salas de TryHackMe, retos de HackTheBox o reproducción de exploits de CVEs recientes en mi laboratorio doméstico. Mensualmente: asisto a la reunión de mi capítulo local de OWASP y participo en un grupo online de intercambio de inteligencia de amenazas con profesionales de seguridad de 15 empresas. Trimestralmente: hago un curso monográfico. El trimestre pasado fue seguridad en la nube con AWS; este trimestre, análisis de malware con Ghidra. Cuando cae una vulnerabilidad importante como Log4Shell, evalúo nuestra exposición de inmediato, creo reglas de detección e informo al equipo. Este enfoque ha dado sus frutos varias veces: tuve reglas de detección para la vulnerabilidad de MOVEit listas en 6 horas desde su divulgación porque venía siguiendo los TTPs del actor de amenazas a través de mis fuentes de inteligencia.

Respuesta modelo

MITRE ATT&CK es una base de conocimiento de tácticas, técnicas y procedimientos (TTPs) de los adversarios, organizada por fases del ciclo de vida de un ataque: acceso inicial, ejecución, persistencia, escalada de privilegios, evasión de defensas, acceso a credenciales, descubrimiento, movimiento lateral, recolección, exfiltración y mando y control. Lo utilizo de tres formas. Primero, para ingeniería de detección: mapeo las reglas de detección de nuestro SIEM con las técnicas de ATT&CK para identificar brechas de cobertura. Si descubro que no tenemos detecciones para T1055 (inyección de procesos), priorizo la construcción de esas reglas. Segundo, para threat hunting: uso ATT&CK para estructurar búsquedas basadas en hipótesis. Si la inteligencia de amenazas indica que un grupo APT concreto está atacando nuestro sector, busco sus TTPs documentados en nuestro entorno. Tercero, para investigación de incidentes: cuando detecto una técnica, ATT&CK me indica qué hizo probablemente el adversario antes y qué hará después, lo que me ayuda a acotar la investigación con mayor eficiencia.

Respuesta modelo

El cifrado simétrico utiliza la misma clave para cifrar y descifrar: es rápido, pero requiere un intercambio seguro de claves. AES-256 es el estándar. Ejemplo real: cifrado de datos en reposo en una base de datos. El servidor de aplicaciones guarda la clave y cifra o descifra los datos al leer y escribir. El cifrado asimétrico usa un par de claves: la clave pública cifra y la clave privada descifra. Es más lento, pero resuelve el problema del intercambio de claves. RSA y ECDH (para el intercambio de claves) son los algoritmos habituales. Ejemplo real: el handshake TLS. Cuando visitas un sitio web, tu navegador usa la clave pública del servidor para establecer una clave de sesión compartida y luego cambia al cifrado simétrico para la transferencia real de datos. Este enfoque híbrido combina la seguridad del cifrado asimétrico para el intercambio de claves con la velocidad del cifrado simétrico para grandes volúmenes de datos. En la práctica, siempre recomiendo AES-256 para datos en reposo, TLS 1.3 para datos en tránsito, y una gestión adecuada de claves mediante servicios como AWS KMS, en lugar de almacenar las claves junto a los datos que protegen.

Respuesta modelo

Seguiría un proceso de investigación estructurado. Primero, alcance: identificar el origen de la alerta y los indicadores iniciales, como volumen inusual de datos hacia una IP externa, patrones de DNS tunneling o acceso no autorizado a almacenamiento en la nube. Preservar las evidencias de inmediato: captura instantánea de los sistemas afectados, registros de red y anotación de la línea temporal. Segundo, análisis: revisar en el SIEM la línea temporal completa de actividad del usuario o sistema de origen. ¿A qué datos se accedió? ¿Cuándo comenzó el comportamiento anómalo? ¿Es la IP de destino conocida como maliciosa? Cruzar con alertas de DLP, registros de endpoints y logs de autenticación. Tercero, determinar: ¿se trata de una exfiltración real, una transferencia de datos autorizada o un falso positivo? Consultaría al propietario de los datos y al responsable del usuario antes de escalar. Cuarto, si se confirma que es malicioso: aislar los sistemas afectados, deshabilitar las cuentas comprometidas, bloquear el canal de exfiltración e iniciar el plan de respuesta a incidentes, incluida la notificación legal y de cumplimiento. Quinto, documentar todo en el sistema de seguimiento de incidentes con línea temporal, evidencias y cadena de custodia. Los primeros 30 minutos son críticos: la velocidad de contención se correlaciona directamente con el volumen de datos perdidos.

Respuesta modelo

Zero Trust opera bajo el principio de no confiar nunca y verificar siempre: sin confianza implícita basada en la ubicación de red, el dispositivo o la identidad del usuario. Cada solicitud de acceso se autentica, autoriza y cifra independientemente de su origen. Implementación por fases. Primera, identidad: autenticación robusta para todos los usuarios (MFA obligatorio, preferiblemente resistente al phishing como FIDO2). Acceso de mínimo privilegio con aprovisionamiento justo a tiempo. Segunda, dispositivo: asegurarse de que los dispositivos cumplen las líneas base de seguridad (sistema operativo parcheado, protección de endpoints, cifrado) antes de conceder acceso. Evaluación de la postura del dispositivo en cada conexión. Tercera, red: microsegmentación para limitar el movimiento lateral. Sustituir la VPN por proxies con reconocimiento de identidad (como BeyondCorp o Zscaler) que conceden acceso por aplicación. Cuarta, datos: clasificar los datos, cifrarlos en reposo y en tránsito e implementar controles DLP. Quinta, monitorización: verificación continua. No basta con autenticar en el inicio de sesión; hay que supervisar el comportamiento durante toda la sesión. El comportamiento anómalo activa la reautenticación o la revocación del acceso. Implementaría esto de forma incremental, comenzando por los sistemas más sensibles y ampliando el alcance a lo largo de 12 a 18 meses.

Respuesta modelo

Lo abordaría con cuidado, porque podría ser desde un error de configuración de control de acceso hasta una amenaza interna intencionada. Primero, verificaría el hallazgo en silencio: confirmar que los registros de acceso son precisos, comprobar si el rol del empleado cambió recientemente (un cambio de rol sin actualización de acceso es habitual) y determinar a qué datos se accedió. No alertaría al empleado. Segundo, escalaría a mi responsable de seguridad y a Recursos Humanos con evidencias documentadas: qué se accedió, cuándo, con qué frecuencia y si algún dato fue descargado o transferido al exterior. Tercero, según su orientación, trabajaría con IT para restringir el acceso de forma discreta (si parece un problema de control de acceso) o implementaría monitorización reforzada si se sospecha de amenaza interna. Preservaría todas las evidencias por si el asunto derivara en un proceso legal. La clave es la proporcionalidad de la respuesta: saltar a la conclusión de amenaza interna cuando lo que hay es una política RBAC rota genera dramatismo innecesario y daña la confianza.

Respuesta modelo

Acciones inmediatas (primera hora): evaluar nuestra exposición. ¿Es el componente vulnerable accesible desde internet? ¿A qué datos tiene acceso? ¿Hay un exploit conocido en circulación? Si somos activamente explotables, implementaría mitigaciones de emergencia: reglas WAF para bloquear patrones de exploit conocidos, restricciones a nivel de red para limitar el acceso al servicio vulnerable y desactivación de la funcionalidad afectada si el impacto en el negocio es asumible. A corto plazo (primer día): implementar monitorización para los indicadores específicos de explotación, aumentar el nivel de registro del sistema afectado y buscar signos de explotación pasada. Comunicación: informar a la dirección de seguridad y a los propietarios de los sistemas afectados con una evaluación clara del riesgo y el estado de las mitigaciones. A medio plazo: aplicar el parche del fabricante en cuanto esté disponible, tenerlo preparado y probado en staging para desplegarlo en cuestión de horas tras su publicación. Si no llega ningún parche en una semana, evaluar si migrar a una alternativa o implementar cambios arquitectónicos para aislar el riesgo. Durante todo el proceso: registrar la vulnerabilidad en nuestro registro de riesgos con los controles compensatorios documentados.

Respuesta modelo

Realizaría una evaluación estructurada del riesgo del proveedor. Primero, clasificación de datos: ¿qué datos de clientes procesará la herramienta? ¿Datos personales, financieros, de salud? Esto determina los requisitos regulatorios (RGPD, CCPA, HIPAA, PCI-DSS). Segundo, postura de seguridad del proveedor: solicitar su informe SOC 2 Tipo II, la certificación ISO 27001 y los resultados de sus pruebas de penetración. Revisar sus prácticas de cifrado de datos (en reposo y en tránsito), los controles de acceso y las capacidades de respuesta a incidentes. Tercero, revisión técnica: ¿cómo funciona la integración? ¿OAuth o autenticación por contraseña? ¿Qué permisos de API necesita? ¿Dónde se almacenan los datos geográficamente (relevante para el RGPD)? ¿Podemos aplicar SSO y MFA? Cuarto, revisión contractual: acuerdo de tratamiento de datos, plazos de notificación de brechas, cláusulas de propiedad y eliminación de datos, derecho de auditoría. Puntuaría al proveedor en una matriz de riesgo y presentaría una recomendación: aprobar, aprobar con condiciones (requisitos de seguridad específicos) o rechazar con alternativas. Si se aprueba con condiciones, fijaría una fecha de revisión para verificar su cumplimiento.

Respuesta modelo

Escalaría el riesgo con claridad, sin actitud confrontacional. Presentaría el hallazgo con una evaluación concreta: la gravedad de la vulnerabilidad (puntuación CVSS), la explotabilidad (¿existe un exploit público? ¿es explotable de forma remota?), los datos en riesgo y el impacto estimado en el negocio en caso de brecha. Propondría controles compensatorios para el período intermedio: segmentación de red para limitar la exposición, reglas WAF para bloquear patrones de ataque conocidos, monitorización y alertas reforzadas para intentos de explotación y reducción de permisos de acceso. Trabajaría con el responsable del sistema para entender por qué el parcheo tarda 3 meses: a veces el plazo es real (ventanas de cambio regulatorio, dependencias complejas); otras, es simple inercia de planificación. Si los controles compensatorios pueden reducir el riesgo a un nivel aceptable, documentaría el riesgo residual aceptado con la firma del responsable del sistema y su dirección. Si el riesgo es realmente crítico y ningún control compensatorio es suficiente, escalaría al CISO con una recomendación clara: a partir de ahí se convierte en una decisión de negocio, no solo técnica.