req_id [id_req]

Commentaires sur le groupe de travail

8.1.6

Cette exigence devrait être considérée comme plus concrète (par exemple, les sauvegardes ne doivent être conservées que pendant X fois, les surveillances doivent être surveillées pour détecter tout vol ou toute corruption, et les sauvegardes doivent être régulièrement auditées pour confirmer leur capacité à revenir en production). L'hypothèse actuelle est trop large et nécessiterait davantage de définition.

5.1.4

Doublon d'autres scénarios de test. Il s'agit d'un scénario de test peu coûteux. Recommandé pour supprimer.

7.3.3

Doublon d'autres scénarios de test. Il s'agit d'un scénario de test peu coûteux. Recommandé pour supprimer.

1.2.2

supprimer en raison d'une autre exigence comme la version 4.1.1

2.2.4

Supprimer Req car il est couvert par 4.3.1

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

empêcher l'utilisation non autorisée.) qui couvre la résistance à l'usurpation d'identité 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 fournisseurs de services cloud. 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 suffisamment spécifique pour être appliquée.

2.4.5

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

2.7.5

Les tests n'étant pas réalisables, car il pourrait nécessiter une analyse de fournisseurs OOB tiers, le risque présenté ici est faible, car le code d'authentification est de courte durée.

2.8.2

n'est pertinente que pour les solutions MFA personnalisées, également couvertes par 6.4.2 et 6.4.1

2.8.5

Supprimer l'exigence couverte par l'étape 2.7.6 En outre, l'enregistrement des tentatives infructueuses est couvert par l'exigence de journalisation de l'ASVS

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. Cependant, la condition 4.3.1 (vérifier que les interfaces d'administration utilisent une authentification multifacteur appropriée afin d'empêcher toute utilisation non autorisée) couvre la MFA pour les interfaces d'administration et couvrira ce risque.

2.9.1

Cette exigence concerne les appareils physiques conformément à la norme ASVS. (Les clés de sécurité cryptographiques sont des cartes à puce ou des clés FIDO, dans lesquelles l'utilisateur doit brancher ou associer les

à l'ordinateur pour terminer l'authentification. Les vérificateurs envoient un défi nonce à la méthode

des appareils ou des logiciels cryptographiques, et l'appareil ou le logiciel calcule une réponse en fonction d'un

clé cryptographique stockée.) qui rend cette exigence non applicable au CASA, car le risque d'authentification des appareils physiques est couvert par la norme 4.3.1 aux fins du MFA (physique ou logiciel).

2.9.3

Cette exigence concerne les appareils physiques conformément à la norme ASVS. (Les clés de sécurité cryptographiques sont des cartes à puce ou des clés FIDO, dans lesquelles l'utilisateur doit brancher ou associer les

à l'ordinateur pour terminer l'authentification. Les vérificateurs envoient un défi nonce à la méthode

des appareils ou des logiciels cryptographiques, et l'appareil ou le logiciel calcule une réponse en fonction d'un

clé cryptographique stockée.) qui rend cette exigence non applicable au CASA, car le risque d'authentification des appareils physiques est couvert par la norme 4.3.1 aux fins du MFA (physique ou logiciel).

2.10.1

Cette exigence est une contradiction de la version 2.10.2

2.10.3

Couvert 2.4.1 (vérifiez que l'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 les risques d'attaques hors connexion et de stockage des mots de passe.

2.10.4

Couvert par la section 6.4.2 : vérifier que le matériel de clé n'est pas exposé à l'application, mais utilise un module de sécurité isolé comme un coffre-fort pour les opérations de chiffrement

3,2.3

Couverts par les versions 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

Requête couverte par MFA pour 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la sécurité.

5.3.2

La partie de cette exigence qui spécifie que chaque caractère Unicode est valide peut compliquer le test. Toutes les applications n'incluent pas un format de texte suffisamment grand pour y insérer tous les caractères Unicode. De plus, certains systèmes d'exploitation et outils de piratage ne sont pas compatibles avec l'intégralité de l'espace Unicode. Par conséquent, vous ne pouvez pas le tester même si le serveur le permet. Valeur de sécurité contestable dans l'ensemble. A été initialement inclus en version bêta, mais a été supprimé en raison de problèmes lors des tests.

6,2.5

couverts par 6.2.4 et 6.2.3

6,2.6

couverts par 6.2.4 et 6.2.3

6.3.1

couverts par 6.2.4 et 6.2.3

6.3.3

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

7.1.2

couverts par la version 7.1.1

7,1.3

couverts par la version 7.1.1

7.3.1

couverts par la version 7.1.1

7.3.3

couverts par la version 7.1.1

8.1.3

Il est difficile de décrire ce qu'est un paramètre acceptable ou nécessaire. Il ne s'agit pas d'un scénario pouvant être testé. Qu'est-ce qui est nécessaire ? Comment déterminer si une exception est valide ? Hors du champ d'application de la CASA

8.3.3

Cette condition ne peut pas être testée, mais elle est pertinente pour les règles de confidentialité et les conditions d'utilisation, et non pour la sécurité des applications. Il s'agit d'un examen juridique et de conformité qui n'entre pas dans le champ d'application de la loi CASA

8.3.6

Le contrôle est propre au système (variante Windows/Linux) et à l'appareil. Dans la plupart des cas, il ne s'agit pas du contrôle de l'application.

8.3.8

couvertes par 1.8.1, 1.8.2 et 1.1.4

9,2.5

couverts par la version 8.3.5 et des examens des règles d'enregistrement de l'application.

10.1.1

Elle est examinée par l'architecture et constitue une bonne pratique recommandée. Condition non vérifiable

10.2.3

Nous ne pouvons pas le faire dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Cependant, définir la tâche spécifique pour garantir que les portes dérobées ne sont pas présentes nécessite un examen détaillé ligne par code et ne garantit pas l'absence de portes dérobées.

Il est difficile de tester des fonctions malveillantes bien conçues

10.2.4

Aucun moyen de tester. Nous ne pouvons pas le faire dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Cependant, définir la tâche spécifique pour garantir que les portes dérobées ne sont pas présentes nécessite un examen approfondi du code ligne par ligne et ne garantit pas l'absence de portes dérobées.

Il est difficile de tester des fonctions malveillantes bien conçues

10,2.5

Aucun moyen de tester. Nous ne pouvons pas le faire dans un délai raisonnable. Tout code étrange doit être documenté et examiné. Cependant, définir la tâche spécifique pour garantir que les portes dérobées ne sont pas présentes nécessite un examen approfondi du code ligne par ligne et ne garantit pas l'absence de portes dérobées.

Il est difficile de tester des fonctions malveillantes bien conçues

13.1.1

Couverts par les sections 5.2.6 et 5.3.9

12.3.1

risque de balayage traversé par d'autres exigences du chapitre 5 (Validation, assainissement et encodage) de l'ASVS et de la CASA

12.3.3

Couverts par les sections 5.2.6 et 5.3.9

12.3.6

couverts par 10.3.2 12.4.1 et 12.4.2

12.5.1

couverts par 10.3.2 et 12.4.2

12.5.2

couverts par 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la sécurité.

13.2.3

Couverte par la version 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la sécurité.

14.4.1

couvert par la version 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 une véritable faille de logique métier, il peut s'agir d'une gravité plus faible. Par exemple, si vous ne validez pas le numéro de téléphone correctement, vous n'obtiendrez que son affichage incorrect sur la page d'informations, ce qui n'aura pas de conséquences directes sur la sécurité.

14.4.3

couverts par 5.2.7 et 5.3.3

14,4.5

couverts par 6.2.1 et 9.2.1

14.4.7

couvert par la version 12.4.1

14.5.3

couverts par la version 14.5.2

2.1.5

couverts par la version 2.1.1

2.1.6

couverts par la version 2.1.1

2.2.3

Ne concerne pas la casa, car le risque est couvert par d'autres contrôles antiautomatisation

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 du programme ASVS

3.2.1

Faible risque d'exposition et couvert par d'autres contrôles du programme ASVS

3,4.4

Faible risque d'exposition et couvert par d'autres contrôles du programme ASVS

3.4.5

Faible risque d'exposition et couvert par d'autres contrôles du programme ASVS

4.2.1

couverts par l'article 13.1.4

5.2.8

couvertes par d'autres vérifications de validation et d'assainissement des entrées

5,3,5

couvertes par d'autres vérifications de validation et d'assainissement des entrées

7.4.1

couvertes par les vérifications de journalisation

8.2.3

couverts par 8.1.1

9.1.1

couverts par 6.2.1 et 9.2.1

1.2.3

couverts par 1.1.4, 1.8.4 et 1.8.2

1.4.4

couverts par 1.1.4, 1.8.4 et 1.8.2

1.5.2

couverts par 1.1.4, 1.8.4 et 1.8.2

1.5.3

couverts par 1.1.4, 1.8.4 et 1.8.2

1.5.4

couverts par 1.1.4, 1.8.4 et 1.8.2

1.9.1

couverts par 1.1.4, 1.8.4 et 1.8.2

1.11.3

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.1

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.2

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.3

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.4

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.5

couverts par 1.1.4, 1.8.4 et 1.8.2

1.14.6

couverts par 1.1.4, 1.8.4 et 1.8.2

6.1.2

Couvert par la version 6.1.1

6.1.3

Couvert par la version 6.1.1

2.10.2

Couvert par la version 2.5.4

2.2.1

Couverte par l'article 11.1.4

2.7.3

Couvert par la version 2.7.2

2.7.4

Couvert par la version 2.7.2

5.1.2

Couvert par le contrôle anti-automatisation

6.2.2

algorithmes cryptographiques approuvés non définis

8.2.1

Couvert par la version 8.1.1

9,1.2

Couvert par la version 9.2.1

9,1.3

Couvert par la version 9.2.1

5.5.1

Couverte par la version 1.8.2

14.2.1

Couverte par la version 1.14.6

3.3.4

Cela n'est pas vrai pour les applications utilisant AuthN/Z sans état. Accepter la recommandation du groupe NCC à supprimer. Cela devrait être couvert par la version 3.3.3

req_id [id_req]

Description

1.1.4

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

1.8.1

Vérifier que toutes les données sensibles sont identifiées et classées par 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 des exigences de chiffrement, d'intégrité, de conservation, de confidentialité et d'autres exigences de confidentialité, et qu'elles sont

appliquée dans l'architecture.

2.1.1

Vérifiez que la longueur des mots de passe définis par l'utilisateur est supérieure ou égale à 12 caractères

2,5.4

Vérifiez que les comptes partagés ou par défaut sont absents (par exemple, "root").

"admin" ou "sa").

4.2.1

Vérifiez que les données sensibles et les API sont protégées contre les attaques IDOR (Non-Secure Direct Object Reference) visant à créer, lire, mettre à jour et supprimer des enregistrements, comme par exemple la création ou la mise à jour d'un enregistrement d'une autre personne, la consultation des enregistrements de tous les utilisateurs ou la suppression de tous les enregistrements.

1.14.6

Vérifier que l'application n'utilise pas d'éléments non compatibles, non sécurisés ou obsolètes

les technologies côté client comme les plug-ins NSAPI, Flash, Shockwave et ActiveX ;

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