Preguntas de entrevista de ciberseguridad de nivel Mid-level

En la práctica, no. AES-128 ya exige unos 2^128 de esfuerzo para romperse por fuerza bruta — totalmente inviable — así que AES-256 no te hace realmente más seguro frente a la fuerza bruta; sobre todo añade margen (reserva poscuántica, cumplimiento). Ambos están estandarizados y sin romper. Tu modo (GCM), el manejo de nonces y la gestión de claves importan mucho más que 128 frente a 256. «AES-256 es el doble de seguro» es la idea errónea.

No. El antivirus es una señal, no una prueba. Omite ataques sin archivo y en memoria, muestras nuevas u ofuscadas, el abuso de herramientas legítimas (living-off-the-land) y los rootkits diseñados para ocultarse de él. La ausencia de prueba no es prueba de ausencia — la garantía real proviene de la telemetría EDR, el análisis forense de memoria, el análisis conductual y la caza de IOC. Tratar un análisis antivirus limpio como prueba de un sistema limpio es un error clásico de respuesta a incidentes.

No. La nube funciona con un modelo de responsabilidad compartida: el proveedor asegura la infraestructura subyacente («seguridad de la nube»), pero tú sigues siendo responsable de tus datos, la gestión de identidades y accesos, la configuración y — en IaaS — el sistema operativo y los parches («seguridad en la nube»). La gran mayoría de las brechas en la nube son errores de configuración del cliente, como buckets públicos e IAM demasiado permisivo, no fallos del proveedor. Suponer que el proveedor asegura tus datos es justamente cómo ocurren esas brechas.

No. Borrar la cookie solo quita la credencial de tu navegador — el registro de sesión (o un JWT aún válido) en el servidor suele seguir siendo utilizable hasta que expire o se invalide de forma explícita. Un atacante que ya capturó el token puede seguir usándolo. El error trata la cookie como la sesión misma; es solo un puntero al estado del servidor. El cierre real debe invalidar la sesión en el servidor, o revocar y dar un TTL corto al token.

En gran medida no. El nombre de host de destino se envía en claro en la extensión SNI del ClientHello de TLS, y tu consulta DNS suele revelarlo también, de modo que un ISP o una red pueden ver QUÉ sitio visitas incluso por HTTPS — solo que no pueden leer la ruta ni el contenido. El ClientHello cifrado (ECH) y el DNS-over-HTTPS pueden cerrar esta brecha, pero no son universales. «HTTPS lo oculta todo» es la idea equivocada.

No. La MFA sube mucho el listón, pero los factores OTP y push son phisheables: los kits de adversario en el medio (p. ej. Evilginx) retransmiten el inicio de sesión y el código en tiempo real, y la fatiga MFA / push-bombing empujan al usuario a aprobar. Los códigos capturados son reutilizables dentro de su corta ventana. El error es «MFA = imposible de phishear»; lo que importa es el tipo de factor. La MFA resistente al phishing — passkeys FIDO2/WebAuthn ligados al origen del sitio — es lo que realmente lo derrota.

No. El NAT (y el PAT) asigna direcciones privadas a una IP pública y, como efecto secundario, descarta las conexiones entrantes no solicitadas porque no existe ninguna correspondencia para ellas. Eso no es una política de seguridad — no hay inspección, ni reglas, ni registro — y la travesía de NAT, el hole punching y el C2 iniciado en salida pasan sin problema. El NAT es una herramienta de direccionamiento; aun así necesitas un cortafuegos real. «NAT = cortafuegos» es la idea equivocada.

No por sí solo. Muchos sistemas mantienen válidas las sesiones existentes y los tokens ya emitidos tras un cambio de contraseña — tokens de actualización OAuth, «contraseñas de aplicación», claves de API y cookies persistentes — así que un atacante con una sesión activa puede permanecer dentro. La respuesta correcta es cambiar la contraseña Y invalidar todas las sesiones y tokens, revocar las credenciales de aplicación y auditar los dispositivos MFA y los ajustes de recuperación. Creer que un restablecimiento solo expulsa al atacante es un error clásico de respuesta a incidentes.

No. La mayoría de las intrusiones reales establecen persistencia (servicios, tareas programadas, claves de inicio, implantes) que sobrevive a un reinicio, así que el atacante simplemente vuelve. Peor aún, apagar borra las pruebas volátiles — procesos en ejecución, conexiones de red, malware en memoria y claves de cifrado — que necesitas para acotar el incidente. Lo correcto es contener aislando el host mientras se preserva la memoria, y luego investigar. Reiniciar o apagar como «solución» es un instinto dañino.

No. Una sal es un valor aleatorio único almacenado justo al lado del hash; su función es lograr que contraseñas idénticas produzcan hashes distintos y anular las rainbow tables precalculadas — no permanecer en secreto. Es normal que un atacante que roba la base obtenga también las sales. Lo que protege de verdad las contraseñas es un hash lento y salado (bcrypt, scrypt, Argon2). Una «pimienta» secreta opcional y separada es un concepto diferente.

Un modelo de terceros es una dependencia de cadena de suministro: verifica que provenga de una fuente de confianza con sumas de verificación/firmas coincidentes, que su licencia permita tu uso, y que el formato de archivo no ejecute código arbitrario al cargarse (prefiere serialización segura frente a formatos tipo pickle). «Se carga» y «velocidad de descarga» no dicen nada sobre la confianza, y suponer que los modelos públicos son seguros ignora los riesgos reales de envenenamiento y deserialización.

Enviar PII de clientes a una API externa la expone al procesamiento y la retención de un tercero y puede incumplir obligaciones de privacidad. Minimiza y redacta lo que se envía, confirma los términos de uso/retención del proveedor y un acuerdo de procesamiento de datos (o garantías de no entrenamiento), o pasa a un despliegue privado para datos sensibles. La longitud de la clave es irrelevante, y enviar más PII aumenta la exposición.

El almacenamiento de contraseñas necesita un hash deliberadamente lento, salado y con alto coste de memoria — bcrypt, scrypt o Argon2 — para que crackear hashes robados sea costoso y las rainbow tables no apliquen. Un hash rápido como SHA-256 se fuerza por fuerza bruta trivialmente a gran escala; el cifrado reversible implica que una sola compromisión de clave expone todas las contraseñas a la vez; y el texto plano es indefendible por muy cerrada que esté la base de datos. Elija Argon2id (o bcrypt) con un factor de coste ajustado y un salt único por usuario.

SSLv3, TLS 1.0 y RC4 están rotos u obsoletos y permiten ataques de downgrade y descifrado, así que desactívelos y exija TLS 1.2 o 1.3 con suites de cifrado fuertes y con forward secrecy, aceptando la rara pérdida de clientes muy antiguos. Dejarlos activos por compatibilidad mantiene la debilidad explotable. Añadir un segundo certificado o pasar a uno autofirmado no elimina los protocolos débiles, y el autofirmado daña la confianza sin arreglar la criptografía.

La integridad probatoria se basa en hashear la imagen en la adquisición (por ejemplo, SHA-256) y verificar el hash después para probar que no fue alterada, mantener una cadena de custodia documentada, y analizar una copia de trabajo para que el original quede intacto. Renombrar el archivo no hace nada por la integridad, y comprimirlo para ahorrar espacio no prueba la integridad ni ayuda a la admisibilidad. Tocar el original arriesga una destrucción de pruebas que puede hacer que se descarte la evidencia. Hashea, documenta la custodia y trabaja sobre una copia verificada.

Los auditores comprueban evidencias, no intenciones: muestra la política de revisión de accesos, los registros fechados de cada revisión con la firma de un aprobador y la confirmación de que los accesos señalados se revocaron y verificaron. Una confirmación verbal no prueba nada reproducible, una promesa de empezar el próximo trimestre demuestra que el control no operó durante el periodo auditado, y un organigrama describe líneas jerárquicas, no decisiones de acceso. Solo los artefactos fechados y atribuibles demuestran que el control operó según lo diseñado durante todo el periodo.

Las copias de seguridad son necesarias pero no suficientes: la recuperación ante desastres y la continuidad de negocio son la capacidad probada de restaurar las operaciones dentro de los objetivos acordados de tiempo y punto de recuperación (RTO/RPO), lo que exige un plan documentado, dependencias mapeadas, runbooks y restauraciones validadas, no solo la existencia de archivos de copia. Afirmar que son lo mismo confunde una copia de datos con una capacidad operativa. El DR no es solo contratar un seguro, que transfiere la pérdida financiera pero no restaura los sistemas. Y las copias no hacen innecesario un plan de DR: las copias no probadas fallan habitualmente cuando por fin se necesitan. La aclaración: el DR debe ejercitarse, no presumirse.

Un manejo inconsistente suele significar que no hay una definición compartida de sensibilidad, así que el control fundamental es un esquema de clasificación de datos (p. ej., público/interno/confidencial/restringido) con requisitos definidos de manejo, almacenamiento y compartición por nivel, que permite a los equipos aplicar controles proporcionados. No cifrar nada 'para simplificar' o tratar todos los datos como públicos despoja de protección a los datos que la necesitan. Borrar todos los datos de más de un día destruye registros que el negocio y la ley requieren. Solo un esquema de clasificación alinea la fuerza de los controles con la sensibilidad real de los datos.

El riesgo de una baja es el acceso que persiste, así que el control a verificar es el desaprovisionamiento puntual de cada vía de acceso —cuentas de directorio, SSO, VPN, credenciales privilegiadas y de servicio, y SaaS de terceros— conciliado con el proceso de alta/cambio/baja (JML). Suponer que RR. HH. lo gestiona todo sin verificar deja brechas sin propietario. Mantener la cuenta activa 'por si vuelve' es un riesgo permanente y no supervisado. Desactivar solo el correo ignora los muchos otros sistemas que la persona aún podría alcanzar. La clave es verificar que el acceso se elimina real y completamente, no confiar en que así fue.

La gobernanza significa que el riesgo se captura y se gestiona, no se maneja de manera informal: regístralo en el registro de riesgos con la probabilidad y el impacto evaluados, asigna un propietario responsable, decide y documenta el tratamiento (mitigar, transferir, aceptar o evitar) y fija una fecha de revisión. Resolverlo tú mismo en el momento se salta la propiedad, la priorización y el seguimiento, y puede que ni siquiera te corresponda. Ignorarlo hasta que se convierta en un incidente es negligente, y enviarlo por correo a todos genera ruido pero ninguna responsabilidad ni seguimiento. El registro convierte una observación puntual en una decisión rastreada, con propietario y revisada.

Las cuentas de servicio sin usar y con permisos excesivos son objetivos preferentes y una gran superficie de ataque. Inventaríelas, desactive o elimine las no usadas (vigilando roturas), ajuste las supervivientes al mínimo privilegio y dé a cada una un propietario y una revisión recurrente. Dejarlas es un riesgo permanente, darles acceso admin general maximiza el radio de impacto, y consolidar todo en una sola cuenta compartida destruye el mínimo privilegio y la rendición de cuentas.

La persistencia en Linux se esconde en las rutas de ejecución programada y de arranque: cron y timers/unidades de systemd, claves añadidas en authorized_keys SSH, archivos rc del shell y scripts de perfil modificados, y binarios de servicio o bibliotecas precargadas troyanizados. Revísalos sistemáticamente. El historial del navegador y la configuración del fondo de pantalla no son mecanismos de persistencia, y reiniciar no eliminará nada que se restablezca en el arranque — solo lo relanza. El propósito de la persistencia es sobrevivir a los reinicios, así que un reinicio no demuestra nada.

Un binario SUID-root se ejecuta con privilegios de root, y si es escribible por todos un atacante puede reemplazarlo o modificarlo para ejecutar código arbitrario como root — una vía clásica de escalada de privilegios local. Retira el bit SUID, corrige el propietario y los permisos, e investiga cómo apareció esta mala configuración, ya que puede indicar un compromiso. Cifrar el archivo deja intacta la ruta ejecutable, y renombrarlo solo traslada el problema sin eliminar la escalada. Ninguna de estas opciones aborda la causa raíz.

El SOC necesita actuar, así que entrega contenido de detección estructurado y accionable: IOC de red, hashes, artefactos de host como el mutex, y firmas conductuales o YARA que pueda desplegar para cazar y bloquear. Un relato exhaustivo de llamadas a la API no es directamente operativo. Un solo hash lo cambian los atacantes trivialmente. Una atribución especulativa no sirve al SOC para defenderse. El objetivo: detecciones que el SOC pueda desplegar hoy.

Detona solo en una VM desechable y aislada, con snapshots y una red controlada (por ejemplo, servicios simulados o egress estrechamente monitorizado), de modo que el malware no pueda alcanzar producción ni internet sin control. El antivirus de tu portátil no contendrá de forma fiable malware activo. Un servidor de producción pone en riesgo sistemas reales. La máquina de un colega solo traslada el peligro. El aislamiento y los snapshots reversibles son el núcleo de un laboratorio de malware seguro.

La identificación de la familia guía las decisiones: a partir de la nota, la extensión y los IOC puedes señalar si existe un descifrador gratuito, los TTP típicos del grupo (incluido el robo de datos para extorsión) y el radio de impacto probable, alimentando al equipo de IR. Reformatear destruye la evidencia y la información de alcance. La gramática de la nota no es accionable. Recomendar negociar es una decisión de negocio y legal, no el primer paso del analista. Identifica primero, luego habilita al IR.

Empieza con triaje estático en un entorno aislado: calcula hashes, extrae cadenas, inspecciona las cabeceras PE y los imports, y verifica la reputación, para entender la muestra antes de arriesgarte a ejecutarla. Ejecutarla en tu propia estación puede infectarte a ti y a la red. Subir muestras de clientes con nombres identificables filtra datos sensibles a terceros. Borrarla destruye la evidencia y la posibilidad de crear detecciones.

Como los firewalls evalúan las reglas de arriba abajo, una regla any/any amplia cerca de la parte superior cortocircuita todas las reglas inferiores y permite todo el tráfico — el firewall deja en la práctica de aplicar nada. Reemplácela por reglas explícitas de mínimo privilegio para los flujos realmente necesarios, ordenadas para que los permisos y denegaciones específicos surtan efecto, terminando en una denegación por defecto. Llamarla eficiente es erróneo, moverla al final aún puede ocultar la denegación por defecto, y renombrarla no cambia nada de lo que permite.

Si el navegador adjunta automáticamente la cookie de sesión, una página maliciosa puede desencadenar la transferencia en nombre de la víctima — es Cross-Site Request Forgery (CSRF). Proteja las peticiones que cambian de estado con tokens anti-CSRF y cookies SameSite, y verifique la cabecera Origin/Referer. La cookie prueba la identidad pero no la intención, un CAPTCHA de inicio de sesión no protege una acción ya autenticada, y HTTPS protege la confidencialidad del transporte, no la falsificación de peticiones.

Si un atacante puede subir un archivo ejecutable del lado del servidor (o HTML/SVG) a un directorio servido, puede lograr ejecución remota de código o XSS almacenado. Valide el tipo de contenido real, almacene los archivos fuera de la raíz web o en un almacén no ejecutable, aleatorice los nombres y sírvalos de modo que no puedan ejecutarse ni interpretarse como marcado. Las cargas de página más lentas y el uso de disco son problemas operativos, no el riesgo de seguridad explotado aquí.

LSASS almacena credenciales y secretos en caché, así que un proceso inesperado leyendo su memoria es el sello del robo de credenciales (por ejemplo, un volcado de tipo mimikatz). Tría el proceso ofensor y su padre, aísla el host para detener el movimiento lateral, y rota las credenciales que pudieron capturarse — incluidas las cuentas privilegiadas y de servicio. No tiene nada que ver con el renderizado gráfico ni el espacio en disco, e ignorarlo como normal puede llevar a un compromiso de todo el dominio. Los distractores de apariencia inocua son justo cómo los analistas pasan por alto una intrusión activa.

El software legítimo rara vez ejecuta PowerShell desde %TEMP% mediante una tarea programada recién creada — es una técnica común de persistencia y ejecución. Examina la definición de la tarea, el script invocado, el proceso creador y la cronología, contén el host y barre el entorno en busca del mismo patrón. Las actualizaciones no se ven así, confiar ciegamente en las tareas programadas ignora una TTP conocida, y borrar System32 rompe el sistema operativo sin hacer nada contra la amenaza. Las tres primeras opciones reflejan un criterio peligrosamente débil.

Es control de acceso roto (IDOR): el servidor no comprueba que el usuario autenticado pueda acceder al objeto solicitado. La corrección es una autorización por objeto aplicada en el servidor en cada solicitud. Sanear el número no establece la propiedad. Cifrar u ofuscar el ID es oscuridad y sigue siendo adivinable, filtrable o reproducible. El método HTTP es irrelevante para la autorización. Verifica siempre el derecho del llamante sobre el objeto concreto antes de devolverlo.

Es un fallo de asignación masiva (over-posting): el servidor mapea a ciegas el JSON del cliente sobre campos sensibles del modelo. Corrígelo vinculando solo una lista blanca explícita de campos permitidos (DTO / strong params) para que atributos privilegiados como isAdmin no los pueda establecer el cliente. Ocultar el campo en el frontend y añadir validación en el cliente se evitan ambos con una solicitud cruda. Renombrar isAdmin es oscuridad, fácilmente descubierta. Controla qué campos se vinculan, en el servidor.

Las consultas parametrizadas son la verdadera corrección: separan el código de los datos, de modo que la entrada del usuario siempre se trata como un valor, nunca como SQL capaz de cambiar la estructura de la consulta. El escape manual es propenso a errores y evitable según codificaciones y dialectos. Un WAF es un control compensatorio, no una solución, y los trucos de codificación lo burlan. Una comprobación de longitud no detiene la inyección. Corrígelo en la capa de la consulta.

El XSS almacenado se corrige codificando los datos para el contexto exacto donde se renderizan (cuerpo HTML, atributo, JavaScript, URL) para que el navegador los trate como texto, con una Content-Security-Policy como segunda capa. Poner la palabra «script» en lista negra se evita trivialmente mediante manejadores de eventos, mayúsculas mezcladas y codificaciones. No puedes obligar a tus usuarios a desactivar JavaScript. Pedir a los usuarios que no introduzcan HTML no es un control aplicable. Codifica en la salida, cada vez que renderizas.

El código transitivo se ejecuta en tu aplicación, así que una CVE crítica es tu riesgo. Evalúa si la ruta de código vulnerable es realmente alcanzable, luego remedia subiendo o anulando la versión (o mitigando) y verifica en producción. Ignorarla por ser transitiva deja un agujero conocido que un atacante puede explotar. Silenciar la auditoría solo oculta el aviso. Reinstalar node_modules trae la misma versión vulnerable. Haz seguimiento mediante SCA, no la acalles.

El modelado de amenazas es más barato y eficaz en la fase de diseño, antes de que el código fije las decisiones: recorre los flujos de datos, enumera amenazas con un marco como STRIDE, integra las mitigaciones y revísalo a medida que el diseño evoluciona. Hacerlo solo tras un incidente o en el pentest anual encuentra los problemas cuando ya son caros de corregir y están expuestos. Y fiarse de «desarrolladores cuidadosos» es una esperanza, no un control repetible y auditable.

Un 30 % de clics es una línea base que mejorar, no una lista de personas a castigar: combinar formación dirigida por rol y un botón de reporte sin fricción con defensas técnicas (MFA, filtrado de correo, mínimo privilegio) para que un solo clic no derive en compromiso, y seguir la tendencia en el tiempo. Avergonzar públicamente a los empleados suprime el reporte del que dependes. Declarar al personal irrecuperable elimina un control que deberías reforzar. Otro correo alarmista a toda la plantilla no es una intervención medible ni cambia el comportamiento.

Las simulaciones ensayan el lado humano y de decisión de la RI — quién tiene autoridad para declarar un incidente, cómo fluye la comunicación legal/RR. PP./dirección y dónde se rompe el manual — para que la primera vez que tomes esas decisiones no sea durante una crisis real. Es mucho más barato encontrar brechas en un ejercicio que en plena brecha. No son una casilla de cumplimiento vacía, no sirven para asignar culpas por incidentes pasados, y son transversales, no solo del SOC — la dirección debe practicar las decisiones que solo ella puede tomar.

Sin registros de auditoría del plano de control estás ciego ante quién hizo qué a nivel de nube, y la detección, la forense y el cumplimiento dependen de ese registro. Activa CloudTrail de inmediato, a nivel de organización, entregando a un bucket separado, con acceso controlado y resistente a manipulación (inmutable). Decir que no importa mientras nada vaya mal ignora que no tendrías historial cuando algo vaya mal. Esperar a un incidente significa que las primeras acciones decisivas ya quedan sin registrar e irrecuperables. Los registros de aplicación no capturan la actividad de API, IAM ni consola del plano de control.

Los puertos de administración abiertos a todo Internet se escanean y atacan por fuerza bruta en minutos, así que la solución es reducir la superficie de ataque: restringe el ingreso del security group a CIDR de administración conocidos o VPN, o elimina por completo el tráfico entrante usando un bastión o SSM Session Manager. Mover SSH a un puerto no estándar es seguridad por oscuridad que los escáneres vencen de forma trivial. Una contraseña más fuerte no reduce la superficie expuesta ni detiene el credential stuffing. Confiar en un firewall de host ignora la superficie de ataque que el security group anuncia abiertamente a Internet.

Los datos de clientes expuestos públicamente son una exposición activa: remedia primero el acceso activando Block Public Access y corrigiendo la política del bucket y la política IAM para detener la fuga en curso. Luego extrae los registros de acceso (S3 server access logs / eventos de datos de CloudTrail) para evaluar qué se alcanzó realmente y activa los procesos de brecha y notificación según la política. Abrir un ticket para el próximo sprint deja datos regulados expuestos durante días. Copiar los datos a otro sitio crea una segunda copia pero deja el bucket original abierto. Renombrar no cambia nada de sus permisos.

Los secretos deben vivir en un almacén gestionado con control de acceso, auditoría y rotación, inyectados en runtime, nunca versionados en el control de código. Usa un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) y elimina los valores versionados del historial, luego rótalos porque deben tratarse como comprometidos. El base64 es codificación, no protección: cualquiera puede decodificarlo. Un repo privado sigue propagando el secreto a todos con acceso de clonación, además de los sistemas de CI y los forks. Compilarlo en el binario solo oculta un secreto que sigue siendo trivial de extraer.

Una clave estática incrustada en una imagen se filtra con facilidad y vive para siempre, así que la solución es eliminar por completo la credencial de larga duración: adjunta un rol IAM mediante un perfil de instancia, que entrega credenciales temporales rotadas automáticamente sin nada incrustado. La rotación manual cada 90 días sigue dejando un secreto de larga duración en la AMI entre rotaciones. Mover la clave a una variable de entorno no la hace menos estática ni menos filtrada. Enviarla por correo al equipo de operaciones propaga la exposición a buzones y archivos.

El cambio manual en la consola es deriva de configuración: el próximo terraform apply puede revertir en silencio el arreglo, y el cambio además se saltó la revisión y la auditoría. Reconcílialo codificando el cambio en Terraform, ejecutando plan/apply para que el código y la realidad coincidan, y añadiendo salvaguardas contra cambios ad hoc en la consola (acceso a consola con mínimo privilegio, SCP, detección de deriva). No hacer nada deja una mina para el próximo apply. Borrar el estado de Terraform es destructivo y puede dejar recursos huérfanos o duplicados. Abandonar Terraform tira por la borda la reproducibilidad, la revisión y los rastros de auditoría.

Sigue el orden de volatilidad. La RAM, las conexiones de red activas y la tabla de procesos desaparecen al apagar; captúralas primero, luego toma una imagen forense del disco documentando los hashes y una cadena de custodia ininterrumpida. Un apagado limpio destruye la evidencia residente en memoria — incluido el malware sin archivos y las claves que solo viven en la RAM. Copiar-y-luego-borrar altera la escena y rompe la integridad. Ejecutar el antivirus de la empresa muta el sistema y puede poner en cuarentena o borrar el mismo artefacto que necesitas analizar.

Las reglas de enfrentamiento suelen excluir la denegación de servicio en producción, y una caída no planificada causa un daño real al negocio y puede anular el compromiso. Verifica primero el alcance; si una prueba de concepto destructiva no está autorizada, demuestra la vulnerabilidad por medios más seguros y documenta claramente el impacto probable. Lanzar el exploit por una captura de pantalla es temerario. Ejecutarlo repetidamente por «métricas de fiabilidad» multiplica la caída. Omitirlo en silencio oculta al cliente un riesgo serio y explotable.

Los compromisos profesionales terminan con una limpieza completa y un inventario de artefactos, para no dejar nueva superficie de ataque ni enturbiar el entorno del cliente. Dejar shells o cuentas para que el cliente las encuentre es negligente y peligroso: un atacante real podría reutilizarlas. Mantener una puerta trasera «para la próxima» es poco ético y probablemente ilegal. Borrar tus propios registros de actividad destruye la pista de auditoría que el cliente necesita para validar la prueba y reconstruir lo que hiciste.

Las pruebas de ingeniería social deben mantenerse dentro de pretextos acordados y éticos: lo bastante realistas para ser útiles, pero sin coacción, sin suplantar autoridades ni explotar situaciones personales o médicas. Un restablecimiento genérico de contraseña de IT acordado en las reglas de enfrentamiento es válido. Hacerse pasar por el hijo enfermo de un empleado real o amenazar a alguien con el despido causa un daño psicológico genuino. Hacerse pasar por las fuerzas del orden suplanta a una autoridad y suele ser ilegal incluso con un compromiso firmado.

Demuestra la vulnerabilidad sin perjudicar al cliente ni acumular sus datos: muestra que puedes leer datos arbitrarios mediante la versión de la base, el esquema o una sola muestra anonimizada, y detente ahí. Volcar todo el conjunto de datos personales genera responsabilidad de notificación de brecha y de tratamiento para ambas partes. Eliminar una tabla es destructivo y va mucho más allá de una prueba de concepto. Cifrar la base y exigir una recompensa es extorsión, no una prueba: es un delito, no un hallazgo.

La autorización define el compromiso: probar fuera del alcance acordado es potencialmente ilegal e infringe las reglas de enfrentamiento, por muy tentador que sea el objetivo. Documenta lo que viste, detente y obtén la aprobación escrita del cliente antes de continuar. Explotarlo por «más hallazgos» nunca justifica un acceso no autorizado. Explotarlo en silencio confiando en que no te pillarán es a la vez poco ético y un delito, y ampliar el alcance por tu cuenta priva al cliente de su consentimiento informado.

Un informe útil impulsa la remediación: clasifica por riesgo de negocio (probabilidad × impacto), destaca las cadenas de explotación que llevan a un compromiso crítico y da soluciones accionables para cada hallazgo. El orden alfabético entierra lo importante bajo lo que empieza por «A». Lo más largo primero premia la verborrea sobre la gravedad. Eliminar los hallazgos bajos oculta riesgo real y los patrones que el cliente necesita para la defensa en profundidad, dejándolo con una imagen falsamente tranquilizadora.

Los directivos son precisamente las cuentas que quieren los atacantes (BEC, fraude de transferencias), así que eximirlos invierte el modelo de riesgo. Resuelve la fricción, no el control: despliega passkeys/FIDO2 resistentes al phishing, más rápidos que los códigos. Ceder a la exención destruye la credibilidad del programa y deja sin protección tus cuentas de mayor valor. Cancelar el proyecto de MFA abandona un control de primer nivel. Activarlo a escondidas a sus espaldas destruye la confianza y la rendición de cuentas.

Mínimo privilegio más acceso justo-a-tiempo: concede los permisos mínimos necesarios, acotados en el tiempo y registrados, para que depurar sea posible sin un admin permanente que se convierte en un riesgo duradero y un punto ciego de auditoría. Un cluster-admin permanente viola el mínimo privilegio y amplía el radio de impacto de cualquier compromiso. Una negación total bloquea el trabajo legítimo e invita a apaños paralelos arriesgados. Compartir la credencial común de la cuenta de servicio admin destruye la rendición de cuentas — las acciones no se pueden atribuir a una persona.

Trata cualquier secreto subido como quemado: revócalo y rótalo primero, porque los bots rastrean los commits públicos en segundos, luego revisa CloudTrail en busca de abusos y purga el secreto del historial. Borrar el commit no sirve de nada — la clave ya está clonada, bifurcada y cacheada por terceros. Hacer el repo privado deja una clave ya filtrada y activa en manos de los atacantes. Añadir el archivo al .gitignore no cambia nada para un secreto ya commiteado.

Los datos sensibles nunca deberían llegar a los registros: redacta o enmascara en el origen primero para detener la hemorragia, luego remedia los registros históricos y restringe el acceso. PCI DSS prohíbe almacenar así los PAN completos y los CVV, y las contraseñas nunca deberían registrarse. Unos registros «internos» siguen siendo un objetivo de primer orden. Cifrar o restringir el acceso al almacén sigue dejando secretos en texto plano en los registros, accesibles para cualquiera con permiso de lectura — copias de seguridad, pipelines de SIEM y administradores los ven todos.

Las renovaciones manuales fallan, así que elimina el problema mediante ingeniería con renovación ACME automatizada más monitorización de caducidad que avisa con días de antelación. Un recordatorio de calendario es el proceso manual que ya falló. Un certificado autofirmado de larga duración rompe la confianza pública y viola los límites de vigencia modernos (las CA topan la validez en ~398 días, y bajando). Desactivar TLS cambia un corte de disponibilidad por una pérdida catastrófica de confidencialidad e integridad.

Reduce los falsos positivos mediante ingeniería de detección, no cegándote. Reajusta para que las alertas disparen solo en patrones que importan — una misma contraseña probada en muchas cuentas (spraying), una cuenta atacada muchas veces (stuffing/fuerza bruta), viaje imposible — manteniendo los eventos brutos consultables en un panel. Luego mide la precisión de las alertas con el tiempo. Desactivar la regla elimina una señal real, una supresión global crea un punto ciego permanente, y contratar gente para triar puro ruido no escala y los quema.

Consultas TXT de alto volumen y alta entropía, o subdominios largos hacia un solo dominio, son una firma clásica de tunneling DNS / C2-exfiltración: se cuelan datos dentro del DNS para evadir el filtrado de salida. Captura una muestra de consultas para analizarla, sinkholea o bloquea el dominio para cortar el canal, y pivota al host para hallar el proceso responsable. Descartarlo como caché normal o un sitio lento deja pasar una exfiltración en curso. Reiniciar el servidor DNS no hace nada contra el endpoint comprometido y solo interrumpe la resolución de nombres.

Asume que la contraseña ya está comprometida: fuerza un restablecimiento Y revoca las sesiones y tokens activos de la cuenta, porque un reset por sí solo no expulsa a un atacante que ya posee una sesión viva o un token de actualización. Luego caza inicios de sesión anómalos, solicitudes MFA, reglas de buzón y concesiones OAuth de la ventana de exposición. Borrar el correo o decirle al usuario que cambie la contraseña «la próxima vez» deja la cuenta abierta de par en par. Un análisis antivirus aborda el malware del endpoint, no las credenciales robadas en la nube.

Tría por impacto y alcanzabilidad: el volcado de credenciales (firma de mimikatz) en un controlador de dominio es un evento sobre las joyas de la corona que puede llevar a la compromisión total del dominio, así que trabájalo primero. El escaneo de puertos externo ya fue bloqueado por el IDS, la extensión de navegador no aprobada es de baja gravedad, y un certificado TLS caducado en una máquina de prueba interna es informativo. La habilidad central del SOC es priorizar por radio de impacto y probabilidad de escalada, no por la antigüedad ni por lo «ruidosa» que sea la alerta.

La IA ayuda al SOC triando y deduplicando alertas, resumiendo incidentes, enriqueciendo contexto, redactando detecciones y acelerando la incorporación de analistas, reduciendo la fatiga y el tiempo de permanencia. Los riesgos: conclusiones alucinadas o erróneas con seguridad, sesgo de automatización donde los analistas dejan de verificar, prompt injection mediante datos de logs o alertas controlados por el atacante, fuga de datos sensibles a modelos de terceros, y adversarios que usan las mismas herramientas. Mantén un humano en el bucle, verifica las salidas y aísla las entradas no confiables.

La prompt injection directa es cuando un usuario escribe instrucciones adversarias directamente en el prompt para anular el system prompt o las reglas de seguridad. La prompt injection indirecta esconde instrucciones maliciosas dentro de contenido externo que el modelo ingiere después —una página web, un correo, un PDF o un documento RAG—, de modo que el ataque se dispara sin que la víctima lo escriba. La inyección indirecta es el mayor riesgo porque el atacante y la víctima son personas distintas, y la carga útil llega en datos en los que la app confía implícitamente.

El manejo inseguro de salidas es confiar en lo que el modelo devuelve y pasarlo a un sistema aguas abajo sin validación ni codificación. Como la salida del modelo es influenciable por el atacante, renderizarla como HTML en bruto causa XSS, pasarla a un recuperador de URL causa SSRF, y pasarla a un shell o una consulta SQL causa inyección de comandos o SQL. La solución es tratar la salida del modelo exactamente como entrada de usuario no confiable: codificación de salida sensible al contexto, listas de permitidos, saneamiento y parametrización antes de que llegue a cualquier sink.

El OWASP Top 10 for LLM Applications es la lista de consenso de los riesgos más críticos al construir con grandes modelos de lenguaje. La edición 2025 cubre prompt injection, divulgación de información sensible, supply chain, envenenamiento de datos y modelo, manejo inseguro de salidas, excessive agency, fuga de system prompt, debilidades de vectores y embeddings, desinformación y consumo no acotado. Existe porque las listas tradicionales de appsec no capturan los modos de fallo propios de los LLM, y da a los equipos un vocabulario común y una checklist para priorizar controles.

Las apps LLM filtran datos de varias formas: el modelo memoriza y regurgita datos sensibles de entrenamiento o fine-tuning, el system prompt (que puede guardar secretos o lógica) se extrae, los documentos RAG recuperados exponen datos que el usuario no debería ver, y el contexto de un usuario o sesión se mezcla con otro. La prevención implica minimización de datos antes del entrenamiento, nunca poner secretos en los prompts, aplicar autorización por usuario en la recuperación, filtrado de salidas y redacción de PII, y aislamiento por inquilino.

El credential stuffing reproduce pares usuario:contraseña conocidos de brechas de terceros, apostando a la reutilización de contraseñas: alta tasa de éxito por intento, a menudo repartido entre muchas IP y dispositivos para parecer humano. El password spraying prueba una o dos contraseñas comunes (como Winter2026!) en muchas cuentas para mantenerse bajo los umbrales de bloqueo. El stuffing explota la reutilización; el spraying explota contraseñas compartidas débiles. La MFA derrota a ambos.

La Cyber Kill Chain modela una intrusión como siete etapas secuenciales: reconocimiento, armamentización, entrega, explotación, instalación, comando y control (C2) y acciones sobre objetivos. Los defensores asignan detecciones y controles a cada etapa; como las etapas son secuenciales, romper un solo eslabón —bloquear el correo de phishing, matar el C2— interrumpe todo el ataque. Empuja a detectar pronto en vez de solo en la brecha final.

Un IOC es un artefacto forense de que algo malicioso ya ocurrió: un hash de archivo malicioso, una IP o dominio de C2, una clave de registro conocida como dañina. Un IOA es una señal de comportamiento de un ataque que se desarrolla, independientemente de las herramientas concretas, p. ej. un documento de Word que lanza PowerShell y luego sale a Internet. Los IOC son reactivos y fáciles de evadir cambiando un hash; los IOA capturan la intención y sobreviven a los cambios de herramienta.

La persistencia es cómo el malware sobrevive a reinicios y cierres de sesión. Los básicos en Windows son las claves Run/RunOnce del registro (HKLM y HKCU), las tareas programadas y los servicios de Windows, además de las carpetas de inicio, las suscripciones a eventos WMI y el secuestro de DLL. Los cazas con autoruns/Sysinternals, Sysmon y los registros de eventos, buscando binarios sin firmar, rutas extrañas como %AppData% y entradas creadas justo tras el compromiso inicial.

El orden de volatilidad clasifica la evidencia según lo rápido que se desvanece, para recopilar primero lo más frágil. A grandes rasgos: registros/caché de CPU, luego RAM y estado en ejecución (procesos, conexiones de red, ARP), luego archivos temporales/swap, luego disco, luego registro y datos de monitorización remotos y, por último, soportes de archivo y copias de seguridad. También trabajas sobre copias forenses, las hasheas y mantienes una cadena de custodia para que la evidencia siga siendo admisible.

El ransomware es malware que cifra (y cada vez más exfiltra) datos y luego exige pago. En un caso activo: aislar los hosts afectados de la red sin apagarlos si puedes preservar la memoria, identificar el alcance, el paciente cero y la cepa, preservar la evidencia, encontrar y expulsar el punto de apoyo y cualquier puerta trasera, y luego restaurar desde copias offline reconocidas como limpias. Pagar es un último recurso y nunca garantiza la recuperación.

SPF publica qué IP pueden enviar correo en nombre de un dominio. DKIM añade una firma criptográfica para que el receptor verifique que el mensaje no fue alterado y proviene del dominio. DMARC liga los resultados de SPF/DKIM al encabezado From: visible mediante la «alineación», indica a los receptores qué hacer ante un fallo (none/quarantine/reject) y envía informes. SPF y DKIM por sí solos no protegen el From que ve el usuario; DMARC es lo que lo impone.

El análisis estático examina una muestra sin ejecutarla —hashes, cadenas, imports, encabezados y desensamblado—, así que es seguro y de cobertura completa, pero lo derrotan el empaquetado y la ofuscación. El análisis dinámico detona la muestra en un sandbox aislado y observa el comportamiento real —archivos, registro, procesos, red—, lo que atraviesa la ofuscación pero solo revela lo que se ejecuta en esa sesión y puede ser evadido por malware consciente del sandbox. Los analistas combinan ambos.

El registro Security es primario: 4624 inicio de sesión correcto (con tipo de inicio), 4625 inicio fallido, 4634/4647 cierre de sesión, 4672 privilegios especiales asignados, 4720 cuenta creada, 4688 creación de procesos (con línea de comandos si está habilitada) y 4768/4769 Kerberos. Añade 7045 instalación de servicio (registro System), 4698 tarea programada creada y el registro de bloques de script de PowerShell (4104). El tipo de inicio de sesión y la auditoría de líneas de comandos son lo que hace útiles estos registros.

La clasificación etiqueta los datos por sensibilidad para que la organización aplique controles proporcionales al valor y al riesgo, evitando tanto la infraprotección como la sobreprotección costosa. El propietario de los datos (un rol de negocio) fija la clasificación y acepta el riesgo, mientras que el custodio de los datos (a menudo TI) implementa y mantiene los controles de protección.

Una política es la declaración obligatoria de alto nivel de la intención de la dirección; una norma es una regla específica obligatoria que aplica la política (p. ej. AES-256); un procedimiento es el instructivo obligatorio paso a paso; una directriz es una recomendación opcional. Las políticas, normas y procedimientos son obligatorios, mientras que las directrices son discrecionales.

El análisis cuantitativo asigna valores monetarios concretos para calcular la pérdida esperada; el análisis cualitativo clasifica el riesgo en escalas relativas (alto/medio/bajo) mediante juicio experto. El cuantitativo usa SLE = valor del activo x factor de exposición, ARO = ocurrencias esperadas por año, y ALE = SLE x ARO para expresar la pérdida anual esperada en euros.

Puedes mitigar (reducir probabilidad/impacto con controles), transferir (trasladar el impacto financiero mediante seguros o contratos), evitar (detener por completo la actividad arriesgada) o aceptar (tolerar a sabiendas el riesgo residual). La elección depende del apetito de riesgo y de una comparación coste-beneficio frente a la pérdida esperada del riesgo.

Parte de una imagen base mínima y de confianza (distroless o slim) para reducir la superficie de ataque, escanea las imágenes en busca de CVE conocidas en la CI y en el registro, fija y verifica los digests de las imágenes, ejecuta con un usuario no-root y evita incrustar secretos. Firma las imágenes y aplica políticas de admisión para que solo se ejecuten imágenes escaneadas y firmadas. Reconstruye con regularidad para que las capas base parcheadas se propaguen.

Un usuario es una identidad de larga duración con credenciales permanentes; un rol es una identidad sin credenciales permanentes que cualquier principal de confianza puede asumir para obtener tokens de corta duración; una política es el documento JSON que concede permisos, adjunto a cualquiera de los dos. El privilegio mínimo significa preferir roles a usuarios, acotar las políticas a acciones y recursos específicos, y conceder solo lo que una tarea necesita — y luego revisar y depurar con el tiempo.

CloudTrail registra cada llamada a la API en la cuenta — quién hizo qué, cuándo, desde dónde — dándote el rastro de auditoría con autoridad para investigaciones y cumplimiento. GuardDuty es un servicio gestionado de detección de amenazas que analiza CloudTrail, los flujos de VPC y los registros de DNS para sacar a la luz hallazgos como la exfiltración de credenciales o la minería de criptomonedas. CloudTrail es la fuente de verdad que debes proteger; GuardDuty convierte esa telemetría en alertas accionables.

Los errores clásicos son ACL públicas o políticas de bucket que permiten acceso anónimo o a todos los usuarios de AWS, principales demasiado amplios o acciones con comodín, ausencia de cifrado por defecto y falta de registro. Se previenen activando Block Public Access a nivel de cuenta, usando políticas IAM/bucket con privilegio mínimo, exigiendo cifrado por defecto y TLS, y activando el registro de accesos y reglas de Config para detectar desviaciones.

Almacena los secretos en un servicio gestionado dedicado (Secrets Manager, Parameter Store, Vault), cifrados con una clave de KMS, y concede el acceso mediante roles IAM para que las cargas de trabajo los recuperen en tiempo de ejecución con credenciales de corta duración. Nunca incrustes secretos en el código, las imágenes de contenedor o archivos .env versionados. Añade rotación automática, políticas de clave acotadas y registro de auditoría para que cada recuperación sea rastreable.

Los security groups son cortafuegos con estado adjuntos a instancias/ENI: solo tienen reglas de permitir, y el tráfico de retorno de un flujo permitido se autoriza automáticamente. Las network ACL son filtros sin estado en el límite de la subred: tienen reglas ordenadas de permitir y denegar, y debes permitir explícitamente el tráfico de retorno en los puertos efímeros. Los security groups son el control principal; las NACL añaden barreras gruesas a nivel de subred, como bloquear un rango de IP.

RSA es un algoritmo asimétrico usado para cifrar datos o crear firmas digitales con un par de claves. Diffie-Hellman es un protocolo de acuerdo de claves que permite a dos partes derivar un secreto compartido sobre un canal público sin transmitirlo nunca. Resuelven problemas distintos: RSA prueba identidad y puede envolver claves; DH negocia una clave de sesión, y su variante efímera ofrece confidencialidad hacia adelante.

Un HMAC es un código de autenticación de mensajes con clave: aplica un hash al mensaje junto con una clave secreta mediante una construcción anidada (hash interno y externo con rellenos derivados de la clave). Prueba tanto la integridad (el mensaje no fue alterado) como la autenticidad (proviene de alguien que posee la clave). Un hash simple no prueba ninguna de las dos, ya que cualquiera puede recalcularlo; HMAC además resiste ataques de extensión de longitud.

Un JWT tiene tres partes en base64url —cabecera, carga útil (reclamaciones) y firma— unidas por puntos. El servidor firma la cabecera y la carga útil con un secreto o una clave privada, y verifica esa firma en cada solicitud para confiar en las reclamaciones sin estado de sesión en el servidor. Errores: aceptar alg=none, la confusión de claves de RS256 a HS256, no validar expiración/emisor/audiencia, poner secretos en la carga útil legible, y la falta de una vía de revocación.

La aplicación redirige al usuario al servidor de autorización para iniciar sesión y dar consentimiento. El servidor redirige de vuelta con un código de autorización de corta duración. El backend de la aplicación intercambia luego ese código (más su secreto de cliente) en el endpoint de token por un token de acceso, sobre un canal trasero de servidor a servidor. Esto mantiene los tokens fuera del navegador/la URL. Los clientes públicos añaden PKCE para vincular el código al solicitante original.

Almacena las contraseñas usando una función de hashing de contraseñas deliberadamente lenta, salada y adaptativa —bcrypt, scrypt o Argon2— nunca un hash rápido de propósito general como SHA-256 o MD5. Los hashes rápidos están hechos para la velocidad, así que atacantes con GPU pueden probar miles de millones de intentos por segundo contra una base de datos filtrada. Los hashes lentos tienen un factor de trabajo ajustable (y un coste de memoria) que hace cada intento caro, manteniendo la fuerza bruta impracticable incluso tras una filtración.

Perfect Forward Secrecy (PFS) significa que cada sesión deriva una clave única de un intercambio de claves efímero que se descarta después. Si un atacante roba más tarde la clave privada de largo plazo del servidor, aún no puede descifrar el tráfico capturado previamente, porque esa clave nunca se usó para derivar las claves de sesión. Se logra con Diffie-Hellman efímero (DHE/ECDHE).

El SSO centraliza la autenticación en un proveedor de identidad (IdP). Cuando un usuario visita un proveedor de servicio (la app), la app redirige al IdP; el usuario inicia sesión una vez, y el IdP devuelve una aserción o token firmado que avala su identidad. SAML lo lleva como una aserción XML firmada; OIDC lo lleva como un token de identidad JSON firmado montado sobre OAuth 2.0. La app confía en la firma del IdP en lugar de manejar las contraseñas ella misma.

Escanea las imágenes en busca de CVE conocidas en paquetes del SO y bibliotecas de la app, además de configuraciones erróneas y secretos incrustados, tanto en el momento del build como de forma continua en el registro — porque aparecen nuevas CVE después de construir una imagen. Usa imágenes base mínimas o distroless para reducir la superficie de ataque, fija y referencia las imágenes base por digest, y ejecuta el contenedor como no-root. El escaneo es necesario pero no sustituye a la protección en runtime.

El escaneo de IaC analiza estáticamente definiciones de Terraform, CloudFormation, Kubernetes y similares contra una política para detectar configuraciones erróneas — buckets S3 públicos, grupos de seguridad abiertos, cifrado ausente — antes de que se aprovisionen. Como la misma plantilla aprovisiona muchos recursos, corregirla una vez evita la deriva repetida, y detectarlo antes de aplicar es mucho más barato que remediar recursos cloud en producción. Las herramientas incluyen Checkov, tfsec y KICS, idealmente aplicadas como barreras de policy-as-code.

El SAST lee el código fuente sin ejecutarlo y encuentra pronto fallos como los puntos de inyección, pero con muchos falsos positivos. El DAST ataca la aplicación en ejecución desde fuera, sin visibilidad del código, y encuentra problemas realmente explotables pero tarde y con cobertura superficial. El IAST instrumenta la aplicación en ejecución para correlacionar el comportamiento en runtime con el código, obteniendo resultados precisos con contexto del código, pero necesita una aplicación ejercitada y soporte de un agente.

Usa defensa en profundidad: los hooks pre-commit (p. ej. gitleaks) atrapan secretos antes de que lleguen, el escaneo de CI en el servidor atrapa lo que se cuela, y escaneos periódicos de todo el historial encuentran filtraciones antiguas. Y lo crítico: un secreto que llegó a un repositorio remoto debe tratarse como comprometido y rotarse — borrar el commit no ayuda porque vive en el historial, los forks y los logs. Combina esto con un gestor de secretos real para que los secretos no estén en el código en absoluto.

El shift left consiste en mover la seguridad antes — al diseño, al IDE y al pull request — donde los problemas son más baratos de corregir que en producción. Evitas bloquear a los desarrolladores haciendo que el camino seguro sea el camino fácil: feedback rápido y en contexto, gates de bajo falso positivo que solo fallan en duro ante problemas nuevos de alta severidad, configuraciones seguras por defecto y plantillas de paved road, y tratando la seguridad como un facilitador en lugar de un veto tardío.

El SCA inventaría los componentes de código abierto y de terceros que una aplicación incorpora —incluidas las dependencias transitivas— y señala los que tienen CVE conocidos o licencias problemáticas. Importa porque la mayor parte del código moderno son dependencias que no escribiste tú, y un único paquete transitivo vulnerable (como Log4j) puede exponer toda la aplicación. Un buen SCA prioriza por alcanzabilidad y explotabilidad, no solo por el recuento bruto de CVE.

Un SBOM es un inventario legible por máquina de cada componente, biblioteca y dependencia de un software, con versiones e idealmente hashes. Importa porque cuando aparece una nueva vulnerabilidad, puedes consultar tus SBOM para responder al instante a «¿estamos afectados y dónde?» en lugar de improvisar. Los dos estándares dominantes son SPDX y CycloneDX, y los SBOM son cada vez más exigidos por la normativa y las compras.

El cliente y el servidor acuerdan un secreto compartido en un solo viaje de ida y vuelta usando Diffie-Hellman efímero (ECDHE). El ClientHello lleva los grupos compatibles y un key share; el servidor responde con su key share y su certificado, ambas partes derivan las mismas claves, y los datos de aplicación fluyen de inmediato, con confidencialidad hacia adelante por defecto.

La codificación (como Base64) es un cambio de formato reversible sin secreto — no es seguridad. El cifrado es reversible con una clave y protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de longitud fija, usado para comprobaciones de integridad y almacenamiento de contraseñas, y no puede revertirse para obtener la entrada.

El mínimo privilegio significa que cada usuario, proceso y servicio recibe solo el acceso mínimo necesario para su tarea, y nada más. Limita el radio de impacto de una cuenta comprometida, reduce el riesgo de amenaza interna y disminuye la superficie de ataque. Se aplica mediante acceso basado en roles, revisiones de acceso periódicas y elevación justo a tiempo.

Un día cero es una vulnerabilidad que el fabricante aún no conoce (o no ha parcheado), por lo que los defensores han tenido «cero días» para arreglarla. Como no existe parche, la defensa se apoya en controles por capas, detección por comportamiento, segmentación, mínimo privilegio y respuesta rápida a incidentes en lugar de una firma.

Comprime primero y luego cifra. Un buen cifrado produce una salida estadísticamente indistinguible de lo aleatorio, así que el texto cifrado no tiene patrones que comprimir: comprimir después es inútil. La advertencia importante: comprimir juntos datos secretos y datos controlados por el atacante antes de cifrar puede filtrar información a través de la longitud del texto cifrado, que es exactamente lo que hacen los ataques CRIME y BREACH.

Desde un punto de vista puramente de seguridad, un falso negativo suele ser peor: significa que un ataque real pasó sin detectarse, así que no hay respuesta, ni contención, y la brecha puede permanecer latente sin descubrirse. Pero los falsos positivos no son inofensivos: en grandes volúmenes provocan fatiga de alertas, donde los analistas empiezan a ignorar las alertas y se les escapa la real. La respuesta correcta nombra el compromiso, no solo un ganador.

Filtrado. Un puerto filtrado descarta el paquete en silencio, así que el escáner no obtiene respuesta y debe esperar un tiempo de espera: no aprende nada sobre si el host siquiera existe, y el escaneo se ralentiza drásticamente. Un puerto cerrado devuelve un RST de TCP, que confirma que el host está vivo y respondiendo, entregando gratis al atacante valor de reconocimiento.

No por sí solo. HTTPS previene el MITM solo cuando la validación del certificado se exige estrictamente y el cliente llega al sitio por HTTPS desde el principio. Si una CA fraudulenta es de confianza (proxy corporativo, raíz instalada por malware), si el usuario pasa por alto las advertencias de certificado, o si el SSL stripping degrada la conexión a HTTP antes de que arranque TLS, un atacante todavía puede situarse en el medio.

Porque son rápidos. MD5 y SHA-256 están diseñados para la velocidad, que es exactamente lo contrario de lo que se necesita para las contraseñas: un atacante que roba los hashes puede calcular miles de millones de intentos por segundo en una GPU. La solución es una función de derivación de clave deliberadamente lenta y dura en memoria —bcrypt, scrypt o Argon2— combinada con una sal por usuario y un factor de trabajo ajustable.

Los controles se clasifican de dos maneras. Por tipo: administrativo (políticas, formación, procedimientos), técnico/lógico (cortafuegos, MFA, cifrado) y físico (cerraduras, tarjetas, cámaras). Por función: preventivo (detener un evento — MFA, control de acceso), detectivo (descubrir un evento — SIEM, IDS, registros de auditoría), correctivo (reparar después — restaurar copia de seguridad, aplicar parche), disuasorio (desalentar — banners de advertencia) y compensatorio (una alternativa cuando el control principal no es viable). La defensa en profundidad superpone estos controles para que ningún fallo aislado lleve a un compromiso.

El artículo 5 del GDPR establece siete principios: licitud/lealtad/transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad, y responsabilidad proactiva. Ante una brecha de datos personales, el responsable del tratamiento debe notificar a la autoridad de control competente sin dilación indebida y, cuando sea posible, en un plazo de 72 horas tras tener conocimiento (artículo 33). Si la brecha probablemente entrañe un alto riesgo para las personas, el responsable también debe notificar a los interesados afectados sin dilación indebida (artículo 34).

HIPAA (la ley estadounidense Health Insurance Portability and Accountability Act) protege la Protected Health Information (PHI). La Privacy Rule rige el uso y la divulgación de la PHI; la Security Rule se aplica a la PHI electrónica (ePHI) y exige tres categorías de salvaguardas — administrativas, físicas y técnicas. Se aplica a las covered entities (proveedores, planes de salud, cámaras de compensación) y a los business associates que manejan PHI en su nombre, vinculados por Business Associate Agreements. La Breach Notification Rule fija las obligaciones de notificar a las personas, al HHS y, a veces, a los medios.

El NIST Cybersecurity Framework organiza los resultados de ciberseguridad en funciones principales. En el CSF 2.0 hay seis: Govern (la nueva función global para estrategia, roles, decisiones de riesgo y supervisión), Identify (comprender activos y riesgos), Protect (salvaguardas para limitar el impacto), Detect (descubrir eventos), Respond (actuar ante incidentes) y Recover (restaurar capacidades). No son estrictamente secuenciales — funcionan de forma continua y, en conjunto, describen un ciclo de vida completo de gestión del ciberriesgo.

PCI DSS (Payment Card Industry Data Security Standard) es una norma de seguridad mantenida por el PCI Security Standards Council que se aplica a cualquier organización que almacene, procese o transmita datos de titulares de tarjetas. Se organiza en torno a objetivos de control que cubren una red segura, la protección de los datos almacenados, la gestión de vulnerabilidades, un control de acceso fuerte, la monitorización/pruebas y una política de seguridad de la información. El alcance es todo lo que está en el cardholder data environment (CDE) — por lo que la segmentación, la tokenización y no almacenar datos innecesarios son las principales formas de reducirlo.

Trata la concienciación como un cambio de comportamiento, no como una casilla anual. Hazla basada en roles (un desarrollador necesita contenido distinto al de finanzas), continua en lugar de una presentación una vez al año, y anclada en riesgos reales como el phishing, la ingeniería social y el manejo de datos. Refuérzala con simulaciones de phishing, recordatorios en el momento oportuno y canales de notificación claros. Mide resultados — tasa de notificación de phishing, tasa de clics, tiempo hasta notificar — no solo los porcentajes de finalización. Construye una cultura en la que la gente notifique sus errores sin miedo, porque el miedo suprime la notificación.

Un informe SOC 2 Tipo I evalúa si los controles de una organización de servicios están diseñados adecuadamente en un único momento. Un informe Tipo II va más allá: prueba si esos controles operaron de forma eficaz durante un periodo de revisión, normalmente de 3 a 12 meses. Ambos se basan en los Trust Services Criteria de la AICPA — Seguridad (los criterios comunes obligatorios), más opcionalmente Disponibilidad, Integridad del procesamiento, Confidencialidad y Privacidad.

Una línea base es un modelo del comportamiento normal de un host, usuario, cuenta o segmento de red: qué procesos se ejecutan, quién inicia sesión desde dónde y cuándo, los volúmenes de datos típicos, los intervalos normales de beaconing. Una vez que conoces lo normal, las anomalías (pares de procesos padre-hijo raros, binarios vistos por primera vez, inicios de sesión a horas extrañas, salida de datos inusual) se vuelven detectables como desviaciones. Establecer una línea base es el fundamento de la detección de anomalías, pero requiere suficiente historial limpio y un manejo cuidadoso del cambio legítimo para no ahogarte en falsos positivos.

Parte de las técnicas que quieres detectar y luego trabaja hacia atrás hasta la telemetría que las revela — el mapeo de fuentes de datos de ATT&CK ayuda. En la práctica, las fuentes de mayor valor son la telemetría de endpoint de procesos/línea de comandos y carga de módulos (EDR/Sysmon), los registros de autenticación e identidad, el DNS y el flujo proxy/red, y los registros del plano de control de la nube. Luego auditas lo que realmente recopilas y retienes frente a lo que necesita cada técnica, exponiendo los puntos ciegos. Una técnica que no puedes ver en ningún registro aún no es cazable.

La Pyramid of Pain clasifica los tipos de indicadores según lo costoso que le resulta a un atacante cambiarlos una vez que detectas sobre ellos. Los hashes son triviales de alterar (abajo), luego las direcciones IP, los nombres de dominio, los artefactos de red/host, las herramientas y, finalmente, los TTP en la cima — que un atacante solo puede cambiar reconfigurando fundamentalmente su comportamiento. Detectar en los niveles superiores causa más « dolor » y es más duradero, así que los programas maduros invierten el esfuerzo de detección en los comportamientos y los TTP en lugar de solo los IOC.

UEBA (User and Entity Behaviour Analytics) construye líneas base de comportamiento para usuarios y entidades (hosts, cuentas de servicio, dispositivos) y usa estadística o aprendizaje automático para puntuar las desviaciones como riesgo. Sobresale ante amenazas sin firma clara: credenciales comprometidas, abuso interno y movimiento lateral — p. ej. un usuario que de repente accede a sistemas que nunca toca, a horas inusuales, o que mueve volúmenes de datos anómalos. Complementa la detección basada en reglas en lugar de reemplazarla, y necesita ajuste para evitar falsos positivos por cambios de comportamiento legítimos.

La caza de amenazas es la práctica proactiva, guiada por hipótesis, de buscar en la telemetría actividad de un adversario que las detecciones existentes pasaron por alto. A diferencia del triaje de alertas — reactivo y que espera a que una herramienta se dispare — la caza parte de una pregunta (« si un atacante hiciera X, ¿qué evidencia vería? »), la pone a prueba contra los datos y o bien encuentra algo o bien produce una nueva detección. Asume que la prevención y las alertas son imperfectas y que un adversario decidido puede estar ya dentro.

Sigma es un formato YAML abierto y neutral respecto al fabricante para describir detecciones de SIEM. Defines un logsource (product/category, p. ej. Windows process_creation), un bloque detection con selecciones nombradas de coincidencias campo/valor, y una condition que las combina. Un conversor (como sigma-cli/pySigma) traduce la regla al lenguaje de consulta de tu backend real —Splunk, Sentinel, Elastic— de modo que una sola regla es portable. También lleva metadatos: title, level, status, falsos positivos y etiquetas ATT&CK.

Las revisiones de acceso (recertificación) son comprobaciones periódicas en las que un propietario responsable confirma que el acceso de cada persona sigue justificado, y revoca lo que no lo está. Son la red de seguridad que detecta la acumulación de privilegios, las cuentas huérfanas y los derechos concedidos para un proyecto ya terminado. El control solo funciona si un propietario competente —normalmente el responsable o el dueño del recurso— examina de verdad el acceso en lugar de aprobarlo sin mirar, y si las revocaciones se aplican.

El acceso condicional hace que la decisión de acceso dependa del contexto en lugar de una regla fija. Evalúa señales —quién es el usuario, el cumplimiento del dispositivo, la ubicación, la aplicación y una puntuación de riesgo calculada por detección de anomalías— y responde de forma proporcional: permitir, bloquear o exigir un refuerzo como MFA o un dispositivo conforme. El acceso basado en riesgo es la variante dinámica donde una señal de riesgo en tiempo real impulsa la política.

La federación de identidades establece confianza entre un proveedor de identidad (IdP) que autentica usuarios y proveedores de servicios (partes de confianza) que consumen esa autenticación. El IdP verifica al usuario y emite una aserción o token firmado; el proveedor de servicios confía en él en lugar de gestionar sus propias credenciales. Esto habilita el SSO entre dominios y el control centralizado, pero concentra el riesgo: si comprometes el IdP, comprometes todo lo que confía en él.

La MFA resistente al phishing significa que el segundo factor no puede reproducirse contra el sitio real aunque se engañe al usuario. Las passkeys FIDO2/WebAuthn lo logran con criptografía de clave pública ligada al origen: el autenticador firma un desafío atado al dominio del sitio real, así que una credencial capturada por un sitio imitador o un atacante en el medio es inútil. Los códigos TOTP y las notificaciones aún se pueden phishear porque pueden retransmitirse en tiempo real.

PAM controla y monitoriza las cuentas que pueden causar más daño: administradores de dominio, root, cuentas de servicio. Custodia y rota sus credenciales para que ningún secreto se comparta ni quede embebido, intermedia las sesiones para que los administradores nunca vean la contraseña en claro, graba lo que hacen los usuarios privilegiados, y concede idealmente la elevación justo a tiempo en vez de acceso permanente. El objetivo es reducir el radio de impacto de las cuentas que más codician los atacantes.

El RBAC concede permisos mediante roles asignados a usuarios: sencillo de razonar pero propenso a la explosión de roles a medida que se multiplican los casos límite. El ABAC evalúa políticas sobre atributos del usuario, el recurso, la acción y el entorno, por lo que escala a decisiones finas y contextuales a costa de complejidad. La mayoría de los sistemas maduros los combinan: roles para concesiones generales, atributos y políticas para los detalles condicionales.

SCIM (System for Cross-domain Identity Management) es una API REST/JSON y un esquema estándar para crear, actualizar y eliminar cuentas de usuario en todas las aplicaciones. Conectado a un sistema de RR. HH. o a un IdP, automatiza el ciclo de vida joiner-mover-leaver: las cuentas y los permisos se aprovisionan en la contratación, se ajustan en el cambio de rol y —lo más importante— se desaprovisionan en la salida, eliminando las cuentas huérfanas que tanto gustan a los atacantes.

El beaconing de mando y control es el implante llamando periódicamente a casa en busca de instrucciones. Se reconoce por llamadas salientes regulares y de bajo volumen a un intervalo aproximadamente fijo — a menudo con jitter para no parecer mecánico — hacia un pequeño conjunto de destinos, con frecuencia sobre HTTP/HTTPS o DNS con cargas útiles codificadas o cifradas y un User-Agent o patrón de URI distintivo. Se extraen los indicadores estáticamente sacando dominios, IPs, URIs y claves de las cadenas y bloques de configuración, y dinámicamente detonando el ejemplar contra una red falsa y capturando las llamadas reales, luego se asigna el comportamiento a ATT&CK y se alimentan los IOC en la detección.

El empaquetado comprime o cifra la carga útil real y le antepone un stub que la desempaqueta en memoria en tiempo de ejecución; la ofuscación transforma el código o los datos para resistir la lectura y las firmas. El empaquetado se detecta por una entropía de sección alta cercana a 8,0, una tabla de imports diminuta o solo de stub, nombres de sección inusuales o escribibles-ejecutables como UPX0, un punto de entrada fuera de .text, un gran tamaño virtual frente a un pequeño tamaño en bruto, y detectores como Detect It Easy o PEiD. Ninguno de estos es concluyente por sí solo, así que los analistas ponderan varias señales juntas y confirman observando el desempaquetado en tiempo de ejecución.

Un archivo PE empieza con la cabecera DOS y su puntero e_lfanew a las cabeceras PE/NT, que contienen el File Header y el Optional Header (punto de entrada, image base, subsistema). Está dividido en secciones — .text para el código, .data, .rdata, .rsrc para los recursos — cada una con una dirección virtual y un tamaño en bruto. Durante el triaje se lee la tabla de imports en busca de API sospechosas, la tabla de secciones por nombres extraños y entropía alta que insinúan empaquetado, el timestamp y el rich header, los recursos incrustados y cualquier firma digital. Las discrepancias entre estos elementos dicen mucho antes incluso de ejecutar el archivo.

Las herramientas estáticas leen la muestra en reposo: PEStudio, CFF Explorer y pefile para cabeceras e imports, FLOSS y strings para el texto embebido, capa para el mapeo de capacidades, y Ghidra o IDA para el desensamblado. Las herramientas dinámicas la observan ejecutarse dentro de una VM aislada: Procmon y Process Hacker para la actividad del host, Wireshark e INetSim o FakeNet para la red falseada, Regshot para los diffs de antes/después, y x64dbg para el stepping controlado. El flujo de trabajo es triar estáticamente, detonar dinámicamente, y luego volver al desensamblador para rellenar los huecos de comportamiento.

Una regla YARA tiene un bloque meta, una sección strings (patrones de texto, hex o regex, con comodines y saltos) y una condición que combina esas coincidencias con lógica booleana y de conteo. Una regla eficaz se apoya en algo duradero y distintivo — un stub de código único, un nombre de mutex, un marcador de configuración o una combinación de imports inusual — en lugar de valores que un atacante cambia trivialmente como un solo hash o una cadena genérica. Se equilibra la especificidad frente a los falsos positivos, se prueba contra un corpus limpio y se documenta la regla para que otros confíen en ella y la mantengan.

La divulgación coordinada de vulnerabilidades es un proceso en el que un investigador reporta un fallo en privado al fabricante, ambas partes acuerdan la remediación y un plazo, y los detalles se publican solo cuando hay un parche disponible (o vence el plazo acordado). Equilibra dar tiempo a los defensores para parchear con el derecho del público a saber. Un fichero security.txt y una política clara hacen que reportar sea sin fricciones; los programas de bug bounty añaden recompensas estructuradas encima.

El DFIR sigue un proceso disciplinado: identificación (confirmar y delimitar el incidente), adquisición (preservar pruebas siguiendo el orden de volatilidad, con imágenes forenses y hashes), análisis (línea de tiempo, causa raíz, alcance del compromiso) e informe (hallazgos para audiencias técnicas y legales). La cadena de custodia documenta quién manipuló cada artefacto y cuándo, para que la prueba se sostenga si alguna vez llega a un tribunal. Preservar antes de remediar.

ATT&CK es una base de conocimiento de tácticas reales del adversario (el porqué), técnicas (el cómo) y procedimientos. La usas para mapear tus detecciones existentes sobre la matriz, identificar brechas de cobertura y priorizar las técnicas usadas por los actores que realmente atacan tu sector. Ofrece un lenguaje común entre CTI, ingeniería de detección e IR, convirtiendo «¿estamos seguros?» en un mapa de cobertura concreto y medible, impulsado por el comportamiento real del adversario.

La WSTG es una metodología respaldada por una lista de verificación que recorre una aplicación a través de categorías de prueba: recopilación de información, configuración y despliegue, identidad y autenticación, autorización, gestión de sesiones, validación de entradas (inyección/XSS), gestión de errores, criptografía, lógica de negocio y lado cliente. Ofrece cobertura sistemática con identificadores de prueba estables, de modo que los hallazgos son reproducibles y no se omite nada obvio.

PTES define siete fases: pre-engagement (alcance, reglas de enfrentamiento, autorización), recopilación de inteligencia (OSINT, reconocimiento), modelado de amenazas, análisis de vulnerabilidades, explotación, post-explotación (pivoteo, datos de valor, persistencia) e informe. La estructura hace que los proyectos sean repetibles, defendibles y ligados al riesgo de negocio en lugar de hacking improvisado. El pre-engagement y el informe son las fases que los junior subestiman.

El purple teaming es colaborativo en lugar de adversarial: el lado rojo ejecuta TTP específicos y acordados (a menudo asociados a MITRE ATT&CK) mientras el lado azul observa su telemetría en tiempo real para confirmar si cada técnica se registra, alerta y es detectable. Mides la cobertura de detección técnica por técnica, ajustas detecciones y cierras brechas de inmediato, y luego vuelves a probar. El entregable es una detección mejorada y medible — no una lista de quién «ganó».

Un SDLC seguro integra la seguridad en cada fase en lugar de probar al final: requisitos (casos de seguridad y de abuso), diseño (modelado de amenazas), implementación (estándares de codificación segura, SAST/SCA en el IDE y la CI), pruebas (DAST, pentest), liberación (gates y aprobación) y operación (monitorización, parcheo, retroalimentación). El shift-left mueve los defectos antes, donde son baratos de corregir; modelos de madurez como OWASP SAMM y BSIMM miden cuán bien lo haces realmente.

La gestión de vulnerabilidades es un ciclo continuo: descubrir activos y vulnerabilidades (escaneo, inventario de activos), priorizar por riesgo real (CVSS más explotabilidad, exposición y criticidad de los activos — marcos como EPSS y SSVC ayudan), remediar o mitigar, verificar la corrección e informar sobre tendencias y SLA. El escaneo es la parte fácil; la disciplina está en priorizar y cerrar el ciclo para que el riesgo realmente baje con el tiempo.

Un proxy directo se sitúa delante de los clientes y hace peticiones salientes en su nombre — para control de salida, filtrado, cacheo y anonimato. Un proxy inverso se sitúa delante de los servidores y recibe peticiones entrantes en su nombre — para balanceo de carga, terminación TLS, cacheo y como fachada de seguridad para un WAF. La dirección a la que mira, lado cliente o lado servidor, es la distinción clave.

Traceroute descubre los routers entre tú y un destino explotando el campo TTL. Envía paquetes con TTL=1, luego 2, luego 3, y así sucesivamente. Cada router decrementa el TTL; cuando el TTL llega a cero, ese router descarta el paquete y devuelve un mensaje ICMP Time Exceeded, revelando su dirección. Al ir subiendo el TTL, traceroute mapea cada salto en orden hasta alcanzar el destino.

NAT (Network Address Translation) reescribe la IP de origen o destino a medida que los paquetes cruzan una frontera, normalmente mapeando direcciones internas privadas a públicas. PAT (Port Address Translation, o NAT overload) lo amplía traduciendo también los puertos, permitiendo que muchos hosts internos compartan una sola IP pública — cada flujo distinguido por su puerto. PAT es lo que usan los routers domésticos y de oficina para poner toda una LAN tras una sola dirección.

Una VLAN (LAN virtual) particiona lógicamente un switch físico en dominios de difusión de capa 2 separados, de modo que dispositivos en VLAN distintas no pueden alcanzarse directamente aun en el mismo hardware. Se rotula con una etiqueta 802.1Q en los enlaces troncales. El valor de seguridad es la segmentación: aislar el tráfico de usuarios, servidores, invitados e IoT limita el alcance de la difusión y el movimiento lateral, forzando el tráfico entre VLAN a pasar por un router o cortafuegos donde se aplica la política.

Una DMZ (zona desmilitarizada) es un segmento de red situado entre la Internet no confiable y la red interna de confianza, que aloja servicios expuestos al público como servidores web, de correo y DNS. Las reglas del cortafuegos permiten que Internet alcance la DMZ pero restringen estrictamente el acceso de la DMZ a la red interna. El objetivo es la contención: si un servidor público se ve comprometido, el atacante queda atrapado en la zona de amortiguación en lugar de aterrizar dentro de la LAN.

Enumera de forma sistemática: revisa sudo -l, los binarios SUID/SGID, las tareas cron, la versión del kernel y del SO, los archivos escribibles en rutas privilegiadas, las capabilities y las credenciales almacenadas. Herramientas como LinPEAS automatizan el barrido, pero aun así verificas cada hallazgo contra GTFOBins o una técnica conocida.

Identifica el servicio y la versión exactos, busca en Exploit-DB o searchsploit un PoC que coincida, y luego lee el código línea por línea antes de ejecutarlo: corrige la IP objetivo, el puerto y la dirección del reverse shell, regenera cualquier shellcode y entiende qué hace para que no se vuelva en tu contra.

Primero identifica el formato del hash (hashid o contexto) y luego ejecuta hashcat o John con el modo correcto contra un diccionario como rockyou, aplicando reglas para mutar los candidatos. Usa el flag de formato correcto (NTLM, sha512crypt, NetNTLMv2, etc.) para que la herramienta hashee los intentos igual que lo hizo el objetivo.

Para SMB, enumera los recursos compartidos, comprueba el acceso anónimo/sesión nula, lista los usuarios e identifica la versión para CVE conocidas. Para SNMP, prueba community strings por defecto como «public» y recorre la MIB para extraer nombres de usuario, procesos en ejecución, software instalado y detalles de red.

Por separado, la SQLi expone o modifica datos y puede llegar al RCE; la XSS almacenada secuestra sesiones en el navegador de las víctimas. Encadenadas, puedes usar la SQLi para plantar una carga XSS almacenada que se dispara en la sesión de un admin, robar su sesión y escalar al control total de la aplicación.

Enumera primero: privilegios actuales, derechos de sudo, binarios SUID/SGID, tareas cron, archivos escribibles en el PATH, versión del kernel y credenciales almacenadas. Luego explota la ruta más sencilla y fiable — a menudo una regla de sudo mal configurada o un GTFOBin SUID — antes de recurrir a un exploit del kernel.

Enumera los privilegios de la cuenta y las malas configuraciones del host: privilegios de token como SeImpersonate, rutas de servicio sin comillas, permisos de servicio débiles, AlwaysInstallElevated y credenciales almacenadas. Luego abusa del más fiable — la suplantación de token (ataques Potato) es una vía común a SYSTEM.

Una bind shell abre un puerto de escucha en el objetivo y espera a que te conectes a él. Una reverse shell hace que el objetivo se conecte hacia fuera a un listener que tú controlas. Las reverse shells suelen ganar porque el tráfico saliente esquiva las reglas de cortafuegos entrantes y el NAT.

El privilegio mínimo significa que cada usuario, proceso o servicio obtiene solo el acceso mínimo necesario para su tarea, y nada más. Reduce el radio de impacto de cualquier compromiso o error. Se aplica con acceso basado en roles, elevación just-in-time, revisiones de acceso periódicas y la eliminación de derechos de administrador permanentes.

Nunca codifiques secretos en el código fuente ni los subas a git. Guárdalos en un gestor de secretos o bóveda dedicada, inyéctalos en tiempo de ejecución, acota el acceso con privilegios mínimos, rótalos con regularidad y prefiere credenciales dinámicas de corta duración frente a las estáticas persistentes. Audita cada acceso.

Forzar TLS en todas partes, autenticar cada solicitud (p. ej. tokens OAuth2/OIDC) y autorizar por objeto para que los usuarios solo alcancen sus propios datos. Añade validación de entradas, limitación de tasa y cuotas, validación de esquema y registro exhaustivo. El fallo de API más común es la autorización a nivel de objeto rota, así que comprueba la propiedad en cada acceso a un recurso.

Una PKI es el sistema de CA, certificados y políticas que vincula las claves públicas con las identidades. Para validar un certificado de servidor, un cliente construye una cadena hasta una raíz de confianza, verifica cada firma, comprueba las fechas de validez y el nombre de host, confirma el uso de la clave, y comprueba la revocación mediante CRL u OCSP.

La fuerza bruta apunta a una sola cuenta con muchos intentos de contraseña, por lo que se ven muchos fallos concentrados en un mismo usuario. El password spray lo invierte: una o pocas contraseñas comunes probadas en muchas cuentas, de forma lenta y sigilosa, de modo que cada cuenta solo registra un par de fallos. La señal de detección es la proporción de cuentas frente a fallos y el timing, no el número bruto de fallos.

Primero entiende por qué la regla se dispara tanto: encuentra el patrón benigno común detrás del ruido. Luego escribe la exclusión más estrecha posible (host, cuenta o comportamiento específico), documenta la justificación y valida que un verdadero positivo seguiría disparándose. Evita supresiones amplias que crean puntos ciegos en silencio.

ATT&CK es una base de conocimiento de tácticas y técnicas adversarias del mundo real. En un SOC mapeas cada regla de detección a las técnicas que cubre, construyes un mapa de cobertura (a menudo con el ATT&CK Navigator) y luego priorizas cerrar las brechas según qué técnicas son más relevantes para tu modelo de amenazas y sobre cuáles no tienes visibilidad alguna.

El CSRF engaña al navegador de un usuario autenticado para que envíe una petición que cambia el estado a un sitio donde está autenticado, abusando del hecho de que las cookies se envían automáticamente. Se detiene con tokens anti-CSRF (un valor secreto por sesión que el atacante no puede leer ni adivinar) y el atributo de cookie SameSite, que impide que las cookies acompañen a las peticiones de sitios cruzados.

Nunca almacenes contraseñas en texto plano ni cifradas de forma reversible, y nunca con hashes rápidos de propósito general como MD5 o SHA-256. Usa una función de hash de contraseñas lenta y exigente en memoria — Argon2id (preferida) o bcrypt — con una sal aleatoria única por contraseña y un factor de coste ajustado, de modo que un atacante que robe la base de datos no pueda descifrar los hashes de forma viable.

Las sentencias preparadas envían primero la plantilla de la consulta a la base de datos, con marcadores de posición, de modo que la estructura queda fijada antes de que llegue ningún dato del usuario. Los parámetros se vinculan después como datos puros y nunca pueden interpretarse como SQL — así que una entrada como ' OR 1=1 se trata como una cadena literal, no como código. Esta separación es la solución canónica y fiable contra la inyección.

La defensa principal es la codificación de salida contextual — codificar los datos no confiables para el lugar exacto donde aterrizan (cuerpo HTML, atributo, JavaScript, URL). Combínalo con API DOM seguras (textContent en lugar de innerHTML), el autoescapado de los frameworks, la validación de entrada y una Content-Security-Policy como defensa en profundidad de respaldo que limita qué scripts pueden ejecutarse.

La Same-Origin Policy es la regla del navegador según la cual un script de un origen (esquema + host + puerto) no puede leer las respuestas de un origen diferente, lo que protege las sesiones autenticadas. CORS es una relajación controlada: un servidor devuelve cabeceras Access-Control-Allow-Origin para habilitar explícitamente que orígenes concretos lean sus respuestas, por lo que flexibiliza la SOP en lugar de eludirla.

Las cabeceras de seguridad clave incluyen Strict-Transport-Security (fuerza HTTPS, bloquea el SSL stripping), Content-Security-Policy (limita las fuentes de scripts, mitiga el XSS), X-Frame-Options o CSP frame-ancestors (bloquea el clickjacking), X-Content-Type-Options: nosniff (detiene el MIME sniffing) y Referrer-Policy (controla la filtración del referente). Cada una aborda una clase de ataque concreta.

La inyección SQL permite que la entrada de un atacante altere una consulta. Las técnicas en banda devuelven datos directamente: la basada en UNION añade un UNION SELECT para extraer columnas adicionales, y la basada en errores filtra datos a través de los mensajes de error de la base de datos. Cuando no hay salida visible, los atacantes usan SQLi a ciegas — la booleana infiere datos de las diferencias de respuesta verdadero/falso, y la basada en tiempo usa retrasos como SLEEP() para leer datos bit a bit.

Todo XSS inyecta un script controlado por el atacante en el navegador de una víctima. El XSS almacenado persiste la carga útil en el servidor (por ejemplo, un comentario) y afecta a todos los que la ven; el XSS reflejado rebota la carga útil desde el servidor en una sola respuesta, normalmente mediante un enlace manipulado; el XSS basado en el DOM nunca llega a la lógica del servidor — JavaScript vulnerable del lado del cliente escribe entrada no confiable en la página.