ID de solicitud

Comentarios sobre el grupo de trabajo

8,1

Se debería reconsiderar este requisito como algo más práctico (p.ej., las copias de seguridad solo se deben retener durante X tiempo, las copias de seguridad deben supervisarse en busca de robos o corrupción, las copias de seguridad deben auditarse con regularidad para confirmar su capacidad de volver a producción). La suposición actual es demasiado amplia y necesitaría más definición.

5.1.4

Duplicado de otros casos de prueba Este es un caso de prueba de bajo valor y alto esfuerzo. Recomendado para quitar.

7.3.3

Duplicado de otros casos de prueba Este es un caso de prueba de bajo valor y alto esfuerzo. Recomendado para quitar.

1.2.2

quitar debido a la cobertura en otros requisitos, como 4.1.1

2.2.4

Quita la solicitud, ya que se encuentra en la versión 4.3.1.

(4.3.1 Verifica que las interfaces administrativas usen la autenticación de varios factores adecuada para

evitar el uso no autorizado)

2.2.5

La mayoría de los CSP no admiten la opción de quitar como mTLS; además, la mayoría de los desarrolladores que se probaron para CASA usarán la autenticación basada en contraseñas.

2.4.3

El estándar, tal como está escrito, no es lo suficientemente específico para que pueda aplicarse

2.4.5

El requisito que se quitó en la versión 5 de ASVS y los algoritmos de hash recomendados en 2.4.1 no pueden cumplir con este requisito

2.7.5

Las pruebas son inviables, ya que pueden requerir un análisis de proveedores de OOB de terceros, el riesgo aquí es bajo porque el código de autenticación es de corta duración.

2.8.2

es relevante para las soluciones de MFA personalizadas, también incluidas en las versiones 6.4.2 y 6.4.1.

2,8,5

Quita el requisito, ya que lo cubre 2.7.6. Además, el registro de intentos fallidos está cubierto por el requisito de registro del ASVS.

2,8,6

La OTP física a nivel de la aplicación no es un caso práctico común, por lo que se necesita para las interfaces de administrador. Sin embargo, la solicitud 4.3.1 (verificar que las interfaces administrativas usen la autenticación de varios factores adecuada para evitar el uso no autorizado) cubre la MFA para interfaces de administrador y cubrirá este riesgo.

2,9,1

Este requisito cubre los dispositivos físicos de acuerdo con ASVS (las llaves de seguridad criptográfica son tarjetas inteligentes o FIDO, en las que el usuario debe conectar o sincronizar el dispositivo).

a la computadora para completar la autenticación. Los verificadores envían un nonce de desafío al

dispositivos criptográficos, y el dispositivo o software calcula una respuesta según una

.

2,9,3

Este requisito cubre los dispositivos físicos de acuerdo con ASVS (las llaves de seguridad criptográfica son tarjetas inteligentes o FIDO, en las que el usuario debe conectar o sincronizar el dispositivo).

a la computadora para completar la autenticación. Los verificadores envían un nonce de desafío al

dispositivos criptográficos, y el dispositivo o software calcula una respuesta según una

.

2,10.1

El requisito es una contradicción de la versión 2.10.2

2,10.3

Cubierto por 2.4.1 (verifica que se use una de las siguientes funciones de hashing de contraseñas cuando se almacena la contraseña del usuario para la aplicación: argon2id, scrypt, bcrypt o PBKDF2), que cubre el riesgo de ataques sin conexión y el almacenamiento de contraseñas.

2,10.4

Cobertura de la versión 6.4.2. Verifica que el material de claves no esté expuesto a la aplicación, sino que use un módulo de seguridad aislado, como una caja fuerte para operaciones criptográficas.

3,2

Cubierto por 3.4.1, 3.4.2 y 3.4.3

3.5.1

El usuario puede revocar los tokens mediante el proveedor de OAuth

4,3

La solicitud de MFA cubre las interfaces de administrador y el acceso con privilegios

5.1.3

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

5.1.4

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

5.3.2

La parte de este requisito que especifica que todos los caracteres Unicode son válidos puede dificultar la prueba. No todas las aplicaciones incluirán un formulario de texto lo suficientemente grande como para ajustarse a cada carácter unicode. Además, hay una falta de compatibilidad con ciertos sistemas operativos y herramientas de hackeo para todo el espacio de Unicode, lo que no te permite probar esto incluso si el servidor lo admite. Valor de seguridad cuestionable en general. Se incluyó originalmente en la versión beta, pero se quitó debido a problemas en las pruebas.

6,2.5

cubierto por 6.2.4 y 6.2.3

6,2

cubierto por 6.2.4 y 6.2.3

6.3.1

cubierto por 6.2.4 y 6.2.3

6,3

abarcado por otros requisitos de generación de números al azar.

7.1.2

cubierto por 7.1.1

7,1.3

cubierto por 7.1.1

7.3.1

cubierto por 7.1.1

7.3.3

cubierto por 7.1.1

8,1

Es difícil describir qué es un parámetro aceptable o necesario. No es un caso que se pueda probar. ¿Qué se considera necesario? ¿Cómo determinaremos si una excepción es válida? Se considera fuera del alcance de CASA.

8,3

No es un requisito que se pueda probar y sea relevante para la política de privacidad y las Condiciones del Servicio, no por la seguridad de la aplicación. Esta es una revisión legal y de cumplimiento, y está fuera del alcance de CASA.

8,3

El control es específico del sistema (variante Windows/Linux) y específico del dispositivo. En la mayoría de los casos, no es el control de la aplicación.

8,3

cubierto por 1.8.1, 1.8.2 y 1.1.4

9,2

cubierto por 8.3.5 y las revisiones de las políticas de registro de la aplicación.

10,1

Está cubierto por la revisión de la arquitectura y es una práctica recomendada. El requisito no se puede probar

10.2.3

No es posible hacerlo en un tiempo razonable. Cualquier código extraño debe estar documentado y revisado. Sin embargo, configurar la tarea específica para garantizar que las puertas traseras no estén presentes requeriría una revisión detallada del código de línea y no garantiza que las puertas traseras no estén presentes.

Difíciles de probar funciones maliciosas bien diseñadas

10,2.4

No hay forma posible de probar. No es posible hacerlo en un tiempo razonable. Cualquier código extraño debe estar documentado y revisado. Sin embargo, configurar la tarea específica para garantizar que las puertas traseras no estén presentes requerirá una revisión detallada del código de línea y no garantiza que las puertas traseras no estén presentes.

Difíciles de probar funciones maliciosas bien diseñadas

10,2.5

No hay forma posible de probar. No es posible hacerlo en un tiempo razonable. Cualquier código extraño debe estar documentado y revisado. Sin embargo, configurar la tarea específica para garantizar que las puertas traseras no estén presentes requerirá una revisión detallada del código de línea y no garantiza que las puertas traseras no estén presentes.

Difíciles de probar funciones maliciosas bien diseñadas

13.1.1

Cubierto por 5.2.6 y 5.3.9

12,3

riesgo en el recorrido de la ruta de acceso que cubren otros requisitos existentes del capítulo 5 (Validación, Desinfección y codificación) de ASVS y CASA

12,3

Cubierto por 5.2.6 y 5.3.9

12,3

cubierto por 10.3.2 12.4.1 y 12.4.2

12,5.1

cubierto por 10.3.2 y 12.4.2

12,5.2

cubierto por 10.3.2 12.4.1 y 12.4.2

13,1

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

13,2

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

13,2

Cubierto por 4.2.2

13,2

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

13,3

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

14,4.1

cubierto por 5.3.1

14,4.2

Esta solicitud se cubre con otros requisitos de validación de entrada y, si la falta de validación no introduce una vulnerabilidad real de lógica empresarial, puede ser una gravedad menor. Por ejemplo, si el número de teléfono no se valida correctamente, solo se mostrará de forma inadecuada en la página de información, lo que no implica consecuencias de seguridad directas.

14,4

cubierto por 5.2.7 y 5.3.3

14,4,5

cubierto por 6.2.1 y 9.2.1

14,4.7

cubierto por 12.4.1

14,5.3

cubierto por 14.5.2

2,1

cubierto por 2.1.1

2,1

cubierto por 2.1.1

2.2.3

No es relevante para Casa porque el riesgo está cubierto por otros controles contra la automatización

2.5.6

protegida por otra protección por contraseña

3.1.1

Riesgo bajo de exposición y cobertura de otros controles del ASVS

3.2.1

Riesgo bajo de exposición y cobertura de otros controles del ASVS

3,4.4

Riesgo bajo de exposición y cobertura de otros controles del ASVS

3.4.5

Riesgo bajo de exposición y cobertura de otros controles del ASVS

4.2.1

cubierto por 13.1.4

5.2.8

cobertura de otras comprobaciones de validación de entrada y de limpieza

5,3

cobertura de otras comprobaciones de validación de entrada y de limpieza

7,4.1

cubierto por verificaciones de registros

8,2

cubierto por 8.1.1

9,1

cubierto por 6.2.1 y 9.2.1

1.2.3

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.4.4

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.5.2

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.5.3

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.5.4

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.9.1

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.11.3

cubierto por 1.1.4, 1.8.4 y 1.8.2

1,14.1

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.14.2

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.14.3

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.14.4

cubierto por 1.1.4, 1.8.4 y 1.8.2

1.14.5

cubierto por 1.1.4, 1.8.4 y 1.8.2

1,14,6

cubierto por 1.1.4, 1.8.4 y 1.8.2

6.1.2

Cubierto por 6.1.1

6.1.3

Cubierto por 6.1.1

2,10.2

Cubierto por 2.5.4

2.2.1

Cubierto por 11.1.4

2.7.3

Cubierto por 2.7.2

2.7.4

Cubierto por 2.7.2

5.1.2

Cobertura del control de automatización

6.2.2

algoritmos criptográficos aprobados no definidos

8,2

Cubierto por 8.1.1

9,1

Cubierto por 9.2.1

9,1

Cubierto por 9.2.1

5.5.1

Cubierto por 1.8.2

14,2

Cubierto por 1.14.6

3.3.4

Esto no es así para las aplicaciones que usan AuthN/Z sin estado. Acepta la recomendación del grupo de NCC para quitarla. Esto debe estar cubierto por la versión 3.3.3.

ID de solicitud

Descripción

1.1.4

Verifica la documentación y la justificación de todos los límites de confianza, los componentes y los flujos de datos significativos de la aplicación.

1.8.1

Verifica que todos los datos sensibles estén identificados y clasificados en los niveles de protección

1.8.2

Verifica que todos los niveles de protección tengan un conjunto asociado de requisitos de protección, como requisitos de encriptación, requisitos de integridad, retención, privacidad y otros requisitos de confidencialidad.

aplicada en la arquitectura.

2.1.1

Verifica que las contraseñas configuradas por el usuario tengan al menos 12 caracteres

2,5

Verificar que las cuentas compartidas o predeterminadas no estén presentes (p.ej., "raíz",

“admin” o “sa”).

4.2.1

Verifica que las API y los datos sensibles estén protegidos contra ataques de referencia insegura de objetos directos (IDOR) destinados a crear, leer, actualizar y borrar registros, como crear o actualizar el registro de otra persona, ver los registros de todos o borrar todos los registros.

1,14,6

Verifica que la aplicación no sea compatible, no sea segura o esté obsoleta.

tecnologías del cliente, como complementos NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL, o applets de Java del cliente.