Preguntas de entrevista de Security Architect

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. 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 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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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 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.

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 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.

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.

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.

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.

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).

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.

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.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Asume que ningún control es perfecto — por ejemplo, combinando firewall, segmentación de red, protección de endpoints, MFA, mínimo privilegio y cifrado en lugar de confiar solo en el perímetro.

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).

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.

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.

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).

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 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.

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.

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.

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.

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.

El moderno NIST SP 800-63B prioriza la longitud sobre la complejidad: permitir frases de contraseña largas (al menos 8, admitir 64+), aceptar todos los caracteres incluidos los espacios, y no imponer reglas de composición como «una mayúscula, un símbolo». Filtrar las contraseñas nuevas contra listas de contraseñas filtradas, eliminar la expiración periódica obligatoria (rotar solo ante evidencia de compromiso), y descartar las «preguntas de seguridad» basadas en conocimiento. El objetivo: reglas que resistan ataques reales en vez de empujar a los usuarios hacia patrones predecibles.

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.

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.

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.

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.

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.

La defensa en profundidad consiste en superponer varios controles de seguridad independientes de modo que, si uno falla, los demás sigan protegiendo el activo. Ningún control se supone perfecto, así que se apilan medidas preventivas, de detección y de respuesta en las capas de red, host, aplicación y datos.

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.

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.

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.

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 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.