RE: I-0453: TSF And Support Code

["Knoke, Jim" <Jim.Knoke@GetronicsGov.com>]

I we may need a more dynamic assurance requirement on "Trusted but
non-TSF" (TBNT) code. For example, if the TOE is EAL7, it might be
reasonable to expect  TBNT to confirm to higher that EAL2 requirements.
OTOH, if we are looking at test code, I probably wouldn't want ATE_,
ADV_FSP, or ADV_HLD to apply to it at all.

I'd like TBNT code to include code that might invocable by the TSF
during normal operations. Some self-tests and abstract machine tests
could fall into this category, as well as "dumb" library code obtained
from a third-party. It seems to me that the evaluators have to determine
the criticality and danger that a given piece of TBNT code has, and then
apply reasonable assurances.

> -----Original Message-----
> From: NIAP Interpretations Board [mailto:ccevs-nib@nist.gov] 
> Sent: Friday, November 15, 2002 3:55 PM
> To: Multiple recipients of list
> Subject: I-0453: TSF And Support Code
> 
> 
> 
> 
>   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.
> 
> 
> 
>