The NIT has published a Technical Decision for FPT_TST_EXT.1.

FPT_TST_EXT.1.1 in CPP_ND_V3.0E has been modified as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection:

• During initial start-up (on power on) to verify the integrity of the TOE firmware and software;

• During start-up (pPrior to providing any cryptographic services) and [selection: at no other time, on-demand, continuously, [assignment: conditions under which self-tests should occur]] to verify correct operation of cryptographic implementation necessary to fulfil the TSF;

• [selection: no other, start-up, on-demand, continuous, at the conditions [assignment: conditions under which self-tests should occur]] self-tests [assignment: describe self-test objective’list an identifier for each self-test that is additional to those identified in the first two bullet points’].

to demonstrate the correct operation of the TSF.: [assignment: list of self-tests run by the TSF] and if failure detected [assignment: describe resulting error state]

Application Note 27

It is expected that self-tests are carried out during initial start-up of the TOE (physical or virtual power on). Other options should only be used if the developer can justify why they are not carried out during initial start-up. It is expected that at least self-tests for verification of the integrity of the TOE firmware and software as well as for the correct operation of cryptographic functions necessary to fulfil the SFRs will be performed. If not, all self-tests are performed during start-up multiple iterations of this SFR are used with the appropriate options selected. In future versions of this cPP the suite of self-tests will be required to contain at least mechanisms for measured boot including self-tests of the components which perform the measurement.For the third bullet point the following restriction applies: If, and only if ‘no other’ is selected in the selection, ‘none’ may be used in the second assignment.

Non-distributed TOEs may internally consist of several components that contribute to enforcing SFRs. Self-testing shall cover all components that contribute to enforcing SFRs and verification of integrity shall cover all software that contributes to enforcing SFRs on all components.

For distributed TOEs all TOE components have to perform self-tests. This does not necessarily mean that each TOE component has to carry out the same self-tests.: the ST describes the applicability of the selection (i.e. when self-tests are run) and the final assignment (i.e. which self-tests are carried out) to each TOE component.

An Application Note is added for FPT_TST_EXT1.2:

For all failed self-tests related to enforcing SFRs as defined in FPT_TST_EXT1.1 the reaction of the TOE to

the failure needs to be specified. On the one hand, FPT_TST_EXT.1.2 allows to model TOEs that react to

all failures of self-tests related to enforcing SFRs the same way be selecting 'all failures' in the first

selection and selection of the corresponding reaction of the two in the second selection. On the other

hand, it allows to model TOEs that react differently to different failures of self-tests to enforcing SFRs by

specifying the list of failures in the first selection and the corresponding reaction of the TOE in the

second selection. In the latter case, it shall be clear which failure of a self-test causes which behavior of

the TOE.

Section 4.1.5. Device Failure is updated as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

4.1.5. Device Failure

Security mechanisms of the Network Device generally build up from roots of trust to more complex sets of mechanisms. Failures could result in a compromise to the security functionality of the device. A Network Device self-testing its security critical components at both start-up and during run-time ensures the reliability of the device’s security functionality.

The TSS activity for FPT_TST_EXT.1 in Section 2.5.3.1, item 187 of CPP_ND_V3.0E-SD is modified as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

The evaluator shall examine the TSS to ensure that it details each of the self-tests that are run by the TSFidentified by the SFR; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. If more than one failure response is listed in FPT_TST_EXT.1.2, the evaluator shall examine the TSS to ensure it clarifies which response is associated with which type of failure.

The Test for FPT_TST_EXT.1 in Section 2.5.3.3, item 193 of CPP_ND_V3.0E-SD is modified as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

The evaluator shall either verify that the self-tests described above are carried out during initial start-up or that the developer has justified any deviation from this.according to the SFR and in agreement with the descriptions in the TSS.

For more information, please see the NIT Decision.