Preguntas de entrevista para Analista de Ciberseguridad

Respuesta modelo

Empiezo por el traspaso del turno anterior: reviso los casos abiertos, lo que quedó pendiente de respuesta del cliente y cualquier alerta silenciada temporalmente. Después compruebo la salud del propio servicio —conectores de ingesta caídos, agentes de EDR sin reportar, reglas deshabilitadas—, porque una alerta que no llega es más peligrosa que un falso positivo. A partir de ahí trabajo la cola por prioridad: valido la alerta, reúno contexto del usuario y del activo, decido si es falso positivo, incidente contenible en mi nivel o escalado, y documento cada paso en el sistema de tickets con las evidencias. En los huecos de baja carga dedico tiempo a afinar reglas ruidosas y a una hipótesis de caza; al cerrar, preparo el traspaso escrito para el compañero entrante.

Respuesta modelo

Ordeno por impacto potencial sobre el negocio, no por la severidad que trae la alerta. Miro tres cosas: criticidad del activo según el inventario del cliente, si hay indicios de actividad interactiva de un atacante frente a algo automatizado, y si el vector sigue abierto. Una alerta de movimiento lateral hacia un controlador de dominio pasa por delante de un troyano ya bloqueado por el EDR, aunque la segunda venga marcada como crítica. Si dos casos siguen empatados, contengo primero lo que puedo contener con reversión sencilla —aislar un equipo— y escalo en paralelo, avisando al coordinador para pedir refuerzo antes de acumular retraso.

Respuesta modelo

El más exigente fue un compromiso de credenciales en una entidad del sector asegurador. La alerta inicial era menor: un inicio de sesión correcto desde una IP de un proveedor de nube a las tres de la madrugada. Al correlacionar vi enumeración de recursos compartidos y creación de una tarea programada en dos servidores. Aislé los equipos con el EDR, forcé el restablecimiento de las credenciales afectadas y revoqué los tokens de sesión, y escalé al nivel 3 con la línea temporal ya montada. Después participé en el análisis forense: el acceso inicial venía de una campaña de fatiga de MFA sobre un usuario con permisos heredados que nadie había revisado. El cierre incluyó informe conforme a la guía CCN-STIC 817 y una revisión de permisos que eliminó 40 accesos innecesarios.

Respuesta modelo

No lo cierro y me olvido: lo documento como candidato a ajuste. Primero cuantifico cuántas alertas genera y cuánto tiempo de analista consume, luego busco el patrón que separa el comportamiento legítimo del sospechoso —un rango de IP, una cuenta de servicio, una franja horaria de un proceso de respaldo— y propongo el ajuste con esa evidencia. La exclusión se acuerda con el cliente y queda registrada con fecha, motivo y responsable, nunca aplicada por iniciativa propia y en silencio. Después reviso el efecto a las dos semanas para confirmar que la regla sigue detectando lo que debe detectar.

Respuesta modelo

Sí. He trabajado tres años en un servicio 24x7 con rotación de mañana, tarde y noche en ciclos de una semana, además de guardias localizadas un fin de semana de cada cuatro. Sé lo que exige el turno de noche y cómo organizarme para llegar descansada, y no tengo restricciones de conciliación que me impidan cubrirlo. Lo único que le pediría es conocer el calendario con antelación razonable, porque con la planificación publicada con dos o tres semanas de margen el modelo funciona sin incidencias.

Respuesta modelo

Tengo una rutina fija en lugar de leer al azar. A diario reviso los avisos del INCIBE-CERT y del CCN-CERT y el boletín de vulnerabilidades del fabricante de nuestra pila; semanalmente leo dos o tres informes de inteligencia de amenazas y traduzco al menos uno a una hipótesis de caza aplicable a mis clientes. Cada mes reproduzco una técnica nueva en mi laboratorio con Atomic Red Team y compruebo si nuestras reglas la detectan; si no, escribo la detección. A eso sumo la RootedCON y las Jornadas STIC del CCN cuando el calendario lo permite.

El IDS observa el tráfico de red y alerta sobre patrones conocidos o anómalos, pero no ve lo que ocurre dentro del equipo ni descifra el tráfico cifrado. El EDR vive en el endpoint: registra procesos, línea de comandos, escrituras en el registro y conexiones, detecta comportamientos y además permite responder, aislando la máquina o matando un proceso. El SIEM no detecta por sí mismo en el endpoint ni en la red: agrega y normaliza los eventos de ambos junto con los de identidad, nube, proxy y aplicaciones, y permite correlacionarlos y conservarlos para la investigación. Un ataque real deja huellas parciales en cada capa: la conexión saliente en la red, el proceso padre sospechoso en el endpoint y el inicio de sesión anómalo en el proveedor de identidad. Solo la correlación en el SIEM convierte esas tres señales débiles en un incidente.

El patrón regular con jitter y un dominio recién registrado apunta a comunicación con un servidor de mando y control. Empiezo por confirmar el patrón en un intervalo amplio para descartar telemetría legítima o un cliente de actualización mal configurado, y compruebo la reputación y la fecha de registro del dominio. En el EDR identifico qué proceso genera las consultas, su proceso padre, la línea de comandos y la ruta del binario; si es un ejecutable en una carpeta temporal o de perfil de usuario, la sospecha se confirma. A partir de ahí aíslo el equipo, recojo la muestra y las evidencias volátiles, bloqueo el dominio y la IP en el proxy y el firewall, busco el mismo indicador en el resto del parque y escalo con la línea temporal, el vector de entrada probable y el alcance identificado.

El Kerberoasting aprovecha que cualquier usuario autenticado puede solicitar un ticket de servicio para una cuenta con SPN registrado. Ese ticket va cifrado con el hash de la contraseña de la cuenta de servicio, así que el atacante lo extrae y lo ataca sin conexión hasta obtener la contraseña, sin generar ruido en el controlador de dominio. Para detectarlo vigilo los eventos 4769 con tipo de cifrado RC4 cuando el dominio ya opera con AES, y sobre todo la anomalía de volumen: un mismo usuario solicitando tickets para muchos SPN distintos en pocos minutos. Como medidas preventivas, contraseñas largas y aleatorias en cuentas de servicio, uso de cuentas de servicio administradas de grupo, revisión de qué cuentas tienen SPN y por qué, y evitar que cuentas de servicio pertenezcan a grupos privilegiados.

El ENS, regulado por el Real Decreto 311/2022, fija los principios y las medidas de seguridad obligatorias para las entidades del sector público y para los proveedores que les prestan servicios. Los sistemas se clasifican en categoría BÁSICA, MEDIA o ALTA según el impacto en las dimensiones de confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad, y de esa categoría dependen las medidas exigibles. Para el SOC se traduce en obligaciones concretas: registro y protección de los logs de actividad con retención definida, monitorización continua, detección de intrusión, gestión documentada de incidentes con clasificación y notificación al CCN-CERT, y evidencias suficientes para la auditoría de conformidad, que en categorías MEDIA y ALTA es bienal. En la práctica, condiciona qué se registra, cuánto tiempo se conserva y cómo se documenta cada caso.

Tres marcos que se solapan. Con el RGPD y la LOPDGDD, si hay brecha de datos personales con riesgo para los derechos de las personas, el responsable notifica a la AEPD en un máximo de 72 horas desde que tiene constancia, y comunica a los afectados sin dilación indebida cuando el riesgo es alto. Con NIS2, las entidades esenciales e importantes envían una alerta temprana en 24 horas, la notificación con la valoración inicial en 72 horas y el informe final en el plazo de un mes. En el ámbito del ENS, la notificación al CCN-CERT sigue la clasificación de la guía CCN-STIC 817. Mi papel como analista no es decidir la notificación, sino detectar y clasificar a tiempo y entregar la línea temporal y el alcance para que el responsable de seguridad y el DPD puedan cumplir el plazo.

Lo uso para tres cosas. Primero, como lenguaje común: cada caso de uso y cada informe se etiqueta con la táctica y la técnica, de modo que un incidente se describe igual entre turnos y con el cliente. Segundo, como mapa de cobertura: cruzo mis reglas contra la matriz y detecto huecos, priorizando las técnicas que los grupos activos contra el sector del cliente utilizan de verdad, no la matriz entera. Y tercero, como guion de validación: reproduzco la técnica en el laboratorio con Atomic Red Team o Caldera, verifico si genera alerta y, si no, escribo la detección. La cobertura por sí sola es una métrica engañosa; lo que importa es la calidad de la detección en las técnicas que le afectan.

Sigo el orden de volatilidad: primero lo que desaparece al apagar o con el paso de los minutos —memoria RAM, procesos en ejecución, conexiones de red, sesiones abiertas y contenido de caché— y después el disco, los registros del sistema y los datos de respaldo. Antes de tocar nada aíslo el equipo de la red sin apagarlo, para no perder la memoria ni disparar mecanismos de borrado asociados al apagado. Documento cada acción con marca de tiempo, herramienta y responsable, calculo el hash de cada imagen para acreditar integridad y mantengo la cadena de custodia por escrito. Si el incidente puede acabar en un procedimiento judicial o en una reclamación al seguro, esa documentación vale tanto como el hallazgo técnico.

Actúo dentro de lo que el procedimiento acordado con ese cliente me autoriza a hacer sin confirmación, que es la razón por la que ese documento se firma antes de que ocurra nada. Si el contrato contempla contención autónoma, deshabilito la sesión y revoco los tokens, aíslo los equipos implicados y bloqueo la IP, documentando cada acción con su hora. Si no la contempla, aplico las medidas reversibles y de menor impacto, sigo escalando por la lista de contactos alternativos y por el canal de emergencia, y aviso al coordinador de guardia de mi organización. En paralelo mantengo la vigilancia sobre la cuenta y preparo la línea temporal para la llamada de primera hora. Lo que no hago nunca es esperar en silencio a que alguien conteste.

Le escucho y trato la explicación como una hipótesis más, no como una resolución. Verifico técnicamente lo que afirma: si dice que instaló esa herramienta, compruebo la hora, el usuario, el proceso padre y el origen de la descarga. Si todo encaja, cierro el caso como falso positivo dejando constancia de quién aportó la confirmación y con qué evidencia. Si no encaja, o si no puedo verificarlo, mantengo el caso abierto y escalo al responsable de seguridad del cliente, que es quien tiene autoridad para aceptar ese riesgo. Explico siempre el porqué sin tono acusatorio: precisamente los equipos de directivos son objetivo prioritario, y una cuenta comprometida se comporta al principio como un usuario legítimo.

Determino primero la exposición real: qué activos tienen la versión afectada, cuáles son accesibles desde internet y si existe autenticación previa. Con esa lista, comunico al cliente en el mismo día un resumen breve con activos afectados, riesgo y opciones. Mientras se decide el parcheo, propongo mitigaciones inmediatas: restringir el acceso por origen, desactivar el módulo vulnerable o interponer una regla en el WAF. En paralelo despliego detección específica del patrón de explotación y busco retroactivamente indicios de explotación previa a la publicación, porque en varias campañas la fecha de aviso llegó después del primer uso real. Y dejo el fin de semana cubierto con instrucciones claras para el turno entrante.

Primero confirmo el patrón con datos y no con una impresión: reviso una muestra de casos cerrados, sus tiempos y la ausencia de evidencias adjuntas. Después hablo con él directamente, porque la causa habitual no es mala fe sino sobrecarga, falta de formación en un tipo de alerta o un procedimiento poco claro. Si es un problema de conocimiento, me ofrezco a revisar juntos los casos dudosos y a mejorar la documentación. Sea cual sea la causa, informo al coordinador del SOC, porque hay casos cerrados que deben reabrirse y revisarse: el riesgo para el cliente no se resuelve con una conversación entre compañeros. Lo planteo como revisión de calidad del servicio, no como una denuncia personal.

Lo comunico de inmediato, antes de que lo detecte el cliente, y restablezco la conectividad una vez confirmado que la alerta era un falso positivo. Aviso al coordinador y al contacto del cliente con un mensaje claro: qué ha pasado, desde qué hora, qué he hecho para revertirlo y cuál es la situación actual. Después escribo el análisis de la causa: qué evidencia me llevó a decidir el aislamiento y en qué punto falló mi criterio o el procedimiento. Si el procedimiento permitía aislar con ese nivel de evidencia, propongo endurecerlo, por ejemplo exigiendo una segunda comprobación para activos marcados como críticos. Ocultarlo o retrasar el aviso convertiría un error operativo en un problema de confianza.