1.4.7 - Access Control Documentation

[EnigmaRosa]

Note: This is referred to as 4.1.6 in #2033 but it was determined that it belonged in v1 instead.

Proposing a documentation requirement for the access control system design, as it is currently missing from v1.

#	Description	L1	L2	L3	CWE
1.4.7	[Added] Verify documentation and definition of all user, resource, action, and environmental attributes and access control policies.	✓	✓	✓	284

[elarlang]

This is a requirement we need to have. I wrote related comment to other issue (#2058 (comment)) - we just need to analyze, that the documentation covers the need for all V4 implementation requirements.

Comment from Josh (#2033 (comment)):

However, I think the wording needs to be simpler/clearer.

@tghosth - any direction or proposal what should be improved?

[elarlang]

When it is PR time, note that I moved away added 1.4.6, so the requirement can have a number 1.4.6 with the label [ADDED] (I'll check and take care of it when it is PR-ready)

[jmanico]

Note, documenting access control policy is so fundamental to good access control that I would like to keep it in the access control section. I do not want developers to have to hop to a variety of different sections to get access control right.

[elarlang]

If we have structure to keep all documentation requirements in V1, then we do that. The point is to point out questions for the analysis step and to provide a separate set of requirements (without going through entire ASVS). If this requirement should be located somewhere else, most likely it will be missed/skipped at that step.

What we going to do with current V1 content is up to separate discussion #1063 / #1831

[jmanico]

My point is, if developers are building access control then the most important thing - since its business logic - is to implement what was documented and to maintain that documentation. I worry this will be missed if it's only in v1.

[tghosth]

I think my challenge with this requirement is that I am not sure that I understand exactly what it is talking about:

Verify documentation and definition of

That seems clear enough

all user, resource, action,

Are we talking about the different dimensions where access control has to be enforced?

For example:

• Is the user allowed to interact with this particular entity type (e.g. orders in an eCommerce system)
• Is the user allowed to perform this particular action on this entity type (e.g. can they create an order or only view an order)
• Is the user allowed to interact with this particular instance of this entity type (e.g. can they only see or modify orders for their department but not other departments)
• Is the user allowed to interact with these particular fields of this particular entity type (e.g. they can view order details but they are not allowed to see the standard discount amount)

(If I have understood this correctly, does the 4th bullet this solve Problem 1 in this comment @elarlang?)

and environmental attributes

We talk about environmental in the context of where the user is located somewhere else, is that what we are talking about here?

and access control policies.

Not sure what we are adding here.

[EnigmaRosa]

@tghosth The term "attributes" (whether they are user, resource, action, or environmental) references attribute based access control (ABAC) where attributes describe the user (user ID, group membership, etc.), resource (file type, creation date, some other metadata, etc), action (read, write, edit), and environment (contextual information, this can even include the type of encryption used). Meanwhile, it is the policy that actually sets the rule (i.e. users in the "admins" group can read/write/edit/delete all folders). Would it be helpful if I clarified this in the requirement?

[tghosth]

I think it would be helpful to add some clarification in the requirements but I don't think the requirement should be too long. It may best to make a slightly clearer requirement and back it up with some explanatory text at the beginning of the section. Does that sound ok? @EnigmaRosa

[EnigmaRosa]

Makes sense. How about something along the lines of "Verify the documentation and definition of the application's access control system, including access control policies and any relevant information that is used to determine access"

[tghosth]

How do you feel about the following @EnigmaRosa, it is a little longer but I have tried to make it a little clearer.

Verify that the application's access control documentation defines the rules for how access control decisions are made. It should also explain the user or subject attributes, the attributes of the resource being accessed and any environmental factors which are considered when making these decisions.

We could then potentially include a little more info in the section header text and then reference the NIST ABAC standard.

Also keen to get input from @elarlang and @jmanico

[jmanico]

I like this direction @tghosth - if you want it a bit more brief I would go with something like:

Verify that access control documentation clearly defines the rules for access control decision-making, specifying user/subject attributes, resource attributes, and relevant environmental factors involved in the process.

[elarlang]

Few notes for last comments:

• "Should" is topic for recommendations and rises the question, is the text for a requirement or for a recommendation
• Although "clearly" is one of my "parasite words", I would not use it in the requirement text.
• / must be "and" or "or"

[jmanico]

That is helpful, @elarlang

How about:

Verify that access control documentation defines the rules for access control decision-making, specifying user attributes, subject attributes, resource attributes, and relevant environmental factors involved in the process.

[tghosth]

I think user and subject are interchangable. Whilst user is more understandable I think subject is more correct.

I would suggest:

Verify that access control documentation defines the rules for access control decision-making, specifying user and subject attributes, resource attributes, and relevant environmental factors involved in the process.

I think some explanation in the section heading would still be needed.

Any further comments?

[elarlang]

Let's get it in. If someone has ideas for improvements we can do it later.

Would @EnigmaRosa like to handle the PR or we do?

[EnigmaRosa]

I’ll handle the PR

…

On Sat, Sep 28, 2024 at 12:07 Elar Lang ***@***.***> wrote: Let's get it in. If someone has ideas for improvements we can do it later. Would @EnigmaRosa <https://github.com/EnigmaRosa> like to handle the PR or we do? — Reply to this email directly, view it on GitHub <#2065 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLXUAH7MNWUL62N63O76ATZY3H2LAVCNFSM6AAAAABNVI326WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBQG4ZDCMRVGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[elarlang]

Added to V1.4 Access Control Architecture via #2123

#	Description	L1	L2	L3	CWE
1.4.7	[ADDED] Verify that access control documentation defines the rules for access control decision-making, specifying user and subject attributes, resource attributes, and relevant environmental factors involved in the process.	✓	✓	✓