Closed elarlang closed 3 months ago
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.
No clear proposals, just some thoughts for further discussion.
tldr: I think we should stay away from legal requirements.
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.
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:
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
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.
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:
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.
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:
It definitely applies for financial institutions.
As such I think it is almost always valid to expect that.
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
I'm really not convinced we need those requirements in ASVS.
If you are still sure you want to keep them:
ping @tghosth
Following discussion with @elarlang, reduce to Level 3 since this is not a protective control as such but rather a risk reduction mechanism.
@set-reminder 10 mins josh to look at
⏰ Reminder Wednesday, April 17, 2024 3:42 PM (GMT+02:00)
josh to look at
🔔 @tghosth
josh to look at
Opened #1931
Changes:
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:
maybe we should have separate policy related/oriented section
edit: cwe 212 is kind of related, but not correct