PD-0051: Must Only Security Relevant Error Messages Be Provided In An FSP?

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

The CEM guidance 4:ADV_FSP.2-5 (paragraph 1379), item b, states that as part of the description of the interface the error codes must be described "... along with listing of the reason why the open request might be denied ..." Is it sufficient to specify only those error messages that are deemed by the developer/sponsor to be security relevant, or must all error conditions should be provided so that the evaluator can determine which of the return codes are security relevant?

Resolution

It is the responsibility of the developer/sponsor to provide the evaluator with sufficient information to demonstrate that the design analysis was accomplished. For this case, the developer needs to produce the complete list of error codes and the reasons for each to be issued.

Support

Without sufficient information, the evaluator is in the position of merely accepting the conclusions of the developer/sponsor, with no basis for checking or questioning those conclusions. At this point, it is the developer/sponsor that is performing the evaluation. This is clearly contrary to the notion of independent evaluation.

The notion of "security relevant error returns" is erroneous and misleading. Which error returns are interesting from a security sense is, at least to some extent, a function of policies enforced and threats identified. Mininally, each error return reveals something about the system. Certainly, where mandatory policies are enforced, error returns are a source of covert channels and thus all returns codes are "security relevant." Thus, it is the responsibility of the evaluator to assess the significance of return codes issued by the TOE. Additionally, without a complete description of the interface, to include return codes, the evaluator is unable to either assess the completeness and accuracy of developer testing, or to develop independent evaluator tests.

Modification History:

2004-08-12

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

References:

• CC v2.1

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0083