I-0453: TSF And Support Code
- Subject: I-0453: TSF And Support Code
- From: "NIAP Interpretations Board" <email@example.com>
- Date: Fri, 15 Nov 2002 12:35:08 -0800
- Content-description: Mail message body
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
- Reply-to: firstname.lastname@example.org
This transaction consists of a request for interpretation for CCIMB
consideration. It is being posted in accordance with the procedures of
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 email@example.com in a form suitable for
posting. All comments should be posted no later than Monday, January
CCITSE/CEM REQUEST FOR INTERPRETATION (PROPOSED)
I-0453: TSF And Support Code
TYPE: Request for Interpretation
STATUS: Ready for External Review
TITLE: TSF And Support Code
COMMENTS DUE BY: Monday, January 27, 2003 to firstname.lastname@example.org
I-0054 Support Code Need Not Meet All Architecture Requirements
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.?
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.
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
* Code supporting trusted recovery, if it is available only in
* 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
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.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com