1.4.7 add specific for L2

[tghosth]

[ADDED] Verify that access control documentation defines explicit rules for restricting function-level, data-specific, and field-level access based on consumer permissions, specifying relevant consumer and resource attributes, as well as environmental factors involved in decision-making.

Change to

[ADDED] Verify that access control documentation defines explicit rules for restricting function-level, data-specific, and (for L2) field-level access based on consumer permissions, specifying relevant consumer and resource attributes, as well as environmental factors involved in decision-making.

[tghosth]

@elarlang what do you think?

[elarlang]

Current requirement:

• Verify that access control documentation defines explicit rules for restricting function-level, data-specific,
  • this is addressing Level 1 requirements V4.1.3 and V4.1.6
• ... and field-level access based on consumer permissions, specifying relevant consumer and resource attributes,
  • this addresses Level 2 requirement V4.1.7
• ... as well as environmental factors involved in decision-making.
  • this addresses requirement V4.1.8 that is marked level 2 at the moment, but me and Josh have marked it level 3 during reworking levels

So, in case we change the level for V4.1.8 for 3, then it requires (for L3) into the requirement or some other solution.

#	Description	Level	CWE
4.1.3	[MODIFIED, COVERS 4.1.2] Verify that the application ensures that function-level access is restricted to consumers with explicit permissions.	1	285
4.1.6	[MODIFIED, MOVED FROM 4.2.1, COVERS 13.1.4] Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).	1	639
4.1.7	[ADDED] Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA).	2	283
4.1.8	[ADDED] Verify that adaptive security controls related to authentication and authorization decisions based on a consumers environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented as defined in access control documentation.	2

[jmanico]

Why can't we split the documentation requirement into different requirements specific to each level? It looks very strange to see one documentation requirement with logic that has one portion at one level and another portion (field level) at l2.

So like Elar is saying if we have V4.1.8 for 3, then why not have a doc requirement that maps to that exactly, even if some of the documentation requirements have some overlap? It would seem more clear to me.

[elarlang]

Why can't we split the documentation requirement into different requirements specific to each level?

We can, this is one option.

At the moment was goal to avoid unnecessary duplication and have less requirements, which means we mostly put similar things together into one requirement. With setting levels, there may come need to split current requirements into a separate requirements, as one part matches with one level and another part matches for another level. This is part of the larger task at the moment.

So, @tghosth - what is your opinion to have a set of per-level documentation? A bit duplication, but maybe it is the most clear way.

[jmanico]

Why can't we split the documentation requirement into different requirements specific to each level?

We can, this is one option.

At the moment was goal to avoid unnecessary duplication and have less requirements, which means we mostly put similar things together into one requirement. With setting levels, there may come need to split current requirements into a separate requirements, as one part matches with one level and another part matches for another level. This is part of the larger task at the moment.

So, @tghosth - what is your opinion to have a set of per-level documentation? A bit duplication, but maybe it is the most clear way.

I think this is a reasonable goal and I support your decision either way.

[tghosth]

what is your opinion to have a set of per-level documentation? A bit duplication, but maybe it is the most clear way.

So in this case that means splitting 1 requirement into 3, right? I would be tempted to make 4.1.7 L3 to avoid that...

[elarlang]

I don't think 4.1.7 is L3 topic, it was between L1 and L2.

[tghosth]

So you think we need to split 1.4.7 into 3 requirements or do you prefer adding explanations in the requirement about what is applicable for each level?

[elarlang]

I don't have a strong opinion on this, if I need to choose one I prefer to have one requirement with "for L2" and "for L3" written into it. It is not ideal, but it is compact and clear.

We used L1/L2/L3 definitions inside requirements many times for OAuth requirements in V51.

[tghosth]

Let's wait for the resolution of #2591

[jmanico]

I say we charge forward and deal with splitting on a case by case basis. If we can all agree to that then I'm happy to close out 2519.

[tghosth]

Ok so to try and handle this one:

"[ADDED] Verify that access control documentation defines explicit rules for restricting function-level and data-specific access based on consumer permissions, specifying relevant consumer and resource attributes. For L2, this should also include field-level access and for L3 this should also consider environmental and contextual factors involved in decision-making."