Preguntas de entrevista de ciberseguridad de nivel Senior

No. No puedes comparar la longitud bruta de clave entre familias de algoritmos distintas. Por cómo se endurece la matemática subyacente de cada uno, una clave de curva elíptica de 256 bits da aproximadamente la misma seguridad que una clave RSA de 3072 bits — unos 128 bits de fuerza, según NIST. Más grande no es simplemente más fuerte: ECC alcanza una fuerza equivalente con claves mucho más pequeñas, por eso lo prefieren los sistemas modernos. Dentro de un mismo algoritmo, claves más largas sí ayudan, hasta cierto punto.

No necesariamente. Cifrar dos veces con el mismo algoritmo no dobla sin más la seguridad — el resultado clásico es que 2DES añade solo alrededor de un bit de fuerza efectiva por los ataques meet-in-the-middle (encuentro en el medio), y por eso existe 3DES. Más importante aún, los esquemas multicapa caseros tienden a introducir errores de implementación que debilitan todo el conjunto. Usa un único cifrado autenticado bien probado (AES-GCM) con una gestión de claves sólida en lugar de apilar cripto.

La autonomía sin límites más el acceso a herramientas es la «agencia excesiva» de OWASP LLM: un modelo manipulado o equivocado puede tomar acciones destructivas. Acótalo con herramientas de mínimo privilegio, exige confirmación humana para operaciones irreversibles, y mantén los permisos estrechos y auditados. Confiar en él o darle admin amplía el radio de impacto, y ocultar un botón en la interfaz no hace nada respecto a la capacidad subyacente del modelo de invocar la acción.

El contenido no confiable que el modelo ingiere puede llevar instrucciones — es la inyección de prompts indirecta. No puedes evitar del todo que el modelo sea influido, así que aísla el contenido recuperado como dato, acota qué herramientas/permisos tiene el agente, exige confirmación para acciones sensibles, y evita darle secretos que pudiera ser coaccionado a filtrar. Suponer que el modelo simplemente ignorará las instrucciones inyectadas es exactamente el modo de fallo que se explota.

Esto es el «manejo inadecuado de la salida» de OWASP LLM: la salida del modelo, influida por la entrada del usuario, puede convertirse en inyección de comandos al pasarla a un shell o a eval. Trátala como no confiable — asigna intenciones a una pequeña lista blanca de acciones parametrizadas, valida estrictamente y ejecuta en un entorno aislado en vez de lanzar cadenas generadas en bruto. Confiar en la salida, subir el límite de tokens o solo registrar no detiene la inyección.

Si la recuperación extrae cualquier documento indexado sin importar quién pregunta, el modelo expondrá fielmente datos que el usuario no debería ver — es un fallo de autorización, no una alucinación. Aplica los permisos del usuario a nivel de documento en el momento de la recuperación, para que solo los fragmentos autorizados entren en el contexto. Un prompt de sistema más largo es evitable y no implementa control de acceso, la temperatura no tiene relación, y otro modelo tiene la misma brecha.

Entrenar con datos de usuario no verificados permite a un atacante envenenar el modelo — implantando puertas traseras, disparadores o comportamiento sesgado que aflora más tarde. Contrólalo con verificación y filtrado de datos, seguimiento de procedencia, detección de anomalías en el conjunto de datos y evaluación del comportamiento del modelo tras el entrenamiento. «Más datos es mejor» ignora la integridad, y la verdadera preocupación es el envenenamiento, no la velocidad ni el espacio en disco.

Una reconstrucción fiable de un incidente surge de correlacionar telemetría independiente en una sola cronología: registros de autenticación, datos de proceso/ejecución del EDR, marcas de tiempo MAC del sistema de archivos, flujos de red y eventos del SIEM, para ordenar las acciones y acotar el alcance. Un solo registro o el evento más reciente por sí solo pierde la cadena y puede inducir a error o estar manipulado. Adivinar a partir de una fuente o preguntar al atacante no son métodos de investigación. La correlación entre fuentes independientes revela la actividad completa del atacante y resiste a un atacante que editó una de ellas.

Un vacío en los registros locales durante un incidente puede significar registros borrados o manipulados, un paso antiforense común, así que no trates la ausencia de registros como ausencia de actividad. Coteja con registros centralizados/reenviados, EDR y datos de red que el atacante probablemente no pudo alterar, y documenta el vacío de integridad como un hallazgo. Suponer que el servidor estaba inactivo confía en pruebas que el atacante puede controlar, tratar el vacío como prueba de que no pasó nada es justo la conclusión que él quiere, y borrar más registros destruye lo que queda. Corrobora en su lugar con telemetría independiente.

Los marcos fijan un mínimo y pueden cumplirse por completo mientras persiste un riesgo real, así que una lista de verificación superada no significa seguro: señala la brecha, evalúa su riesgo e impulsa su tratamiento, sea cual sea el estado de cumplimiento. Concluir que es seguro porque el cumplimiento pasó es una confusión peligrosa entre dos cosas distintas. Eliminar la brecha del informe es una tergiversación, e incluso fraude. Esperar al próximo ciclo de auditoría deja a sabiendas una exposición real abierta. La postura madura trata el cumplimiento como prueba de un suelo, no de un techo, y actúa sobre el riesgo que realmente puede verse.

El alcance de PCI DSS abarca los sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas, más cualquier sistema conectado a ellos o capaz de afectarlos, así que una segmentación de red eficaz aísla el entorno de datos de tarjetas (CDE) y saca de alcance los sistemas ajenos, reduciendo coste, esfuerzo y riesgo. Cifrar todos los servidores no define una frontera y los sistemas conectados siguen en alcance; añadir cortafuegos por todas partes sin un objetivo no es segmentación si no restringe ni valida los flujos de datos; y dejar de leer en voz alta los números de tarjeta es higiene, no un control de alcance. La respuesta sistémica es controlar dónde viven los datos de tarjetas y qué puede alcanzarlos.

Un informe SOC 2 solo te aporta garantía si lo lees de verdad: confirma que es del tipo correcto (el Tipo II prueba la eficacia operativa a lo largo del tiempo, el Tipo I solo el diseño en un momento), revisa el alcance y qué criterios de servicios de confianza cubre, que el periodo es actual y no tiene huecos, qué opinión emitió el auditor (sin salvedades o con salvedades) y examina las excepciones señaladas más los controles complementarios de la entidad usuaria (CUEC) que te corresponden. Limitarse a confirmar que el informe existe —o juzgarlo por el logo de la portada o el número de páginas— no dice nada sobre la eficacia real de los controles del proveedor ni sobre tus obligaciones residuales.

Un open redirect en un flujo de autenticación permite al atacante crear un enlace de login de apariencia fiable que, tras la autenticación, envía al usuario — y potencialmente un código de autorización o token — a un dominio controlado por el atacante, permitiendo el secuestro de cuenta y un phishing convincente. Corríjalo allow-listando estrictamente los redirect URI exactos del lado del servidor y rechazando cualquier otro. No es cosmético ni un problema de rendimiento, y HTTPS no ayuda porque el destino del atacante también puede ser un sitio HTTPS válido.

El malware fileless vive en la memoria de los procesos (inyección, carga reflectiva, LOLBins), así que adquiere y analiza una imagen de memoria para hallar el código inyectado, los módulos sospechosos y las relaciones entre procesos. Un escaneo antivirus del disco y un disco limpio no te dicen nada de un implante en memoria. La papelera de reciclaje es irrelevante. El análisis de memoria es la herramienta adecuada cuando no hay archivo que triar, y debes capturar antes de reiniciar el host.

Usa servicios de red simulados o un egress estrechamente monitorizado y no atribuible, para estudiar el comportamiento del C2 sin revelar tu IP real al atacante ni dejar que el host reciba comandos dañinos. Interactuar desde la IP corporativa alerta al operador y arriesga un daño real. Puentear el sandbox a la LAN invita a la propagación. Desactivar los logs tira los datos del análisis. Controla la red para observar sin exponerte ni ser instrumentalizado.

El packing oculta el código real, así que entropía alta más imports ausentes es señal de desempaquetar — detecta el packer y vuelca la imagen desempaquetada desde memoria una vez que el loader se ha ejecutado, y luego analiza la carga útil real. Las cadenas ilegibles son prueba de evasión, no de inocuidad. Declararlo falso positivo o renombrar la extensión ignora una muestra activamente ofuscada. La propia ofuscación es un fuerte indicador malicioso que conviene investigar.

El malware suele comprobar artefactos de VM/sandbox, tiempos de ejecución cortos o interacción del usuario y permanece inactivo si los detecta. Disfraza y endurece la VM de análisis, alarga la ejecución o pasa a bare metal, y extrae el comportamiento desde una imagen de memoria del host vivo. Suponer que está roto o que el host se equivocó ignora una muestra probadamente maliciosa en el mundo real. Reiniciar no cambia nada porque la lógica de evasión se dispara en cada ejecución.

Recuperar del lado del servidor URLs controladas por el atacante es Server-Side Request Forgery (SSRF): permite alcanzar servicios internos o el endpoint de metadatos del cloud para robar credenciales. Mitíguelo con una allow-list de hosts y esquemas permitidos, bloqueando rangos privados y link-local (revisando de nuevo tras cada redirección) y endureciendo el acceso a metadatos con IMDSv2. Decir que no hay riesgo ignora el acceso que concede la petición, y un spinner de carga o una caché no cambian nada sobre dónde puede conectarse el servidor.

`alg: none` permite a cualquiera fabricar un token sin firmar de apariencia válida y suplantar a cualquier usuario — una elusión total de autenticación, no un hallazgo menor. Corrígelo permitiendo en el servidor una lista blanca de los algoritmos esperados y verificando siempre la firma con la clave correcta; nunca confíes en el encabezado alg del propio token para elegir el método de verificación. Una expiración más larga o cambiar dónde se guarda el token no hace nada contra tokens falsificados y sin firmar. Es crítico y explotable, así que documentar no es una corrección.

La inyección de prompts no se resuelve por completo con más texto; asume que el modelo puede ser subvertido y restringe lo que se le permite HACER. Da a las herramientas el mínimo privilegio, condiciona las acciones de alto impacto a confirmación humana, y valida o aísla las llamadas a herramientas antes de actuar (OWASP LLM «agencia excesiva» y «gestión inadecuada de salidas»). Suplicar en el prompt del sistema es evitable. Una temperatura mayor solo añade aleatoriedad, y solo registrar deja constancia del daño sin impedir la acción inyectada.

Equilibra usabilidad y riesgo: impón acceso condicional ligado a la postura del dispositivo y aísla los datos corporativos en un contenedor gestionado (MAM/MDM) para poder controlarlos y borrarlos selectivamente sin apoderarte de todo el dispositivo personal. El acceso sin restricciones arriesga la fuga en endpoints no gestionados, posiblemente comprometidos. Una prohibición rotunda empuja a soluciones inseguras como reenviar datos al correo personal. Y enviar los datos como adjuntos los dispersa de forma incontrolable por dispositivos que nunca recuperarás.

Ningún producto único detiene todos los ataques, así que la seguridad madura superpone controles independientes —la defensa en profundidad— para que el fallo de uno no signifique la compromisión. Asocia el gasto propuesto a las brechas reales en identidad, red, endpoint, datos y detección, y conserva los controles complementarios que ya funcionan. Apostarlo todo a una sola herramienta crea un punto único de fallo, y arrancar los controles existentes para sustituirlos reduce la cobertura. No gastar nada en absoluto ignora brechas reales.

El cifrado en reposo defiende exactamente una amenaza — el robo físico o de disco — y no hace nada frente a una aplicación comprometida, credenciales robadas o tráfico interceptado, porque la base de datos descifra de forma transparente para cualquier consulta autorizada. Un diseño sólido también exige TLS en tránsito, autenticación y autorización fuertes, y una gestión de claves adecuada con separación de funciones. Duplicar el cifrado en reposo añade coste sin cambiar el modelo de amenazas, y cifrar solo las copias de seguridad deja expuestos los datos en producción y sus rutas de acceso.

Si la clave reside con el texto cifrado, quien roba la base de datos obtiene ambos, así que el cifrado no protege nada — es un candado con la llave pegada a él. Las claves deben gestionarse en un KMS o HSM dedicado, separadas de los datos, con control de acceso estricto, rotación y separación de funciones. Hashear la clave la vuelve unidireccional e inútil para descifrar, y almacenar copias adicionales en el mismo lugar solo multiplica la exposición en vez de reducirla.

Enviar datos personales a un tercero extiende tu frontera de confianza, así que primero realiza una evaluación de seguridad del proveedor — tratamiento de datos, cifrado, controles de acceso, certificaciones como SOC 2 / ISO 27001, subencargados, condiciones de notificación de brechas — y firma un acuerdo de tratamiento de datos (DPA) antes de cualquier transferencia. Un contrato de precio o la palabra verbal de un comercial no es diligencia debida. Y un «sitio web pulido» no dice nada sobre cómo protege realmente los datos el proveedor; tú sigues siendo responsable.

La confianza basada en la ubicación de red significa que un único punto de apoyo dentro concede un amplio movimiento lateral: una credencial de VPN obtenida por phishing y el atacante está «dentro». El zero trust elimina la confianza implícita: cada acceso se autentica, autoriza y reevalúa de forma continua según la identidad y la postura del dispositivo, con mínimo privilegio y segmentación (NIST SP 800-207). Una segunda VPN o una VPN más amplia solo extiende el mismo problema de confianza plana, y confiar en la LAN en lugar de la VPN repite el error original.

«Seguro» no es binario; un CISO comunica en el lenguaje del riesgo de negocio: los riesgos más relevantes, cómo los controles actuales los reducen frente al apetito de riesgo del consejo, las inversiones previstas y el riesgo residual que se acepta. Un «sí» absoluto es una falsa garantía que se derrumba en cuanto ocurre un incidente. «No, nunca estaremos seguros» es técnicamente cierto pero inútil y delata falta de control del problema. Una lista de cortafuegos y herramientas refleja gasto, no riesgo ni resultados que el consejo pueda gobernar.

La gestión de una brecha se rige por la ley y el contrato: trabajar con el área legal para cumplir los plazos de notificación obligatorios (como las 72 horas del RGPD ante la autoridad de control) e informar a las personas afectadas con exactitud. El ocultamiento expone a multas mucho mayores, sanciones y daño reputacional cuando sale a la luz. Difundir prematuramente detalles técnicos en bruto y sin verificar puede confundir a los clientes y ayudar a los atacantes. Culpar públicamente a un empleado no es exacto, ni legal, ni una gestión de crisis eficaz.

Las métricas de nivel de consejo deben conectarse con el riesgo y los resultados: tiempos de detección y respuesta (MTTD/MTTR), cumplimiento de SLA de parcheo en sistemas críticos, cobertura de controles y cómo evoluciona el riesgo residual frente al apetito. El número de ataques bloqueados por el cortafuegos, el recuento de firmas de antivirus y el total de correos recibidos son cifras vanidosas — impresionan pero no dicen nada sobre si el riesgo baja. El consejo gobierna el riesgo, así que las métricas deben dejarle ver la tendencia y decidir.

El gasto en seguridad debe seguir al riesgo, no a la moda: usar una evaluación de riesgos para dirigir el dinero donde el impacto al negocio y la probabilidad son más altos y la cobertura de controles actual es más débil, y luego medir la reducción lograda. Comprar lo que vende el proveedor popular ignora tu perfil de amenaza real y a menudo financia herramientas sin usar. Repartir el presupuesto por igual infrafinancia las pocas áreas que más importan. Copiar a los competidores asume que su perfil de riesgo es igual al tuyo, lo cual rara vez ocurre.

Cuando no puedes remediar, gestionas el riesgo: reducir la exposición con controles compensatorios (segmentación de red, restricción de accesos, monitorización reforzada), cuantificar el riesgo residual y lograr que el propietario de negocio responsable lo acepte formalmente con una fecha de revisión definida. Un apagado unilateral excede la autoridad del CISO y daña al negocio. Ignorarlo porque no se puede arreglar es negligencia. Omitirlo del registro de riesgos oculta la responsabilidad, rompe el rastro de auditoría y significa que nadie consta como dueño de la decisión.

La brecha de un proveedor también es tu incidente: invocar la respuesta a incidentes para acotar qué datos e integraciones quedaron expuestos, rotar todos los secretos compartidos, claves API y relaciones de confianza SSO, evaluar tus propias obligaciones de notificación regulatoria y exigir al proveedor su divulgación. Esperar pasivamente al proveedor cede el control de tu propio calendario y obligaciones. Una rescisión pública del contrato es teatro prematuro antes de conocer siquiera tu exposición. Asumir que no te afectó omite precisamente la evaluación que esperan los reguladores y tus clientes.

Un rol de instancia con privilegios excesivos convierte cualquier fallo a nivel de aplicación —especialmente un SSRF que alcanza el servicio de metadatos de la instancia— en una toma de control total de la cuenta, porque el atacante hereda las credenciales del rol. Sustituye el comodín por las acciones mínimas y los ARN de recursos que la carga de trabajo usa realmente, y exige IMDSv2 para endurecer el endpoint de metadatos. Una VPC no restringe el IAM en absoluto. Una sola regla de denegación es un juego del topo que deja todo lo demás permitido. Un balanceador de carga es irrelevante para el alcance del daño de la credencial.

La contención prima sobre la recuperación prematura: detén la propagación aislando los segmentos afectados y cortando el vector — desactiva la cuenta de servicio abusada, bloquea SMB entre segmentos, retira el host de staging — preservando evidencia, luego erradica y recupera. Restaurar en una red que aún cifra vuelve a perder los datos restaurados. Pagar el rescate no detiene el cifrado en curso y conlleva riesgo legal y de sanciones. Cortar la electricidad de todas las máquinas destruye evidencia volátil y puede corromper archivos a medio escribir, dificultando una recuperación limpia.

Erradicar antes de entender el alcance deja al atacante persistir en sistemas que no has encontrado y simplemente volver. Caza rápido los IOC y las credenciales robadas por todo el parque, identifica cada host afectado y cada mecanismo de persistencia, y luego erradica en todas partes a la vez. Borrar un solo host es un juego de whack-a-mole que alerta al atacante mientras deja intactos sus otros puntos de apoyo. Un apagón total de internet de una semana es desproporcionado y daña al negocio. Borrar solo el archivo de malware ignora la persistencia, el movimiento lateral y las credenciales ya robadas.

Lo que importa es el impacto: una credencial de servicio reutilizada o con privilegios excesivos que desbloquea el admin del dominio o sistemas críticos es el hallazgo relevante, así que prueba la reutilización y mapea los privilegios y la ruta de movimiento lateral. Descifrar primero todos los demás hashes es trabajo inútil que retrasa lo importante. Cambiar la contraseña de la cuenta de servicio es destructivo, rompe producción y alerta a los defensores. Enviar una credencial activa en texto plano por correo es en sí una exposición y mala seguridad operativa.

Descubrir una intrusión activa es una emergencia fuera de banda: las reglas de enfrentamiento deben definir una ruta de escalada, así que invócala de inmediato, preserva las pruebas y evita contaminar un incidente en curso. Seguir probando puede interferir con el atacante real o destruir las pruebas que necesitan los respondedores. Intentar expulsar tú mismo al atacante queda fuera de alcance, es arriesgado y puede alertarlo. Esperar al informe final podría significar días de brecha continua y pérdida de datos.

Una RCE sin autenticar en un servidor expuesto a Internet es de nivel emergencia: reduce la ventana de exposición con un despliegue probado, por etapas o gradual, y añade controles compensatorios (restringir el acceso, reglas WAF) mientras tanto. Esperar a la ventana trimestral deja un agujero explotable como un gusano abierto durante semanas. Parchear a ciegas en producción en horario laboral sin pruebas arriesga una caída y un rollback chapucero. Confiar en el firewall perimetral no sirve de nada — el servicio ya está expuesto y el exploit no necesita credenciales.

Las redes planas permiten que un único dispositivo de invitado comprometido alcance directamente los sistemas más valiosos. Segmenta por nivel de confianza y aplica tráfico de mínimo privilegio entre zonas para contener y monitorizar el movimiento lateral. Un firewall de borde no hace nada por el tráfico este-oeste entre hosts que ya están dentro. Re-direccionar las IP de los servidores financieros es seguridad por oscuridad que cualquier escaneo derrota. El antivirus es una capa de detección, no un sustituto del control arquitectónico de aislar los sistemas sensibles.

La cadena de suministro de LLM abarca modelos base, variantes fine-tuneadas, datasets, embeddings, plugins, librerías y la plataforma de alojamiento, cada uno un lugar para introducir riesgo. Las amenazas incluyen descargar pesos de modelo manipulados o con backdoor, fine-tunes maliciosos, datasets envenenados o con licencia contaminada, plugins vulnerables o sobreprivilegiados, y repos de modelos con typosquatting. Defensas: obtener modelos de registros de confianza, verificar integridad y procedencia, mantener un AI bill of materials, escanear y fijar dependencias, verificar plugins y aplicar mínimo privilegio a todo lo que el modelo integre.

El NIST AI Risk Management Framework (AI RMF 1.0) es un marco voluntario y basado en el riesgo para gobernar una IA confiable a lo largo de su ciclo de vida. Su núcleo son cuatro funciones: Govern (cultura, política, rendición de cuentas, y atraviesa las demás), Map (contexto e identificación de riesgos), Measure (evaluar y seguir riesgos) y Manage (priorizar y responder). También define características de confiabilidad: válida y fiable, segura, segura y resiliente, responsable y transparente, explicable, con privacidad mejorada y justa. Complementa listas técnicas como el OWASP LLM Top 10 a nivel de programa.

La seguridad RAG significa tratar cada documento recuperado como entrada no confiable. Riesgos clave: prompt injection indirecta oculta en el contenido recuperado, envenenamiento de la base de conocimiento o los embeddings, y falta de autorización por usuario, de modo que el modelo devuelve datos a los que el usuario no tiene acceso. Las defensas incluyen control de acceso aplicado en la recuperación, procedencia del contenido y verificación en la ingesta, tratar el texto recuperado como datos y no como instrucciones, validación de salidas, y aislar el almacén de vectores por inquilino.

Un agente LLM convierte texto en acciones mediante herramientas y function calls, así que una prompt injection se convierte en una acción real: el riesgo de excessive agency. Asegúralo dando a cada herramienta el mínimo privilegio y alcance que necesite, validando y acotando los argumentos de las herramientas, exigiendo confirmación humana para acciones sensibles o irreversibles, ejecutando en sandbox, limitando la tasa y presupuestando las llamadas, y registrando cada invocación de herramienta. Nunca dejes que la salida del modelo, influida por datos no confiables, autorice directamente una acción de alto impacto.

El envenenamiento de datos de entrenamiento es cuando un atacante manipula los datos usados para preentrenar, hacer fine-tuning o generar los embeddings de un modelo, de modo que el modelo resultante se comporte de forma maliciosa: incrustando un disparador de backdoor, inyectando sesgo o degradando la precisión. Explota el hecho de que los modelos rastrean y confían en datasets enormes, a menudo de origen web. Las defensas incluyen curar y firmar las fuentes de datos, verificaciones de procedencia e integridad, detección de anomalías en los datos de entrenamiento, versionado de datasets, y limitar quién puede contribuir a los corpus de entrenamiento y RAG.

La exfiltración por DNS codifica datos robados en consultas DNS (p. ej. etiquetas de subdominio largas enviadas a un servidor autoritativo controlado por el atacante), abusando de que el DNS casi siempre está permitido en salida y a menudo sin monitorizar. Detéctala con anomalías: volumen de consultas inusualmente alto a un dominio, subdominios largos / de alta entropía, muchos subdominios únicos por dominio padre, abuso de registros TXT/NULL y consultas a dominios recién registrados o raros.

La inyección de procesos ejecuta el código del atacante dentro del espacio de memoria de un proceso legítimo para que la actividad se mezcle y herede la confianza de ese proceso. Las técnicas clásicas incluyen la inyección de DLL (CreateRemoteThread + LoadLibrary), el process hollowing (lanzar un proceso benigno suspendido, desmapearlo, escribir código malicioso) y la inyección APC. Los defensores la detectan con hooks de API del EDR, relaciones padre/hijo o regiones de memoria anómalas (RWX, memoria ejecutable sin respaldo en archivo) y eventos CreateRemoteThread de Sysmon.

DAC permite al propietario de los datos conceder el acceso a su discreción; MAC aplica el acceso de forma centralizada mediante etiquetas/habilitaciones y es no discrecional; RBAC concede el acceso a través de roles laborales; ABAC evalúa atributos (usuario, recurso, entorno) frente a una política para decisiones detalladas y contextuales.

La continuidad del negocio (BCP) es la estrategia amplia para mantener las funciones críticas del negocio operando durante y después de una interrupción; la recuperación ante desastres (DRP) es el subconjunto centrado en TI que restaura sistemas y datos. El RTO es el tiempo máximo tolerable para restaurar una función; el RPO es la pérdida de datos máxima tolerable medida en tiempo.

La defensa en profundidad superpone controles múltiples, variados e independientes a través de personas, procesos y tecnología, de modo que el fallo de cualquier control no resulte en un compromiso. Asume que todo control acabará fallando y usa la redundancia y la variedad para ralentizar, detectar y contener a un atacante.

La due diligence es la investigación y comprensión continuas de los riesgos (saber qué se debe hacer), mientras que la due care consiste en tomar las acciones razonables que una persona prudente tomaría para abordarlos (hacerlo realmente). La diligence es investigación y supervisión; la care es implementación y mantenimiento.

La gestión del ciclo de vida de la identidad rige una cuenta desde su creación hasta su retirada: aprovisionamiento en la incorporación (alta), ajuste de permisos al cambiar de rol (cambio) y desactivación oportuna en la salida (baja), con revisiones de acceso periódicas a lo largo del proceso. Los fallos más comunes son la acumulación de privilegios en los cambios y las cuentas huérfanas por desactivaciones omitidas.

Integra la seguridad en cada fase del SDLC en lugar de probar al final: los requisitos incluyen requisitos de seguridad y privacidad, el diseño incluye modelado de amenazas, el desarrollo sigue normas de codificación segura con SAST, las pruebas añaden DAST y revisiones, y el lanzamiento requiere aprobación, todo gobernado por la política, la separación de funciones y el control de cambios. Corregir los fallos pronto es drásticamente más barato que tras el lanzamiento.

IMDS es un endpoint link-local (169.254.169.254) que da a una instancia sus metadatos, incluidas las credenciales temporales de su rol IAM adjunto. El SSRF puede engañar al servidor para que recupere esa URL y filtre esas credenciales. IMDSv2 exige un PUT para obtener un token de sesión de corta duración, fija un TTL/límite de saltos de IP por defecto de 1, y rechaza solicitudes con ciertas cabeceras — de modo que un simple GET de SSRF ya no puede alcanzarlo.

El RBAC controla qué pueden hacer las identidades contra la API de Kubernetes — los Roles y ClusterRoles conceden verbos sobre recursos, vinculados a sujetos vía RoleBindings — y debe seguir el privilegio mínimo, evitando cluster-admin y comodines. Las políticas de red controlan el tráfico de pod a pod, que permite todo por defecto hasta que aplicas un default-deny y luego permites explícitamente los flujos requeridos. Juntos limitan el radio de impacto si un pod o token se ve comprometido.

La CI/CD es de alto valor porque guarda las credenciales de despliegue y ejecuta código no confiable. Los riesgos incluyen dependencias y acciones de build comprometidas, secretos filtrados o demasiado amplios, acciones de terceros mutables, y runners o confianza OIDC con privilegios excesivos. Redúcelos con dependencias fijadas y verificadas, federación OIDC de corta duración en vez de claves de larga duración, privilegio mínimo acotado a repos/ramas concretos, runners efímeros aislados, y artefactos firmados con procedencia rastreada (SLSA).

Kerberos depende de un centro de distribución de claves (KDC) de confianza. El cliente se autentica una vez ante el servidor de autenticación y obtiene un ticket de concesión de tickets (TGT) cifrado con la clave del KDC. Para alcanzar un servicio, presenta el TGT al servicio de concesión de tickets y recibe un ticket de servicio cifrado con la clave de ese servicio. El servicio lo descifra y confía en él. Las contraseñas nunca atraviesan la red, y los tickets tienen tiempo limitado.

El cliente construye una cadena desde el certificado del servidor (hoja) hacia arriba a través de una o más CA intermedias hasta una CA raíz en su almacén de confianza. Verifica la firma de cada certificado usando la clave pública del siguiente emisor, comprueba las fechas de validez, la coincidencia de nombre/host, el uso de la clave y la revocación (CRL/OCSP). La confianza termina en una raíz autofirmada preaprobada; la cadena solo es válida si cada eslabón es correcto.

La firma vincula criptográficamente un artefacto con su productor, para que los consumidores puedan verificar que no fue manipulado ni sustituido. La procedencia son metadatos firmados que describen cómo, dónde y a partir de qué fuente se construyó el artefacto. Juntas — mediante herramientas como Sigstore para la firma sin claves y el framework SLSA para los niveles de procedencia — permiten a quien despliega verificar que una imagen proviene del pipeline y la fuente esperados, frustrando la manipulación y los ataques de sustitución de dependencias.

Los lockfiles fijan las versiones y hashes exactos de las dependencias para que cada build resuelva los mismos bytes verificados — haciendo los builds reproducibles y bloqueando actualizaciones maliciosas silenciosas. Fijar por digest, verificar los hashes de integridad y acotar los paquetes internos a un registro privado también defienden contra la confusión de dependencias, donde un atacante publica un paquete público de versión superior que coincide con un nombre interno para secuestrar la resolución. El principio: nunca dejar que el build descargue silenciosamente código no verificado.

Trata el pipeline como infraestructura de producción: contiene las credenciales para entregar código y llegar a producción, así que comprometerlo evita todos los controles posteriores. Endurécelo con runners aislados y efímeros; tokens de mínimo privilegio y corta duración (federación OIDC en vez de secretos de larga duración); ramas protegidas y config de pipeline revisada; acciones de terceros fijadas por digest; y registro de auditoría completo. El pipeline es un objetivo de primer nivel, no fontanería.

Rompe la build solo ante hallazgos de alta confianza, alta severidad y recién introducidos; avisa (sin bloquear) en todo lo demás para que los desarrolladores sigan confiando en el gate. Gestiona los falsos positivos con reglas afinadas, baselining de los problemas preexistentes y supresiones documentadas, acotadas en el tiempo y revisadas, en lugar de desactivar los escáneres. Un gate que avisa en falso acaba ignorándose o esquivándose, así que la calidad de la señal lo es todo.

Confirma el XSS. Si alert() se disparó siquiera, el navegador analizó y ejecutó tu JavaScript inyectado en el contexto de la página: esa es la vulnerabilidad. Una ventana vacía solo significa que el argumento de cadena que pasaste no se mostró como esperabas (el manejo de comillas, la codificación o la alteración del contexto rompieron el mensaje), no que el payload esté bloqueado. El punto de ejecución está activo; a partir de ahí refinas el payload.

No. CORS no es una defensa contra el CSRF: en realidad afloja la política del mismo origen para que una página pueda leer respuestas entre orígenes que de otro modo no podría. El CSRF no necesita leer la respuesta; solo necesita que el navegador de la víctima envíe una petición autenticada que cambie el estado. Las defensas reales son los tokens anti-CSRF, el atributo de cookie SameSite y comprobar Origin/Referer.

La gobernanza es cómo la dirección fija el rumbo, define la rendición de cuentas y alinea la seguridad con los objetivos de negocio — las políticas, los roles y la supervisión que dicen cómo es «lo bueno». La gestión de riesgos es el proceso de identificar, evaluar, tratar y monitorizar las amenazas a esos objetivos. El cumplimiento consiste en demostrar la adhesión a las obligaciones — leyes, normativas, contratos y política interna. La gobernanza impulsa las decisiones de riesgo; el riesgo determina qué controles necesitas; el cumplimiento evidencia que esos controles satisfacen las normas exigidas. El cumplimiento es un resultado de una buena GRC, no un sustituto de la seguridad.

ISO/IEC 27001 especifica los requisitos de un Information Security Management System (ISMS): un marco descendente y basado en el riesgo de políticas, procesos, roles y mejora continua (Plan-Do-Check-Act) que rige cómo una organización gestiona la seguridad de la información. El Anexo A es un catálogo de controles de referencia. No se aplican todos a ciegas — se realiza una evaluación de riesgos, se decide qué controles son necesarios y se documentan las decisiones de inclusión/exclusión con justificación en una Statement of Applicability (SoA).

Un KPI (Key Performance Indicator) mide lo bien que rinde una actividad de seguridad frente a su objetivo — por ejemplo, el tiempo medio de detección, el cumplimiento del SLA de parcheo o el porcentaje de sistemas con MFA. Un KRI (Key Risk Indicator) es una señal prospectiva de que la exposición al riesgo aumenta hacia un nivel inaceptable, con un umbral que debería desencadenar una acción — por ejemplo, el número de parches críticos vencidos, el recuento de dispositivos no gestionados o las revisiones de acceso fallidas con tendencia al alza. Los KPI te dicen cómo lo estás haciendo; los KRI te advierten de hacia dónde te diriges.

Trata el riesgo de proveedores como un ciclo de vida, no como un cuestionario puntual. Inventaría a tus terceros y clasifícalos por criticidad y sensibilidad de los datos. Ejecuta una due diligence proporcional al nivel — revisa informes SOC 2 / ISO 27001, cuestionarios de seguridad, resúmenes de pen-test, y los datos y accesos implicados. Incorpora controles al contrato (requisitos de seguridad, derecho de auditoría, notificación de brechas, tratamiento de datos, subprocesadores). Luego monitoriza de forma continua, no solo en el onboarding, y ten un proceso de offboarding limpio para revocar accesos y recuperar o destruir datos. El riesgo de cuarta parte (subprocesadores) también importa.

El beaconing C2 es el check-in periódico que un implante hace a su controlador. Cázalo en la telemetría de red/proxy/DNS buscando regularidad: conexiones a un destino a intervalos casi fijos (incluso con jitter), solicitudes pequeñas y uniformes, ratios bajos de datos-entrantes / datos-salientes, destinos raros de larga duración y huellas TLS/JA3 sospechosas o user-agents extraños. La señal es el ritmo y la rareza del destino, no el payload — que suele estar cifrado.

La ingeniería de detección trata las detecciones como un producto de software con un ciclo de vida: identificar una amenaza o técnica que cubrir, investigar la telemetría y el comportamiento, desarrollar la regla, probarla contra datos de verdaderos positivos y benignos, desplegarla (a menudo por fases), validarla con emulación de adversario y luego ajustarla continuamente para los falsos positivos y retirar las reglas que ya no se justifican. Cada etapa se documenta y se versiona, y la cobertura se rastrea frente a un marco como ATT&CK.

Los LOLBins (living-off-the-land binaries) son herramientas del sistema legítimas, firmadas y preinstaladas — como certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — que los atacantes abusan para descargar, ejecutar o persistir mientras se camuflan con la actividad administrativa normal. Como el propio binario es de confianza, no puedes detectar sobre el archivo; detectas sobre el contexto: argumentos de línea de comandos anómalos, procesos padre inusuales, conexiones de red inesperadas desde estas herramientas, y ejecución desde rutas extrañas o por usuarios inusuales.

La caza basada en TTP usa MITRE ATT&CK como mapa: elige una técnica relevante para tu modelo de amenazas (idealmente una con cobertura débil), forma una hipótesis concreta sobre cómo aparecería en tu telemetría, identifica las fuentes de datos que la revelan, consúltalas y analiza los aciertos. Una buena caza está acotada, guiada por hipótesis, ligada a un comportamiento real de adversario, es repetible y produce un resultado duradero — una nueva detección, una brecha de cobertura documentada o evidencia de que la técnica está ausente — independientemente de si encuentra una intrusión.

El acceso justo a tiempo concede privilegios elevados solo cuando se necesitan, por un tiempo limitado, normalmente con aprobación; luego expiran automáticamente, de modo que no hay privilegio permanente que robar. Las cuentas de emergencia (break-glass) son la excepción deliberada: cuentas de emergencia muy privilegiadas, normalmente inactivas, bloqueadas tras controles estrictos y fuertes alertas, usadas solo cuando fallan las vías de acceso normales. El JIT reduce la superficie de ataque cotidiana; el break-glass garantiza que aún puedes entrar durante una crisis.

Mantén los access tokens de corta duración (minutos) para que uno robado expire rápido, y usa refresh tokens de mayor duración para obtener nuevos access tokens sin volver a pedírselo al usuario. Rota los refresh tokens en cada uso y detecta la reutilización de un token ya consumido como señal de robo, revocando la cadena. El objetivo es equilibrar la limitación de la ventana de un token comprometido frente a no obligar a los usuarios a reautenticarse constantemente.

Zero Trust descarta la suposición de que estar dentro de la red te hace de confianza. Cada petición a un recurso se autentica y autoriza por sus propios méritos —verificando identidad, salud del dispositivo y contexto— mediante un policy decision point, concediendo acceso de mínimo privilegio por sesión. No hay zona interna de confianza; la ubicación de red de una petición es solo una señal más, no un pase libre.

Un desensamblador como Ghidra o IDA te da el mapa estático completo: referencias cruzadas, pseudocódigo decompilado y cada ruta de código se ejecute o no. Un depurador como x64dbg te permite ejecutar el ejemplar bajo control — poner breakpoints, inspeccionar registros y memoria, observar el descifrado ocurrir, y seguir la ruta que el código toma realmente con entradas reales. Se lee la estructura y la intención estáticamente, luego se adjunta el depurador para resolver lo que el análisis estático no puede: cadenas descifradas en tiempo de ejecución, APIs resueltas dinámicamente, cargas útiles empaquetadas y qué rama toma una condición. Los dos juntos cierran sus mutuas carencias.

La inyección de procesos ejecuta código malicioso dentro de otro proceso para ocultarse y heredar su confianza. La inyección remota clásica reserva memoria en un objetivo con VirtualAllocEx, escribe una carga útil vía WriteProcessMemory y la ejecuta con CreateRemoteThread. Las variantes incluyen la inyección de DLL vía LoadLibrary, el process hollowing que desmapea un proceso legítimo suspendido y reemplaza su imagen, la inyección APC que encola código en un hilo, y la carga reflexiva o mapeada manualmente que evita LoadLibrary por completo. Se detectan por las secuencias de API reveladoras, la memoria RWX en un proceso normalmente limpio, los hilos sin archivo de respaldo en disco y las anomalías padre-hijo.

El malware consciente del sandbox comprueba si lo están observando antes de portarse mal. Busca artefactos de VM e hipervisor (drivers, prefijos MAC, claves de registro, CPUID), herramientas de análisis y depuradores (nombres de proceso, IsDebuggerPresent, temporización del single-stepping), y señales de un usuario real (pocos procesos, sin documentos recientes, sin movimiento de ratón, poco uptime, disco pequeño). Puede demorarse con sleeps largos o solo activarse en una fecha, idioma o dominio concretos. Los analistas lo contrarrestan endureciendo la VM para que parezca real, parcheando las comprobaciones, adelantando los sleeps, simulando actividad del usuario y confirmando el comportamiento con desensamblado estático.

El desempaquetado recupera el código original que el packer ocultó. Para packers conocidos usas el desempaquetador correspondiente o un emulador. Para packers personalizados desempaquetas manualmente: ejecutas la muestra en un depurador, dejas que el stub descomprima el payload en memoria, encuentras el momento en que salta al original entry point (a menudo poniendo un breakpoint en memoria que pasa a ser ejecutable, o en el tail jump), luego vuelcas la imagen del proceso desde memoria y reconstruyes la import address table con una herramienta como Scylla o PE-sieve. El resultado es un PE ejecutable o analizable que contiene el payload real.

Un pentest busca cobertura amplia — encontrar tantas vulnerabilidades como sea posible en un objetivo delimitado. Un red team es emulación de adversario dirigida por objetivos: elegir una meta (p. ej. alcanzar los datos más valiosos), emular los TTP de un actor de amenaza concreto, mantenerse sigiloso para probar la detección y la respuesta, y evitar el escaneo ruidoso. El red teaming mide al equipo azul y a toda la organización, no solo al activo; ambos requieren reglas de enfrentamiento estrictas y autorización.

Una evaluación de riesgos identifica los activos y su valor, las amenazas y vulnerabilidades que podrían afectarlos, y luego estima el riesgo como función de la probabilidad y el impacto. Puedes hacerla cualitativamente (alto/medio/bajo, rápido y subjetivo) o cuantitativamente (SLE × ARO = ALE, basado en datos pero más difícil). Marcos como NIST RMF e ISO 27005 le dan estructura, y el resultado alimenta el tratamiento del riesgo: mitigar, transferir, evitar o aceptar.

Empieza por entender el modelo de amenazas de la aplicación y dónde maneja entradas no confiables, secretos, autenticación y autorización. Usa SAST para escanear ampliamente y DAST contra la aplicación en ejecución, pero trata la salida de las herramientas como pistas, no como hallazgos — descarta falsos positivos. Luego dedica el tiempo humano a las áreas de alto valor y dependientes del contexto que las herramientas pasan por alto: lógica de autorización, lógica de negocio, uso de criptografía y fronteras de confianza. Rastrea el flujo de datos desde la fuente hasta el sink.

El modelado de amenazas responde a cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué hacemos al respecto y si hicimos un buen trabajo. Diagramas el sistema (a menudo un diagrama de flujo de datos con fronteras de confianza), enumeras amenazas con un marco como STRIDE, priorizas por riesgo y asignas mitigaciones. PASTA añade un matiz centrado en el riesgo y el atacante; los árboles de ataque descomponen un único objetivo. Hacerlo en tiempo de diseño es mucho más barato que parchear producción.

Usa el host comprometido como relé hacia la subred inalcanzable. Configura una redirección de puerto para un único servicio, o un proxy SOCKS dinámico (SSH -D o chisel) y enruta tus herramientas a través de él con proxychains, para que tu máquina atacante alcance los hosts internos por el pivote.

Enumera los privilegios actuales (whoami /priv), los servicios mal configurados (permisos débiles, rutas de servicio sin comillas), AlwaysInstallElevated, las tareas programadas, las credenciales almacenadas y los parches que faltan. WinPEAS o PowerUp automatizan el barrido; los abusos de privilegios de token como SeImpersonate son victorias frecuentes de alto valor.

Cualquier usuario autenticado del dominio puede solicitar un ticket de servicio Kerberos (TGS) para cualquier cuenta con un SPN. Ese ticket se cifra con el hash de contraseña NTLM de la cuenta de servicio, así que lo extraes y crackeas la contraseña sin conexión — sin necesidad de acceso privilegiado para empezar, y es casi silencioso.

El pivoting convierte un host comprometido en un relé para alcanzar segmentos internos a los que tu máquina no puede enrutar. Usas reenvío de puertos, un proxy SOCKS sobre tu canal C2 (p. ej. Chisel, el reenvío dinámico de SSH) o enrutamiento por agente, y luego ejecutas herramientas a través de ese túnel para atacar la siguiente subred.

Un buen informe sirve a dos públicos: un resumen ejecutivo que encuadra el riesgo de negocio para la dirección, y hallazgos detallados y reproducibles con evidencias, calificaciones de riesgo precisas y remediación priorizada para el equipo técnico. El informe — no el exploit — es el entregable.

Reducir la superficie de ataque (eliminar paquetes y servicios sin uso), forzar SSH solo por clave sin inicio de sesión root, mantener el sistema parcheado, ejecutar un cortafuegos de denegación por defecto que exponga solo los puertos necesarios, aplicar privilegios mínimos mediante sudo y permisos de archivos, habilitar auditd y registro centralizado, y añadir monitorización de integridad más un MAC como SELinux o AppArmor.

Un SDLC seguro integra la seguridad en cada fase en lugar de añadirla al final. Los requisitos incluyen casos de seguridad y de abuso, el diseño añade modelado de amenazas, el desarrollo usa codificación segura y SAST más escaneo de dependencias, las pruebas añaden DAST y pruebas de penetración, y operaciones añade monitorización, parcheo y respuesta a incidentes — desplazando la seguridad hacia la izquierda.

La segmentación divide una red en zonas aisladas para que una brecha en una no pueda alcanzar libremente a las demás, limitando el movimiento lateral. Zero trust va más allá: elimina por completo la confianza implícita basada en la ubicación de red, autenticando y autorizando cada solicitud venga de donde venga — la microsegmentación es una forma de implementarlo.

Casi todo pasa por el DNS, así que los logs de DNS revelan amenazas que otras fuentes pasan por alto: beaconing de command-and-control (llamadas regulares a un dominio), tunneling y exfiltración DNS (alto volumen de subdominios largos y codificados) y dominios generados algorítmicamente (DGA). Se detectan mediante patrones como la regularidad de las consultas, la entropía, los tipos de registro y el volumen, no por una sola resolución sospechosa.

El movimiento lateral es un atacante que usa un punto de apoyo para alcanzar otros sistemas. Los signos incluyen logons de red inesperados (tipo 3) y RDP (tipo 10), acceso a recursos compartidos admin como C$ y ADMIN$, herramientas de ejecución remota como PsExec, WMI y WinRM, patrones de pass-the-hash, y una cuenta normalmente local que de repente se autentica en muchos hosts.

Content-Security-Policy es una cabecera de respuesta HTTP que indica al navegador qué fuentes de scripts, estilos, imágenes y otros contenidos pueden cargarse y ejecutarse en una página. Al prohibir el script en línea y los orígenes no confiables — idealmente mediante nonces o hashes — actúa como una defensa en profundidad de respaldo que neutraliza las cargas útiles de XSS inyectadas, incluso cuando alguna se cuela.

El SSRF engaña a un servidor para que realice peticiones HTTP (u otras) a un destino elegido por el atacante, abusando de la posición de red del servidor para alcanzar servicios internos tras el cortafuegos. En la nube es especialmente grave porque el servicio de metadatos de instancia (por ejemplo, 169.254.169.254) puede devolver credenciales IAM, convirtiendo un SSRF en un compromiso de la cuenta en la nube.

El XXE abusa de un analizador XML que resuelve las entidades externas definidas en la DTD de un documento. Un atacante declara una entidad que apunta a un archivo local o una URL interna, y el analizador la obtiene — permitiendo la divulgación de archivos, el SSRF y la denegación de servicio. La solución es desactivar el procesamiento de DTD y la resolución de entidades externas en la configuración del analizador.