1.3.2 - Multiple Concurrent Sessions Handling (Documentation)
ryarmst opened this issue · 15 comments
Starting with the following proposal for documenting the handling of multiple concurrent sessions:
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify documentation of intended behavior and handling of multiple concurrent (parallel) sessions initiated for the same account or identity including all controls intended to terminate one or multiple active sessions. | ✓ | ✓ | ✓ |
L1 requirement based on 3.8.2, 3.8.5, and 3.8.6.
Like it! Thank you!
Slight change
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify that the application documents the intended behavior and handling of multiple concurrent (parallel) sessions initiated for the same account or identity including all controls intended to terminate one or multiple active sessions. | ✓ | ✓ | ✓ |
Overall I think it sounds good :)
Verify that the application documents ...
this does not feel right :)
How about:
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify that the application documentation defines the intended behavior and handling of multiple concurrent (parallel) sessions initiated for the same account or identity including all controls intended to terminate one or multiple active sessions. | ✓ | ✓ | ✓ |
I'm a bit worried, that "behavior and handling sessions" are a bit vague here. It's not clear from the requirement, what we need to verify and what must be done.
Yes, on looking over, I agree. Consider:
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify that the application documentation defines whether multiple concurrent (parallel) sessions initiated for the same account or identity are permitted and the controls (both administrative and user-facing) to identify and manage distinct active sessions. | ✓ | ✓ | ✓ |
This wording may exclude some possible desirable controls. Thoughts?
Seems like a 2 separate topics here?
One requirement:
Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account.
And something for other - but what goal it has?
... and the controls (both administrative and user-facing) to identify and manage distinct active sessions.
Most every app I use allows for parallel sessions - which are secured by all of the other requirements we talk about in this section. I suggest we drop 1.3.2, it does not really help for security. Multiple sessions are the norm, I do not see why we need special requirements to talk about them.
For example, if you have an backoffice account meant to be used from by one user from one workstation, you have logical limitation for "1 active session per account".
It depends on the application needs, that's why we need the documented security decision.
@elarlang This is such an edge case in my world - but I see it's more frequent in back-office and finance so I drop my concern.
Following discussion with @elarlang, I will propose the following simplification for this requirement:
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify that the application documentation defines whether multiple concurrent (parallel) sessions initiated for the same account or identity are permitted. | ✓ | ✓ | ✓ |
Last proposal:
Verify that the application documentation defines whether multiple concurrent (parallel) sessions initiated for the same account or identity are permitted.
It defines it as boolean - multiple allowed or not, but does not set the limit, how many parallel sessions are allowed.
I prefer my direction:
Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account.
Just an idea - should it cover also the situation, when a "max amount of allowed sessions is reached" and then new authentication is made, is it FIFO there or anything else.
How about this:
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 1.3.2 | Verify that the documentation defines how many concurrent (parallel) sessions are allowed for one account as well as the intended behaviours and actions to be taken when the maximum number of active sessions is reached. | ✓ | ✓ | ✓ |
Clear for me