PD-0150: FTA_SSL.1 and 2 SFRs in the Firewall, Traffic Filter Firewall, VPN, and IDS MR PPs

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

In the Firewall, Traffic Filter Firewall, VPN, and IDS MR PPs, the FTA_SSL.1 and FTA_SSL.2 requirements call for a TSF-initiated and User-initiated session locking ability. The session locking shall provide display clearing/overwriting and disable all activity of the user's access/display other than unlocking the session once the user is reauthenticated.

TSF-initiated session locking and User-initiated locking

(This wording is taken from the Traffic Filter Firewall Medium Robustness PPs, although the wording in the others is the same)

FTA_SSL.1 TSF-initiated session locking

FTA_SSL.1.1 - Refinement: The TSF shall lock a local interactive session after [a Security Administrator-specified time period of inactivity] by:

• clearing or overwriting display devices, making the current contents unreadable;

• disabling any activity of the user's data access/display devices other than unlocking the session.

FTA_SSL.1.2 - Refinement: The TSF shall require the user to re-authenticate prior to unlocking the session.

FTA_SSL.2 User-initiated locking

FTA_SSL.2.1 - Refinement: The TSF shall allow user-initiated locking of the user's own local interactive session by:

• clearing or overwriting display devices, making the current contents unreadable;

• disabling any activity of the user's data access/display devices other than unlocking the session.

FTA_SSL.2.2 - Refinement: The TSF shall require the user to re-authenticate prior to unlocking the session.

Application Note: The interactive sessions in FTA_SSL.1 and FTA_SSL.2 are those of the local administrator. Non-administrators only have remote access to the TOE and the requirements for session locking levied on them are specified in FTA_SSL.3.

An issue arises when interactive sessions are provided through a console port on the device. This port may require a terminal emulator that is run through a peripheral computer or terminal server in order to reach the command line. The requirements of FTA_SSL.1 and FTA_SSL.2 can be met by the TOE with the exception of the requirement for "clearing or overwriting display devices, making the current contents unreadable", as that would have to be enforced by the terminal emulator in the environment. How should situations like this be handed, as it is out of the control of the TOE?

Resolution

In environments where FTA_SSL.1 and FTA_SSL.2 must be enforced but the actual terminal device is in the environment (such as might be the case with terminal emulators or remote graphics terminal through an X window server) the TSF must demonstrably make a best effort at clearing or overwriting the screen. Examples of this would include sending standardized clear screen sequences (typically Control-L) or using the appropriate GUI commands to clear the screen. There must also be administrative guidance that makes clear how the emulator or equivalent must be configured so as to not retain information.

Support

It is understood that there may be mechanisms within the IT environment that can capture/retain portions of data through: terminal emulators, screen shots, and remote graphics terminals that are outside the control of the TOE. Therefore, the TSF can only make a best effort to use a clear command or overwrite the screen. If the IT environment does not have the ability to provide a clear or overwrite of the screen, a notation should be made in the Administrative Guide of this inability.

Modification History:

2009-06-01

PD Issued (April/May ODRB Agenda Item 3.a.i)

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0280