4.1.4 - how should we relate to "deny by default"?

[jmanico]

4.1.4 looks a little sloppy and could use some clarification.

[cmlh]

Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.

[jmanico]

Hey @cmlh thanks for posting the text. Do you agree this needs a little cleanup? Any suggestions?

[cmlh]

@jmanico wrote

Hey @cmlh thanks for posting the text. Do you agree this needs a little cleanup? Any suggestions?

I'd recommend 4.1.4 be applicable to Level 3 (as defined under the 4.x TOV specification).

We should split and into two separate requirements i.e. "...minimal or no permissions and users/roles...".

Also a certifier could interpret "users/roles do not receive access to new features until access is explicitly assigned." as requiring to add the existing group to a newly created "new features" group even when the existing users are exactly the same and therefore cause debt within IAM?

[elarlang]

Never used this requirement in pen-tests, what it gives extra which is not covered by 4.1.3 for example?

4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

4.1.4 basically says, that user should not have permissions when just created? And should not have access till it's not given? For me it's just common sense to use 4.1.3.

Probably reason for different requirements comes from covering CWE's:

• 4.1.3 - CWE-285: Improper Authorization
• 4.1.4 - CWE-276: Incorrect Default Permissions (part of permission issues https://cwe.mitre.org/data/definitions/275.html)

So, the question is - do we need to have separate requirement for "incorrect default permissions"

[jmanico]

I typically start news users with default permissions. I am ok with deleting this requirement. Are you ok with a delete here too @cmlh ? Is 4.1.3 emough?

[cmlh]

Are you ok with a delete here too @cmlh ? Is 4.1.3 enough?

I am willing to commit to deletion 4.1.4 @jmanico provided we have addressed CWE-285 and CWE-276 in their entirety as raised by @elarlang, perhaps aligning the requirement text to reflect that of CWE-276 is the solution?

[elarlang]

@cmlh , I made quick stats for you, based on ASVS v4.0.2, we have:

• requirements: 286
• requirements with cwe set: 276
• unique cwe values: 129

The point - not all CWE's are covered.

... the point and question here is, what problem or vector this requirement could solve which is not covered by other requirements? In this case, 4.1.3.

[jmanico]

Did a lot of searching and found deny by default is mostly a network security concept and in the interest of so many new requirements entering ASVS I'm politely deleting this requirement

[tghosth]

I am reopening this as I think that it bears further discussion.

I actually think that 4.1.4 "deny by default" is a lot more actionable/testable than the "principle of least privilege" which to me is a lot more conceptual.

• "deny by default" - says that a newly created user should not receive permissions until explicitly assigned them. Can verify this by looking at the user creation process.
• "principle of least privilege" - says that at any point in time, a user should only have the permissions that they need. Verifying this is very subjective.

I would actually be inclined to drop 4.1.3 and restore 4.1.4 but I am open to suggestions.

See also #1352

[tghosth]

I am not going to revert this but I think we do need to find a way of reflecting the deny by default concept in the updated version.

[EnigmaRosa]

@tghosth Looking over this, I'm inclined to agree with the deletion decision. That being said, because deny by default principle is a factor in access control, I think we would be remiss if we don't mention it. What if we did something along the lines of "Verify that all users are explicitly assigned permissions instead of being added to a generally-permissioned group by default".

[elarlang]

@EnigmaRosa - can you please clarify, what is the attack vector / problem / vulnerability the proposal addresses?

[EnigmaRosa]

@elarlang - the only one I can think of is for highly sensitive (L3) applications, where users need to be explicitly permissioned, such as for medical records.

[elarlang]

Is it actionable? And is it different by concept from the requirements we have (4.1.3, 4.2.1 - related discussion #1934)?

[EnigmaRosa]

Actionable? Yes - we state that users for L3 applications have to be explicitly granted permissions and not put in a default group. Is it worthwhile? Unsure. Different in concept? No

[elarlang]

With "actionable" - my question is, how do you verify that? What are the preconditions to do that?

[jmanico]

This can all be verified by auditing the flow of access control assignment to users and objects. I like this direction.

Access control is one of the top priorities (per the OT10) and being business logic, it's not easy to flesh out this section. But since it's so important to security, I like these kinds of additional design-centric requirements for access control.

[tghosth]

I actually think that 4.1.4 "deny by default" is a lot more actionable/testable than the "principle of least privilege" which to me is a lot more conceptual.

• "deny by default" - says that a newly created user should not receive permissions until explicitly assigned them. Can verify this by looking at the user creation process.
• "principle of least privilege" - says that at any point in time, a user should only have the permissions that they need. Verifying this is very subjective.

I would actually be inclined to drop 4.1.3 and restore 4.1.4 but I am open to suggestions.

See also #1352

So having returned to this issue 1.5 years later, my thoughts are pretty much the same as my previous comment which I have quoted here.

Practically speaking, I am ok with some form of merge between 4.1.3 and 4.1.4 as I also noted here.

This then brings us to Elar's very valid questions:

what is the attack vector / problem / vulnerability the proposal addresses?

I would argue that this is wider than just medical applications but rather the concept here is that a user should not start off with more permissions than they actually need.

With "actionable" - my question is, how do you verify that? What are the preconditions to do that?

This is clearly a verifiable requirement although it would require either creating a new user and seeing what permissions they received or understanding the logic from the application developers, i.e. probably not just a pen test :)

I also agree with the direction of Jim's comment below:

Access control is one of the top priorities (per the OT10) and being business logic, it's not easy to flesh out this section. But since it's so important to security, I like these kinds of additional design-centric requirements for access control.

[jmanico]

I’d rather err on the side of more than less ASVS access control requirements per previous comments.

I often help while flying or just on my phone and it’s hard for me to see the full thread so please bear with my repetition.

Some thoughts. And again please forgive if these are in the wrong comment. I am doing my best to contribute when and how I can.

1) I like deny by default as a requirement. Very solid and actionable. 2) Since access control is business logic and not a standard technical bug, having clear policy documentation is often the truth for what the access control policy should be. Having a access control policy doc seems very important to both development and testing.

2a) Define and document all user attributes, resource attributes, action attributes, and environmental attributes used in access control decisions.

2b) Define and document access control policies that utilize attributes to determine access.

Also some other suggestions from the ABAC standard.

3) Ensure access control policy attributes are transmitted and stored securely to maintain their integrity and confidentiality.

4) Ensure the access control system can make real-time access decisions based on current attribute values.

5) Implement policies that enforce separation of duties to prevent conflicts of interest and fraud. (Duplicate but I like this wording)

6) Implement measures to control the aggregation and inference of sensitive information from attributes.

7) Ensure that access control policies do not inadvertently expose sensitive information through attribute combinations.

8) Incorporate environmental and contextual attributes (e.g., time of day, location) into access control decisions to enhance security.

9) Provide user and administrator interfaces to manage attributes and policies securely.

These might be out of place mentioned here and I’m glad to open new issues or do deeper analysis when I’m on my laptop if this direction interests you.

[tghosth]

@EnigmaRosa should hopefully handle this as part of the V4 rework

[EnigmaRosa]

Now that we're addressing some re-structuring, I'd like to return to this - I believe #2063 covers deny by default, and would like to propose closing this issue out in favor of continuing there.