Раздел: Документация
0 ... 112 113 114 115 116 117 L.3 Session locking (FTA SSL) This family defines requirements for the TSF to provide the capability for locking and unlocking of interactive sessions (e.g. keyboard locking). When a user is directly interacting with subjects in the TOE (interactive session), the users terminal is vulnerable if left unattended. This family provides requirements for the TSF to disable (lock) the terminal or terminate the session after a specified period of inactivity, and for the user to initiate the disabling (locking) of the terminal. To reactivate the terminal, an event specified by the PP/ST author, such as the user re-authentication must occur. A user is considered inactive, if he/she has not provided any stimulus to the TOE for a period of time. A PP/ST author should consider whether FTPTRP.1 Trusted path should be included. In that case, the function session locking should be included in the operation in FTPTRP.1. FTA SSL.1 TSF-initiated session locking User application notes FTASSL. 1 TSF-initiated session locking, provides the capability for the TSF to lock an active user session after a specified period of time. Locking a terminal would prevent any further interaction with an existing active session through the use of the locked terminal. If display devices are overwritten, the replacement contents need not be static (i.e. screen savers are permitted). This component allows the PP/ST author to specify what events will unlock the session. These events may be related to the terminal (e.g. fixed set of keystrokes to unlock the session), the user (e.g. reauthentication), or time. Operations Assignment: In FTA SSL.1.1 the PP/ST author should specify the interval of user inactivity that will trigger the locking of an interactive session. If so desired the PP/ST author could, through the assignment, specify that the time interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value. In FTA SSL.1.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: "user re-authentication" or "user enters unlock key-sequence". FTASSL.2 User-initiated locking User application notes FTASSL.2 User-initiated locking, provides the capability for an authorised user to lock and unlock his/her own terminal. This would provide authorised users with the ability to effectively block further use of their active sessions without having to terminate the active session. If devices are overwritten, the replacement contents need not be static (i.e. screen savers are permitted). Operations Assignment: In FTASSL.2.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: "user re-authentication", or "user enters unlock key-sequence". FTASSL.3 TSF-initiated termination User application notes FTASSL.3 TSF-initiated termination, requires that the TSF terminate an interactive user session after a period of inactivity. The PP/ST author should be aware that a session may continue after the user terminated his/her activity, for example, background processing. This requirement would terminate this background subject after a period of inactivity of the user without regard to the status of the subject. Operations Assignment: In FTA SSL.3.1 the PP/ST author should specify the interval of user inactivity that will trigger the termination of an interactive session. If so desired, the PP/ST author could, through the assignment, specify that the interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value. L.4 TOE access banners (FTA TAB) Prior to identification and authentication, TOE access requirements provide the ability for the TOE to display an advisory warning message to potential users pertaining to appropriate use of the TOE. FTATAB.1 Default TOE access banners This component requires that there is an advisory warning regarding the unauthorised use of the TOE. A PP/ST author could refine the requirement to include a default banner. 0 ... 112 113 114 115 116 117
|
