PSS-06 Session Management
Protect interactions with the service using session management that meets at least the current state of the art and withstands known attacks, and invalidate a session once detected as inactive using a timeout configurabl
4
artefacts
1
held by a system
2
at each review
moderate
to go live
Cloud console / configuration management
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Configuration showing the inactivity timeout value and who may change it · Cloud console / configuration management
periodic reviewEvidence produced at each review
- Test evidence that a token is refused after logout or timeout · Document repository
- Assessment against known session attacks such as fixation and replay · Document repository
governing documentDocuments that govern the control
- Design documentation for session token generation, storage and invalidation · Document repository
First move
Start with the 1 of 4 artefacts that already live in a system (Cloud console / configuration management); keep the periodic reviews but log each one as a dated record with a named reviewer.
Common gaps auditors find
- Session appears closed in the interface while the underlying token stays valid
- Inactivity timeout set so long that it never triggers in practice
- Tokens not reissued after a privilege elevation
- Customers unable to adjust the timeout although the platform supports it
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetPSS-05 Authentication Mechanisms · PSS-07 Confidentiality of Authentication Information