PEPS UT4

¿Cuáles de los siguientes no es un mecanismo en el desarrollo seguro?. Autenticación. Encriptación. Segmentación. Autorización.

El NIST establece un framework de desarrollo de software seguro (SSDF), con prácticas recomendadas fundamentales, sólidas y seguras basadas en documentos de práctica de desarrollo de software. Las prácticas se organizan en cuatro grupos ¿Cuál de esos grupos se preocupa de asegurarse de que las personas, los procesos y la tecnología están preparados para realizar el desarrollo de software seguro a nivel de organización?. Responder a las vulnerabilidades (RV). Proteger el software (PS). Producir software bien protegido (PW). Preparar la organización (PO).

A la hora de usar la criptografía. no todas las funciones de criptografía de la aplicación deben ser implementadas en sistemas confiables. ninguna de las anteriores. no es necesario proteger los "master secrets" del acceso no autorizado porque ese caso no puede darse. los módulos de criptografía deberían en caso de fallo, fallar en forma segura.

¿Cuáles de los siguientes no es un principio según OWASP Development Guide?. No confiar en los sistemas externos: validar datos de entrada y salida. Utilizar la seguridad por ocultación. Mínimo privilegio (POLP). Minimizar los puntos de ataque.

A la hora de la gestión de la autenticación y las contraseñas no se debe. utilizar peticiones PUT y GET para transmitir las credenciales de autenticación. enviar las contraseñas únicamente a través de una conexión cifrada. indicar en las condiciones de error qué parte de los datos de autenticación era incorrecta. Cambiar todas las contraseñas e identificaciones de usuario por defecto proporcionadas por el proveedor o desactivar las cuentas asociadas.

A la hora del manejo de archivos se recomienda. guardar los archivos transferidos en el mismo contexto que la aplicación web. enviar la ruta absoluta de los archivos al usuario. no permitir transferir al servidor todos los tipos de archivo. no eliminar los archivos temporales tras su uso.

El NIST establece un framework de desarrollo de software seguro (SSDF), con prácticas recomendadas fundamentales, sólidas y seguras basadas en documentos de práctica de desarrollo de software. Las prácticas se organizan en cuatro grupos ¿Cuál de esos grupos se preocupa de identificar las vulnerabilidades residuales en las versiones de software y responder adecuadamente para abordar esas vulnerabilidades y evitar que ocurran otros similares en el futuro?. Preparar la organización (PO). Proteger el software (PS). Producir software bien protegido (PW). Responder a las vulnerabilidades (RV).

A la hora de validar la entrada y la salida de datos no se debe. Validar sólo los campos ocultos. Validar todas las entradas con una lista "blanca" de caracteres permitidos. Validar la longitud de los datos. Validar los tipos de datos esperados.

WSTG es. Es una guía que muestra cómo verificar la seguridad de una aplicación en funcionamiento. Es una guía que muestra cómo verificar la seguridad de la aplicación en si misma. Es una guía para realizar test de caja gris. Es una guía que muestra cómo diseñar y construir una aplicación segura.

A la hora de la gestión de la autorización y control de acceso. no se debe limitar el número de transacciones que un solo usuario o dispositivo puede realizar en un periodo de tiempo determinado. no se debe utilizar un único componente en todo el sitio para comprobar la autorización de acceso. se debe aplicar controles de autorización en todas las solicitudes, incluidos los scripts del lado del servidor y los includes. se debe denegar todos los accesos en caso de que la aplicación no pueda acceder a la información de configuración de seguridad.

Para prevenir los problemas de Insecure Design (Diseño inseguro) no se recomienda. escribir pruebas unitarias y de integración para validar que todos los flujos críticos sean resistentes al modelo de amenazas. establecer y utilizar un ciclo de vida de desarrollo seguro con los profesionales de AppSec para ayudar a evaluar y diseñar controles relacionados con la seguridad y la privacidad. utilizar el modelado de amenazas para la autenticación crítica, el control de acceso, la lógica empresarial y los flujos de claves. no limitar el uso de recursos por usuario o servicio.

MASVS no esta pensado para. Ofrecer un estándar para que la industria pueda utilizar en las revisiones de seguridad de aplicaciones móviles. Proveer requerimientos para arquitectos y desarrolladores de software que buscan desarrollar aplicaciones móviles seguras. Ser una guía completa para probar la seguridad de aplicaciones de dispositivos móviles. Proporcionar recomendaciones específicas sobre el nivel de seguridad que se recomienda para los diferentes casos de uso.

¿Cuál de las siguientes no es una práctica de programación segura OWASP?. Administración de perfiles de usuarios. Administración de sesiones. Manejo de errores y logs. Protección de datos.

A la hora de la gestión de la seguridad en las bases de datos no se recomienda. la aplicación debe utilizar el nivel de privilegio más alto posible al acceder a la base de datos. utilizar consultas parametrizadas fuertemente tipadas. las cadenas de conexión a la base de datos no deben de estar incluidas en el código de la aplicación. utilizar la validación de la entrada y si la validación falla, no ejecutar el comando de la base de datos.

A la hora de la seguridad en las comunicaciones no se recomienda. utilizar conexiones SSL para todo el contenido que requiera acceso autenticado y para todo otro tipo de información sensible. las conexiones SSL que fallen se transformen en una conexión insegura. implementar cifrado para todas las transmisiones de información sensible. filtrar los parámetros que contengan información sensible de los referer HTTP, cuando existen vinculos a sitios externos.

¿Cuál de las siguientes vulnerabilidades no se incluye dentro de Security Logging and Monitoring Failures?. Las pruebas de penetración y los escaneos realizados por herramientas de pruebas dinámicas (DAST) de seguridad de aplicaciones (como OWASP ZAP) no activan las alertas. Las advertencias y los errores no generan mensajes de registro, son inadecuados o poco claros. Los registros de las aplicaciones y las API no se supervisan para detectar actividades sospechosas. Los eventos auditables, como los inicios de sesión, los inicios de sesión fallidos y las transacciones de alto valor, se registran.

ASVS es. Es una guía que muestra cómo verificar la seguridad de la aplicación en funcionamiento. Es una guía para realizar pentesting. Es una guía que muestra cómo diseñar y construir una aplicación segura. Es una guía que muestra cómo verificar la seguridad de una aplicación.

En el siguiente ejemplo: Ejemplo: un ladrón de coches pasa por un estacionamiento revisando coches en busca de puertas abiertas y cuando encuentran una, abre la puerta y toma lo que sea que haya dentro. ¿Cuál es la vulnerabilidad?. el contenido del coche. los coches. la puerta abierta. el ladrón.

Los niveles de verificación de MASVS son. Dos niveles de verificación de seguridad (MASVS-L2 y MASVS-L3) y un conjunto de requisitos de resistencia a la ingeniería inversa (MASVS-R). Tres niveles de verificación de seguridad (MASVS-L1, MASVS-L2 y MASVS-L3). Ninguna de las anteriores. Dos niveles de verificación de seguridad (MASVS-L1 y MASVS-L2) y un conjunto de requisitos de resistencia a la ingeniería inversa (MASVS-R).

MSTG no. clarifica el rol de los mecanismos de protección de software en la seguridad móvil y no proporciona requerimientos para verificar su efectividad. proporciona una línea de base para pruebas de seguridad completas y consistentes. describe los procesos y técnicas para verificar la lista de requisitos. es una guía completa para probar la seguridad de aplicaciones de dispositivos móviles.

¿Qué se debe tener en cuenta para asegurar un almacenamiento seguro de contraseñas en aplicaciones web?. No almacenar contraseñas en absoluto. Utilizar algoritmos de encriptación débiles. Almacenar contraseñas de forma segura utilizando técnicas de hash y salting. Almacenar las contraseñas en texto claro.

¿Cuál de las siguientes opciones describe mejor el objetivo del desarrollo seguro de aplicaciones web?. Evitar el uso de autenticación y autorización. Integrar medidas de seguridad en el ciclo de desarrollo de software. Garantizar que las aplicaciones web sean completamente invulnerables. Permitir el almacenamiento de contraseñas en texto claro.

¿Qué función cumple el "Almacenamiento seguro de datos" en aplicaciones móviles?. Salvaguardar la información sensible del usuario. Evitar fugas de información en los ejecutables. Validar las compras realizadas dentro de la aplicación. Proteger la autenticidad de las aplicaciones.

¿Qué estándar establece los requisitos de verificación necesarios para el nivel de seguridad de una aplicación?. ASVS. ISO 9001. HIPAA. NIST SP 800-171.

¿Qué se utiliza para verificar y asegurar el nivel de seguridad de una aplicación?. GDPR. ASVS. HIPAA. SOC 2.

¿Cuál de las siguientes opciones representa una comprobación de seguridad a nivel de aplicación según ASVS?. Validación de entrada. Encriptación del disco duro. Uso de contraseña segura. Configuración de red.

¿Qué se revisa en la fase de despliegue del SSDLC?. El plan de respuesta ante incidentes. El diseño visual. Los colores de la intefaz. Las méticas de marketing.

¿Qué metodología se usa para categoizar amenazas?. CSS. STRIDE. SEO. HTML.

A la hora de la configuración de los sistemas. se deben registrar sólo las excepciones de cifrado. hay que asegurarse de que los servidores, los frameworks y los componentes del sistema estén parcheados. es imprescindible restringir las cuentas del servidor web, de los procesos y de los servicios a los menores privilegios posibles. se deben utilizar gestores de excepciones seguros.