CompTIA SecurityX — Preguntas de práctica y simulacro de examen

En el AWS Shared Responsibility Model, AWS gestiona la seguridad "de" la nube (infraestructura física, hipervisor, red global), mientras que los clientes gestionan la seguridad "en" la nube (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Los security groups (con estado, a nivel de instancia) y las NACLs (sin estado, a nivel de subnet) son siempre controles de red configurados por el cliente, sin importar el modelo de servicio. ¿Por qué no las otras? La seguridad física del centro de datos es una obligación central de AWS. La infraestructura de red global la administra AWS. Aplicar parches al hipervisor es responsabilidad de AWS según el límite de IaaS. Ese límite se desplaza según el modelo de servicio: EC2 (IaaS) deja más responsabilidad al cliente; Lambda (serverless) deja menos. Según el AWS Well-Architected Security Pillar, cualquier decisión de configuración sobre las cargas de trabajo del cliente le corresponde al cliente. Ref: AWS Shared Responsibility Model; AWS Well-Architected Security Pillar; NIST SP 800-145.

Clasifica por el mecanismo de entrega, no por la historia que lo envuelve. Un adversario que envía mensajes para obtener acceso a los sistemas de las víctimas está haciendo phishing, y la clase cubre explícitamente los adjuntos y enlaces maliciosos, así como hacerse pasar por una fuente de confianza. Suplantar a un proveedor es un refinamiento del objetivo que hace el mensaje más convincente, pero no cambia cuál es la técnica.

Los distractores pertenecen a etapas posteriores o a objetivos distintos. Abusar de credenciales existentes describe a un adversario que ya tiene acceso a una cuenta válida, que es cómo continúa una intrusión y no cómo llega esta. Mezclar el tráfico de comandos con protocolos ordinarios de capa de aplicación es un comportamiento de comando y control que solo importa cuando ya existe un punto de apoyo. Ejecutar código dentro de otro proceso es una técnica de ejecución y evasión en un host que ya fue comprometido.

Consejo para el examen: acertar con la clasificación importa porque las contramedidas son distintas. La entrega se contrarresta con autenticación de mensajes, detonación de adjuntos y un canal de reporte para los usuarios, mientras que el abuso de credenciales y la ejecución de código necesitan controles totalmente diferentes, así que etiquetar mal la técnica te lleva a la defensa equivocada.

El shadow IT es el uso de sistemas, dispositivos, software o servicios en la nube sin la aprobación explícita de la organización, lo que crea riesgo no gestionado y puntos ciegos de gobernanza. Aquí el departamento de TI usó almacenamiento en la nube no aprobado — la definición de manual. ¿Por qué no las otras? El riesgo residual es el riesgo que queda después de aplicar controles, y presupone que existen controles. El riesgo inherente es el riesgo de partida antes de cualquier control, y no tiene que ver con el uso no autorizado. El riesgo transferido implica trasladar el riesgo a un tercero mediante un seguro o la subcontratación. El shadow IT socava el inventario de activos, el cumplimiento, la respuesta a incidentes y la protección de datos, porque los equipos de seguridad no pueden proteger lo que no saben que existe. Genera huecos en las evaluaciones de riesgo, en la aplicación de políticas y en el cumplimiento normativo. Ref: NIST CSRC Glossary (shadow_it); NIST SP 800-53 Rev 5 CM-8 (System Component Inventory); NIST CSF Identify function.

El certificate pinning vincula un certificado o una clave pública concretos al servidor esperado de una aplicación, complementando la validación estándar de la cadena TLS. TLS estándar confía en cualquier CA del almacén del dispositivo; una CA comprometida o fraudulenta puede emitir certificados falsos y habilitar la interceptación MITM. El pinning lo impide al verificar que el certificado del servidor coincide con un hash incrustado de antemano. Enfoques: pinning de la hoja (estricto), pinning de la CA intermedia (flexible) o pinning de la clave pública (sobrevive a la renovación del certificado). ¿Por qué no los otros? Los ataques DoS atacan la disponibilidad, no la autenticación. El XSS explota el DOM del navegador, algo ajeno a la seguridad del transporte. La inyección SQL ataca el análisis de las consultas, no TLS. Entre los riesgos del pinning está la complejidad operativa durante la rotación de certificados; los pins de respaldo son esenciales para evitar quedarse fuera. Ref: OWASP Mobile Security Testing Guide (MSTG); OWASP Mobile Top 10 M3; RFC 7469 (HTTP Public Key Pinning).