I-0389: Recovery To A Known State

["Interpretations Working Group" <iwg@gibraltar.ncsc.mil>]

[The following is the ASCII version of the proposal as posted on Gibraltar. A
pretty-printed PDF version is attached.]

  This transaction consists of a proposal for a National Interpretation of
  a Common Criteria document. It is being posted in accordance with the
  procedures of the IWG.

  Comments on this proposal are welcomed and should be posted to this
  transaction chain.  If any party wishes to post a comment anonymously,
  the comment should be mailed to IWG@gibraltar.ncsc.mil in a form
  suitable for posting.  All comments should be posted no later than
  Monday, February 5, 2001.


                 CCITSE/CEM  NIAP INTERPRETATION (PROPOSED)


     _________________________________________________________________

                       I-0389: Recovery To A Known State
     _________________________________________________________________

NUMBER:               I-0389
STATUS:               Ready for External Review
TYPE:                 NIAP Interpretation

TITLE:                Recovery To A Known State

SOURCE REFERENCE:     CC v2.1 Part 2 Subclause 10.8 FPT_RCV
                      CC v2.1 Part 2 Subclause J.8 FPT_RCV
RELATED TO:
     I-0406           Automated Or Manual Recovery Is Acceptable

ISSUE:

   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.

STATEMENT OF INTERPRETATION:

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

SPECIFIC INTERPRETATION:

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


     * 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.
       _IWG Note: This is operating on the assumption that I-0406 is
       approved before I-0389. If that is not the case, then
       FPT_RCV.2-NIAP-0406 above should be changed to FPT_RCV.1._

     * 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.
       _IWG Note: This assumes that I-0406 has been approved. If this is
       not the case, Figure 10.1 is modified to show that component 1 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: _[DEL:_ No other components _:DEL]_
     _FPT_RCV.NIAP-0389-1_

       _IWG Note: This assumes that I-0406 is approved before I-0389. If
       this is not the case, the above change should be made to FPT_RCV.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
     recovered 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 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.

       _IWG Note: This assumes that I-0406 has been approved. If this is
       not the case, Figure J.1 is modified to show that component 1 is
       immediately hierarchical to component NIAP-0389-1._

PROJECTED IMPACT:

   Negligible impact anticipated.

SUPPORT:

   _Note: This queue entry should not be sent to management until I-0406
   is approved._

   The words in the annex for FPT_RCV state:

     Throughout this family, the phrase "secure state" is used. This
     refers to some state in which the TOE has consistent TSF data and a
     TSF that can correctly enforce the policy. This state may be the
     initial "boot" of a clean system, or it might be some checkpointed
     state. The "secure state" is defined in the TSP model. If the
     developer provided a clear definition of the secure state and the
     reason why it should be considered secure, the dependency from
     FPT_FLS.1 to ADV_SPM.1 can be argued away.

   Although this allows a secure state to be a previously checkpointed
   state, this ability is buried. This component makes it explicit; it
   also makes it clear that a previously known state may or may not be a
   secure state.

   Note: This interpretation is being applied to the CC as modified by
   I-0406.

0389.pdf