[Public Interpretations Database]

PD-0117: PP conformance Using an Underlying Evaluated Product

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.

Effective Date: 2005-05-23
Last Modified 2006-08-02

Issue

A TOE under evaluation has components that rely upon an underlying host for partial or complete satisfaction of selected SFRs. This underlying host is an operating system that has been previously evaluated against the same version of the CC, and this underlying host is viewed as part of the TOE and TSF.

If the ETR and the Evaluation Work Packages for the underlying host that would need to be examined for such a TOE (see CCEVS Policy Letter # 2, "Reuse of Previous Evaluation Results and Evidence" and CCRA Management Committee Information Statement 2002-08-009-002 with the same title) are not available to the Evaluation Team, what visibility must the evaluation team for the TOE have into the evaluation evidence from the underlying host's evaluation?

Resolution

To include a previously-evaluated IA product (PEP) as a component of a TOE in a larger evaluation for which that component's ETR and Evaluation Work Packages are not available to the Evaluation Team, the following conditions apply:

  1. The PEP must have been evaluated with the same or greater assurance requirements (i.e., the set of its assurance components must be a superset of those claimed by the TOE).

  2. The PEP must have included one or more of the following: (a) one or more SFRs upon which the TOE has dependencies, and/or (b) one or more SFRs that serve to support one or more SFRs of the TOE.

  3. The PEP cannot have SFRs that are inconsistent with the SFRs of the TOE. For example, use of the access control requirements in one TOE, and the information flow requirements in the other, for the same objects.

    The PEP will, in all probability, have other SFRs that do not fall into either category defined above (dependent or supportive). The evaluator will have to provide rationalization for each of those SFRs that supports one of the following conclusions:

    1. The PEP SFR is the same as an SFR in the TOE.

    2. The PEP SFR has no relationship at all to any SFRs in the TOE.

    3. The PEP SFR is hierarchical to one or more SFRs in the TOE.

    4. The PEP SFR specifies different assignments and/or selections for the same SFR in the TOE but those assignments do not conflict.

    5. The PEP SFR specifies different actions/mechanisms/etc. for the same objects/subjects/resources/etc. as an SFR in the TOE but they do not conflict.

  4. When the TOE purports to use the interfaces to the PEP in an evaluated manner, the evaluation team for the TOE must verify that the interface with the previously evaluated product is used in accordance with the secure usage guidelines in the administrative and/or user guidance for the PEP, which must be available to the evaluation team.

    If the TOE does not use the interfaces to the PEP in an evaluated manner, then additional analysis and testing is required. The analysis should include a complete list of interfaces used, the parameters supplied to those interfaces, and the results expected back. The differences between their use by the TOE and their use by the PEP should be explained. The new or expanded threats due to the unevaluated usage should be listed and how they are addressed must be explained.

  5. The PEP must be the evaluated version, or a version that has been subject to a successful continuity of assurance process for the version being used by the TOE.

  6. Testing of the TOE must ensure that the security functions of the PEP that are used by the TOE are tested. Furthermore they must be tested to the same extent that similar functions were tested during the evaluation of the PEP.

  7. The TOE must contain administrative guidance that describes procedures for configuring the PEP to help secure the TOE. If FPT_SEP is in the set of SFRs of the TOE, then this configuration must protect the TOE from untrusted entities. The items to be protected would include the TOE's code, data, and operations. For example, the PEP might be configured not to permit untrusted users any access to the PEP's interfaces and make the TOE responsible for controlling that access. Analysis needs to be provided to demonstrate that the resulting configuration is sufficient to do this.

  8. The ST, ETR, VR, VPL entry, and certificate for the TOE must reference the applicable Security Target of--and, if applicable, the Assurance Continuity Maintenance Report for--the PEP(s).

 

Support

The rationale for the conditions is as follows:

  1. If the assurance of the PEP is greater-than or equal-to that of the TOE, then the TOE's evaluation team can have confidence that all of the assurance requirements for the TOE will have been met by the PEP without further examination. The PEP can than be treated as a black box, with the focus being on the interfaces utilized by the TOE.

  2. The whole point of this PD is to reuse the evaluation evidence and results of a previous evaluation and that necessarily means reusing the SFRs contained therein. By having the PEP's evaluation include the SFRs that are needed by the TOE, the TOE's evaluation team can have assurance that those SFRs were tested adequately by the previous evaluation team as demonstrated by the Validation Report.

    For example, if the TOE is depending on the PEP for timestamps, the PEP must include FPT_STM.1. Another example: If the ST claims that the TOE meets FAU_STG.1 by storing audit records in a file protected by a PEP's access control mechanism, the PEP must include FDP_ACC/FDP_ACF.

  3. If there are conflicting assignments, selections, actions, mechanisms, objects, subjects, and/or resources mentioned in SFRs contained in the STs of the PEP and the TOE, then these conflicts may indicate the existence of internal inconsistencies in the TOE and the TOE may be implementing a function differently than the PEP is providing it. For example, suppose the TOE depends upon the PEP to store audit records, and the TOE also has a requirement to overwrite the oldest audit record when the audit trail is full. An inconsistency would then exist if the PEP had an SFR requiring that audit records are to be ignored when the audit trail is full.

  4. The user and administrative guidance of the PEP must be available to users of the product, in particular, the sponsor of the TOE. If the interfaces are used as described in this guidance, the evaluation team can have confidence that the interfaces are being used in a manner that was covered by the analysis and testing of the previous evaluation. In the case where the interfaces are not used in such a fashion, not only is the guidance still needed but the evaluators must essentially perform an evaluation of those interfaces in the manner in which they are used by the TOE.

  5. In order for the evidence of the previous evaluation to be usable, it must first be applicable--and it is only applicable if the version being used is what was evaluated. If this is not the case, the sponsor may have to use some mechanism to get the desired version evaluated: encouraging the sponsor to update their evaluated version; funding the original lab to do a "version-update" evaluation; or including an analysis of the differences in the evaluation of the TOE to demonstrate that those differences have no effect upon the TOE.

  6. The testing needs to make sure that the interface between the two TOEs is appropriately exercised. Regardless of all the analysis performed, the composition problem still remains and testing will provide a large portion of the assurance.

  7. All of the evaluator's analysis and testing are useless if the customer doesn't know how to configure the PEP to provide the protections the TOE needs. Amongst other effects this constraint ensures that the PEP cannot be used by an untrusted user to undermine or weaken the TOE.

  8. This constraint makes it clear that the TOE has a previously evaluated component and identifies the applicable evaluation related information about that component.

 

Modification History:

2005-05-23
PD Created
2005-07-19
Removed some confusing acronym usage. Added references. Clarified the wording to make it clear when this PD is applicable, as opposed to Policy Letter #2.

References:

  • CCEVS Policy Letter #2: Reuse of Previous Evaluation Results and Evidence
  • CCEVS Policy Letter #8: Rules for Component Evaluations under CCEVS (Supplement to CCEVS Policy Letter #2)
  • PD-0101: Level of Detail Necessary for Assurance Requirements on Third Party Products
  • PD-0113: Use of Third-Party Security Mechanisms in TOE Evaluations

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0241