Preguntas de entrevista Especialista en ciberseguridad

Empiezo definiendo cuidadosamente el alcance: qué activos están incluidos, cuál sería el impacto de negocio de una interrupción y qué ventanas de mantenimiento están disponibles. Uso una combinación de herramientas de escaneo automatizadas como Nessus o Qualys para identificar CVEs conocidos y luego verifico manualmente para eliminar falsos positivos. En sistemas de producción priorizo primero las comprobaciones de solo lectura y no intrusivas, y programo cualquier prueba activa durante ventanas de bajo tráfico con el equipo de operaciones informado. Tras el escaneo, clasifico los hallazgos por puntuación CVSS y contexto de negocio, porque una puntuación crítica en un sistema solo interno representa un riesgo diferente al de la misma puntuación en una API expuesta a Internet. Todo queda documentado en un informe de remediación con responsabilidades y plazos claros.

He trabajado con Splunk y Microsoft Sentinel en entornos de producción, y con QRadar en un entorno de laboratorio. La fatiga de alertas es uno de los mayores retos prácticos en cualquier SOC. Mi enfoque es ajustar en el origen: reviso las reglas de alerta trimestralmente y suprimo o ajusto cualquier regla que no haya generado ningún verdadero positivo en 90 días. También creo reglas de correlación que agrupan alertas de baja fidelidad en un único incidente de mayor confianza, en lugar de saturar la cola con eventos individuales. Para nuevos entornos comienzo midiendo el tráfico normal durante dos a cuatro semanas antes de activar alertas por umbral. Monitorizo las tasas de falsos positivos por regla en un panel sencillo para que el equipo pueda ver qué reglas necesitan atención.

Sigo varios feeds de inteligencia de amenazas: el catálogo de vulnerabilidades explotadas conocidas de CISA, los avisos de seguridad de Microsoft y CrowdStrike, y fuentes comunitarias como SANS Internet Storm Center. Me suscribo a resúmenes semanales de Krebs on Security y The Hacker News para tener un contexto más amplio. En mi equipo dirijo una sesión mensual breve en la que analizamos juntos una brecha reciente o un CVE de actualidad y discutimos qué controles lo habrían detectado o limitado. También participo en competiciones CTF algunas veces al año para mantener mis habilidades prácticas en áreas como la ingeniería inversa. Documento las amenazas relevantes en nuestra base de conocimientos interna para que todo el equipo se beneficie.

En mi puesto anterior, nuestro SIEM lanzó una alerta un viernes a las 23h mostrando tráfico saliente inusual desde un controlador de dominio hacia una IP externa desconocida. Estaba de guardia. Inmediatamente aislé la máquina afectada de la red para contener la posible propagación, luego extraje los registros relevantes de Splunk de las 48 horas anteriores. En 20 minutos identifiqué que una cuenta de servicio había sido utilizada para ejecutar comandos PowerShell que exfiltraron un listado de directorio a un endpoint externo. Escalé al responsable de seguridad y abrí un ticket de incidente formal. Rastreamos el acceso inicial a un correo de phishing que había entregado un documento con macro tres días antes. Coordiné con IT el restablecimiento de credenciales, el parche del vector y un escaneo completo de endpoints similares. El incidente quedó contenido en cuatro horas. El post-mortem nos llevó a bloquear la ejecución de macros en todos los endpoints.

Durante una prueba de penetración interna de rutina descubrí que una aplicación web interna antigua era vulnerable a inyección SQL en su endpoint de inicio de sesión. La aplicación seguía procesando datos de RRHH de unos 400 empleados. Detuve inmediatamente las pruebas para evitar la extracción involuntaria de datos y documenté el payload exacto y la respuesta que confirmaban la vulnerabilidad, con capturas de pantalla, para que el equipo de desarrollo tuviese pasos de reproducción claros. Escalé al propietario de la aplicación y al CISO esa misma tarde a través de nuestro proceso de divulgación de vulnerabilidades, clasificándola como crítica. Recomendé poner la aplicación fuera de línea temporalmente mientras se preparaba un parche. Trabajé con el desarrollador para probar el parche en staging y lo validé en producción al día siguiente. El ciclo completo desde el descubrimiento hasta la corrección verificada tardó 36 horas.

Tenía la tarea de desplegar la autenticación multifactor en todos los entornos cloud. Un equipo de ingeniería se resistió con fuerza, argumentando que el MFA en las cuentas de servicio de su pipeline CI/CD rompería su flujo de despliegue. En lugar de escalar inmediatamente, programé tiempo con su responsable técnico para entender la fricción específica. Resultó que su preocupación era legítima: sus herramientas no admitían prompts MFA interactivos en pipelines automatizados. Investigué alternativas y propuse usar tokens de cuenta de servicio de vida corta con una lista de IPs permitidas estricta y rotación automatizada mediante HashiCorp Vault como control compensatorio, documentado en nuestro registro de brechas ISO 27001. El equipo de ingeniería apreció que hubiese tomado en serio su restricción. El resultado fue el despliegue completo en cuentas interactivas en dos semanas.

La autenticación es el proceso de verificar quién es un usuario o sistema. La autorización es el proceso que determina qué está permitido hacer a esa identidad verificada. Son controles distintos y los fallos en cada uno tienen consecuencias diferentes. Una vulnerabilidad de autenticación rota significa que un atacante puede suplantar completamente a un usuario legítimo. Una vulnerabilidad de autorización rota significa que un atacante ya autenticado puede acceder a recursos o realizar acciones que no debería poder, como acceder a los datos de otro usuario cambiando un ID en una URL. En el diseño de seguridad necesitas ambas: autenticación fuerte con MFA, gestión segura de sesiones y hashing de credenciales, combinada con un modelo de autorización bien definido usando control de acceso basado en roles. Un error común es asumir que la autenticación es suficiente: muchas brechas reales implican credenciales válidas usadas para acceder a datos que deberían haber tenido control de acceso pero no lo tenían.

Divido una prueba de penetración en cinco fases. Primero, alcance y reglas de enfrentamiento: acuerdo con el cliente qué está dentro del alcance, qué está excluido, qué métodos de prueba están permitidos y a quién llamar si algo sale mal. Segundo, reconocimiento: recopilo inteligencia de fuentes abiertas usando herramientas como Shodan, Amass y theHarvester para mapear la superficie de ataque. Tercero, escaneo y enumeración: uso Nmap para el descubrimiento de puertos y servicios, luego herramientas más específicas según lo que encuentro. Cuarto, explotación: intento explotar las debilidades identificadas, siempre dentro de las reglas acordadas, y documento a qué accedo, no solo que entré. Quinto, informe: redacto un informe estructurado en torno al riesgo de negocio. Siempre debriefing con el cliente en persona antes del informe escrito para que no lean hallazgos críticos en frío.

El phishing es el vector de acceso inicial más común. La defensa comienza con controles técnicos: filtrado de correo, configuración DMARC y SPF, y bloqueo de la ejecución de macros en documentos Office. Pero la defensa más duradera es la formación en concienciación de seguridad con ejercicios regulares de phishing simulado. La inyección SQL ocurre cuando la entrada del usuario se inserta en consultas de base de datos sin saneamiento. La defensa principal es usar consultas parametrizadas o sentencias preparadas: esto hace que la inyección sea estructuralmente imposible. El WAF añade capas adicionales, pero las consultas parametrizadas son innegociables. Los ataques man-in-the-middle apuntan a los datos en tránsito, típicamente en redes no seguras. La defensa es imponer TLS en todas las conexiones, implementar cabeceras HSTS, usar certificate pinning para aplicaciones móviles y formar a los usuarios para que no se conecten al Wi-Fi público sin VPN.