1.4.6 - Contextual attributes for access decisions

[EnigmaRosa]

Note: This is discussed in #2033 as 4.3.5, but is now 4.3.4 to account for updating numbering.

Proposing a requirement to consider additional attributes with regards to access control decisions for sensitive (i.e. L3) applications.

#	Description	L1	L2	L3	CWE
4.3.4	[ADDED] Verify that environmental and contextual attributes such as time of day and location are incorporated into access control decisions.			✓	1220

[elarlang]

Comment from Elar (#2033 (comment)):

We can not require it as general requirement. It is application specific. Also, if we look towards Zero Trust framework, it is going against it (checking Location). It can be material for recommendation.

Comment from Josh (#2033 (comment)):

• So I actually think this is an important requirement for L3.
• I think there would be a question as to whether this is an AuthN or an AuthZ question but I think maybe it fits better here.

Comment from Elar (#2033 (comment))

I would put it to the threat-model-based-monitoring section, not the application authorization decision.

Related requirement in logging section:

#	Description	L1	L2	L3	CWE
7.2.5	[MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected.		✓	✓	390

Comment from Josh (#2033 (comment)):

OK so that is alerting rather than taking active action. Maybe we can expand and improve this requirement to also talk about taking action and be clearer about the environmental aspects?

[tghosth]

Hi @EnigmaRosa,

I had a discussion with Elar about this. We agree that the concept is important but is hard to be too prescriptive about the actual requirement. We therefore think it might be good as an L3 documentation requirement as that means that the application developer is expected to have considered this and documented an effective way to carry it out.

What do you think about putting the following in 1.4?

Verify that there are documented controls which use changes to a user's regular environmental and contextual attributes (such as time of day, location, IP address, device) to make security decisions including around authentication and authorization.

[jmanico]

I like the idea of merging this into 1.4

[EnigmaRosa]

Yes, this is why I had it proposed as a requirement exclusively to L3. I am okay with merging into 1.4.

[tghosth]

I am okay with merging into 1.4.

Excellent, I think you can open a PR :)

[elarlang]

For V1 "Verify that there are documented controls" should be something like "Verify that there are documentation for controls" e. g. implementation requirement vs documentation requirement.

[tghosth]

Good point @elarlang,

maybe something like;

Verify that the application documentation defines controls which use changes to a user's regular environmental and contextual attributes (such as time of day, location, IP address, device) to make security decisions including around authentication and authorization.

[EnigmaRosa]

Created the PR!

[elarlang]

From PR:

#	Description	L1	L2	L3	CWE
1.4.6	[ADDED] Verify that the application documentation defines controls which use changes to a user's regular environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization.			✓	1120

• The initial proposal for the requirement was for a true-false implementation requirement and therefore was discussed as a Level 3 requirement. Should we use Level 2 for the requirement? It forces analytics to think about it, and analyze application needs, and then developers can implement according to that.
• "CWE-1120: Excessive Code Complexity" - does not make sense to me. If there is no good match, it is better to just leave it empty.

[tghosth]

I agree with dropping the CWE.

@elarlang My opinion is that this is quite a challenging requirement and I would prefer to keep it as L3.

[elarlang]

Ack, let's drop the CWE and move on.

[ryarmst]

Sorry, I am behind on this one, but it may be worth updating the wording to include a reference to session attributes/characteristics. For example, consider the current draft NIST SP 800-63B-4 that defines "Session Monitoring" (section 5.3) as a category for these controls.

[elarlang]

@ryarmst - is it more topic for 3.7.1?

3.7.1 Verify that the application requires re-authentication or secondary verification before allowing highly sensitive transactions, modifications to account profile or authentication settings, or a large export of sensitive data.

[ryarmst]

@elarlang No, sorry, I will clarify. Consider using an IP address as a contextual attribute. I will suggest two possible use cases (not commenting on their merits as actual controls):

1. Tracking changes to a user's IP address between distinct login/authentication events.
2. Tracking changes to a user's IP address within a single authenticated session.

For (2) above, you could consider this a part of authorization logic, but the property is nevertheless bound to a user's session. At my organization, we've historically referred to these as "session-bound properties". The NIST document similarly refers to these as "session characteristics". As another example, this recent post from Slack details how they use a number of session characteristics to detect what they refer to as session forking (as far as I can tell, this is perhaps the first published use of this term).

Unless I am misunderstanding the intent of 1.4.6, I interpret the authorization decisions to be fulfilling (2) above and therefore strongly based on session characteristics. If so, I simply suggest adding a reference to "session characteristics" or something similar in the requirement so it can be correlated with other standards and publications. Here is a suggestion (added text emphasized):

Verify that the application documentation defines controls which use changes to a user's regular and session-specific environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization.

Does this make sense?

[elarlang]

I just add it here as potentiall related:

7.2.5 [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected.

[elarlang]

I'm not a fan of mentioning session-specific requirements in authorization-related requirements. Also, I'm not sure do we need to duplicate it in the session section kind of.

ping @tghosth

[tghosth]

So to me this whole requirement is a little wide ranging which I think makes sense and therefore it doesn't necessarily fit cleanly into a particular chapter.

I think Ryan's idea makes sense so maybe something like:

#	Description	L1	L2	L3	CWE
1.4.6	[ADDED] > Verify that the application documentation defines controls which use changes to a user's regular environmental and contextual attributes (such as time of day, location, IP address, or device) to make security decisions, including those pertaining to authentication and authorization. These changes should be detected both when the user tries to start a new session and also in the course of an existing session.			✓

What do you think @elarlang @ryarmst ?

[elarlang]

Ok for me.

Just in case, don't carry the > to the requirement after [ADDED]