Security+ — Conceptos Generales de Seguridad: 45 preguntas de práctica

Step 1: Definir los requerimientos de negocio y seguridad. Se requiere: a) aplicar menor privilegio para desarrolladores externos, asegurando que solo accedan a recursos necesarios, y b) fortalecer la autenticación para reducir riesgo de cuentas comprometidas.

Step 2: Mapear controles a requerimientos. RBAC es un enfoque probado para implementar menor privilegio: se crean roles (por ejemplo, desarrollador externo) con permisos estrictamente limitados a los recursos dev. Esto facilita gestión y revisión de privilegios. MFA refuerza la autenticación, exigiendo factores adicionales (algo que sabes, algo que tienes, algo que eres), disminuyendo probabilidad de acceso con credenciales robadas o mediante ataques de fuerza bruta.

Step 3: Evaluar alternativas y complementariedad. ABAC ofrece control más dinámico y granular basado en atributos (hora, ubicación, propiedad del recurso), y puede ser adecuado, pero su implementación es más compleja y suele necesitar políticas y etiquetado maduros; no es la respuesta ideal para una implementación rápida centrada en menor privilegio. SSO mejora experiencia y centraliza autenticación, pero por sí sola no reduce privilegios ni añade factores adicionales de autenticación. Trap: Confundir facilidad de gestión con cumplimiento del principio de menor privilegio. SSO facilita el acceso y reduce la fatiga de credenciales, pero si los roles y permisos no están correctamente diseñados, SSO puede ampliar, no limitar, los privilegios. Asimismo, ABAC a menudo se considera más avanzado que RBAC, pero su complejidad operativa puede hacer que no sea la mejor primera opción para un control de acceso inmediato a terceros. Why each wrong answer fails: - Control de acceso basado en atributos (ABAC): ABAC puede implementar políticas muy precisas evaluando múltiples atributos contextuales; sin embargo, su despliegue requiere etiquetado de recursos y gestión de políticas complejas. En el escenario planteado la pregunta pide combinar menor privilegio y fortalecimiento de autenticación con soluciones prácticas; ABAC puede ser correcto en contextos sofisticados pero no es la opción directa y empresarialmente más común para este caso. - Inicio de sesión único (SSO): SSO centraliza la autenticación y mejora la experiencia del usuario, pero no crea controles de autorización más restrictivos ni añade factores de autenticación adicionales por sí mismo. SSO se utiliza bien en conjunto con MFA, pero SSO solo no satisface ambos requisitos solicitados. Why each correct answer works: - Control de acceso basado en roles (RBAC): Permite asignar permisos mínimos según roles predefinidos y revisar fácilmente privilegios; es una forma práctica y escalable de aplicar el principio de menor privilegio en entornos empresariales. - Autenticación multifactor (MFA): Añade robustez a la autenticación, mitigando riesgos asociados a credenciales comprometidas de terceros. Combinado con RBAC reduce tanto el riesgo de acceso indebido como el alcance de cualquier acceso que ocurra. Conclusión: La combinación de RBAC para restringir permisos y MFA para fortalecer la autenticación ofrece una solución equilibrada, operativa y alineada con el principio de menor privilegio para desarrolladores externos.

Step 1: Analizar la configuración descrita: el portal acepta TLS 1.0 y suites de cifrado obsoletas. Esto es un problema de protocolo y cifrado porque versiones antiguas de TLS/SSL contienen debilidades conocidas explotables.

Step 2: Evaluar las consecuencias técnicas: TLS 1.0 carece de mecanismos modernos como protección robusta contra ataques de padding, soporte adecuado para PFS en muchas implementaciones y es susceptible a ataques de downgrade, POODLE (si se negocia SSLv3), y otras vulnerabilidades criptográficas.

Step 3: Determinar la clasificación correcta de la vulnerabilidad: se trata de uso de un protocolo inseguro/obsoleto; la mitigación es deshabilitar TLS 1.0/1.1, habilitar TLS 1.2+ y suites fuertes con PFS, y aplicar actualizaciones de servidor. Trap: confundir un protocolo inseguro con un certificado expirado u otros controles externos; aunque un certificado expirado es un problema, no explica la aceptación de versiones y suites obsoletas. Why each wrong answer fails: Certificado expirado falla porque ese problema se refiere a la validez y confianza del certificado X.509; el escenario habla de versiones de protocolo y suites de cifrado, no de validez del certificado. Envío de tokens sin cifrar en la URL falla porque es un problema de manejo de datos sensibles y de diseño de la aplicación (exposición en logs y referers), no está relacionado con los protocolos TLS soportados por el servidor. Ausencia de un firewall de red falla porque un firewall es un control perimetral que puede filtrar tráfico, pero no corrige configuraciones criptográficas en el servidor web; además, un firewall no mitigará ataques que aprovechen la debilidad de TLS cuando el tráfico es legítimamente permitido. En un entorno empresarial real, continuar ofreciendo TLS 1.0 puede llevar a compromiso de confidencialidad e integridad de las comunicaciones, incumplimiento de estándares (PCI DSS, NIST) y explotación por actores que realicen ataques de downgrade o aprovechen vulnerabilidades de cifrado antiguas. Recomendación inmediata: deshabilitar versiones obsoletas, usar TLS 1.2/1.3 con suites seguras y revisar configuraciones con herramientas de escaneo de SSL/TLS.

Step 1: Identificar las características del escenario: correo dirigido al ejecutivo con detalles personales y de la empresa, enlace para revisar pago — esto indica un ataque focalizado que busca engañar a una persona concreta.

Step 2: Mapear a vectores de ataque conocidos: spear phishing es la forma de phishing dirigida usando información personalizada para aumentar la probabilidad de éxito; watering hole compromete sitios que la víctima visita; inyección SQL explota aplicaciones web; fuerza bruta intenta adivinar credenciales por prueba y error.

Step 3: Concluir la mejor correspondencia técnica: el uso de información específica del ejecutivo y la intención de que haga clic en un enlace para revisar una factura coinciden con spear phishing. Trap: confundir cualquier ataque con phishing genérico; el matiz aquí es 'spear' porque es dirigido y personalizado, no un correo masivo. Why each wrong answer fails: Watering hole falla porque en ese vector el atacante compromete un sitio web frecuentado por la víctima para distribuir malware, no envía correos personalizados; en este escenario no se menciona un sitio comprometido. Inyección SQL falla porque es una vulnerabilidad técnica que se explota a través de entradas en una aplicación web para manipular bases de datos; no tiene relación con un correo dirigido. Fuerza bruta falla porque se trata de un ataque automatizado contra credenciales mediante intentos repetidos; aquí el atacante busca engañar al usuario para que entregue credenciales o ejecute código, no adivinarlas. Adicionalmente, en entornos empresariales se observa que spear phishing suele ser precursor de compromisos con exfiltración de datos o fraude financiero dirigido, por eso las medidas preventivas recomendadas incluyen formación específica para ejecutivos, autenticación multifactor y procedimientos de verificación de cambios en pagos. En resumen, el contexto y las señales personalizadas identifican claramente spear phishing como el vector más probable.

Step 1: Entender los requisitos de auditoría. Se necesitan dos propiedades: a) que los registros no puedan ser modificados ni borrados sin detección (inmutabilidad), y b) que las acciones sean atribuidas a actores específicos y verificables (integridad y atribuibilidad).

Step 2: Seleccionar controles criptográficos y de almacenamiento adecuados. El almacenamiento WORM previene modificaciones posteriores a la escritura a nivel de medio o sistema de archivos; esto satisface la condición de inmutabilidad técnica, útil para conservar evidencias legales. Las HMACs (códigos de autenticación de mensaje con clave) o firmas digitales aplicadas a cada entrada o a bloques de entradas permiten verificar que los registros no han sido alterados desde su creación; si las claves están bien gestionadas y las firmas se almacenan de manera separada, se logra integridad verificable y capacidad de auditoría.

Step 3: Evaluar las alternativas y sus limitaciones. Un SIEM centralizado y sincronizado en tiempo mejora visibilidad y correlación de eventos, pero sin firmas ni almacenamiento inmutable, un atacante con privilegios podría alterar entradas o inyectar eventos. El cifrado simétrico con clave compartida protege confidencialidad, pero no proporciona no repudio ni prueba de autoría: cualquiera que tenga la clave podría cifrar o modificar entradas y no habría manera criptográfica de demostrar quién realizó la acción. Trap: Creer que solo centralizar logs en un SIEM resuelve integridad y no repudio. A menudo se asume que la centralización es suficiente; sin embargo, si el SIEM o sus bases de datos no implementan inmutabilidad o firmas, un actor con acceso al SIEM puede alterar entradas. Otro error es considerar el cifrado como sinónimo de integridad y no repudio: el cifrado simétrico protege confidencialidad, pero no distingue autores dentro de un grupo que comparte la clave. Why each wrong answer fails: - SIEM centralizado con sincronización de tiempo pero sin firma de logs: Aunque la sincronización de tiempo (NTP seguro) y el SIEM facilitan la correlación y detección, la ausencia de firmas o almacenamiento inmutable significa que un atacante con privilegios podría modificar o borrar entradas en la base del SIEM. Por tanto, no cumple el requisito de inmutabilidad verificable por sí solo. - Cifrado simétrico de logs con una clave compartida entre administradores: El cifrado simétrico protege confidencialidad del contenido de los logs, pero con una clave compartida no existe una forma criptográfica robusta de atribuir acciones a individuos ni de evitar que cualquiera con la clave genere o modifique entradas. No proporciona no repudio ni integridad verificable en entornos donde varias personas tienen la clave. Why each correct answer works: - Almacenamiento WORM (Write Once Read Many) para archivos de logs: WORM evita modificaciones e implementa retención inmutable a nivel de almacenamiento; esto protege registros contra alteración y eliminación, convirtiéndolos en evidencia más fiable. - HMACs o firmas criptográficas sobre entradas de log con gestión de claves: Las HMACs y firmas permiten detectar cualquier modificación y, en el caso de firmas digitales con claves individuales y certificados, atribuir las entradas a actores concretos; una buena gestión de claves y almacenamiento de certificados/cadenas de confianza completa el eslabón para auditoría y no repudio. Conclusión: Para cumplir auditorías que exigen inmutabilidad y atribuibilidad, combine WORM para retención inmutable y mecanismos criptográficos (HMAC/firmas) con gestión de claves y controles de acceso estrictos; el SIEM y la sincronización horaria son complementos valiosos pero no sustituyen estos mecanismos.

Step 1: Identificar la naturaleza del vector. La ingeniería social explota factores humanos mediante manipulación, engaño o coerción. Los ejemplos típicos incluyen correos fraudulentos (phishing), llamadas telefónicas (vishing), mensajes SMS (smishing) y acceso físico con engaños como tailgating.

Step 2: Analizar cada opción a la luz del comportamiento humano y el acceso. Un correo electrónico de phishing masivo está diseñado para engañar a usuarios para que entreguen credenciales o descarguen malware; es un vector social por excelencia. Tailgating explota la cortesía o descuido de empleados para ganar acceso físico sin credenciales; es ingeniería social física.

Step 3: Diferenciar de ataques técnicos. Inyección SQL y XSS son vectores que explotan vulnerabilidades en código y manejadores de entrada; requieren interacción técnica con la aplicación más que manipulación directa de la víctima (aunque XSS puede inducir a usuarios a realizar acciones, sigue siendo una vulnerabilidad técnica). Trap: Un error común es pensar que cualquier ataque que resulte en interacción del usuario es ingeniería social; por ejemplo, algunos XSS reflejados inducen al usuario a hacer clic, pero la raíz es una falla en la validación de entrada (vulnerabilidad de software), no una manipulación psicológica deliberada. Why each wrong answer fails: - Correo electrónico de phishing masivo que solicita credenciales (Correct): Este es claramente ingeniería social por manipulación del usuario para capturar credenciales. - Inyección SQL en un sitio web de la empresa (Incorrect): Esta es una vulnerabilidad de aplicación donde el atacante envía consultas maliciosas; no explota directamente la psicología del usuario, sino la falta de saneamiento de entradas. - Acceso físico mediante tailgating (Correct): Es ingeniería social física, aprovechando normas sociales y descuido para acceder a áreas restringidas. - Cross-site scripting (XSS) en una aplicación web interna (Incorrect): Este explota falta de escape/filtrado de entrada de la aplicación y puede conducir a ejecución de scripts en el navegador; es una vulnerabilidad técnica, aunque a veces pueda combinarse con ingeniería social, su naturaleza primaria no es psicológica. En resumen, para clasificar vectores como ingeniería social hay que centrarse en la manipulación humana; los ataques que explotan vulnerabilidades técnicas sin engaño directo no califican como tales.

Step 1: Entender el riesgo de amenaza interna. Un empleado con privilegios puede acceder y extraer datos si tiene demasiados derechos o si su comportamiento cambia. Mitigar esto requiere controles que limiten privilegios y que detecten actividad inusual.

Step 2: Elegir controles complementarios. Administrativamente, implementar separación de funciones (segregación de tareas), revisiones de acceso y procesos de aprobación reduce la posibilidad de que una sola persona tenga control completo sobre datos sensibles sin supervisión. Técnicamente, una solución UEBA (User and Entity Behavior Analytics) monitorea patrones de uso y puede alertar sobre volúmenes inusuales de acceso o transferencias, picos fuera de horario, movimientos laterales o uso indebido de privilegios.

Step 3: Implementación y respuesta. Aplicar políticas de acceso basadas en roles, revisiones periódicas de cuentas privilegiadas, y habilitar UEBA integrándola con logs y DLP/IDS para automatizar alertas. Definir playbooks de respuesta para investigar y contener actividad sospechosa. Trap: No confundir controles que protegen los datos en reposo (p. ej., cifrado de disco) con controles que previenen o detectan exfiltración deliberada por un usuario privilegiado. Aunque el cifrado protege contra robo de hardware, no evita que un usuario legítimo copie datos a ubicación externa. Why each wrong answer fails: - Separación de funciones y revisiones periódicas de accesos (Correcto): un control administrativo que reduce riesgo de excesiva concentración de privilegios y permite detectar permisos inadecuados mediante revisiones. - Cifrado de disco completo en las estaciones de trabajo (Incorrecto): protege contra acceso físico al dispositivo o robo de equipo, pero no impide que un usuario con acceso legítimo copie o exfiltre datos a través de canales autorizados. - Solución de análisis de comportamiento de usuarios y entidades (UEBA) para detectar actividad anómala (Correcto): control técnico que identifica patrones inusuales (descargas masivas, accesos fuera de horario) y facilita la detección temprana de un insider que filtra información. - Guardias de seguridad en la entrada para revisar credenciales físicas (Incorrecto): control físico útil para protección física, pero ineficaz para detectar o prevenir exfiltración digital realizada por un empleado con credenciales válidas desde el interior. En conjunto, la separación de funciones y UEBA abordan tanto la prevención administrativa como la detección técnica de amenazas internas; el cifrado de disco y la seguridad física son complementarios pero no suficientes para este vector.

Step 1: Definir confidencialidad. Confidencialidad implica asegurarse de que la información solo sea accesible a personas o entidades autorizadas. Los controles que limitan acceso o protegen datos en reposo/transmisión se asocian directamente a confidencialidad.

Step 2: Evaluar cada control respecto a confidencialidad. El cifrado de disco completo (FDE) cifra los datos en reposo; si un dispositivo es robado o un atacante obtiene bloques de almacenamiento, no podrá leer la información sin las claves, por lo tanto protege confidencialidad. RBAC controla qué roles/usuarios pueden ver o manipular determinados recursos; al aplicar el principio de mínimo privilegio, se minimiza la exposición de datos a usuarios no autorizados.

Step 3: Contrastar con integridad y autenticación. Las sumas de verificación (hash) garantizan que los datos no hayan sido modificados (integridad), pero no evitan que usuarios no autorizados lean los datos. La MFA fortalece la certeza de la identidad (autenticación), reduciendo riesgo de compromiso de cuentas, lo que indirectamente ayuda a confidencialidad; sin embargo su función primaria es autenticar, no proteger el contenido en reposo. Trap: Muchos examinandos creen que cualquier control de acceso o autenticación es igualmente un control de confidencialidad. Aunque relacionados, la función primaria importa: la integridad, la autenticación y la confidencialidad son objetivos distintos del triángulo CIA. Why each wrong answer fails: - Cifrado de disco completo en estaciones de trabajo y servidores (Correct): Directamente protege datos en reposo, impidiendo lectura por actores no autorizados. - Control de acceso basado en roles (RBAC) que limita permisos por puesto (Correct): Restringe quién puede ver o acceder a recursos, aplicando confidencialidad mediante permisos. - Sumas de verificación (hash) para verificar integridad de archivos (Incorrect): Hashes detectan modificaciones (integridad) y no impiden la lectura por usuarios no autorizados; no son un control de confidencialidad por sí solos. - Autenticación multifactor (MFA) para acceso a sistemas críticos (Incorrect): MFA protege la autenticación (comprobación de identidad) y reduce riesgo de compromisos de cuentas; contribuye indirectamente a confidencialidad pero su objetivo principal no es cifrar datos ni limitar permisos en sí. Conclusión: Para preservar confidencialidad en la práctica empresarial, se priorizan controles que impidan la lectura o el acceso no autorizado directo a datos (encriptación, controles de acceso), mientras que integridad y autenticación tratan otros aspectos del modelo CIA.

Step 1: Identificar los objetivos de seguridad relevantes. En este caso, confidencialidad (C de CIA) y no repudio. Confidencialidad demanda mecanismos que protejan datos en tránsito y en reposo frente a divulgación no autorizada. No repudio exige evidencia criptográfica que vincule acciones o transacciones a una identidad única y verificable.

Step 2: Mapear controles a objetivos. Una VPN TLS autenticada por certificados de cliente cifra el canal de comunicación y autentica el extremo cliente, por lo que protege la confidencialidad en tránsito y evita ataques pasivos y algunos ataques activos. Las firmas digitales generadas con claves privadas gestionadas por PKI, preferiblemente con marcas temporales (timestamping) y registro en servidores de auditoría, aportan el mecanismo criptográfico para no repudio: demuestran que un titular de clave privada aprobó un documento/acción en un tiempo concreto.

Step 3: Integrar y operar. Desplegar VPN TLS con CAs internas o federadas, usar certificados de cliente con provisioning seguro (HSM o módulos TPM cuando sea posible), y aplicar políticas de gestión de claves (revocación, expiración). Para no repudio, emitir y validar certificados X.509, usar algoritmos de firma robustos (p. ej., RSA 3072 / ECDSA con curvas seguras), y conservar registros firmados y marcas temporales para auditoría forense. Trap: Una trampa común es confundir cifrado en reposo o MFA con garantía de no repudio. Aunque el cifrado protege la confidencialidad, por sí solo no demuestra que una acción fue realizada por una identidad concreta. Del mismo modo, factores de MFA como SMS fortalecen la autenticación, pero no generan evidencia no repudiable del mismo modo que las firmas digitales vinculadas a una clave privada. Por qué cada opción incorrecta falla: - Cifrar discos duros con AES‑256 (opción 3): Excelente para confidencialidad en reposo, pero no aborda la confidencialidad en tránsito ni proporciona no repudio para transacciones. Es un control técnico importante, pero insuficiente para demostrar la autoría de acciones. - MFA con SMS (opción 4): Mejora la autenticación y reduce el riesgo de acceso no autorizado, pero los mensajes SMS son susceptibles a interceptación/sim swapping y no crean una prueba criptográfica de autoría comparable a una firma digital; por ello no satisfacen la propiedad de no repudio. En resumen, la combinación de un túnel TLS autenticado con certificados de cliente y firmas digitales con marcación temporal y registro proporciona tanto confidencialidad en tránsito como evidencia de no repudio para acciones y transacciones empresariales.

Step 1: Determinar el mecanismo de aplicación. Requisitos como hora del día, ubicación de red y estado de parche/antivirus requieren que un sistema tome decisiones en tiempo real y aplique reglas automáticas; esto implica tecnología y lógica de control.

Step 2: Clasificar el control. Controles técnicos (lógicos) son aquellos implementados por hardware o software para restringir acceso y aplicar políticas (ej. NAC, MDM, gateways de acceso, soluciones de acceso condicional de IAM). Estos sistemas evalúan la postura del dispositivo, atribuyen contexto (ubicación, hora) y permiten o deniegan acceso según políticas configuradas.

Step 3: Integración con controles administrativos y físicos. Aunque la política de base puede definirse administrativamente y la seguridad física puede limitar accesos, la ejecución real y el bloqueo/permitido lo hace el control técnico. Trap: pensar que porque existe una "política" es administrativa; en este caso la política se implementa y aplica automáticamente por controles técnicos. Por qué fallan las respuestas equivocadas: Control administrativo: define la política y condiciones pero no es responsable de la verificación en tiempo real ni de la aplicación técnica de los requisitos de ubicación o postura. Control físico: implicaría controles como cerraduras o acceso a salas; no puede evaluar el estado de software de un dispositivo ni la hora en un sentido lógico. Control de compensación: son medidas alternativas temporales cuando no se pueden implementar controles primarios; no describen un mecanismo para aplicar reglas contextuales en tiempo real. En resumen, la necesidad de evaluar parámetros dinámicos y aplicar decisiones de acceso la transforma en un control técnico implementado por sistemas de control de acceso condicional y soluciones de seguridad en el endpoint y la red.

Step 1: Identificar el vector inicial. El correo que simula ser del equipo de TI y que dirige al usuario a un enlace para iniciar sesión es característico de spear phishing. La intención es engañar a un usuario concreto (o a un grupo reducido) para robar credenciales o inducir a ejecutar una acción insegura. La personalización y la urgencia son señales típicas.

Step 2: Evaluar el entorno de explotación. La instrucción de usar la red Wi‑Fi pública aumenta el riesgo de un ataque man-in-the-middle (MitM). En redes públicas mal configuradas, un atacante puede posicionarse entre el usuario y el portal (por ejemplo mediante un punto de acceso malicioso o ARP spoofing) y capturar credenciales, cookies o modificar tráfico en tránsito.

Step 3: Determinar el impacto y combinación de vectores. Combinando spear phishing (captura en la página falsa) y MitM (intercepción en la red) se eleva la probabilidad de exfiltración de credenciales y sesión. Un adversario puede usar ambas técnicas en tándem —redirigir al usuario a una página de phishing accesible solo por la red maliciosa o capturar datos si el sitio no usa TLS fuerte— incrementando el riesgo de compromiso de cuentas corporativas. Trap: Un error común es asumir que solo existe un vector cuando en entornos reales se combinan varios: el phishing entrega el cebador y la red pública facilita la intercepción. No hay que analizar estos eventos aisladamente. Por qué cada respuesta incorrecta falla: - Malware por macros en un archivo adjunto: Aunque plausible en campañas de phishing, en el escenario descrito no se menciona ningún adjunto ni indicación de descargar/abrir un documento con macros; la acción pedida es iniciar sesión en un enlace, lo que se alinea más con phishing web que con entrega de malware por macros. Además, macros implican ejecución de código en el endpoint, no intercepción en la red. - Credential stuffing: Este ataque aprovecha credenciales robadas y reutilizadas en múltiples servicios mediante automatización. En este caso la táctica descrita busca robar credenciales específicas del usuario mediante un enlace y/o MitM, no explotar credenciales previamente filtradas. Credential stuffing es una etapa posterior posible tras obtener credenciales, pero no es el vector inicial descrito. En resumen: spear phishing y MitM son las amenazas principales por el contenido del correo y la instrucción de usar una red pública. El análisis distingue entre vector de entrega (phishing) y punto de intercepción/exposición (Wi‑Fi pública/MitM).

Step 1: Definir los tres pilares del modelo CIA. Confidencialidad evita divulgación no autorizada; Integridad evita modificaciones no autorizadas; Disponibilidad garantiza acceso a datos y servicios autorizados cuando se necesitan.

Step 2: Asociar cada opción con el pilar correcto. La opción sobre disponibilidad (1) corresponde a Disponibilidad. La opción sobre no ser alterado (3) corresponde a Integridad. La opción sobre verificar el remitente (4) se relaciona con Autenticación o No repudio, no directamente con confidencialidad.

Step 3: Elegir la opción que describe confidencialidad: proteger información contra accesos no autorizados mediante cifrado y controles de acceso (2). Trap: confundir confidencialidad con integridad o disponibilidad porque los controles a menudo se solapan (por ejemplo, una solución de cifrado puede ayudar a integridad si incluye MACs), pero el objetivo primario de la confidencialidad es prevenir la divulgación. Por qué cada respuesta incorrecta falla: - Garantizar disponibilidad para usuarios autorizados cuando la necesiten: Esto describe Disponibilidad, no Confidencialidad. - Asegurar que los datos no sean alterados sin autorización: Esto define Integridad; las medidas típicas incluyen hashes, controles de versión y controles de acceso centrados en escritura. - Probar que un mensaje proviene realmente del remitente declarado: Esto se relaciona con Autenticación y No repudio (p. ej., firmas digitales), no con confidencialidad. Detalles técnicos adicionales: Para implementar confidencialidad en una empresa se usan cifrado en tránsito (TLS), cifrado en reposo (AES sobre discos o bases de datos), controles de acceso basado en roles (RBAC), segmentación de redes y principios de privilegio mínimo. La prueba de confidencialidad en auditoría revisa políticas de acceso, logs de permiso, configuración de cifrado y procesos de gestión de claves. Evitar la trampa de elegir respuestas que describen efectos secundarios o metas relacionadas; enfóquese en la definición central del término.

Step 1: Vector de entrada — El pipeline de CI/CD incorporó una dependencia comprometida; cuando bibliotecas de terceros en la cadena de suministro contienen malware, el software final queda infectado. Esto es la esencia de un ataque a la cadena de suministro: la confianza en componentes externos es explotada.

Step 2: Escalada y acceso persistente — El código malicioso aprovechó privilegios de una cuenta de servicio para leer credenciales/configuraciones y enviarlas fuera del entorno. La explotación de una cuenta de servicio con privilegios genera acceso lateral y persistencia, permitiendo al atacante moverse entre sistemas sin alertar a usuarios humanos.

Step 3: Impacto y mitigación — El compromiso combinado permite ejecutar acciones en nombre de la cuenta de servicio, robar secretos, alterar builds y desplegar malware. Mitigaciones incluyen políticas de aprovisionamiento de dependencias (vendor vetting, reproducible builds, firmas, verificación de hash), rotación y separación de privilegios para cuentas de servicio, y uso de secretos gestionados (vaults) con acceso granular. Trap: Una confusión común es asumir que solo el código fuente comprometido produce daño; en entornos modernos, artefactos binarios y paquetes de terceros son vectores críticos. Otro error es equiparar esto con ataques de red (ARP spoofing), que no explican la inserción de un paquete malicioso en la cadena de construcción. Por qué cada respuesta incorrecta falla: Respuesta 2 — Secuestro de sesión por ARP spoofing: ARP spoofing es un ataque de red local que facilita MITM dentro de una LAN; no explica cómo una dependencia en el pipeline logró exfiltrar credenciales desde dentro de la build ni cómo código malicioso llegó al repositorio de dependencias. Respuesta 4 — Inyección de SQL: Aunque la inyección de SQL puede resultar en exfiltración de datos, el vector descrito no es manipulación de consultas en una base de datos por entradas de usuario sino la inclusión de código malicioso en una dependencia externa. Por qué las respuestas correctas aplican: Respuesta 1 — Ataque a la cadena de suministro: La causa raíz es la dependencia comprometida añadida al pipeline, típico de supply chain attacks. Respuesta 3 — Compromiso de cuenta de servicio/credenciales privilegiadas: La exfiltración de credenciales de una cuenta de servicio muestra que las credenciales privilegiadas fueron comprometidas y abusadas por el código malicioso. Conclusión técnica: Implementar firma/verificación de paquetes, escaneo de dependencias, políticas de least privilege para cuentas de servicio, rotación de claves automáticas, y entornos de ejecución aislados para builds. También monitorizar el uso de cuentas de servicio y habilitar alertas por comportamiento anómalo.