Preguntas de entrevista Ingeniero de seguridad

El modelado de amenazas es más valioso cuando se realiza de forma colaborativa con el equipo de ingeniería durante la fase de diseño, antes de que se escriba ningún código, porque ahí es cuando los cambios son más baratos. Uso el framework STRIDE como punto de partida estructurado: Suplantación, Manipulación, Repudio, Divulgación de información, Denegación de servicio y Elevación de privilegios. Repaso cada componente del sistema con el equipo, identificando activos, límites de confianza y flujos de datos, luego pregunto sistemáticamente qué podría salir mal para cada categoría STRIDE. Capturo las amenazas en un documento de modelado de amenazas que mapea cada amenaza a una calificación de probabilidad e impacto y, crucialmente, a una mitigación específica. Las mitigaciones se convierten en requisitos de seguridad que alimentan el backlog de desarrollo. También reviso el modelo de amenazas en los cambios de diseño clave, porque un modelo que refleja la arquitectura original pero no la actual da una falsa confianza.

Una prueba de penetración útil comienza con un alcance claro y un modelo de amenazas, no con un ejercicio de escaneo genérico. Los mejores pentests son dirigidos: simulan los caminos de ataque más probables para el sistema específico. Abordo los pentests en fases: reconocimiento para entender la superficie de ataque, escaneo y enumeración para identificar servicios y versiones, identificación de vulnerabilidades, explotación de los hallazgos, y post-explotación para entender el radio de explosión de una compromisión. Lo que distingue los resultados útiles es la especificidad: un hallazgo que dice "inyección SQL en el endpoint de inicio de sesión a través del parámetro de nombre de usuario, explotable para extraer la tabla de usuarios" es accionable. También insisto en las pruebas de regresión después de la remediación para verificar que el arreglo es efectivo. Para la seguridad continua prefiero una combinación de DAST automatizado en CI/CD y ejercicios periódicos de red team.

Zero-trust significa que cada solicitud se autentica y autoriza independientemente de su origen, incluido desde dentro de la red corporativa. La implementación práctica tiene varios componentes. Primero, identidad fuerte para cada usuario y servicio: uso SSO con MFA para usuarios humanos e identidad de carga de trabajo (roles IAM de AWS, cuentas de servicio de Kubernetes) para la comunicación máquina a máquina. Segundo, verificación de confianza del dispositivo mediante una solución MDM. Tercero, micro-segmentación: en lugar de confiar en todo dentro de una VPN, uso tecnología de service mesh o una API gateway para exigir que cada llamada de servicio esté autenticada. Cuarto, verificación continua: no otorgo acceso permanente; uso tokens de corta duración y validación de sesión para que las credenciales comprometidas tengan un radio de explosión limitado. La transición a zero-trust es gradual y requiere la aceptación de los equipos de ingeniería.

Integrar la seguridad en el SDLC significa hacer de la seguridad el camino de menor resistencia en lugar de una barrera al final. En la fase de diseño, dirijo talleres de modelado de amenazas con los equipos de ingeniería y publico patrones de seguridad reutilizables que los equipos pueden adoptar sin reinventarlos cada vez. En la fase de desarrollo, integro herramientas SAST en el IDE y el pipeline de CI para que las vulnerabilidades comunes como la inyección SQL y el XSS se marquen en el punto de introducción. También mantengo una guía de codificación segura referenciada en las plantillas de revisión de código. En la fase de despliegue, uso escaneo automatizado de infraestructura con Checkov y Trivy. La clave para que todo esto funcione es la experiencia del desarrollador: si las herramientas de seguridad añaden fricción significativa sin un valor claro, los equipos encontrarán formas de evitarlas.

Detectamos una anomalía en nuestro SIEM a las 2am: una cuenta de servicio interna estaba haciendo llamadas API a un endpoint externo que no estaba en nuestra lista de permitidos, a una tasa consistente con la exfiltración de datos. Seguí el playbook de respuesta a incidentes: contener primero, luego investigar. Revoqué inmediatamente las credenciales de la cuenta de servicio y aislé el servicio afectado de la red, luego convoqué al equipo de respuesta a incidentes. La investigación reveló que una dependencia en nuestro pipeline de build había sido comprometida en un ataque a la cadena de suministro y estaba exfiltrando variables de entorno. Realizamos una auditoría completa de los secretos potencialmente expuestos y los rotamos todos como precaución. La revisión post-incidente llevó a varias mejoras sistémicas. El tiempo desde la detección hasta la contención fue de 22 minutos.

Encontré una vulnerabilidad de tipo SSRF (Server-Side Request Forgery) en una herramienta de administración interna. El equipo de ingeniería la calificó de baja prioridad porque la herramienta era solo interna y requería inicio de sesión. Mi análisis mostró que el SSRF era explotable para alcanzar el endpoint de metadatos de instancia de AWS, lo que permitiría a un atacante con cualquier acceso interno obtener credenciales IAM y escalar a acceso completo a la cuenta AWS. Preparé una nota de una página con una demostración de prueba de concepto en un entorno de staging y una cadena de ataque clara: desde un correo de phishing a un empleado hasta el acceso a los datos de S3. Hacer concreto el camino de ataque completo movió la conversación de "¿es esto teóricamente posible?" a "¿qué tan rápido podemos arreglarlo?" El equipo priorizó el arreglo en el siguiente sprint.

Lideré la implementación de un programa de escaneo de secretos en nuestra organización de ingeniería. Antes del programa, no había detección sistemática de secretos confirmados en el control de versiones. Empecé con un escaneo retrospectivo de todo nuestro historial de Git usando truffleHog, que reveló 47 secretos únicos en 12 repositorios durante un período de tres años. Validé cada hallazgo, confirmé que 31 eran válidos y potencialmente aún activos, y coordiné su rotación con los equipos relevantes en dos semanas. Luego configuré hooks de pre-commit y una barrera de CI usando GitLeaks que bloqueaba cualquier commit que contuviera un patrón de secreto detectado. Seis meses después, la barrera de CI había bloqueado 23 commits accidentales de secretos. El programa me costó unas tres semanas de trabajo implementarlo y ahora es una parte permanente de nuestro flujo de desarrollo.

Un SIEM solo es tan útil como la calidad de sus reglas y la velocidad de su proceso de respuesta. Empiezo identificando los escenarios de mayor riesgo que el SIEM necesita detectar, basándome en el modelo de amenazas: robo de credenciales, movimiento lateral, exfiltración de datos y escalada de privilegios son las categorías principales. Luego identifico las fuentes de logs que evidenciarían cada escenario y las ingiero en el SIEM con una capa de normalización de datos. Para la sintonización de alertas, empiezo con reglas de alta fidelidad y bajo volumen en lugar de intentar capturarlo todo de inmediato, porque la fatiga de alertas mata la calidad de respuesta. Sintonizo cada regla durante dos semanas revisando cada alerta para entender la tasa de falsos positivos, luego ajusto umbrales hasta que la tasa de falsos positivos sea inferior al 10%. También construyo informes semanales sobre tendencias de postura de seguridad, no solo alertas en tiempo real.

La gestión de vulnerabilidades es un problema de priorización, no de escaneo. Cada organización tiene más vulnerabilidades de las que puede corregir, así que la disciplina es decidir qué corregir primero y qué aceptar como riesgo. Mi enfoque comienza con escaneo continuo usando un escáner basado en agentes autenticados, combinado con análisis de composición de software para las dependencias de aplicaciones. No trato las puntuaciones CVSS solas como la señal de prioridad: una vulnerabilidad CVSS crítica en un sistema aislado sin acceso externo tiene menor prioridad que una vulnerabilidad CVSS alta en un servicio de producción orientado al cliente. Calculo la prioridad combinando severidad, explotabilidad, exposición y criticidad del activo. Comunico SLAs a los equipos de ingeniería por nivel de riesgo: crítico con exploit público en activos orientados a Internet obtiene 48 horas; alta severidad obtiene 7 días; media obtiene 30 días.

Los frameworks de cumplimiento a menudo se implementan como un ejercicio de documentación separado de la práctica real de seguridad, lo que crea lo peor de ambos mundos: carga sin protección. Mi enfoque es construir controles que estén automatizados y evidenciados por salidas del sistema en lugar de por atestaciones manuales siempre que sea posible. Para SOC 2 Tipo II, mapeo cada requisito de control a una verificación automatizada o un log del sistema que prueba que el control está funcionando, para que el paquete de evidencias se genere a partir de la instrumentación existente en lugar de ensamblarse manualmente. Por ejemplo, la evidencia de control de acceso proviene de las exportaciones de políticas IAM; la evidencia de gestión de cambios proviene del rastro de auditoría CI/CD. Uso una herramienta GRC para mantener el mapeo de controles. También involucro a los equipos de ingeniería en el diseño de controles.