PD-0077: Are All Aspects of the TSFI Documented in ADV_FSP.2?

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

Are non-security relevant details (i.e., errors, effects, and exceptions) required to meet FSP.2.3C?

The CC requires the following in ADV_FSP.2.3C:

The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions and error messages.

The CEM presents the following associated work unit and guidance:

ADV_FSP.2-5 The evaluator shall examine the presentation of the TSFI to determine that it adequately and correctly describes the complete behaviour of the TOE at each external interface describing effects, exceptions and error messages.

1379: In order to assess the adequacy and correctness of an interface's presentation, the evaluator uses the functional specification, the TOE summary specification of the ST, and the user and administrator guidance to assess the following factors:

a. All security relevant user input parameters (or a characterisation of those parameters) should be identified. For completeness, parameters outside of direct user control should be identified if they are usable by administrators.

b. Complete security relevant behaviour described in the reviewed guidance should be reflected in the description of semantics in the functional specification. This should include an identification of the behaviour in terms of events and the effect of each event. For example, if an operating system provides a rich file system interface, where it provides a different error code for each reason why a file is not opened upon request, the functional specification should explain that a file is either opened upon request, or else that the request is denied, along with a listing of the reasons why the open request might be denied (e.g. access denied, no such file, file is in use by another user, user is not authorised to open the file after 5pm, etc.). It would be insufficient for the functional specification merely to explain that a file is either opened upon request, or else that an error code is returned. The description of the semantics should include how the security requirements apply to the interface (e.g. whether the use of the interface is an auditable event and, if so, the information that can be recorded).

c. All interfaces are described for all possible modes of operation. If the TSF provides the notion of privilege, the description of the interface should explain how the interface behaves in the presence or absence of privilege.

d. The information contained in the descriptions of the security relevant parameters and syntax of the interface should be consistent across all documentation.

While the CC requirement appears to require all interfaces details (security and non-security relevant), the guidance presented in paragraph of 1379 of the CEM limits the functional specification description to security relevant aspects of an interface.

Resolution

In general, the CC/CEM is ambiguous with regard to the level of documentation that is required for different types of TSFIs.

This resolution relies upon two terms that are not defined in the CC/CEM in an effort to clarify and properly scope the application of the requirements.

• Direct Errors. Direct errors are defined as errors that are directly related to a TSFI. Examples include errors that are the direct result of API calls and parameter-checking for configuration files).

• Indirect Errors. Indirect errors are those errors that are not directly tied to the invocation of a TSFI, but which are reported to the user as a result of processing that occurs in the TSF. Such errors may be related to a TSFI (setting a parameter in a configuration that is error-checked when read, returning an immediate notification) or not (setting a parameter that, in combination with certain system states, generates an error condition that occurs at a later time. An example might be resource exhaustion of a TSF resource due to setting a parameter to too low of a value).

Given these definitions, the resolution is as follows:

All interfaces into the TSF must be accounted for in the documentation that the developer provides to meet the ADV_FSP.2 requirements. This is supported by ADV_FSP.2.5C which states that the "functional specification shall include rationale that the TSF is completely specified."

This will include interfaces that implement the TSP as well as interfaces that must be trusted to behave properly (e.g, when FPT_SEP and FPT_RVM are part of the ST, reference CEM v1.0 para 1377). This notion is further supported by the CC definition of the TSF which states: "[The TSF comprises] all [of the] hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the TSP".

Although all TSFI's must be covered (to include those that are relied upon to behave properly), it is acceptable for the developer evidence to provide information for each interface at differing levels of detail or abstraction. The level of detail required depends on the role the interface plays in implementing the TSP.

For those interfaces through which security mechanisms are manipulated or invoked, security checks are performed, or security effects are observed (i.e., "security relevant" in CEM terminology), the developer documentation must provide complete details of the security relevant effects, exceptions and security relevant direct error messages. For all other effects, exceptions, and direct error messages, the developer documentation must provide sufficient detail so that an evaluator can confirm the determination of non-security-relevance. Developer documentation of indirect errors is not required.

Each one of these interfaces must have an explicit description of the behavior of the interface (e.g., general functions performed, audit record cuts, other predictable security related effects) when the interface is invoked as well as an explicit list of error messages (e.g., codes) of direct errors resulting from security related events that this interface can generate.

For all other interfaces (i.e., "non-security relevant" interfaces), the developer documentation must provide "sufficient detail so that an evaluator can determine whether the interface is security relevant [or not]" (reference CEM v1.0, para 1377). At a minimum this detail must include:

• The name of the interface;
• The purpose of the interface;
• A list of parameters and an associated description of the parameters for the interface

Note that "It only needs to work correctly." is not considered an acceptable justification; the justification must reflect the purpose of the interface with respect to the security functions performed by the TSF.

In responding to CEM work unit 4:ADV_FSP.2-7, the evaluator must examine the description for these interfaces and other documentation provided as part of the developer produced evidence and make a determination whether the interface is security relevant or not. It may be the case that during the course of this analysis some parameters, effects or (direct) error messages may be discovered not to be present in the functional specification. If it is concluded by the evaluator that these effects, (direct) error messages, and parameters are not security relevant, the functional specification need not be updated. The results of all this analysis must be recorded as part of the Evaluation Technical Report which is reviewed by the Validator.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CEM v1.0 Part 2 ADV_FSP.2-5
• CC v2.1 Part 3 ADV_FSP.2.3C

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0192