2.10.4 and 6.4.1 seem like duplicates

[tghosth]

We currently have the following requirements:

#	Description	L1	L2	L3	CWE	NIST §
2.10.4	[GRAMMAR] Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage should resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.		✓	✓	798

#	Description	L1	L2	L3	CWE
6.4.1	[MODIFIED] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy back-end secrets such as service account or 3rd party application credentials.		✓	✓	798
6.4.2	[MODIFIED] Verify that key material is not exposed to the application (neither the front-end nor the back-end) but instead uses an isolated security module like a vault for cryptographic operations.		✓	✓	320

(6.4.2 included for information although I don't think it is a duplicate.)

I think 2.10.4 and 6.4.1 are duplicates.

We also need to think in the context of whether section 2.10 should move to the config chapter.

[jmanico]

I think merging is a good idea. I’d suggest moving this item to the cryptography section.

[tghosth]

@elarlang what do you think?

[elarlang]

2.10.4 provides the problem statement and 6.4.1 a way how to solve the problem. In case 6.4.1 is the one and only way to solve 2.10.4, those can be merged.

At the moment both requirements have a clear focus, and both should be carried to the merged requirement.

My worry at the moment is - is the Cryptography paragraph your default idea to look for the requirement handling the "hardcoded credentials" or secret management in general?

[meghanjacquot]

We currently have the following requirements:

Description L1 L2 L3 CWE NIST §

2.10.4 [GRAMMAR] Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage should resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage. ✓ ✓ 798

Description L1 L2 L3 CWE

6.4.1 [MODIFIED] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to and destroy back-end secrets such as service account or 3rd party application credentials. ✓ ✓ 798 6.4.2 [MODIFIED] Verify that key material is not exposed to the application (neither the front-end nor the back-end) but instead uses an isolated security module like a vault for cryptographic operations. ✓ ✓ 320 (6.4.2 included for information although I don't think it is a duplicate.)

I think 2.10.4 and 6.4.1 are duplicates.

I think that they have overlap, but not that they are complete duplicates. Depending upon which part is emphasized I think it makes more sense to keep the merge in chapter 2 or if other parts are emphasized it could make sense to move it to chapter 6.

If the emphasis is on the secret management from 2.10.4 then I think it makes sense to move it to 6.10.X. If the emphasis is on how services authenticate then it should stay in 2.10.X. I lean more towards merging language and moving it 6.10.X.

This could be an example of merged language, "Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy back-end secrets, such as service accounts or 3rd party application credentials. Verify that no secrets are included in the source doe or stored within source code repositories. Possible solutions could include the following: the use of a secure software key store (L1), hardware TPM (L2), or an HSM (L3).

We also need to think in the context of whether section 2.10 should move to the config chapter.

I don't think 2.10 should move to the configuration chapter. The items in 2.10 all heavily relate to authentication. For example, from 2.10.1 "Authentication should use individual service accounts,...", and from 2.10.2 "Verify that if a credential has to be used for service authentication,...".

[elarlang]

I don't think 2.10 should move to the configuration chapter. The items in 2.10 all heavily relate to authentication. For example, from 2.10.1 "Authentication should use individual service accounts,...", and from 2.10.2 "Verify that if a credential has to be used for service authentication,...".

The rest of V2 is about the user authentication into/for the application, V2.10 is about authentication between services and therefore does not really match with the rest of the paragraph.

[meghanjacquot]

I don't think 2.10 should move to the configuration chapter. The items in 2.10 all heavily relate to authentication. For example, from 2.10.1 "Authentication should use individual service accounts,...", and from 2.10.2 "Verify that if a credential has to be used for service authentication,...".

The rest of V2 is about the user authentication into/for the application, V2.10 is about authentication between services and therefore does not really match with the rest of the paragraph.

But isn't that ok that different sections relate to different aspects of auth?

For example, the intro V2 states "Authentication is the process of establishing or confirming the authenticity of an individual or device. It involves verifying claims made by a person or about a device, ensuring resistance to impersonation, and preventing the recovery or interception of passwords."

So auth with service seems like it would fit into the V2 section?

[elarlang]

Yes, in my opinion it is.

Most of the chapter texts are leftovers from v4.0.3 and it is good to just ignore them at the moment.

It can fit to different places. From the word "authentication" it belongs to V2, from the word "service" it belong to V14. I prefer to keep V2 for "user authentication". The same way is done with authorization, we don't have service authorization requirements in V4, we have them in V14.

[meghanjacquot]

Ahh, that's helpful additional information, thanks Elar.

If we're ignoring the intro text, and considering V2 to be more focused on Auth regarding users, then I agree that it would make sense to associate these with V14.

Maybe we can agree upon language regarding 2.10.4 and 6.4.1 and then I can open up a new issue for moving parts of V2 to V14.

So thoughts on this as merged language, @elarlang @jmanico @tghosth :

"Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy back-end secrets, such as service accounts or 3rd party application credentials. Verify that no secrets are included in the source doe or stored within source code repositories. Possible solutions could include the following: the use of a secure software key store (L1), hardware TPM (L2), or an HSM (L3)."