PD-0063: What Information Must Be Provided in the TSS Rationale?

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

An ST must contain a TSS and a TSS Rationale. There is no metric either 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)

References:

• CEM v1.0 Part 2 ASE_TSS.1-5, ASE_TSS.1-9

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0186