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

["Observation Decisions Review Board" <faigin@aero.org>]

Based on comments received in private email, the ODRB has further clarified 
item 7 in PD 0113:

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 	2005-11-28

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:

   1.      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.

   2.  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.

   3. 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".

   4.  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.

  5. 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.

   6. 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.

   7. 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)