[Public Interpretations Database]

PD-0104: Testing All Claimed Platforms


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-04-20
Last Modified 2006-08-02

Issue

Assume a TOE runs on multiple platforms, where each platform is a layered abstract machine such that the TOE has no dependencies on any layer except the uppermost layer. Is it acceptable to select test configurations based solely on variances in the upper most layer of the abstract machine?

Resolution

As discussed in PD-0084, claiming that a TOE runs in multiple IT environments does not require that the TOE be tested with each environment, although this would be acceptable. If the testers wish to limit the scope of testing, they may either:

  1. Include only a subset of specific platform or platforms in the evaluated configuration and conduct the testing effort using those specific platforms; or

  2. Provide a detailed rationale explaining why testing on one platform is equivalent to testing some or all others. For example, the rationale would address why a Java interface will give identical results on all platforms, despite the fact that the interfaces behave differently on different platforms when Java is used.

In both of the above cases, the certificate, VR, and VPL entry will clearly state what was tested. Any platform that is not tested or covered by a rationale is not to be included in the evaluated configuration. Any SFRs that are provided by the platform are not to be credited to the TOE.

Also, the IGS procedures detail the secure installation of the TOE; therefore, if there are settings, configuration options, etc of the platform(s) that will affect the installation of the TOE, they must be included, as would any other part of the environment that affects installation.

Support

It is recognized that risk of missing security critical issues is increased by not testing with each environment with which the ST claims the TOE is compatible. Yet this is symptomatic of the CC paradigm and is addressed by (1) accepting the risk and making it explicit via "truth in advertising" on the CC certificate and care in the presentation of evaluation results or (2) by the ST author changing the definition of the TOE to reduce the risk. It is not be addressed by enlarging the scope of the evaluation activities.

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 Part 3 ATE_COV.1
  • CC v2.1 Part 3 ATE_FUN.1
  • CC v2.1 Part 3 ATE_IND.2
  • CEM v1.0 Part 2 ATE_COV.1
  • CEM v1.0 Part 2 ATE_FUN.1
  • CEM v1.0 Part 2 ATE_IND.2

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0228