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

[Alex Ragen <aragen@netvision.net.il>]

Though the goal of this clarification seems straightforward and clear, it
still leaves evaluators/validators with a judgment call: how much detail is
required in the publicly available ST? It's not just a question of balancing
the customer's need to know how something is done with the vendor's need to
keep the details secret from competitors. These details must also be kept
secret from the customers' users, who may be looking for ways around the
TOE's  annoying and inconvenient security mechanisms. 
Why do the details have to be spelled out in the Security Target, where
everyone can see them? Can't at least some of them left for the non-public
HLD and LLD docs? And if so, shouldn't there be clearer guidelines as to
what goes where?
- Alex
===================
Alex Ragen, CISSP, ISSA
alex@alexragen.com
www.alexragen.com
===================
-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Observation
Decisions Review Board
Sent: Thursday, July 27, 2006 5:59 PM
To: Multiple recipients of list
Subject: Re: TSS Level of Detail/PD 0063: What Information Must Be Provided
in the TSS


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)