V8.3 security and policy

[elarlang]

#	Description	L1	L2	L3	CWE
8.3.2	[MODIFIED, SPLIT TO 8.3.9] Verify that users have a method to remove their data on demand.	✓	✓	✓	212
8.3.3	Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.	✓	✓	✓
8.3.9	[ADDED, SPLIT FROM 8.3.2] Verify that users have a method to export their data on demand.		✓	✓

Can we say for each requirement, what is the risk to solve? Is it worth a requirement in the ASVS or those are here because they are just from GDPR or similar?

If we want to keep them:

• should we require level 1? 8.3.2 level 1 vs 8.3.9 level 2 do not match well.
• maybe we should have separate policy related/oriented section

edit: cwe 212 is kind of related, but not correct

[tghosth]

I wonder if all of these should be L2 because they are more like regulatory/legal risks and also like defense in depth rather than primary defense.

I think these sort of requirements which are common to data protection legislation, e.g. GDPR or CCPA are worth keeping but with that change in level.

I think we could separate chapter 8 into things which are actually security risks and things which are regulatory/legal risks but I don't think it is critical.

[elarlang]

No clear proposals, just some thoughts for further discussion.

tldr: I think we should stay away from legal requirements.

8.3.2, 8.3.9

• V8.3.2 Verify that users have a method to remove their data on demand.
• V8.3.9 Verify that users have a method to export their data on demand.

Well, those functionalities are quite a juicy target for attackers. I can understand the abstract meaning and reasoning, but it opens up a new level of impact for attacks.

Maybe it's worth special mention for this in the 3.7.1?

#	Description	L1	L2	L3	CWE	NIST §
3.7.1	[MODIFIED] Verify that the application requires re-authentication or secondary verification before allowing highly sensitive transactions or modifications to account profile or authentication settings.	✓	✓	✓	306

Are those requirements realistic - let's take some bank or gov system, you just can not ask it.

8.3.3

• V8.3.3 Verify that users are provided clear language regarding collection and use of supplied personal information and that users have provided opt-in consent for the use of that data before it is used in any way.

Is it actually 2 requirements?

Verify that users are provided clear language regarding collection

Is this part testable (what is a "clear language")? Is it a bit too much just a policy?

The abstract goal here can be, that the application must not collect (sensitive) data that it does not need, and it should be analyzed via:

• V1.8.1 Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.
• V1.8.2 Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.

Verify that users have provided opt-in consent for the use of that data before it is used in any way.

How we are going to test it? It is written somewhere in a big condition document and it's verified?

ping @tghosth

[tghosth]

tldr: I think we should stay away from legal requirements.

I don't see a problem with some high-level requirements as long as they are implementable/testable.

Well, those functionalities are quite a juicy target for attackers. I can understand the abstract meaning and reasoning, but it opens up a new level of impact for attacks.

Maybe it's worth special mention for this in the 3.7.1?

I think it could already be considered to be covered in 3.7.1. We don't enumerate every possibility there.

Are those requirements realistic - let's take some bank or gov system, you just can not ask it.

Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.

Is it actually 2 requirements?

I think it is one requirement because they are opting in to whatever is described in the wording it talks about.

Is this part testable (what is a "clear language")? Is it a bit too much just a policy?

I agree that is subjective and unhelpful and would recommend removing.

How we are going to test it? It is written somewhere in a big condition document and it's verified?

For testing opt in, you just have to make sure that users have to explicitly agree to it, should be pretty easy.

[elarlang]

Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.

No. The topic is:

• V8.3.2 Verify that users have a method to remove their data on demand.
• V8.3.9 Verify that users have a method to export their data on demand.

Is it always realistic to ask removing your data and export all your data. I don't think so.

If it is available as functionality, it is so critical piece, that it is worth special mentioning in 3.7.1.

[tghosth]

Reauthentication? Definitely realistic. My bank makes me enter in an SMS code every time I want to do some sort of money transfer.

No. The topic is:

* V8.3.2 Verify that users have a method to remove their data on demand.

* V8.3.9 Verify that users have a method to export their data on demand.

Is it always realistic to ask removing your data and export all your data. I don't think so.

If it is available as functionality, it is so critical piece, that it is worth special mentioning in 3.7.1.

Ah ok, I understand better what you mean now. I think that privacy legislation still applies to government bodies except in certain circumstances, for example:

• https://www.compliancejunction.com/who-is-exempt-from-gdpr-requirements/

It definitely applies for financial institutions.

As such I think it is almost always valid to expect that.

[elarlang]

option 1 - cleanup

Back to the beginning:

Can we say for each requirement, what is the risk to solve?

If there is no clear answer, we should remove it.

Also, we have an agreement

• do not have requirements just because they belong to some policy
• to reduce the amount of requirements

I'm really not convinced we need those requirements in ASVS.

option 2 - update

If you are still sure you want to keep them:

• need for re-auth for data export is worth special mention in 3.7.1
• 8.3.3 needs improvement, remove the "clear language" part
• level 2 for 8.3.2
• I don't think CWE-212 is suitable for 8.3.2
• considerations to have separate policy-oriented requirements - but it is already against the logic to not have them at all

ping @tghosth

[tghosth]

Following discussion with @elarlang, reduce to Level 3 since this is not a protective control as such but rather a risk reduction mechanism.

[tghosth]

@set-reminder 10 mins josh to look at

[octo-reminder]

⏰ Reminder
Wednesday, April 17, 2024 3:42 PM (GMT+02:00)

josh to look at

[octo-reminder]

🔔 @tghosth

josh to look at

[tghosth]

Opened #1931

Changes:

• I made them level 3
• I cleaned up 8.3.3
• I removed CWE 212
• I added some guidance to 3.7.1