PD-0113: Use of Third-party Security Mechanisms in TOE Evaluations

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:	2004-11-22
Last Modified	2006-08-02

Issue

For the evaluation of TOEs that rely upon third-party components, current evaluation practice requires sponsors to choose either (1) including the third-party components within the TOE boundary (in which case all of the details about internals need to be available), or (2) excluding third-party components from the TOE boundary (in which case all of the SFRs in which these components played a role must be excluded from the TOE claims).

Although interface specifications are readily available, details of the internals of third-party components are usually impossible to obtain, which makes the first option above unrealistic. The second option, while sound from a technical viewpoint, would result in the exclusion of significant security-relevant functions that are of great interest to potential customers; i.e., it is unlikely that anyone would use the product in the identified evaluated configuration.

Is there any possible middle-ground in this approach?

Resolution

This resolution is intended to address a specific and relatively narrow class of third-party components; specifically those that provide a well-defined function in support of a particular functional requirement and that can have no adverse effect on the rest of the TOE. Typically, such components are external "appliances," such as authentication servers, that connect to the rest of the TOE by a dedicated network hardware connection.

The approach is to treat the component as a module, and substitute testing and configuration assurance for the ADV elements that would be required. In particular, it is not required that internal implementation be provided (from ADV_IMP). That is, a component that fits within the constraints of this decision need never be included in the subset of implementation evidence reviewed by the evaluators. Other EAL4 requirements are satisfied directly, as described below.

In general, this decision is expected to apply to external servers that are connected to the rest of the TOE by a dedicated network interface and that are physically protected within the same security perimeter as the rest of the TOE. As detailed further below, it would not apply to "platforms", such as an operating system used to run an evaluated DBMS. Examples of components that could satisfy these requirements might include a server (and associated authentication tokens) that implements single-use authentication or a server that provides content scanning functions such as virus detection.

Specifically, this decision requires that all of the following constraints be satisfied:

The third-party component must have a well-defined interface and function.

If the interface and function of the component are not well-defined, it cannot be evaluated in this manner. A dedicated server with a well-defined protocol interface can easily satisfy this constraint.
The third-party component's interface must be accessible only by the TSF.

This constraint requires that the component's interface is used - and usable - only by the TSF. That is, no untrusted entity can have direct access to the component. This constraint ensures that inputs to the third-party component are, by definition, well-formed because they are provided by the TSF. If this constraint is not satisfied, residual vulnerabilities in the component could be exposed by ill-formed inputs from untrusted entities. In the dedicated server example, the rest of the TOE must be able to ensure that the server's network connection is not accessible outside the TSF.
The third-party component must be unable to affect operation of any other part of the TOE.

The rest of the TOE must be isolated from the third-party component. That is, no matter how malicious the component might be, it can only affect the particular requirement(s) it is responsible for enforcing. In particular, this means that the rest of the TOE must enforce FPT_SEP and FPT_RVM with respect to the component. This constraint is incompatible with such "platform" components, because (for example), an underlying operating system can affect all parts of a TOE running "on top".
The third-party component must be configured (in accordance with TOE's administrative guidance) so that it is inaccessible to untrusted entities.

This constraint requires that the third-party component not provide its own external interfaces accessible to untrusted entities. Like #2, this constraint is also necessary to minimize the risk of vulnerabilities from untrusted inputs to the component.
The third-party component must support only a single CC functional requirement or narrow group of requirements (except for FPT_SEP or FPT_RVM).

This constraint requires an argument that the functions performed by or supported by the third-party component be sufficiently constrained that the component's role can easily be analyzed and tested. This also ensures that, if the third-party component were to misbehave, only this one (or small set) of SFRs would be affected. The prohibition against FPT_SEP and FPT_RVM is due to the fact that, if the third-party component were to misbehave when providing FPT_SEP or FPT_RVM, then it would be doubtful that any of the other SFRs were being met.
The third-party component's interface and functions must be tested by the sponsor's functional tests.

This constraint is the critical one for the component itself: although the rest of the TOE can be analyzed in accordance with the usual ADV practices, the third-party component cannot, and therefore functional testing is accepted as a substitute. The testing must include testing of both the interfaces and the functions; in particular, for probabilistic functions (e.g., a single-use authentication token, which has a small, but finite, probability of false positives), the testing must show good evidence that the component is delivering an acceptable probability of correct results.
The sponsor must be responsible for showing how the ACM, ADO, and ALC requirements are satisfied for the component.

This constraint addresses other assurance components by requiring that the evaluation sponsor be responsible for satisfying them--but not necessarily performing them directly. For example, the sponsor might identify a specific model or models of the component and take responsibility for ordering the component from its producer, but not physically take possession of it-that is, taking appropriate (typically administrative and procedural) measures to ensure that the correct unit is received by the end customer. Alternatively, the sponsor may choose to use a previously-evaluated product in the evaluated configuration that provides the equivalent or stronger levels of ACM, ADO, and ALC.

Support

The increased popularity of integrating third-party components into evaluated products requires the past all-or-nothing approach to be revisited. However, this new approach is substituting interface specification and testing for analysis of internals; therefore, the conditions that must be met in order for this approach to be used prevents its inappropriate application.

Modification History:

2004-11-22: PD created. (October 2004 ODRB Agenda Item 3.a.iii)
2005-08-16: Modified Item 7 to clarify that a previously evaluated product can also be used, provided it provides the equivalent or stronger levels of ACM, ADO, and ALC. (August 2005 Agenda Item 4.c.i)
2005-11-07: Clarified Item 7 further based on comments received; specifically, added the phrase "in the evaluated configuration". (November 2005 ODRB Agenda Item 4.c.ii)

References:

[1] Application-Layer Firewall Basic Robustness Environment V1.0, June 22, 2000
[2] Traffic-Filter Firewall Protection Profile for Low-Risk Environments, V1.1, April 1999
[3] CyberGuard Firewall/VPN Version 6.1, Security Target, Version 1.0, 23 March 2004
[4] A One-Time Password System, IETF STD0061, N. Haller et. al., February 1998
[5] Sidewinder G2 Firewall Version 6.0 Security Target, Revision Number 00-0937193-G, May 12, 2003
[6] Security Target for Symantec Enterprise Firewall Version 7. For Windows NT, Version 2.0, May 2002, Reference: T426\ST
[7] SECUREWORKS 3.0 Security Target Document Version 1.41, September 2003 Oullim Information Technology Inc.

Related NIs:

None

Related CCIMB-INTERPs:

None

Source OD: 0238