req_id

Comentarios del grupo de trabajo

8.1.6

Se debería reconsiderar este requisito para que sea más práctico (p.ej., las copias de seguridad solo se deben conservar durante un período determinado, se deben supervisar las copias de seguridad para detectar robos o corrupción, se deben auditar las copias de seguridad con regularidad para confirmar su capacidad de volver a la producción). La suposición actual es demasiado amplia y requeriría más definición.

5.1.4

Es un duplicado de otros casos de prueba. Este es un caso de prueba de poco valor y mucho esfuerzo. Se recomienda quitar.

7.3.3

Es un duplicado de otros casos de prueba. Este es un caso de prueba de poco valor y mucho esfuerzo. Se recomienda quitar.

1.2.2

Se quita debido a la cobertura en otra solicitud, como la 4.1.1

2.2.4

Se quitó Req, ya que se incluye en el apartado 4.3.1.

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

evita el uso no autorizado), que abarca la resistencia al robo de identidad contra el phishing en las interfaces de administrador y otras rutas de acceso internas

2.2.5

Se quita porque la mayoría de los CSP no admiten mTLS y la mayoría de los desarrolladores que realizan pruebas 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 como para aplicarse.

2.4.5

Se quitó el requisito en la versión 5 del ASVS, y los algoritmos de hash recomendados en 2.4.1 no cumplen con este requisito.

2.7.5

La prueba no es factible, ya que podría requerir un análisis de los proveedores de OOB externos. El riesgo aquí es bajo, ya que el código de autenticación tiene una duración breve.

2.8.2

El requisito solo es pertinente para las soluciones de MFA personalizadas y también se aborda en los apartados 6.4.2 y 6.4.1.

2.8.5

Se quitó el requisito, ya que también se incluye en el 2.7.6. El registro de intentos fallidos se incluye en el requisito de registro del ASVS.

2.8.6

La OTP física a nivel de la aplicación no es un caso de uso común, esta solicitud es necesaria para las interfaces de administrador. Sin embargo, el requisito 4.3.1 (Verificar que las interfaces administrativas usen la autenticación de varios factores adecuada para evitar el uso no autorizado) abarca la MFA para las interfaces administrativas y cubrirá este riesgo.

2.9.1

Este requisito abarca los dispositivos físicos según el ASVS (las llaves de seguridad criptográficas son tarjetas inteligentes o llaves FIDO, en las que el usuario debe conectar o vincular la

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

dispositivos o software criptográficos, y el dispositivo o software calcula una respuesta basada en un

clave criptográfica almacenada), lo que hace que este requisito quede fuera del alcance de CASA, ya que el riesgo de autenticación de dispositivos físicos se cubre en el punto 4.3.1 para los fines de la MFA (física o de software).

2.9.3

Este requisito abarca los dispositivos físicos según el ASVS (las llaves de seguridad criptográficas son tarjetas inteligentes o llaves FIDO, en las que el usuario debe conectar o vincular la

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

dispositivos o software criptográficos, y el dispositivo o software calcula una respuesta basada en un

clave criptográfica almacenada), lo que hace que este requisito quede fuera del alcance de CASA, ya que el riesgo de autenticación de dispositivos físicos se cubre en el punto 4.3.1 para los fines de la MFA (física o de software).

2.10.1

El requisito contradice el punto 2.10.2.

2.10.3

Se aborda en el punto 2.4.1 (verifica que se use una de las siguientes funciones de hash de contraseñas cuando se almacene la contraseña del usuario para la aplicación: argon2id, scrypt, bcrypt o PBKDF2), que abarca el riesgo de ataques sin conexión y almacenamiento de contraseñas.

2.10.4

Cubierto por el punto 6.4.2: Verifica que el material de la clave no esté expuesto a la aplicación, sino que use un módulo de seguridad aislado, como una bóveda, para las operaciones criptográficas.

3.2.3

Abarca los puntos 3.4.1, 3.4.2 y 3.4.3

3.5.1

El usuario puede revocar tokens a través del proveedor de OAuth

4.3.3

La solicitud está protegida por la MFA para las interfaces de administrador y el acceso con privilegios

5.1.3

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

5.1.4

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

5.3.2

La parte de este requisito que especifica que cada carácter Unicode es válido puede dificultar la prueba. No todas las aplicaciones incluirán un formulario de texto lo suficientemente grande como para contener todos los caracteres Unicode. También hay una falta de compatibilidad con ciertos sistemas operativos y herramientas de hacking para todo el espacio Unicode, lo que impide probar esto incluso si el servidor lo admite. Valor de seguridad cuestionable en general Originalmente, se incluyó 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.6

cubierto por 6.2.4 y 6.2.3

6.3.1

cubierto por 6.2.4 y 6.2.3

6.3.3

cubiertos por otros requisitos de generación de números aleatorios.

7.1.2

Se incluye en la versión 7.1.1

7.1.3

Se incluye en la versión 7.1.1

7.3.1

Se incluye en la versión 7.1.1

7.3.3

Se incluye en la versión 7.1.1

8.1.3

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

8.3.3

No es un requisito verificable, es pertinente para la política de privacidad y las condiciones del servicio, y no se relaciona con la seguridad de la aplicación. Esta es una revisión legal y de cumplimiento, y está fuera del alcance de CASA.

8.3.6

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

8.3.8

cubiertas por 1.8.1, 1.8.2 y 1.1.4

9.2.5

cubiertas por el artículo 8.3.5 y las revisiones de las políticas de registro de la aplicación.

10.1.1

Se incluye en la revisión de 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 se debe documentar y revisar. Sin embargo, establecer la tarea específica para garantizar que no haya puertas traseras requeriría una revisión exhaustiva línea por línea del código y no garantiza que no haya puertas traseras.

Es difícil probar funciones maliciosas bien diseñadas

10.2.4

No hay forma de probarlo. No es posible hacerlo en un tiempo razonable. Cualquier código extraño debe documentarse y revisarse. Sin embargo, establecer la tarea específica para garantizar que no haya puertas traseras requeriría una revisión exhaustiva del código línea por línea y no garantiza que no haya puertas traseras.

Es difícil probar funciones maliciosas bien diseñadas

10.2.5

No hay forma de probarlo. No es posible hacerlo en un tiempo razonable. Cualquier código extraño debe documentarse y revisarse. Sin embargo, establecer la tarea específica para garantizar que no haya puertas traseras requeriría una revisión exhaustiva del código línea por línea y no garantiza que no haya puertas traseras.

Es difícil probar funciones maliciosas bien diseñadas

13.1.1

Cubierto por 5.2.6 y 5.3.9

12.3.1

Riesgo de recorrido de ruta cubierto por otros requisitos existentes del capítulo 5 (Validación, saneamiento y codificación) del ASVS y CASA

12.3.3

Cubierto por 5.2.6 y 5.3.9

12.3.6

Cubierto por 10.3.2, 12.4.1 y 12.4.2

12.5.1

Se incluye en 10.3.2 y 12.4.2

12.5.2

Cubierto por 10.3.2, 12.4.1 y 12.4.2

13.1.5

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

13.2.2

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

13.2.3

Cubierto por el 4.2.2

13.2.5

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

13.3.1

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

14.4.1

cubierto por el 5.3.1

14.4.2

Este requisito se cubre con otros requisitos de validación de entrada. Si la falta de validación no introduce una vulnerabilidad real en la lógica empresarial, la gravedad puede ser menor. Por ejemplo, no validar el número de teléfono correctamente solo genera una visualización incorrecta del número de teléfono en la página de información, lo que no tiene implicaciones directas en la seguridad.

14.4.3

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 el artículo 14.5.2

2.1.5

Cubierto por el 2.1.1

2.1.6

Cubierto por el 2.1.1

2.2.3

No es relevante para la casa, ya que el riesgo se cubre con otros controles anti automatización.

2.5.6

Cubierto por otra protección con contraseña

3.1.1

Bajo riesgo de exposición y cubierto por otros controles de ASVS

3.2.1

Bajo riesgo de exposición y cubierto por otros controles de ASVS

3.4.4

Bajo riesgo de exposición y cubierto por otros controles de ASVS

3.4.5

Bajo riesgo de exposición y cubierto por otros controles de ASVS

4.2.1

cubierto por el artículo 13.1.4

5.2.8

cubiertos por otras verificaciones de validación y limpieza de entradas

5.3.5

cubiertos por otras verificaciones de validación y limpieza de entradas

7.4.1

cubiertas por las verificaciones de registro

8.2.3

cubierto por el requisito 8.1.1

9.1.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 la versión 6.1.1

6.1.3

Cubierto por la versión 6.1.1

2.10.2

Cubierto por el artículo 2.5.4

2.2.1

Cubierto por el 11.1.4

2.7.3

Cubierto por el artículo 2.7.2

2.7.4

Cubierto por el artículo 2.7.2

5.1.2

Cubierto por el control anti automatización

6.2.2

No se definieron los algoritmos criptográficos aprobados.

8.2.1

Cubierto por el 8.1.1

9.1.2

Cubierto por el artículo 9.2.1

9.1.3

Cubierto por el artículo 9.2.1

5.5.1

Cobertura de la versión 1.8.2

14.2.1

Abarca el punto 1.14.6

3.3.4

Esto no se aplica a las aplicaciones que usan AuthN/Z sin estado. Acepta la recomendación de NCC Group para quitar el código. Esto debería estar cubierto por el punto 3.3.3.

req_id

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 se identifiquen y clasifiquen en 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, y que estos

aplicada en la arquitectura.

2.1.1

Verifica que las contraseñas establecidas por el usuario tengan al menos 12 caracteres de longitud.

2.5.4

Verifica que no haya cuentas compartidas o predeterminadas (p.ej., "root",

"admin" o "sa").

4.2.1

Verifica que los datos sensibles y las APIs estén protegidos contra ataques de referencia directa a objetos no seguros (IDOR) dirigidos a la creación, lectura, actualización y eliminación de 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 use funciones no compatibles, inseguras o en desuso.

Tecnologías del cliente, como complementos de NSAPI, Flash, Shockwave y ActiveX

Applets de Java del cliente, Silverlight o NACL