RE: low-level design doc questions (what's in the TSF?)

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

Since there are various assurance requirements that seem to only apply to
the TSF, it seems advantageous for the vendor to define the TSF as the
smallest possible set of "modules" that s/he can get away with. The smaller
the TSF, the cheaper and quicker will be the evaluation of my product. So
that's what I want to do.

Specifically, say I have a "trusted" command which allows the administrator
to display the security level of any object.  Some of the code in this
command enables "privileges" and is considered part of the TSF. The TSF is
layered into an inner "kernel" and outer command code. Now say that some of
the TSF command code calls "standard" C language "library" routines which
are well documented in third-party literature and whose code is obtained
from a third-party (and widely used in the industry). These library routines
know nothing about security nor about the architecture and functionality of
the vendor's product. The library code is linked into the command code
layer. The vendor applies the same developmental and run-time "integrity"
protection to the library as to the rest of the TSF code.

The NIB opinion says (I think) that the library routines must be considered
part of the TSF since improper behavior of the library routines could lead
to faulty behavior in the TSF command code. But, to echo some of Mr.
Arnold's comments, is there really going to be assurance added to the TSF by
having the vendor document (EAL4, semiformal at EAL6) the library routines
and analyze the library code for good modularity (EAL5), small and
comprehensible sections (EAL6), and layering (EAL6)? The architectural
analysis at EAL5/6 could of course lead to vendor/product-specific code
changes in the library code. Are the evaluators really going to spend time
verifying the documentation and architectural properties of the library?

Granted, the vendor's high-level design documentation should mention the
library and explain its architectural place and its (lack of) role in
security.

If the vendor claims that certain portions of the TOE software are not part
of the TSF, how do the evaluators verify this claim? As far as I can see,
none of the CC requirements (including ADV_IMP) would require the vendor to
give the evaluators any information about the non-TSF portions of the TOE
(other than some of the "high" documents giving qualitative, brief
descriptions, and the entire TOE being available for testing). [In my
particular case, it would be easy to provide all library source code for the
evaluators to peruse and analyze.]

If the library is statically linked to the trusted commands and is not
provided to customers, I assume that it does not contain any TSF interfaces
and that it would not be subject to testing requirements. However, if it (or
certain modules within it) is considered part of the TSF and it is provided
to customers as part of the evaluated configuration (which would probably
have to be the case if it were dynamically linked to the trusted commands),
does it then constitute a set of TSF interfaces which are subject to testing
requirements?

The CEM paragraph 1410 says that if any part of a subsystem is in the TSF,
then the entire subsystem is in the TSF. So that means that if an functions
in a library are part of the TSF, the entire library is part of the TSF,
right (I'm assuming that the library routines have to be included in some
subsystem and that it wouldn't make sense to partition, on paper only, the
library into multiple subsystems)? And then every function in the library
would be subject to documentation, architecture, and testing requirements.
So it would then behoove the vendor to extract the smallest set of functions
possible from the third-party library and create a product-specific library.
Which may be simple as long as source code is available from the
third-party.

Would it make sense for the TSF to be defined/clarified as the portions of
the TOE which are strongly/strictly/directly TSP-enforcing and for there to
be separate assurance components for applying low-level documentation and
architectural requirements to portions of the TOE which are not directly
TSP-enforcing, but which are relied upon by the TSP-enforcing portions? And
then exclude these new components from EAL5 and below (but of course a PP
would be allowed to specify them explicitly).

> -----Original Message-----
> From: James Arnold [mailto:James.L.Arnold.Jr@saic.com]
> Sent: Friday, February 08, 2002 11:57 AM
> To: Multiple recipients of list
> Subject: Re: Possible request for interpretation: low-level design doc
> questio ns
> 
> 
> 
> Item 3 - .... My concern about the
> definition of TSF stems from the fact that a large number of
> requirements apply to the TSF without regard for the relative
> "security-relevance." Hence, I have come to the opinion that it is
> POSSIBLE that the notion of TSF does not include things that do not
> enforce any TSP. FPT_SEP is usually brought into this 
> discussion because
> it requires the TSF to be protected. However, I believe FPT_SEP is
> concerned about the mechanisms to provide the necessary protection and
> the application of those mechanisms. The fact that some component
> happens to have privilege (of some sort), but is required only to NOT
> negatively impact any of the TSPs really doesn't apply (as TSF) since
> the lack of function isn't really a function and is certainly beyond
> testing and even analysis would provide little if any 
> assurance. Rather,
> it is only important that there is a sense that it actually is benign
> and assurance that it is actually protected (to indirectly protect the
> TSF).
> 
> The second paragraph of the NIB opinion is somewhat unclear. ....
> If, as the NIB suggests, the intent is to identify which 
> modules are TSF
> vs. non-TSF, the requirement is all but useless since in general it
> would be a mistake to include non-TSF stuff in an evaluation 
> if cost is
> important.
> 
> Original question:
> 
> "Some questions on the Low Level Design documentation requirements
> (ADV_LLD) at EAL 6 and below:
> 
>...
> 3) Can a function be in the TSF if it is not TSP-enforcing? If so, how
> does one determine what is in the TSF?
> 
> NIAP Interpretations Board wrote:
> 
> > "...
> >
> > While the CC is silent on these issues, the NIB offers the 
> following opinion
> >...
> >
> > 3)  The definition of "TSF" is anything that is relied upon 
> to provide
> >     security. This includes not only the portions of the TOE that
> >     actively implement the security policies, but also anything
> >     whose only role in security policy is that they must operate
> >     correctly (because, for example, they are used by the portions
> >     that actively implement security). That is, if the code 
> in question
> >     can be replaced with code that doesn't work, and yet 
> the security
> >     is still implemented, then the code in question is not 
> part of the
> >     TSF.
> >
> >     The confusion seems to stem from the CC wording of
> >     ADV_LLD.1.10C, which required that the TOE be separated into
> >     TSP_enforcing and non-TSP enforcing portions. The intent
> >     should have been either that the *TSF* is so separated, or that
> >     the TOE is separated into TSF and non-TSF portions. However,
> >     the wording of the CEM v1.0 (section B.6.3) make it clear that
> >     this should be read as separating the TOE into TSF and non-TSF
> >     portions. The NIB will bring this to the attention of the CCIMB.