req_id

Commentaires du groupe de travail

8.1.6

Reconsidérez cette exigence pour qu'elle soit plus concrète (par exemple, les sauvegardes ne doivent être conservées que pendant une durée X, les sauvegardes doivent être surveillées pour détecter tout vol/toute corruption, les sauvegardes doivent être régulièrement auditées pour confirmer leur capacité à être remises en production). L'hypothèse actuelle est trop large et nécessite plus de définition.

5.1.4

Duplicata d'autres scénarios de test. Il s'agit d'un scénario de test à faible valeur ajoutée et nécessitant beaucoup d'efforts. Il est recommandé de le supprimer.

7.3.3

Duplicata d'autres scénarios de test. Il s'agit d'un scénario de test à faible valeur ajoutée et nécessitant beaucoup d'efforts. Il est recommandé de le supprimer.

1.2.2

Supprimer en raison de la couverture dans d'autres exigences telles que 4.1.1

2.2.4

Supprimer la demande, car elle est couverte par la section 4.3.1

(4.3.1 Vérifiez que les interfaces d'administration utilisent une authentification multifacteur appropriée pour

empêcher toute utilisation non autorisée), qui couvre la résistance à l'usurpation d'identité contre le hameçonnage dans les interfaces d'administration et les autres chemins d'accès internes.

2.2.5

Supprimer, car mTLS n'est pas compatible avec la plupart des CSP. De plus, la majorité des développeurs testés pour CASA utiliseront l'authentification par mot de passe.

2.4.3

La norme telle qu'elle est rédigée n'est pas assez précise pour être applicable.

2.4.5

Exigence supprimée dans la version 5 de l'ASVS et les algorithmes de hachage recommandés dans la section 2.4.1 ne peuvent pas répondre à cette exigence

2.7.5

Le test est impossible, car il peut nécessiter une analyse des fournisseurs OOB tiers. Le risque est faible, car le code d'authentification est éphémère.

2.8.2

Cette exigence ne concerne que les solutions MFA personnalisées, également couvertes par les sections 6.4.2 et 6.4.1.

2.8.5

Supprimer l'exigence, car elle est déjà couverte par la section 2.7.6. De plus, l'exigence de journalisation de l'ASVS couvre la journalisation des tentatives infructueuses.

2.8.6

L'OTP physique au niveau de l'application n'est pas un cas d'utilisation courant. Cette exigence est nécessaire pour les interfaces d'administration. Toutefois, l'exigence 4.3.1 (Vérifier que les interfaces d'administration utilisent une authentification multifacteur appropriée pour empêcher toute utilisation non autorisée) couvre l'authentification multifacteur pour les interfaces d'administration et couvrira ce risque.

2.9.1

Cette exigence couvre les appareils physiques conformément à la norme ASVS (les clés de sécurité cryptographiques sont des cartes à puce ou des clés FIDO, où l'utilisateur doit brancher ou associer la

un dispositif cryptographique à l'ordinateur pour terminer l'authentification. Les validateurs envoient un nonce de challenge au

des dispositifs ou logiciels de chiffrement, et le dispositif ou logiciel calcule une réponse basée sur un

(clé cryptographique stockée), ce qui rend cette exigence hors du champ d'application de CASA, car le risque d'authentification des appareils physiques est couvert par la section 4.3.1 pour l'authentification multifacteur (physique ou logicielle).

2.9.3

Cette exigence couvre les appareils physiques conformément à la norme ASVS (les clés de sécurité cryptographiques sont des cartes à puce ou des clés FIDO, où l'utilisateur doit brancher ou associer la

un dispositif cryptographique à l'ordinateur pour terminer l'authentification. Les validateurs envoient un nonce de challenge au

des dispositifs ou logiciels de chiffrement, et le dispositif ou logiciel calcule une réponse basée sur un

(clé cryptographique stockée), ce qui rend cette exigence hors du champ d'application de CASA, car le risque d'authentification des appareils physiques est couvert par la section 4.3.1 pour l'authentification multifacteur (physique ou logicielle).

2.10.1

L'exigence est en contradiction avec le point 2.10.2

2.10.3

Couvert par 2.4.1 (Vérifiez qu'une des fonctions de hachage de mot de passe suivantes est utilisée lors du stockage du mot de passe de l'utilisateur pour l'application : argon2id, scrypt, bcrypt ou PBKDF2), qui couvre le risque d'attaques hors connexion et de stockage de mot de passe.

2.10.4

Couvert par 6.4.2 : vérifiez que le matériel clé n'est pas exposé à l'application, mais qu'il utilise plutôt un module de sécurité isolé tel qu'un coffre-fort pour les opérations de chiffrement.

3.2.3

Couvert par les sections 3.4.1, 3.4.2 et 3.4.3

3.5.1

L'utilisateur peut révoquer les jetons via le fournisseur OAuth

4.3.3

La MFA couvre les interfaces d'administration et l'accès privilégié.

5.1.3

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

5.1.4

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

5.3.2

La partie de cette exigence qui spécifie que chaque caractère Unicode est valide peut rendre les tests difficiles. Toutes les applications n'incluent pas un formulaire de texte suffisamment grand pour contenir tous les caractères Unicode. De plus, certains systèmes d'exploitation et outils de piratage ne sont pas compatibles avec l'ensemble de l'espace Unicode, ce qui vous empêche de tester cette fonctionnalité même si le serveur la prend en charge. Valeur de sécurité globale discutable. Initialement inclus dans la version bêta, il a été supprimé en raison de problèmes lors des tests.

6.2.5

couvertes par les sections 6.2.4 et 6.2.3

6.2.6

couvertes par les sections 6.2.4 et 6.2.3

6.3.1

couvertes par les sections 6.2.4 et 6.2.3

6.3.3

couverts par d'autres exigences de génération de nombres aléatoires.

7.1.2

couvert par la section 7.1.1

7.1.3

couvert par la section 7.1.1

7.3.1

couvert par la section 7.1.1

7.3.3

couvert par la section 7.1.1

8.1.3

Il est difficile de décrire ce qu'est un paramètre acceptable ou nécessaire. Cas non testable. Qu'est-ce qui constitue une nécessité ? Comment déterminerons-nous si une exception est valide ? Hors champ d'application de CASA

8.3.3

Exigence non testable, liée aux règles de confidentialité et aux conditions d'utilisation, et non à la sécurité de l'application. Il s'agit d'un examen juridique et de conformité qui ne relève pas du champ d'application de CASA.

8.3.6

Le contrôle est spécifique au système (variante Windows/Linux) et à l'appareil, et dans la plupart des cas, il ne s'agit pas d'un contrôle d'application.

8.3.8

couvertes par les sections 1.8.1, 1.8.2 et 1.1.4

9.2.5

couvertes par les sections 8.3.5 et les règles de journalisation de l'application.

10.1.1

Couvert par l'examen de l'architecture et recommandé. Exigence non testable

10.2.3

Impossible à faire dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Toutefois, la définition de la tâche spécifique visant à s'assurer qu'il n'y a pas de backdoor nécessiterait un examen approfondi du code ligne par ligne et ne garantit pas l'absence de backdoor.

Difficile de tester les fonctions malveillantes bien conçues

10.2.4

Aucun moyen de tester. Impossible à réaliser dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Toutefois, la définition de la tâche spécifique visant à s'assurer qu'il n'y a pas de backdoor nécessiterait un examen approfondi du code ligne par ligne et ne garantit pas l'absence de backdoor.

Difficile de tester les fonctions malveillantes bien conçues

10.2.5

Aucun moyen de tester. Impossible à réaliser dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Toutefois, la définition de la tâche spécifique visant à s'assurer qu'il n'y a pas de backdoor nécessiterait un examen approfondi du code ligne par ligne et ne garantit pas l'absence de backdoor.

Difficile de tester les fonctions malveillantes bien conçues

13.1.1

Couvert par les sections 5.2.6 et 5.3.9

12.3.1

Risque de traversée de répertoire couvert par d'autres exigences existantes du chapitre 5 (Validation, assainissement et encodage) de l'ASVS et de CASA

12.3.3

Couvert par les sections 5.2.6 et 5.3.9

12.3.6

couvertes par les sections 10.3.2, 12.4.1 et 12.4.2

12.5.1

couvertes par les sections 10.3.2 et 12.4.2

12.5.2

couvertes par les sections 10.3.2, 12.4.1 et 12.4.2

13.1.5

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

13.2.2

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

13.2.3

Couvert par 4.2.2

13.2.5

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

13.3.1

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

14.4.1

couvert par la section 5.3.1

14.4.2

Cette exigence est couverte par d'autres exigences de validation des entrées. Si l'absence de validation n'introduit pas de véritable faille de logique métier, la gravité peut être inférieure. Par exemple, si le numéro de téléphone n'est pas validé correctement, il ne s'affichera pas correctement sur la page d'informations, ce qui n'a pas d'implications directes en termes de sécurité.

14.4.3

couvertes par les sections 5.2.7 et 5.3.3

14.4.5

couvertes par les sections 6.2.1 et 9.2.1

14.4.7

couvert par la section 12.4.1

14.5.3

couvert par la section 14.5.2

2.1.5

couvert par la section 2.1.1

2.1.6

couvert par la section 2.1.1

2.2.3

Sans rapport avec Casa, car le risque est couvert par d'autres contrôles anti-automatisation

2.5.6

couvert par une autre protection par mot de passe ;

3.1.1

Faible risque d'exposition et couvert par d'autres contrôles de l'ASVS

3.2.1

Faible risque d'exposition et couvert par d'autres contrôles de l'ASVS

3.4.4

Faible risque d'exposition et couvert par d'autres contrôles de l'ASVS

3.4.5

Faible risque d'exposition et couvert par d'autres contrôles de l'ASVS

4.2.1

couvert par la section 13.1.4

5.2.8

couverts par d'autres vérifications de validation et de nettoyage des entrées.

5.3.5

couverts par d'autres vérifications de validation et de nettoyage des entrées.

7.4.1

couverts par les vérifications de journalisation.

8.2.3

couvert par la section 8.1.1

9.1.1

couvertes par les sections 6.2.1 et 9.2.1

1.2.3

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.4.4

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.5.2

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.5.3

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.5.4

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.9.1

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.11.3

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.1

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.2

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.3

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.4

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.5

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

1.14.6

couvertes par les sections 1.1.4, 1.8.4 et 1.8.2

6.1.2

Couvert par la section 6.1.1

6.1.3

Couvert par la section 6.1.1

2.10.2

Couvert par la section 2.5.4

2.2.1

Couvert par 11.1.4

2.7.3

Couvert par 2.7.2

2.7.4

Couvert par 2.7.2

5.1.2

Couvert par le contrôle anti-automatisation

6.2.2

Algorithmes de chiffrement approuvés non définis

8.2.1

Couvert par 8.1.1

9.1.2

Couvert par la section 9.2.1

9.1.3

Couvert par la section 9.2.1

5.5.1

Couvert par la version 1.8.2

14.2.1

Couvert par la section 1.14.6

3.3.4

Cela ne s'applique pas aux applications utilisant l'authentification/autorisation sans état. Acceptez la recommandation de suppression du groupe NCC. Cela devrait être couvert par la section 3.3.3.

req_id

Description

1.1.4

Vérifiez la documentation et la justification de toutes les limites de confiance, de tous les composants et de tous les flux de données importants de l'application.

1.8.1

Vérifiez que toutes les données sensibles sont identifiées et classées selon des niveaux de protection.

1.8.2

Vérifiez que tous les niveaux de protection sont associés à un ensemble d'exigences de protection, telles que les exigences de chiffrement, les exigences d'intégrité, les exigences de conservation, de confidentialité et autres exigences de confidentialité, et que celles-ci sont

appliquée dans l'architecture.

2.1.1

Vérifiez que les mots de passe définis par les utilisateurs comportent au moins 12 caractères.

2.5.4

Vérifiez qu'aucun compte partagé ou par défaut n'est présent (par exemple, "root",

"admin" ou "sa").

4.2.1

Vérifiez que les données et les API sensibles sont protégées contre les attaques par référence directe à un objet non sécurisée (IDOR) ciblant la création, la lecture, la mise à jour et la suppression d'enregistrements, comme la création ou la mise à jour de l'enregistrement d'une autre personne, la consultation des enregistrements de tous les utilisateurs ou la suppression de tous les enregistrements.

1.14.6

Vérifiez que l'application n'utilise pas de fonctionnalités non compatibles, non sécurisées ou obsolètes.

technologies côté client telles que les plug-ins NSAPI, Flash, Shockwave, ActiveX,

Silverlight, NACL ou applets Java côté client.