I-0453: TSF And Support Code

["NIAP Interpretations Board" <ccevs-nib@nist.gov>]

  This transaction consists of a request for interpretation for CCIMB
  consideration.  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 cc-cmt@nist.gov in a form suitable for
  posting.  All comments should be posted no later than Monday, January
  27, 2003.


             CCITSE/CEM  REQUEST FOR INTERPRETATION (PROPOSED)


     _________________________________________________________________

                         I-0453: TSF And Support Code
     _________________________________________________________________

TYPE:                 Request for Interpretation
NUMBER:               I-0453
STATUS:               Ready for External Review

TITLE:                TSF And Support Code
COMMENTS DUE BY:      Monday, January 27, 2003 to cc-cmt@nist.gov

RELATED TO:
     I-0054           Support Code Need Not Meet All Architecture Requirements

ISSUE:

   Given the current wording of the definition of TSF, all support code
   is part of the TSF because it is necessary to meet AMT, TST, etc.
   This, however, implies it is subject to INT, ALC_*, and so on. Is this
   appropriate for integrity tests, self-tests, etc.?

PROPOSED RESOLUTION

   Consideration should be given to creating a new category of code in
   the TOE that is "Trusted Non-TSF"; in other words, it is code present
   in the TOE to meet an SFR, but is not critical to the correct
   operation and enforcement of protection and accountability mechanisms.
   Such code would be subject to the assurance requirements of a
   to-be-specified lower assurance level, perhaps EAL2.

SUPPORT:

   In Part 1, Clause 2, the CC v2.1 defines the TSF as the set of all
   hardware, firmware, and software that must be relied upon for the
   correct enforcement of the TSP. It defines the TSP as the set of rules
   that regulate how assets are managed, protected, and distributed
   within a TOE.

   From this, one can deduce that the TSF is related to those components
   critical to the enforcement of protection and management policies.
   This clearly would apply to SFR from the FIA, FAU, FMT, and FDP
   classes, and likely also from FCS, FPR, and FTA classes, as these deal
   with aspects of protection as well.

   FPT and the Part 3 assurance requirements are a different beast. It is
   clear that, for some, they must work correctly for protection to work
   correctly. The best examples of this are FPT_SEP and FPT_RVM. But what
   about FPT_AMT? Just because I cannot verify the correct operation of
   the underlying abstract machine, doesn't mean that protection isn't
   there. Similar comments would apply to FPT_TST, and much of the
   assurance realm. The common characteristic is that these latter
   measures don't directly provide protection; rather, they provide
   confidence that the protection mechanisms are working.

   As a result, going by definitions alone, one might surmise that these
   "protection confidence" mechanisms are not part of the TSF. The
   problem is that the CC is sloppy in its word usage; at least for
   FPT_AMT and FPT_TST, the elements state "The TSF shall provide". How
   can something be both TSF and non-TSF?

   Complicating the matter is that the CC does not provide a term for
   such code (i.e., code that is non-TSF, but part of the TOE, and is
   providing a security function explicitly called out by a CC component
   (just not directly protection related).

   In the days of the TCSEC, such code was called "Maintenance" or
   "Support" code. It was explicitly limited to code that could not be
   invoked as part of the operational TCB; for example:


     * Initialization code, whose task is to bring a system to a secure
       initial state, configures available peripherals and initializes
       TCB data structures.

     * System integrity test code that is unavailable once the TCB is
       operational. Such code might be available only in a restricted
       maintenance mode.

     * Code supporting trusted recovery, if it is available only in
       maintenance mode.

     * Code supporting installation and TCB generation, if it is
       unavailable once the system is operational.

   TCSEC Interpretation I-0054 stated that such code had to meet the
   following requirements:

    1. It must be non-invocable through TCB interfaces, and must not be
       invoked by the TCB, once the TCB has reached secure state.
    2. Such code must be protected from external interference or
       tampering (e.g., by modification of code or data structures).
    3. The interfaces and elements categorized as support code needed to
       be identified at a level appropriate for the digraph.

   It appears that such a category of code might be appropriate for the
   CC; that is, code that is not invokable as part of the normal
   operational activity of the TSF.