4.3.5 - Coverage by access control policies and deny by default otherwise

[EnigmaRosa]

Note: This is referenced as 4.3.7 in #2033 but has updated numbering

This requirement addresses two parts: there should not be any objects that don't have their access undefined, but if there is, deny by default. Because this cannot exactly be penetration tested, it is L2 and L3.

#	Description	L1	L2	L3	CWE
4.3.5	[ADDED] Verify that every object is addressed by at least one access control policy, and when an object does not have an access control policy all access to that object is rejected.		✓	✓	280

[elarlang]

Comment from Elar (#2033 (comment)):

4.3.7 - not sure about this one. From implementation perspective it maybe makes sense, from pen-testing perspective is just finding a technical reason for 4.1.3 or 4.2.1 requirement.

Comment from Josh (#2033 (comment)):

• I think this is a little too specific, I also think that practically speaking some data objects will be publicly accessible.
• I would rather see this requirement be a little less specific and lean more into the deny by default concept, which we discussed in 4.1.4 - how should we relate to "deny by default"? 4.1.4 - how should we relate to "deny by default"? #1085.

[jmanico]

I think this is an excellent "secure by default" requirement. Access control is very very hard to test comprehensively and I'd like to have some leeway here to steer developers in the right direction since it's essentially business logic.

[EnigmaRosa]

An object being publicly accessible doesn't mean that it lacks an access control policy - in fact, the access control policy should be "allow access independent of attribute" if we want to force deny by default.

[EnigmaRosa]

@tghosth @elarlang following up on this