Re: TSFI Determination

["Observation Decisions Review Board" <faigin@aero.org>]

Back in October 2008, there was a brief discussion on this list about
what constitutes a TSFI interface under CCv3.1r2. To refresh your
memory, Jim Arnold started the discussion by noting some potential
inconsistencies: 

  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. 

Mike Boberski thought that Jim's read was very literal, and felt that
for Virus Scanners: 

  [He] would modify figure 20 to make it specific to virus type by:

  1.  Adding a subcomponent to the SRV component (representing the
      subcomponent management interfaces for inputting/generating the
      signagures), and 

  2.  Including this new subcomponent's own Ax and Bx interface groups.

  This new SRV subcomponent would then be akin to the PLG subcomponent
  depicted for the OS, for purposes of identifyint TSFI. 

Nir Naaman also responding, noting that it is important not to take the
CCv3.1 Part 2 SFRs too literally, for it has been shown that Part 2 is
hopelessly inconsistent in its terminology. He did feel that the
question is valid when considered in the abstract: Should SFRs be seen
as applying to TOE call-outs to the IT environment (i.e. non-TSFI)? Nir
noted that: 

  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. :-) 

The ODRB/NIB would like to add its 2c to the discussion, albeit a bit
late. First, we note that identifying interfaces to the TOE is
conceptually easy: draw a line around the TOE components, and any
communication across that line, whether initiated by the TOE or by the
IT environment, is a potential interface. At minimum, these should all
be identified; the extent to which they require further analysis depends
on what their function is: SFR-enforcing, SFR-supporting, or
SFR-non-interfering. Note that this "line" approach does capture what we
call "bottom" interfaces; that is, interfaces to the operational
environment. Even if these don't require extensive analysis, identifying
them is important for future impact analyses. 

Jim's original question related to these bottom interfaces (i.e., the Bx
interfaces), and the extent to which they needed to be examined. Nir's
response  correctly identifies the role of the ACO class, as was noted
in Paragraph 557 in Part 3: "The interfaces labelled Bx represent
interfaces to functionality in the IT Environment. These interfaces are
not TSFI and need only be discussed and analysed when the TOE is being
used in a composite evaluation as part of the activities associated with
the ACO class."  

With respect to evaluations that do not involve formal composition
requirements, the ODRB/NIB feels that these Bx interfaces should at
minimum be identified. Whether further analysis is required depends on
the accessibility of the interface. If access to the interface is truly
internal and unavailable to untrusted users (such as internal system
calls to an OS or authenticated encrypted channels to trusted machines),
the identification should be sufficient. If the interface is available
to anything in the operational environment, consideration should be
given to how the interface can be used to direct TOE behavior, with
appropriate analysis based on that categorization and the EAL or ADV
component levels.