RE: I-0453: TSF And Support Code

[Nir Naaman <nir.naaman@metasec.com>]

On Saturday, January 31, 2004 Arnold, James L. Jr. wrote:

> > 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.?
> 
> I think the statement "because it is necessary" should 
> actually be "IF it is necessary". There are certainly 
> instances of support code (e.g., used for
> installation) that are not part of the TSF.
> 

I think Jim has identified a fundamental flaw in the proposed RI. The whole
thing is not really necessary. I'll elaborate.

On Monday, January 12, 2004 Daniel P. Faigin wrote:

> If a PP requires something to apply to the entire TOE, then it is not
> compliant. But this is no different than any other case where 
> the TOE doesn't do something the PP requires. 

So as I understand the topic at hand, we're talking about one of three
cases:
1. A PP defines assurance requirements that apply differently to different
parts of the TOE.
2. An ST author that does not claim conformance to a PP, claims AMT, TST,
etc. in the ST but attempts to avoid providing appropriate evidence to
support the general ST assurance claim.
3. An ST that claims conformance to a PP that does NOT require AMT, TST,
etc. adds these requirements ON TOP of the PP security requirements, but
attempts to avoid providing appropriate evidence to support the general PP
assurance claim.

_CASE 1_: Balanced Assurance Argument in PP
This case does not require any changes to the CC.
As Daniel wrote:

> (One could also use explicitly specified assurance 
> requirements that are slight modifications of the 
> current requirements. Don't be afraid of explicit
> requirements where they are appropriate.)
> 
> > Note that Part 3 requirements are not the only issue here. 
> > Is maintenance code subject to SFRs of the FIA and FAU 
> > classes? What about FPT_RVM? The
> > same argument can be made that it is not.
> 
> And the same solution applies: Explicitly specify the 
> narrowing of scope.
> 


_CASE 2_:ST without PP conformance claim
The solution is simple here: don't claim what you can't prove.
This statement requires some explanation. Specifically, I need to show that
nobody is forcing the ST author to make these claims.
I see two reasons why an ST author might feel obligated to include claims he
or she can't substantiate: satisfaction of dependencies, and the
corresponding code being identified as being part of the TSF.

The following SFRs are dependent on FPT_TST/FPT_AMT (similar arguments can
be made for other "support code"):

Dependencies on FPT_TST.1: FPT_RCV.1, FPT_RCV.2, FPT_RCV.3, 
Dependencies on FPT_AMT.1: FPT_TST.1

Part 2 has the following to say about FPT_TST (paragraph 459):
"The requirements of this family are also needed to detect the corruption of
TSF executable code (i.e. TSF software) and TSF data by various failures
that do not necessarily stop the TOE's operation (which would be handled by
other families). These checks must be performed because these failures may
not necessarily be prevented. Such failures can occur either because of
unforeseen failure modes or associated oversights in the design of hardware,
firmware, or software, or because of malicious corruption of the TSF due to
inadequate logical and/or physical protection." 

Clearly, this is not the "support code" that I-0453 is referring to, but
code that is running while the system is operational, and that is critical
to ensuring that the TOE remains in a secure state. 

Simply not claiming FPT_AMT.1 and FPT_TST.1 solves the problem. Of course,
this doesn't mean that the TOE shouldn't perform the tests, it just means
that it doesn't claim to do so in the ST.

>From I-0453:

> TCSEC Interpretation I-0054 stated that "support 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.   

To me, this set of restrictions seems to imply that the "support code" is
non-TSF, assuming we drop the appropriate SFRs. Therefore, most of the ST
assurance requirements need not be applied to this code.


_CASE 3_: ST claiming compliance with PP but adding lower-assurance SFRs
See case #2. In short: don't do it.

-------

I would also note that although we haven't really solved the composition
problem yet, i.e. building a secure system from secure parts without
re-evaluating everything, it seems pretty straightforward to build a
balanced assurance argument, as follows:

For TOE X, write two STs, X1 and X2.
X1 describes X and its operational environment, and defines a set of
security functional requirements f(X1) and security assurance requirements
a(X1).
X2 describes X in its maintenance mode, and defines a set of security
functional requirements f(X2) and security assurance requirements
a(X2)<a(X1).

Now evaluate both X1 and X2. I suspect it would not be more expensive than a
single monolithic evaluation, and it seems to me to be more scalable in
terms of the management of the evaluation process.

    Nir