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

["Daniel P. Faigin" <faigin@solarium.aero.org>]

On Mon, 3 Mar 2003 05:43:02 -0800, "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

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

Which is why it was published as "Guidance", not an interpretation. Look at
the entry closely. Whether something comes as "guidance" or "precedent"
depends on the body that issues it: The CCIMB can only issue precedent
decisions, which are based on ODs. The NIB can issue guidance,
interpretations, and requests for interpretations, to address larger or more
common issues.

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

Did you read this interpretation at all? It basically says that if you are
pushing off something to the environment, be very clear about what is being
pushed off into the environment. In particular, if you are trying to include
SEP and RVM in your TOE, you're going to have to be very careful about
crafting your requirements, because it is difficult to have SEP and RVM in a
TOE, and not have it in the IT environment.

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

So, where does the fault lie (if your statement is indeed true):

1) Badly written STs that specified the environment incorrectly?
2) Badly evaluated STs that missed verifying all objectives were met
   (actually, this is an ST problem of correspondence)?
3) Errors in Validation.

Everything stems from #1: We have written bad STs.

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

That's why the introduction to the statement said "one of the following".

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

I think we are in agreement.

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

Perhaps, and perhaps (given it might be a narrowing of scope) it might be more
accurately considered an explicitly specified requirement. On the other hand,
looking at the TOE as a whole, it might be a form of iteration, where you can
narrow scope as long as you ensure the entire scope is covered. It is up to
the evaluators to confirm this. 

As for not matching or coming together into a meaningful whole: Everything
needs to be consistent with the overall objectives, hence it is up to the
evaluators to verify the mapping is sensical.

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

Actually, it is if one takes a wholistic approach including software,
hardware, and firmware. It becomes difficult when one starts to separate out
hardware and software. I think you are agreeing with the guidance.

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

You're right. And all this interpretation says is that if you depend on the IT
environment for some service, you specify it in the ST.

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

I think that is only true if everything running on that platform is considered
security relevent. If there is other software not related to the firewall
function present, that software could interfere with the firewall, and in such
cases, you are depending on hardware mechanisms to separate that software. 

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

The IT environment might not know it as SEP; it might know it as virtual
address space separation or a ring mechanism.

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

I think we are in agreement: You need to specify what is provided. Don't be
hogtied by the words of SEP: If you need to craft an explicitly specified
requirement to achieve your goal, do it.

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

You are correct that the CC fails to address the composition issue well; the
source criteria before it did a poor job as well.

Why is SEP special? Only because the question comes up so often. It's
certainly true in other areas as well, timestamps being a good example.

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

I think your complaint, dear sir, is with the CC, not the guidance issued.

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

If that is what you believe, then you are misreading it. All this
guidance says is that one must be explicitly in what comes from the
environment, and what is in the TOE, and you can't meet TOE objectives with
the environment. It also says this is easier with a wholistic approach, but
composition is possible if one crafts the STs with care.

(which, alas, most people do not)

Daniel