req_id

Working Group Feedback

8.1.6

Would reconsider this Requirement to be something more actionable (e.g. Backups should only be retained for X amount of time, Backups should be monitored for theft/corruption, Backups should be regularly audited to confirm their ability to be moved back into production). The current assumption is too broad and would need more definition.

5.1.4

Duplicate of other test cases. This is a high effort low value test case. Recommended to remove.

7.3.3

Duplicate of other test cases. This is a high effort low value test case. Recommended to remove.

1.2.2

remove due to coverage in other req such as 4.1.1

2.2.4

Remove Req as it is covered by 4.3.1

(4.3.1 Verify administrative interfaces use appropriate multi-factor authentication to

prevent unauthorized use.) which covers impersonation resistance against phishing in admin interfaces and other internal access paths

2.2.5

Remove as mTLS is not supported by most CSPs, also the majority of developer tested for CASA will use password based authentication

2.4.3

The standard as written is not specific enough to be enforceable

2.4.5

Requirement removed in V5 of the ASVS and the recommended hashing algorithms in 2.4.1 can't meet this requirement

2.7.5

Testing infeasible as it might require an analysis of 3rd party OOB providers, the risk here is low as the authentication code is short lived.

2.8.2

requirement is only relevant to custom MFA solutions, also covered by 6.4.2 and 6.4.1

2.8.5

Remove requirement as it is covered by 2.7.6 additionally logging failed attempts is covered by the logging requirement of the ASVS

2.8.6

Physical OTP at the application level is not a common use case, this req is needed for admin interfaces. However req 4.3.1 (Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.) covers MFA for admin interfaces and will cover this risk

2.9.1

This requirement covers physical devices according to the ASVS (Cryptographic security keys are smart cards or FIDO keys, where the user has to plug in or pair the

cryptographic device to the computer to complete authentication. Verifiers send a challenge nonce to the

cryptographic devices or software, and the device or software calculates a response based upon a securely

stored cryptographic key.) making this requirement out of scope of CASA as physical devices authentication risk is covered by 4.3.1 for the purpose of MFA (Physical or software)

2.9.3

This requirement covers physical devices according to the ASVS (Cryptographic security keys are smart cards or FIDO keys, where the user has to plug in or pair the

cryptographic device to the computer to complete authentication. Verifiers send a challenge nonce to the

cryptographic devices or software, and the device or software calculates a response based upon a securely

stored cryptographic key.) making this requirement out of scope of CASA as physical devices authentication risk is covered by 4.3.1 for the purpose of MFA (Physical or software)

2.10.1

Requirement is a contradiction of 2.10.2

2.10.3

Covered by 2.4.1 (Verify that one of the following password hashing functions is used when storing the user's password for the application: argon2id, scrypt, bcrypt or PBKDF2) which covers the risk of offline attacks and password storage.

2.10.4

Covered by 6.4.2 Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations.

3.2.3

Covered by 3.4.1, 3.4.2 and 3.4.3

3.5.1

User can revoke tokens via the OAuth provider

4.3.3

Req is covered by MFA for admin interfaces and privileged access

5.1.3

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

5.1.4

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

5.3.2

The part of this requirement that specifies every unicode character is valid can make it challenging to test. Not every application will include a text form large enough to fit every unicode character into it. There is also a lack of support for certain operating systems and hacking tools for the entire unicode space making you unable to test this even if the server supports it. Questionable security value overall. Was originally included in beta but was removed due to issues in testing.

6.2.5

covered by 6.2.4 and 6.2.3

6.2.6

covered by 6.2.4 and 6.2.3

6.3.1

covered by 6.2.4 and 6.2.3

6.3.3

covered by other random number generating requirements.

7.1.2

covered by 7.1.1

7.1.3

covered by 7.1.1

7.3.1

covered by 7.1.1

7.3.3

covered by 7.1.1

8.1.3

It's difficult to describe what's an acceptable or necessary parameter. Not a testable case. What constitutes necessary? How will we determine if an exception is valid? Considered out of scope for CASA

8.3.3

Not a testable requirement, relevant to privacy policy and terms of services and not the application security. This is a legal and compliance review and is out of scope of CASA

8.3.6

Control is system specific (windows/linux variant) and device specific and in most cases not application control.

8.3.8

covered by 1.8.1, 1.8.2, and 1.1.4

9.2.5

covered by 8.3.5 and logging policies reviews of the application.

10.1.1

Covered by architecture review and is a recommended best practice. Requirement is not testable

10.2.3

Not possible to do in a reasonable amount of time. Any weird code should be documented and reviewed, however setting the specific task to ensure that backdoors are not present would require an in depth line by line code review and does not guarantee that backdoors are not present.

Difficult to test for well designed malicious functions

10.2.4

No possible way to test. Not possible to do in a reasonable amount of time. Any weird code should be documented and reviewed, however setting the specific task to ensure that backdoors are not present would require an in depth line by line code review and does not guarantee that backdoors are not present.

Difficult to test for well designed malicious functions

10.2.5

No possible way to test. Not possible to do in a reasonable amount of time. Any weird code should be documented and reviewed, however setting the specific task to ensure that backdoors are not present would require an in depth line by line code review and does not guarantee that backdoors are not present.

Difficult to test for well designed malicious functions

13.1.1

Covered by 5.2.6 and 5.3.9

12.3.1

path traversal risk covered by other existing requirements from chapter 5 (Validation, Sanitization and Encoding) of the ASVS and CASA

12.3.3

Covered by 5.2.6 and 5.3.9

12.3.6

covered by 10.3.2 12.4.1 and 12.4.2

12.5.1

covered by 10.3.2 and 12.4.2

12.5.2

covered by 10.3.2 12.4.1 and 12.4.2

13.1.5

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

13.2.2

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

13.2.3

Covered by 4.2.2

13.2.5

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

13.3.1

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

14.4.1

covered by 5.3.1

14.4.2

This req covered by other input validation requirements and If lack of validation does not introduce an actual business logic vulnerability, then this can be a lower severity. Example being not validating the phone number properly results in only the improper display of the phone number on the info page, which does not have direct security implications.

14.4.3

covered by 5.2.7 and 5.3.3

14.4.5

covered by 6.2.1 and 9.2.1

14.4.7

covered by 12.4.1

14.5.3

covered by 14.5.2

2.1.5

covered by 2.1.1

2.1.6

covered by 2.1.1

2.2.3

Not relevant to casa as the risk is covered by other anti automation controls

2.5.6

covered by other password protection

3.1.1

Low risk of exposure and covered by other controls of the ASVS

3.2.1

Low risk of exposure and covered by other controls of the ASVS

3.4.4

Low risk of exposure and covered by other controls of the ASVS

3.4.5

Low risk of exposure and covered by other controls of the ASVS

4.2.1

covered by 13.1.4

5.2.8

covered by other input validation and sanitization checks

5.3.5

covered by other input validation and sanitization checks

7.4.1

covered by logging checks

8.2.3

covered by 8.1.1

9.1.1

covered by 6.2.1 and 9.2.1

1.2.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.4.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.2

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.5.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.9.1

covered by 1.1.4, 1.8.4 and 1.8.2

1.11.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.1

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.2

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.3

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.4

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.5

covered by 1.1.4, 1.8.4 and 1.8.2

1.14.6

covered by 1.1.4, 1.8.4 and 1.8.2

6.1.2

Covered by 6.1.1

6.1.3

Covered by 6.1.1

2.10.2

Covered by 2.5.4

2.2.1

Covered by 11.1.4

2.7.3

Covered by 2.7.2

2.7.4

Covered by 2.7.2

5.1.2

Covered by Anti Automation Control

6.2.2

approved cryptographic algorithms not defined

8.2.1

Covered by 8.1.1

9.1.2

Covered by 9.2.1

9.1.3

Covered by 9.2.1

5.5.1

Covered by 1.8.2

14.2.1

Covered by 1.14.6

3.3.4

This is not true for applications using stateless AuthN/Z. Agree with NCC Group's recommendation to remove. This should be covered by 3.3.3

req_id

Description

1.1.4

Verify documentation and justification of all the application's trust boundaries, components, and significant data flows.

1.8.1

Verify that all sensitive data is identified and classified into protection levels

1.8.2

Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are

applied in the architecture.

2.1.1

Verify that user set passwords are at least 12 characters in length

2.5.4

Verify shared or default accounts are not present (e.g. "root",

"admin", or "sa").

4.2.1

Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.

1.14.6

Verify the application does not use unsupported, insecure, or deprecated

client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX,

Silverlight, NACL, or client-side Java applets.