Respuestas explicadas del simulacro
Respuestas explicadas del simulacro
Solucionario del simulacro de examen. Para cada pregunta encontrarás la respuesta correcta, por qué lo es y por qué cada una de las otras tres opciones no lo es. Al final tienes una tabla de dominios para saber qué repasar y una escala de desempeño.
Lee las explicaciones aunque hayas acertado: entender por qué las otras opciones fallan es lo que entrena la mentalidad ISC2.
Dominio 1 — Secure Software Concepts
1. Correcta: B — Separation of duties. Que una sola persona cree y apruebe un pago concentra en un individuo un proceso crítico, lo que permite fraude sin control; la separación de funciones exige que acciones sensibles requieran a más de una persona.
- A. Least privilege limita permisos, no separa funciones enfrentadas dentro de un mismo flujo.
- C. Defense in depth trata de capas de control, no de dividir responsabilidades.
- D. Economy of mechanism aboga por diseños simples, ajeno al problema.
2. Correcta: C — Least privilege. Dar permisos de administrador “por si acaso” viola el principio de mínimo privilegio: cada proceso debe tener solo los permisos estrictamente necesarios para su función.
- A. Complete mediation exige verificar cada acceso, no reducir permisos.
- B. Open design dice que la seguridad no debe depender del secreto del diseño.
- D. Psychological acceptability trata de que los controles no estorben al usuario.
3. Correcta: A — Denegar el acceso hasta restablecerse (fail secure). Ante el fallo del subsistema de autorización, el comportamiento seguro por defecto es denegar: fail secure evita que un fallo abra el acceso.
- B. Fail open prioriza disponibilidad sobre seguridad y deja el sistema expuesto.
- C. Continuar con permisos en caché puede prolongar accesos que ya no deberían existir.
- D. Reintentar automáticamente no resuelve el estado inseguro mientras tanto.
4. Correcta: C — El dueño del riesgo (business/data owner). Aceptar un riesgo es una decisión de negocio: la toma el dueño del riesgo, que asume las consecuencias en nombre de la organización, no el personal técnico.
- A. El líder técnico implementa, no acepta el riesgo residual del negocio.
- B. El analista identifica y recomienda, pero no decide la aceptación.
- D. Operaciones mantiene el sistema, no es dueño del riesgo.
5. Correcta: B — Privacy by design desde los requisitos. Tratándose de datos de menores, la privacidad debe incorporarse desde el inicio minimizando la recolección; privacy by design es preventivo y proporcionado al riesgo.
- A. Un aviso extenso no protege los datos, solo informa.
- C. Cifrar al final es un control tardío y parcial.
- D. Anonimizar solo al exportar deja los datos expuestos en el resto del ciclo.
Dominio 2 — Secure Software Lifecycle Management
6. Correcta: D — Un modelo de madurez como OWASP SAMM o BSIMM. Medir madurez y compararse en el tiempo y con la industria es justo el propósito de los modelos de madurez SAMM/BSIMM.
- A. El OWASP Top 10 es una lista de riesgos, no un modelo de madurez.
- B. La CWE Top 25 enumera debilidades de software, no mide madurez.
- C. Un SAST evalúa código en un momento dado, no la madurez del programa.
7. Correcta: D — Sanitizar o destruir de forma segura datos y credenciales. La mayor preocupación al decomisionar es que datos sensibles y credenciales no queden expuestos; deben sanitizarse o destruirse de forma segura.
- A. Documentar la arquitectura es útil pero no es la prioridad de seguridad.
- B. Archivar el código no aborda el riesgo de los datos residuales.
- C. Notificar a los usuarios es operativo, no el control de seguridad clave.
8. Correcta: C — Densidad de vulnerabilidades y tiempo medio de remediación. Una buena métrica de seguridad es accionable y orientada a resultados: densidad de vulnerabilidades por KLOC y MTTR muestran tendencia real del programa.
- A. Las líneas de código no dicen nada sobre seguridad.
- B. Contar reuniones mide actividad, no efectividad.
- D. El número de desarrolladores no es un indicador de seguridad.
9. Correcta: A — NIST SSDF (SP 800-218). El SSDF describe justamente cómo integrar prácticas de seguridad (incluidos modelado de amenazas y revisión de código) en las fases del desarrollo.
- B. PCI DSS es un estándar de datos de tarjetas, no un marco de SDLC seguro.
- C. ISO 9001 trata de gestión de calidad genérica.
- D. ITIL trata de gestión de servicios de TI, no de desarrollo seguro.
Dominio 3 — Secure Software Requirements
10. Correcta: B — Misuse y abuse cases. Capturar cómo un atacante abusaría de una funcionalidad es exactamente el propósito de los misuse/abuse cases, la contraparte adversarial de los casos de uso.
- A. Los casos de uso funcionales describen el comportamiento esperado, no el abuso.
- C. Las historias de usuario expresan valor para el usuario legítimo.
- D. Los diagramas de secuencia modelan interacciones, no intención maliciosa.
11. Correcta: C — Security Requirements Traceability Matrix (SRTM). La SRTM vincula cada requisito de seguridad con su diseño, implementación y prueba, garantizando trazabilidad de extremo a extremo.
- A. Un DFD modela flujos de datos, no traza requisitos.
- B. Un backlog ordena trabajo, no asegura trazabilidad de requisitos de seguridad.
- D. STRIDE identifica amenazas, no rastrea requisitos hasta su prueba.
12. Correcta: A — Clasificar los datos según su sensibilidad e impacto. Antes de elegir controles proporcionales hay que saber qué datos son más sensibles; la clasificación de datos es el primer paso.
- B. Cifrar todo con el algoritmo más fuerte es desproporcionado y prematuro sin clasificar.
- C. El RBAC es un control posterior a conocer la sensibilidad.
- D. Un seguro transfiere riesgo, no define controles de protección de datos.
13. Correcta: B — Las obligaciones regulatorias aplicables (GDPR y HIPAA). Con datos de salud de la UE y EE. UU., los requisitos deben reflejar primero las obligaciones legales; la ley condiciona todo el diseño posterior.
- A. El lenguaje de programación es una decisión técnica secundaria.
- C. El proveedor de nube se decide después de conocer las obligaciones.
- D. El diseño de UI no es un requisito de seguridad prioritario.
14. Correcta: D — Definir los requisitos de seguridad ahora, junto con los funcionales. La seguridad se integra desde los requisitos, no se “añade después”; lo correcto es definir los requisitos de seguridad en paralelo a los funcionales.
- A. Un pentest tardío detecta, pero no sustituye requisitos tempranos.
- B. Documentar el riesgo y dejar decidir sobre la marcha diluye la responsabilidad y llega tarde.
- C. Un WAF es un parche reactivo en producción, no un requisito de fondo.
Dominio 4 — Secure Software Architecture and Design
15. Correcta: C — Spoofing. Hacerse pasar por otro usuario legítimo es suplantación de identidad: la S de STRIDE (Spoofing).
- A. Tampering es alteración no autorizada de datos.
- B. Repudiation es negar una acción realizada.
- D. Elevation of privilege es obtener permisos superiores a los autorizados.
16. Correcta: A — Descomponer la aplicación y construir un DFD. El primer paso del modelado de amenazas es entender el sistema: descomponerlo y diagramar sus flujos de datos antes de identificar o puntuar amenazas.
- B. Puntuar con DREAD ocurre después de identificar las amenazas.
- C. Escribir casos de prueba es una actividad posterior.
- D. Seleccionar contramedidas es el paso final, no el primero.
17. Correcta: D — Reducir la superficie de ataque deshabilitando los endpoints no usados. Endpoints heredados sin uso solo suman superficie de ataque; el diseño seguro busca minimizarla eliminando lo innecesario.
- A. Dejarlos activos mantiene el riesgo aunque se monitoreen.
- B. Documentarlos y continuar no reduce la exposición.
- C. Añadir autenticación complica y conserva un activo inútil y riesgoso.
18. Correcta: B — Gestionar la clave en un KMS o HSM, fuera del código, con rotación. Guardar la clave junto al código anula el cifrado; lo correcto es custodiarla en un KMS/HSM, separada del código y con rotación.
- A. Ofuscar la clave es seguridad por oscuridad, se rompe fácilmente.
- C. Cifrarla con otra clave incrustada solo traslada el problema.
- D. Cambiar de algoritmo no resuelve la mala gestión de la clave.
19. Correcta: B — Prompt injection que ejecute acciones no autorizadas. Un LLM con capacidad de actuar sobre instrucciones en lenguaje natural es vulnerable a prompt injection; el mayor riesgo de diseño es que se manipule para ejecutar acciones no autorizadas.
- A. El costo de tokens es una preocupación operativa, no de seguridad.
- C. La latencia es un tema de rendimiento.
- D. La accesibilidad es importante, pero no es el riesgo de seguridad principal.
20. Correcta: C — Autenticación y autorización servicio a servicio bajo zero trust. Para que un microservicio comprometido no acceda libremente al resto, cada llamada entre servicios debe autenticarse y autorizarse bajo un modelo zero trust.
- A. Confiar en la red interna es el modelo de perímetro que este escenario busca evitar.
- B. Compartir una única API key expande el compromiso a todos los servicios.
- D. Una subred plana facilita el movimiento lateral del atacante.
Dominio 5 — Secure Software Implementation
21. Correcta: A — Usar consultas parametrizadas (prepared statements). La causa raíz de la inyección SQL es mezclar datos y código; las consultas parametrizadas separan ambos y la eliminan.
- B. Escapar comillas a mano es frágil y omite muchos vectores.
- C. Un WAF mitiga en el perímetro pero no corrige la causa.
- D. Limitar la longitud no impide la inyección.
22. Correcta: C — SCA (Software Composition Analysis). Detectar vulnerabilidades conocidas en librerías de terceros es la función del SCA, que analiza dependencias contra bases de datos de CVE.
- A. El SAST analiza el código propio, no las dependencias.
- B. El DAST prueba la app en ejecución, sin identificar componentes.
- D. El fuzzing envía entradas malformadas, no inventaría dependencias.
23. Correcta: D — Moverlas a variables de entorno y a un gestor de secretos, y rotarlas. Las credenciales nunca deben residir en el código; deben externalizarse a un gestor de secretos, inyectarse por entorno y rotarse tras la exposición.
- A. Comentar las credenciales las deja en el historial del repositorio.
- B. Restringir el acceso al repo no saca el secreto del código.
- C. base64 es codificación, no cifrado; se revierte trivialmente.
24. Correcta: B — Validación de entrada más output encoding contextual. El XSS se previene mejor combinando validación de entrada con codificación de salida según el contexto donde se inserta el dato en el navegador.
- A. Solo validar la entrada no cubre todos los contextos de salida.
- C. TLS protege el transporte, no la inyección en el HTML.
- D. La complejidad de contraseñas es ajena al XSS.
25. Correcta: B — Data poisoning; validar procedencia e integridad de los datos de entrenamiento. Inyectar muestras maliciosas en el entrenamiento para sesgar el modelo es data poisoning; el control es asegurar la procedencia e integridad de los datos.
- A. El prompt injection ocurre en inferencia, no en el entrenamiento.
- C. No es una denegación de servicio; el objetivo es corromper el modelo.
- D. La inversión de modelo extrae datos de entrenamiento, no los envenena.
26. Correcta: C — Registrar el detalle internamente y devolver un mensaje genérico. Exponer stack traces filtra información útil para un atacante; lo correcto es registrar el detalle internamente y mostrar un mensaje genérico al usuario.
- A. Mostrar el stack trace a autenticados sigue filtrando información.
- B. Traducir el stack trace mantiene la fuga.
- D. Suprimir todo registro impide diagnosticar y responder incidentes.
Dominio 6 — Secure Software Testing
27. Correcta: A — DAST. Probar la aplicación ya desplegada enviándole peticiones maliciosas sin acceder al código es análisis dinámico (DAST).
- B. El SAST analiza el código fuente de forma estática.
- C. El SCA inventaría y evalúa dependencias.
- D. La revisión estática examina el código, no la app en ejecución.
28. Correcta: D — Fuzzing. Enviar entradas malformadas, inesperadas o aleatorias para provocar fallos es precisamente el fuzzing.
- A. Las pruebas unitarias con casos válidos no exploran entradas inesperadas.
- B. El SCA analiza dependencias, no la robustez del parser.
- C. Las pruebas de aceptación validan requisitos con el usuario.
29. Correcta: D — Enmascarar o anonimizar (data masking) los datos. Usar datos de producción con PII en pruebas viola la privacidad; deben enmascararse o anonimizarse manteniendo el realismo sin exponer datos reales.
- A. Usarlos tal cual expone información personal de clientes.
- B. Cifrar el entorno no evita que QA vea datos reales al usarlos.
- C. Dar acceso a producción amplía la exposición de los datos.
30. Correcta: B — Una prueba de penetración (pentest). Simular un ataque real de un adversario contra el sistema completo en ejecución es el propósito de un pentest.
- A. El SAST revisa código, no simula un ataque al sistema en marcha.
- C. La revisión de requisitos es una actividad temprana y documental.
- D. El SCA analiza dependencias, no ejecuta un ataque.
31. Correcta: B — Definir un bug bar / umbral de severidad y priorizar según riesgo. Con recursos limitados y muchos defectos, se prioriza según riesgo usando un bug bar que fija qué severidades bloquean el lanzamiento.
- A. Corregir todos sin priorizar es irreal y no gestiona el riesgo.
- C. Entregar y posponer todo ignora la severidad de lo crítico.
- D. Dejarlo al criterio individual carece de consistencia y gobernanza.
32. Correcta: C — Red teaming adversarial específico para LLMs. Probar sistemáticamente si el LLM puede ser manipulado para filtrar datos o saltarse restricciones es red teaming adversarial (prompt injection, jailbreaks, fugas).
- A. Las pruebas de carga miden rendimiento, no manipulación.
- B. Las pruebas de usabilidad evalúan la experiencia, no la seguridad.
- D. La validación gramatical no aborda el abuso del modelo.
Dominio 7 — Secure Software Deployment, Operations, Maintenance
33. Correcta: A — Hardening según un secure baseline. Reducir la exposición eliminando servicios innecesarios, cerrando puertos y aplicando una configuración segura de referencia es hardening sobre una línea base segura.
- B. La integración continua automatiza builds, no endurece el servidor.
- C. El blue-green es una estrategia de despliegue, no de endurecimiento.
- D. El chaos engineering prueba resiliencia inyectando fallos.
34. Correcta: B — Contener el incidente según el plan de respuesta. Ante una intrusión activa, el primer paso tras la detección es contener para limitar el alcance, antes de erradicar o recuperar.
- A. Erradicar reinstalando de inmediato puede destruir evidencia y no contiene primero.
- C. El comunicado de prensa es un paso posterior de comunicación.
- D. Buscar culpables internos no es parte de la respuesta técnica inmediata.
35. Correcta: D — Probarlo en staging y desplegarlo mediante gestión de cambios controlada. Incluso un parche crítico debe probarse en staging y aplicarse con gestión de cambios para no romper producción de forma masiva.
- A. Aplicarlo directo a producción arriesga interrupciones no probadas.
- B. Esperar a que un cliente lo reporte deja el sistema vulnerable.
- C. Esperar al ciclo trimestral es demasiado tarde para un parche crítico.
36. Correcta: B — Gestión de configuración con IaC y líneas base versionadas. La divergencia entre servidores se evita gestionando la configuración como código, con líneas base versionadas y reproducibles.
- A. Una hoja de cálculo no impone ni audita la configuración real.
- C. Dar más acceso SSH aumenta la deriva manual, no la reduce.
- D. Reiniciar servidores no unifica sus configuraciones.
Dominio 8 — Secure Software Supply Chain
37. Correcta: C — Un SBOM (Software Bill of Materials). Un inventario legible por máquina de todos los componentes y dependencias del software entregado es precisamente un SBOM.
- A. Un diagrama de arquitectura no lista dependencias de forma procesable.
- B. Un informe de pentest reporta hallazgos, no el inventario de componentes.
- D. Una SRTM traza requisitos, no componentes de terceros.
38. Correcta: A — Provenance y pedigree (con firmas y verificación de integridad). Asegurar que un componente viene de una fuente confiable y no fue alterado en tránsito es cuestión de provenance y pedigree, sostenidos por firmas y verificación de integridad.
- B. Ofuscar el código no prueba su origen ni su integridad.
- C. Minificar dependencias reduce tamaño, no verifica procedencia.
- D. Más pruebas unitarias no acreditan el origen del componente.
39. Correcta: D — Evaluación de riesgo del tercero (due diligence) y requisitos en el contrato. La gestión de riesgo de la cadena de suministro exige evaluar las prácticas del proveedor (due diligence) y fijar requisitos de seguridad contractualmente.
- A. Confiar en la reputación no es una evaluación de riesgo.
- B. Una cláusula de responsabilidad sin evaluar deja el riesgo sin gestionar.
- C. Un antivirus sobre el binario no evalúa las prácticas del proveedor.
40. Correcta: B — Procedencia e integridad del modelo (backdoors o pesos manipulados) y su licencia. Un modelo preentrenado de un repositorio público es un componente de la cadena de suministro: la preocupación clave es su procedencia e integridad (posibles backdoors o pesos manipulados) y su licencia.
- A. El tamaño en disco es una cuestión operativa.
- C. El framework de entrenamiento no determina el riesgo del modelo entregado.
- D. La velocidad de descarga es irrelevante para la seguridad.
Tabla de dominios para autoevaluación
Marca las preguntas que fallaste y localiza el dominio: si concentras errores en un dominio, es tu prioridad de repaso.
| Pregunta | Dominio | Respuesta |
|---|---|---|
| 1 | D1 — Conceptos | B |
| 2 | D1 — Conceptos | C |
| 3 | D1 — Conceptos | A |
| 4 | D1 — Conceptos | C |
| 5 | D1 — Conceptos | B |
| 6 | D2 — Lifecycle | D |
| 7 | D2 — Lifecycle | D |
| 8 | D2 — Lifecycle | C |
| 9 | D2 — Lifecycle | A |
| 10 | D3 — Requisitos | B |
| 11 | D3 — Requisitos | C |
| 12 | D3 — Requisitos | A |
| 13 | D3 — Requisitos | B |
| 14 | D3 — Requisitos | D |
| 15 | D4 — Arquitectura | C |
| 16 | D4 — Arquitectura | A |
| 17 | D4 — Arquitectura | D |
| 18 | D4 — Arquitectura | B |
| 19 | D4 — Arquitectura (IA) | B |
| 20 | D4 — Arquitectura | C |
| 21 | D5 — Implementación | A |
| 22 | D5 — Implementación | C |
| 23 | D5 — Implementación | D |
| 24 | D5 — Implementación | B |
| 25 | D5 — Implementación (IA) | B |
| 26 | D5 — Implementación | C |
| 27 | D6 — Testing | A |
| 28 | D6 — Testing | D |
| 29 | D6 — Testing | D |
| 30 | D6 — Testing | B |
| 31 | D6 — Testing | B |
| 32 | D6 — Testing (IA) | C |
| 33 | D7 — Operaciones | A |
| 34 | D7 — Operaciones | B |
| 35 | D7 — Operaciones | D |
| 36 | D7 — Operaciones | B |
| 37 | D8 — Supply chain | C |
| 38 | D8 — Supply chain | A |
| 39 | D8 — Supply chain | D |
| 40 | D8 — Supply chain (IA) | B |
Errores por dominio
| Dominio | Preguntas | Errores | ¿Repasar? |
|---|---|---|---|
| D1 — Conceptos | 1-5 | ___ / 5 | |
| D2 — Lifecycle | 6-9 | ___ / 4 | |
| D3 — Requisitos | 10-14 | ___ / 5 | |
| D4 — Arquitectura y diseño | 15-20 | ___ / 6 | |
| D5 — Implementación | 21-26 | ___ / 6 | |
| D6 — Testing | 27-32 | ___ / 6 | |
| D7 — Operaciones | 33-36 | ___ / 4 | |
| D8 — Supply chain | 37-40 | ___ / 4 |
Regla práctica: si fallas 2 o más en un mismo dominio, vuelve a ese capítulo antes de reintentar.
Escala orientativa de desempeño
Sobre 40 preguntas (recuerda que el corte real del examen es 700/1000, ~70%):
| Aciertos | Interpretación | Acción recomendada |
|---|---|---|
| < 28 (< 70%) | Aún por debajo del umbral | Repasar todos los dominios y rehacer el simulacro |
| 28-33 (70-82%) | En el filo, aprobarías con margen ajustado | Repasar los dominios débiles según la tabla y practicar con tests oficiales |
| 34+ (≥ 85%) | Sólido y consistente | Estás listo para agendar el examen; haz un repaso final de terminología |
No agendes solo por un buen resultado aislado: busca consistencia por encima del 80% en varios simulacros y practice tests oficiales antes de reservar tu cita en Pearson VUE.
Vuelve al índice del curso para repasar cualquier dominio, o revisa de nuevo la estrategia de examen antes de tu cita.