There are situations where some form of recovery from a known backup is required, but there is no formal model to argue that the known state is provably secure.

It must be possible to recover to a known previous state, as opposed to one that is provably secure.

To address this interpretation, the following changes are made to CC v2.1, Part 2: (additions marked thusly; deletions marked thusly)

• The following component is added to the FPT_RCV family in Subclause 10.8. This component would be immediately below the current lowest component in the existing FPT_RCV hierarchy:

  FPT_RCV.NIAP-0389-1 Recovery to Known State

  Hierarchical to: No other components.

  FPT_RCV.NIAP-0389-1.1 For [selection: [assignment: list of failures/service discontinuities], "no failures/service discontinuities"], the TSF shall ensure the return of the TOE to a previously known state using automated procedures.

  FPT_RCV.NIAP-0389-1.2 When automated recovery from a failure or service discontinuity is not possible, the TSF shall enter a maintenance mode where the ability to return the TOE to a previously known state is provided.

  Dependencies:

  AGD_ADM.1 Administrator guidance

• In Subclause 10.8, rework the component levellings to make FPT_RCV.2-NIAP-0406 immediately hierarchical to the new component.
• In Clause 10, Figure 10.1, the class decomposition figure is updated to show that component 2-NIAP-0406 is immediately hierarchical to component NIAP-0389-1.
• In Subclause 10.8, add the following after the "Component Levelling" diagram:

  FPT_RCV.NIAP-0389-1 Recovery to a Known State, allows a TOE to only provide mechanisms that involve human intervention to a previously known, but not provably secure, state.

• In Subclause 10.8, FPT_RCV.2-NIAP-0406, change the "Hierarchical To:" as follows:

  Hierarchical To: No other components FPT_RCV.NIAP-0389-1

• In Subclause J.8, add the following after paragraph 1236:

  FPT_RCV.NIAP-0389-1 Recovery to a Known State

  In the hierarchy of the trusted recovery family, recovery that recovers only to a previously known state, as opposed to known secure state, is the least desirable.

  User Application Notes

  This component is intended for use in TOEs that do not require recovery to a known secure state. The requirements of this component reduce the threat of protection compromise resulting from an attended TOE returning to an unknown state after recovery from a failure or other discontinuity.

  Evaluator application notes

  It is acceptable for the functions that are available to an authorised user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised users.

  If "no failures/service discontinuities" is selected for FPT_RCV.NIAP-0389.1, this means that there are no explicitly mandated discontinuities for which automated recovery must be provided. The TOE developer always has the option to provide an automated recovery mechanism for a discontinuity.

  Operations

  Selection:

  If there are no explicit situations for which automated recovery is mandated, "no failures/service discontinuities" should be selected in FPT_RCV.NIAP-0389-1.1. Otherwise, the assignment should be selected to provide the list of failures or other discontinuities for which automated recovery must be possible.

  It is acceptable for a PP author to complete only the selection and leave the assignment open, so as to indicate that the list of discontinuities for which automated recovery is required must be non-empty.

  Assignment:

  For FPT_RCV.NIAP-0389-1.1, the PP/ST author should specify the list of failures or other discontinuities for which automated recovery must be possible.

• In Annex J, Figure J.1, the class decomposition figure is updated to show that component 2-NIAP-0406 is immediately hierarchical to component NIAP-0389-1.

Rationale

The RI problem statement assumes that one needs a formal Security Policy Model (ADV_SPM.3) to define secure states. This is an incorrect assumption: an informal Security Policy Model (ADV_SPM.1) is sufficient to define the secure states of a TOE. The current components in FPT_RCV all have dependencies on ADV_SPM.1, implementing this fact. CC Part 2 para 1236 expands on this by stating that if one can give a rationale why a particular state is secure, a full Security Policy Model is not necessary (and hence the dependency on ADV_SPM.1 can be deleted). 

The suggested FPT_RCV.NIAP-0389-1 Recovery to Known State allows return to a previously known state, which cannot be considered to be a secure state (otherwise the author would use the stronger FPT_RCV.1).

This means that the inclusion of FPT_RCV. NIAP-0389-1 may create vulnerabilities in a TOE, as attackers may use the fact that the TOE returns to a previously known state that they have reason to assume is insecure, as the following example illustrates:

“A TOE stores its state every five minutes and, in the case of failure/service discontinuity, restores its previous state. If an attacker induces a failure in the TOE within five minutes of an authorised user logging, the TOE restores the last stored state, and now thinks that the authorised user is still logged in.”