1.3.1 - Session Controls Documentation

[ryarmst]

Branching from #1557

V1.3 Session Management Architecture is currently a placeholder. The latest draft of NIST 800-63B Revision 4 includes:

Agencies SHALL establish and document the inactivity and overall time limits being enforced in a system security plan such as that described in [SP800-39].

I suggest the addition of the following requirement that also captures considerations for additional controls against session hijacking/theft:

#	Description	L1	L2	L3
1.3.1	Verify that session inactivity and overall (absolute) timeouts are documented and are appropriate in combination with other controls protecting against session hijacking attacks.		✓	✓

After reviewing other discussions surrounding similar controls, I think keeping the requirement vague (non-prescriptive) with respect to "other controls" may be the most practical approach. Consider, for example, discussions on client session storage spanning multiple issues (example: see #2010).

[elarlang]

Session decisions to document:

• are parallel sessions allowed; if are, how many
• logout - if user logs out, is it only from the application or also from SSO or is it for the end-user to decide
• max inactivity time
• max session lifetime (overall time by NIST)

Is SSO has separate session from the application (like it usually is), then it all applies (separately) to SSO as well.

[elarlang]

@ryarmst - let's try to get your proposed requirement in. I thik it needs some surrounding text to the chapter as well, maybe @tghosth can help with that.

I prefer "absolute maximum session lifetime" (that we use in 3.3.2) over "overall timeout" from NIST.

Requirement should be level 1, as we have implementation requirements that needs this documented info with level 1 (3.3.2, 3.3.5).

[ryarmst]

I think it may introduce the least friction by providing considerations for design/documentation in the section text rather than too many additional requirements.

I have written a rather verbose proposal for section text below. I think it can be trimmed down. I have written up "considerations" that could be turned into requirements. I also included terminology because I think there has been some ongoing confusion, but it may be more appropriate in the appendix. Some comments are in square brackets.

Proposed Section Text

Session management mechanisms provide applications the capability to correlate user and device interactions over time even using otherwise stateless communication protocols. While applications traditionally utilized session handling capabilities built in to browsers, such as HTTP Cookies or even HTTP Basic Authentication, applications today utilize a variety of techniques and technologies to implement the session management lifecycle (creation, transmission, storage, and termination). [This paragraph is fairly introductory and could be cut].

Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purpose. There is no single pattern that suits all applications. As such, session management systems must be designed with consideration for the relevant strengths and weaknesses in conjunction with the expected use cases of the application and intended level of security assurance. A secure session management system is one that optimally prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session. The most devastating of such attacks is known as session hijacking or takeover attacks.

The following terminology is used within the ASVS:

• Stateful Mechanism or Token - These mechanisms utilize the application server to retain session state and tokens.
• Stateless Mechanism or Token - These mechanisms encode information within the token(s) passed to clients that is not maintained by the server. A server may store some session information (such as a JWT revocation list) and be considered a stateless design.
• Opaque Token - An opaque token is a token with no discernible structure or meaning outside of the issuing server. [Note: at present, V3 appears to conflate opaque tokens with randomly generated tokens, but this use is not universal. For example, Auth0 defines them as "Tokens in a proprietary format typically contain some identifier to information in a server’s persistent storage" and I also came across Ory which uses a signature. Some additional requirement rework may be appropriate for clarity].
• Absolute Maximum Session Lifetime - Also referred to as "Overall Timeout" by NIST, this is the maximal amount of time a session can remain active regardless of user interaction.

Security controls should mitigate the likelihood and potential impact of successful attacks against user sessions. Consider starting with the following questions surrounding session management:

• How long are users expected to interact with an application for a given session?
• How frequently are users expected to interact with the application and at what interval?
• Will users be using personal devices, managed devices, public terminals, or some other system?
• Will users require multiple simultaneous active sessions across devices?
• Are there multiple applications or systems that maintain sessions (for example, SSO providers)?
• Is a stateless session management mechanism required, or can I simple stateful mechanism be used?

Considering the above, evaluate the controls appropriate for your application, including:

• The inactivity and absolute maximum session lifetime appropriate
• Whether multiple concurrent [parallel?] sessions should be permitted
• What session characteristics are relevant to monitor and make security decisions against (for example, source IP address, User Agent, expected interactions within a session, and so on) [Perhaps more relevant for Security Logging]
• How manual logout (session termination) mechanisms are implemented, including user-facing controls as well as propagation to integrated services such as SSO providers

[elarlang]

When I asked chapter texts, I had in mind "few lines" :)

First - I think it makes sense to handle requirement and chapter text in a separate issues.

I have written up "considerations" that could be turned into requirements.

Personally, I prefer, that all "considerations" (or required decisions to be able to implement and later test) for session management are written as separate documentation requirements, as was proposed in 1.3.1.

I also included terminology because I think there has been some ongoing confusion, but it may be more appropriate in the appendix. Some comments are in square brackets.

With terminology we need to check, what should belong to the chapter text and what to the glossary so that we don't duplicate them.

We can move things here and there, but it is a great input to work with.

[tghosth]

Great content @ryarmst :)

I have written up "considerations" that could be turned into requirements.

Personally, I prefer, that all "considerations" (or required decisions to be able to implement and later test) for session management are written as separate documentation requirements, as was proposed in 1.3.1.

I agree with this, I think it would be good if you can combine the considerations into a few documentation requirements.

I also included terminology because I think there has been some ongoing confusion, but it may be more appropriate in the appendix. Some comments are in square brackets.

With terminology we need to check, what should belong to the chapter text and what to the glossary so that we don't duplicate them.

I also agree with this, it may be better to reference the glossary and then put the definitions there.

@elarlang would it make sense for @ryarmst to take those actions and prepare an initial PR that implements them?

[elarlang]

In general, it makes sense, but I think a slightly shorter feedback loop can be helpful e. g. do not waste time and effort on something that is not aligned with our vision of how things in ASVS should be. Maybe just quick validation in chat or here before putting the effort in.

[ryarmst]

Agreed, I will get the details right before a PR. I will open a new issue for a trimmed section text proposal.

@elarlang In terms of additional documentation requirements for V1.3, do you think the following are reasonable to build into requirements?

• The handling of multiple concurrent/parallel sessions
• The handling of manual logouts and session termination for integrated SSO
• What session characteristics are to be recorded (or should this fall under Security Logging?)
• Considerations for stateless vs. stateful mechanisms?

For each, I will open a new issue to propose requirements as appropriate.

[elarlang]

Yes, at the moment I think so. As the result is up to the discussion for each one of them, we will find out :)

[ryarmst]

New issues for items above:

• V3/V1.3 definitions in V3 Terminology Addition #2100
• V1.3 section text proposal: V1.3 Session Management Architecture - Section Text Proposal #2103
• 1.3.2 - Proposed requirement for documenting multiple session handling: 1.3.2 - Multiple Concurrent Sessions Handling (Documentation) #2101
• 1.3.3 - Proposed requirement for documenting session handling with SSO: 1.3.3 - Handling Session Termination with SSO (Documentation) #2102
• Session characteristics are handled in 1.4.6 - Contextual attributes for access decisions #2062 via 1.4.6

[elarlang]

Ok, let's get back to this issue focus and try to move on with 1.3.1 here.

Input/update for further finetuning

Verify that the user's session maximum inactivity period and maximum session lifetime before requiring re-authentication are documented and are appropriate in combination with other controls protecting against session hijacking attacks.

Need to think more about the last sentence - it is not only session hijacking, or even more general session takeover including session fixation vectors, it's in general against attacks if pre-condition is user's active session, e.g. csrf, clickjacking, xss etc.

[ryarmst]

Looks good to me!

[elarlang]

@ryarmst - would you like to open the PR yourself?

[elarlang]

waiting for #2113

[elarlang]

ping, can we get this one moving? The vision here was to provide flexibility to decide own timeout values, but if those are different from NIST provided recommendation, the reasoning must be documented.

[ryarmst]

So I think there are two approaches to consider:

1. Make reference to the NIST standard without including the timeout values.
2. Include the precise reauthentication requirements within the requirement(s).

For (1) above, consider:

Verify that the user's session inactivity period and maximum session lifetime before reauthentication are documented, appropriate in combination with other controls, and that documentation includes justification for any deviations from NIST SP 800-63B reauthentication requirements.

For (2), I think it would be best to split into two separate requirements (for absolute and inactivity). Here is an example for inactivity timeouts:

Verify that session inactivity timeouts are documented, appropriate in combination with other controls protecting against session hijacking attacks, and that deviations from inactivity timeouts of 1 hour for L2 applications and 15 minutes for L3 applications are documented.

Thoughts?

[elarlang]

I'm not happy with the requirement, I have started to build a proposal for improvement 10 times and never reached any result...

So the quick takeaway here is, let's get version 1 into the document and if someone has a proposal for improvement, we can always do that.

[elarlang]

@ryarmst - do you want me to handle the PR or you'll do it yourself?

[ryarmst]

Opened #2154 to resolve