Each of the components within the FPT_RCV family has dependencies on FPT_TST.1. While it is clearly useful for the TOE to be able to test itself to ensure that it has successfully recovered from an error, it is unclear when it might be possible to argue away this dependency.

CCIMB deliberations also identified the need to provide flexibility in defining TOE capabilities for recovery and self-test in these families.

Interpretation

There is a need for additional flexibility of expression within the FPT_RCV and FPT_TST families. There is no need for a dependency between FPT_RCV and FPT_TST. The components of FPT_RCV and FPT_TST are changed to include additional operations, and additional guidance of the applicability of the dependency from FPT_RCV components to FPT_TST.1 has been provided in Annex J.

The CC v2.1 Part 2 FPT is changed as follows:

The dependencies of FPT_RCV components on FPT_TST.1 are removed. The following text is appended to para 1235 of CC Part 2:

It is likely that the use of one of these families will be required to support the adoption of FPT_RCV. This is to ensure that the TOE will be able to detect when recovery is required.

The following new elements replace those currently existing:

FPT_RCV.1.1 After [assignment: list of failures/service discontinuities] the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.

FPT_RCV.2.1 When automated recovery from [assignment: list of failures/service discontinuities] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.

FPT_RCV.3.1 When automated recovery from [assignment: list of failures/service discontinuities ] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided.

FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions [assignment: conditions under which self-test should occur ]] to demonstrate the correct operation of [selection: [assignment: parts of TSF], the TSF].

FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of [selection: [assignment: parts of TSF data], TSF data].

The following text is added following para 1233 of CC Part 2:

There are different interactions between FPT_RCV and FPT_TST components to be considered when selecting FPT_RCV:

The need for trusted recovery may indicated through the results of TSF self-testing, where the results of the self-tests indicate that the TSF is in an insecure state and return to a secure state or entrance in maintenance mode is required.

A failure, as discussed above, may be identified by an administrator. Either the administrator may perform the actions to return the TOE to a secure state and then invoke TSF self-tests to confirm that the secure state has been achieved. Or, the TSF self-tests may be invoked to complete the recovery process.

A combination of a. and b. above, where the need for trusted recovery is indicated through the results of TSF self-testing, the administrator performs the actions to return the TOE to a secure state and then invokes TSF self-tests to confirm that the secure state has been achieved.

Self tests detect a failure/service discontinuity, then either automated recovery or entrance to a maintenance mode.

The following text is appended to para 1235 of CC Part 2:

It is likely that the use of one of these families will be required to support the adoption of FPT_RCV. This is to ensure that the TOE will be able to detect when recovery is required.

The following text is added following para 1236 of CC Part 2:

Following recovery, it may be necessary to confirm that the secure state has been achieved through self-testing of the TSF. However, if the recovery is performed in a manner such that only a secure state can be achieved, else recovery fails, then the dependency to the FPT_TST.1 TSF self-test component may be argued away.

The following text is added following para 1239 of CC Part 2:

Operations

Assignment:

For FPT_RCV.1.1 the PP/ST author should specify the list of failures or service discontinuities (e.g. power failure, audit storage exhaustion, any failure or discontinuity) following which the TOE will enter a maintenance mode.

The following text is inserted immediately before para 1245:

For FPT_RCV.2.1 the PP/ST author should specify the list of failures or service discontinuities (e.g. power failure, audit storage exhaustion) following which the TOE will need to enter a maintenance mode.

The following text is inserted immediately before para 1251:

For FPT_RCV.3.1 the PP/ST author should specify the list of failures or service discontinuities (e.g. power failure, audit storage exhaustion) following which the TOE will need to enter a maintenance mode.

The following text is appended to para 1300 of CC Part 2:

In FPT_TST.1.1 the PP/ST author should specify whether the self tests are to be carried out to demonstrate the correct operation of the entire TSF, or of only specified parts of TSF.

In FPT_TST.1.2 the PP/ST author should specify whether data integrity is to be verified for all TSF data, or only for selected data.

The following text is appended to para 1301 of CC Part 2:

In FPT_TST.1.1 the PP/ST author should, if selected, specify the list of parts of the TSF that will be subject to TSF self-testing.

In FPT_TST.1.2 the PP/ST author should, if selected, specify the list of TSF data that will be verified for integrity.

Rationale:

Investigation identified a lack of flexibility in these components. It may be the case that only part of the TSF needs to be tested in order to support recovery, in which case the SFR FPT_TST.1 is not met. Rather than restricting the response to this request to just provide the clarification to CC Part 2 Annex J regarding the relationship between FPT_RCV and FPT_TST, the additional issues have been addressed.

CC Part 2 Annex J provides some clarification of the relationship between FPT_RCV and FPT_TST. From this it is clear that FPT_RCV addresses recovery from "generally anticipated system failures", such as power interruptions, hardware failures or failure due to administrator error. Such failures are characterised as being easy to detect, and the emphasis is on how recovery to a secure state is achieved. In FPT_TST the emphasis is placed on testing to check for conformance to the specification of the TSF, searching for those failures that might not otherwise be evident.

It is assumed that the inclusion of a dependency of FPT_RCV on FPT_TST was to ensure that, following a system interruption, the TSF should confirm that it is operating correctly through a suite of tests. This would appear to be a flawed argument, since FPT_RCV does not require this approach. The dependency appears to impose an approach to implementing FPT_RCV, rather than identify a necessary precondition. This is particularly true of FPT_RCV.1, where the TOE need only enter a maintenance mode, and recovery requires manual intervention. The two sets of functionality are in fact separate, and the dependency should be removed.

Additional issues fixed:

FPT_TST requires a complete set of tests to ensure correct operation of the TSF. There is no operation to choose what tests are done. Therefore a situation such as this, where only certain very specific failures need to be checked for, may lead to a burdensome testing requirement if the dependency is to be satisfied. It is also the case that FPT_RCV.1 requires entry to a maintenance mode after any failure or discontinuity The dependency on FPT_TST.1 arises on the grounds that recovery is not possible without detection of a failure state through self-testing. This is true, but it may not demand the thorough testing called up by TST. It could, for example, be accomplished through a simple check for a flag being set. The need is therefore identified for additional flexibility of expression within the FPT_RCV and FPT_TST components.

Previously the list of failures/service discontinuities was not required in both RCV.2.1 and RCV.3.1, as it was viewed that were just the complement of those failures/service discontinuities listed in RCV.2.2 and RCV.3.2. This meant that the complete list of failures/service discontinuities was not explicitly specified anywhere, although all possibilities had to be addressed by the implementation of this requirement. The update now allows for the specification of the specific failures/service discontinuities that are to be considered in the implementation of this requirement, making it clear which events are considered.

It was previously necessary in FPT_RCV.1 for the TSF shall enter a maintenance mode for all failures/service discontinuities. However, this Interpretation has indicated that this is not always the case - that there are (valid) requirements for recovery from a particular subset of failures.