NIST for 2.3.4

[tghosth]

@csfreak92 said he would confirm the ~~CWE~~ NIST mapping for this requirement as discussed here: https://github.com/OWASP/ASVS/pull/1263#issuecomment-1113002285

[elarlang]

is it actually closed and merged already?

[tghosth]

I think I meant the NIST mapping 🤦‍♂️

[csfreak92]

Well, to be fair... CWE mapping needs a second look too.

[tghosth]

CWE is a whole other thing, let's worry about NIST for now. If you can do it then great but I think I will mark this as not critical for 5.0

[csfreak92]

Hi @tghosth, can you please assign this to me so that it doesn't go off my radar? I keep forgetting it. Thanks!

[csfreak92]

@tghosth, what if in NIST there is nothing that explicitly says anything about an administrator setting up a user's default password (i,e. the main reason we had this new 2.3.4 requirement)? I am having a hard time finding the closest one to it though...

[tghosth]

I guess if we cannot, then we cannot... If you are sure

[csfreak92]

Let me give it a few passes in reading to ensure I did not miss it somewhere in their docs. I will confirm here whatever I find out.

[csfreak92]

Hi @tghosth, I have read NIST SP 800-63 with a few more passes and cannot really find anything close to this ASVS requirement we have added. However, for NIST SP 800-53r5 I found something arguably closest which is: AC-6 (5) which states:

LEAST PRIVILEGE | PRIVILEGED ACCOUNTS
Restrict privileged accounts on the system to [Assignment: organization-defined personnel
or roles].
Discussion: Privileged accounts, including super user accounts, are typically described as
system administrator for various types of commercial off-the-shelf operating systems.
Restricting privileged accounts to specific personnel or roles prevents day-to-day users from
accessing privileged information or privileged functions. Organizations may differentiate in
the application of restricting privileged accounts between allowed privileges for local
accounts and for domain accounts provided that they retain the ability to control system
configurations for key parameters and as otherwise necessary to sufficiently mitigate risk.
Related Controls: IA-2, MA-3, MA-4.

Again, arguably this is the closest as there were no specifics in NIST that mentions something similar to what we are trying to have developers not do, which in this case is giving them guidelines that system administrators resetting user's passwords and selecting themselves is a terrible idea. I am quite surprised NIST doesn't have anything about it, but maybe because they deem it is basically common sense (which isn't really common at all based on my experiences testing a lot of web apps I still see this issue resurface from time to time).

My rationality for this being the closest NIST mapping is it says system administrators/privileged accounts should be differentiated by organizations to be restricted with accessing privileged information or privileged functions (such as resetting other user's passwords and then selecting them on their own).

What do you think about this mapping? For sure we don't need to force it if it seems too far-fetched, but that's the closest I can see.

[elarlang]

Helper - current 2.3.4 requirement:

#	Description	L1	L2	L3	CWE	NIST §
2.3.4	[ADDED] System administrators should not be able to change or choose any user's password, but rather only be able to initiate the password reset process for the user.	✓	✓	✓	620

Based on your information I would keep the mapping empty as there is no clear match.

And issue is ready to be closed?

[csfreak92]

@elarlang, yes I think that's the best way to keep it that way. Yup, I think we can close this issue determining there's no clear mapping.

[elarlang]

Thank you for the effort!