Re: TSS Level of Detail/PD 0063: What Information Must Be Provided in the TSS

["Observation Decisions Review Board" <faigin@aero.org>]

The ODRB thanks the discussion participants for their input.  Based on the 
comments received, the PD will be updated to more clearly reflect the role of 
the TSS in the evaluation. 

The following is the updated PD:

Issue

An ST must contain a TSS and a TSS Rationale. There is no metric either in Part 
1 or Part 3 of the CC, nor in the CEM, with respect to the level of detail 
required in a TSS. Specifically, is it acceptable for the TSS and TSS Rationale 
to consist solely of assertions of functionality? For example, suppose the ST 
includes a requirement such as FAU_SAR.2 (no users have access to the audit 
records except those that have explicitly been granted access). Is it 
acceptable for the TSS and TSS Rationale for this section to state "Only 
authorized administrators have any access to the audit log", or must the TSS 
and/or TSS Rationale state how the TOE accomplishes this function at some 
level.  

Resolution

The TSS Rationale must describe the mechanisms provided by the TSF to address 
the TSF's SFRs, as well as a high-level description of how these mechanisms are 
implemented. The description of the mechanisms should be from the perspective 
of the TOE user. The level at which this must be described will necessarily 
vary depending upon the complexity of both the product's functions and its 
implementation of those functions, however it shall be at least as detailed as 
the SFRs.  

Support

CC v2.1 Part 1 Paragraph 217 item a states "The statement of the TOE security 
functions shall cover the IT security functions and shall specify how these 
functions satisfy the TOE security functional requirements". This notion of 
requiring a description of how the functions are satisfied is also captured in 
the proposed ASE requirements in ASE_TSS.1.1C. This makes it clear that the 
intent is to describe the "how".  

It may be the case that previous evaluations have not described the "how". The 
CC v2.1 words make it clear in ASE_TSS.1.1C, .2C and .5C that the TSS must show 
how TSFRs are satisfied. The words in CC v3.0 have further clarified the intent 
of the CC authors when they state: "The objective for the TOE summary 
specification is to provide potential consumers of the TOE with a description 
of how the TOE satisfies all the SFRs. The TOE summary specification should 
provide the general technical mechanisms that the TOE uses for this purpose. 
The level of detail of this description should be enough to enable potential 
consumers to understand the general form and implementation of the TOE."  

>From v2.3 Part 1, Paragraph 235, the objective of the TSS Rationale is to show 
"That the TOE security functions and assurance measures are suitable to meet 
the TOE security requirements." For security functional requirements, the TSS 
rationale must offer insight into "how" the TOE meets the associated 
requirements. Statements, although high level, must contain enough detail to 
provide an overview of the mechanisms being employed by the TOE, as well as a 
summary of their implementation, however this does not need to be at a level 
that would permit their implementation. These must be more than a restatement 
of the security functional requirements. The goal is for the reader of the TSS 
to begin to be able to determine how suitable this product will be for a 
potential installation.  

A few examples should help.  

1. 	A firewall product's ST describes a feature to block ports on a time-of-day 
basis. A single sentence along the lines of "The TOE, for each port with a time-
of-day restriction, using the timestamp supplied from the environment, compares 
the current time with the time-of-arrival of the incoming packet and performs 
the specified action based upon that comparison." would be sufficient.  

	It is instructive to note what is and what is not included in that. Where the 
timestamp comes from is mentioned (internal as opposed to an external source), 
as is what time is used for the network traffic (time of arrival as opposed to 
any timestamp present within the packet). No mention is made of internal TOE 
data structures or if some optimization is made for succeeding packets in the 
same connection stream.  

	The reader will not be able to build an equivalent product from this 
description; yet the reader should be able to gain some insight into the 
robustness and tenability of the product. In the example given, a somewhat 
knowledgeable reader would be able to determine that it would be possible to 
shutoff HTTP access at certain times while leaving email available. If the 
mechanism were not on a port basis but on a network interface the reader would 
probably have second thoughts.  

2.	An operating system claims in its ST to support Access Control Lists. It 
describes their syntax and what objects they apply to. The TSS will need 
probably a paragraph to describe how the TOE maintains the security context for 
those objects. The reader could then form some questions concerning what 
subject incoming net traffic might be associated with.  

3.	An application framework claims in its ST that it performs I&A, yet it runs 
on top of a host operating system which has its own I&A. The TSS will need to 
mention the relationship of those two different mechanisms. The reader can then 
start to worry if procedures would need to be written for both product and OS.  


They must also uniquely identify the documents where information that meets the 
requirements is found. For assurance activities performed by the evaluator, the 
approach and results of the activities should be described in the ETR and 
Validation Report.  

Modification History:

2004-08-12
	Updated effective date to reflect the date the PD was issued. (August 2004 NIB 
6.c.xiv) 
2006-04-05
	Updated interpretation to reflect clarifications discussed from a recent OD on 
the same subject. (March 2006 ODRB 3.a.ii) 
2006-07-24
	Refined PD based on comments to reflect the role of the TSS in the evaluation. 
(July 2006 ODRB 4.d.ii)