RE: TSFI Determination

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

On Thursday, October 9, 2008, Arnold, James L. Jr. wrote:
> Is there some distinction between 'another trusted IT product' and a
> 'server upon which the TSF depends'? Should FPT_ITI.1, for 
> example, NOT be used when considering a server upon which 
> the TSF depends, for example?

I think it's important not to take the CCv3.1 Part 2 SFRs too literally.
It's been shown that Part 2 is hopelessly inconsistent in its terminology.
CCv3.0 attempted to set it straight but its Part 2 did not make it into
CCv3.1.
(I wonder how this will be handled going forward to CCv4.)

However, the question is certainly valid when considered in the abstract:
Should SFRs be seen as applying to TOE call-outs to the IT environment (i.e.
non-TSFI)?

To take another (simpler) example, suppose we have the following module,
calling out to the OS in the IT environment:

Module.h: void setTime(void);
Module.c: void setTime(void) { globalTimeSetting = time(); }

Even if setTime() is a TSFI, time() is not. It's a call-out.
I would assert that even if FIA_UAU.2 is claimed, it is not reasonable to
require the TSF to successfully authenticate the OS before allowing the
TSF-mediated change to the globalTimeSetting object.

So my answer to the question above is: "no".

Of course, if a user can cause the TSF to receive an incorrect value in
response to its call-out, this should probably be considered as a potential
vulnerability, either in relation to tampering with the TSF or as a
violation of some other SFR (e.g. restriction of management of TSF time).

In the case of the virus scanner example, it seems that if a subject in the
TSF imports a signature update into the TSF without either the TSF or the
environment ensuring its integrity, the TSP may be seen to be violated in
relation to security management SFRs or to architectural assurances.

How should the evaluation team analyze these call-outs given that they're
not described as TSFI?
Obviously, not in the context of ADV_FSP.

The TSFI determination text and figure in CCv3.1r2p3 section A.2.2 were
originally developed in the CCv2 days. Ken Elliott's presentation from the
4th ICCC provides a useful background for the relevant concepts. In CCv2,
call-outs to the IT environment were described in the context of
ADV_HLD.2.5C: "The high-level design shall identify any underlying hardware,
firmware, and/or software required by the TSF with a presentation of the
functions provided by the supporting protection mechanisms implemented in
that hardware, firmware, or software." - my favorite convention was to model
the IT environment as a subsystem and describe its interfaces and behavior
as for a TOE subsystem.

In CCv3, ADV_TDS focuses entirely on the TOE, with no discussion of the
properties of the underlying abstract machine. ADV_ARC doesn't seem to be
too much help either. 

The ACO class seems to be your best bet. My personal opinion is that the
CCv3 treatment of the composition problem was ill-considered, but I guess
we're stuck with it for now. The good news is, if ACO SARs are not included
in the evaluation, you can always find what you're looking or in ADV_IMP.
:-)

Best regards,
    Nir


> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> Arnold, James L. Jr.
> Sent: Thursday, October 09, 2008 8:30 PM
> To: Multiple recipients of list
> Subject: TSFI Determination
> 
> 
> CCv3.1r2p1 (para 93) indicates: TSF interface (TSFI) - a 
> means by which external entities (or subjects in the 
> TOE but outside of the TSF) supply data to the TSF, 
> receive data from the TSF and invoke services from the
> TSF.
> 
> CCv3.1r2p3 (section A.2.2) figure 20 and surrounding text 
> indicates that a TOE might be associated with a server 
> (i.e., providing some service the TSF depends on) in the 
> IT environment. Figure 20 and para 557 are
> explicit that the applicable interface is not a TSFI and need not be
> analyzed or discussed - that will apparently be handled in an ACO
> evaluation.
> 
> CCv3.1r2p2 includes requirements such as FPT_ITI.1 where the TSF shall
> provide a capability to detect modification of transmitted TSF
> data...and to verify integrity of transmitted data 
> (presumably received by the TSF).
> 
> Is there some distinction between 'another trusted IT product' and a
> 'server upon which the TSF depends'? Should FPT_ITI.1, for 
> example, NOT be used when considering a server upon which 
> the TSF depends, for example?
> 
> Consider the case of signature updates for a virus scanner. The TSF
> depends on the corporate virus signature server to deliver regular and
> timely updates in order to be most effective. Presumably, the 
> signatures must be protected in transit (e.g., across the Internet). 
> As such, it appears that a requirement such as FPT_ITI.1 might be 
> appropriate if the TSF were to, for example, verify digital signatures 
> on newly received signatures. 
> 
> However, since the TSF depends on this server, the example 
> presented in CCv3.1r2p3 (para 557) indicates pretty clearly that the
applicable
> interface is not a TSFI and need to be discussed or analyzed. How then
> should an evaluation team determine conformance to FPT_ITI.1? No TSFI,
> no description, perhaps no tests...
> 
> 
>