RE: I-0463: Platform Inclusion In A TOE With FPT_SEP

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

First, I find this to be an interesting "interpretation" since it doesn't
actually change any criteria or evaluation methodology. This is only an
"opinion" and as such serves a good example of an interpretation for
interpretations sake. This information more appropriately belongs on the
precedent database, if it actually serves as precedent.

Second, I have commented on this "interpretation" in the past and I still
find the opinion embodied in this interpretation to be short sighted and
perhaps flawed. In particular, this opinion ignores the larger more
important issue.

The larger more important issue is the handling of SFRs that cross the
boundary between the TOE and its environment. This is a very common case, in
fact every PP written to date allows at least some aspects of its SFRs to be
fulfilled by the IT environment. This can readily be found by examining the
assumptions. If there is an assumption that the IT environment provides
physical protection, then the TOE is unable to protect itself or reliably
provide most of its security functions unless the IT environment helps it
out by contributing to the ability to provide those security functions. The
opinion in this interpretation serves to draw one essentially arbitrary
line. However, I think the issue of fulfilling SFRs by a combination of TOE
and IT environment could use some serious attention.

STATEMENT:

I certainly agree that all TOE objectives must be fulfilled by the TOE.
However, to date there are no TOEs that can fulfill those objectives 100% by
themselves (counter to the opinion provided in this interpretation).

1. "The relevant portions of the underlying platform should be included" - I
would agree only if an argument required by item 2 cannot be provided.

2. "An argument should be made that FPT_SEP is satisfied independent of the
relevant portions of the underlying platform" - I believe that relatively
simple or non-security relevant support can be provided by the underlying
platform and that the argument should primarily focus on how the TOE/TSF
fulfills the requirement and not on whether or not support is provided by an
underlying platform. The argument should certainly identify any such support
and would be unacceptable if the primary security relevance is found outside
the TOE.

3. "The FPT_SEP requirement should be refined to be explicit about what the
TOE is providing combined with an explicit specification about what the
environment does" - I agree that it would be good to identify features
required of the TOE and IT environment. However, I'm not sure we are talking
about a legal refinement. Would it actually be acceptable to split a SFR and
apply one part to the TOE and the other to the IT environment? Even if it
is, it is not really clear how the two types of requirements are associated
- in other words, while the entire requirement might be present, the two
pieces might be fulfilled and yet not match or come together into a
meaningful whole.

SUPPORT:

While I agree that the TOE and not the IT environment must fulfill the
security objectives and requirements for the TOE, I do not agree that it is
possible to do so 100% for the majority of the existing SFRs.

I also disagree that the TOE must provide its services independent of
support provided by the IT environment. Rather, I believe that the IT
environment cannot provided the required services, while aspects of the IT
environment could be utilized by the TOE to provide them.

I don't agree that hardware is always used for domain separation. For many
products being evaluated, it seems that the physical disposition of the TOE
actually addresses this. For example, if a firewall is equally security and
provides the same services whether it runs on Windows 2000 with a Pentium 4
or on DOS with an Intel 8086, I'd tend to believe that the hardware is not
relevant to the security of the TOE.

Note that do not believe that the FPT_SEP requirement can meaningfully be
moved to the IT environment in general. There is no clear indication that an
IT environment is cognizant of the concept of security relevant in the scope
of the TOE. This essentially means that while the IT environment might be
able to protect itself, even if it is responsible for FPT_SEP it is not
clear it must be able to provide any protection to the TOE. Take a Pentium 4
- the processor protects itself not using its advertised security features,
but rather by virtue of being a piece of hardware that operates and protects
itself in a piece of silicon. While this would address FPT_SEP for the IT
environment, it doesn't do anything for the OS running on the chip. Even if
one considers that the chip provides tasks and memory segments to allow an
OS to define a domain for its own execution allowing the OS to protect
itself, these features mean nothing unless effectively and correctly used by
the OS. Hence, I think it is the OS that should be required to protect
itself and fulfill the FPT_SEP requirement, while the IT environment is
expected to provide the tools so that it can do so. Note also that if
FPT_SEP is not levied on the TOE, then this relieves the TOE of the
responsibility to protect itself.

In Summary:

The CC fails to address the issue of fulfilling requirements by a
combination of the TOE and its environment. This is a common situation that
has been largely ignored. It is not clear why FPT_SEP is being treated
special in this regard.

The CC fails to associate environment and TOE requirements. Another example
I have seen is in the CIMC PP where the IT environment requires a set of
roles and the TOE makes use of those roles. However, since the TOE doesn't
have a role requirement itself it is not clear whether the TOE must use the
roles provided by the IT environment or whether a new (and different) role
requirement could be instantiated for the TOE.

The combination of this opinion and the PPs (and associated guidance)
offered by the U.S. Government seem to indicate that all TOEs must include
hardware. This is not very practical or reasonable for the myriad of
application developers out there. Perhaps it is the intention of PP authors
to limit candidate TOEs or to develop unused PPs, but I also think that the
opinion in this interpretation is perhaps a little too strict.