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

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

On Wed, 17 Jul 2002 05:29:29 -0700, "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

> For those who might be interested in alternate GUIDANCE on this topic,
> consult the Oracle DBMS PP from the UK. It includes FPT_SEP and FPT_RVM and
> specifically excludes the OS from the TOE using assumptions about the
> underlying IT environment. This approach seems reasonable and meaningful and
> does not, practically speaking, limit certain requirements to a very small
> percentage of security-related products.

I haven't looked at that PP, but I don't believe that is alternate
guidance. You say that they specifically use assumptions about the underlying
IT environment (actually, it should be IT security objectives, as assumptions
do not discuss things implemented by IT, but that's a quibble). That goes
along with what we have been saying all along: you need to be specific about
what you were expecting from the environment.

As I read it, the proposed guidance in I-0463 was for the case where FPT_SEP
was a TOE SFR, and there were *no* IT security requirements or assumptions
elsewhere in the PP that addressed FPT_SEP. It was also for the case where
FPT_SEP was a TOE SFR in the PP, and attempts where made in an ST to move
FPT_SEP to the IT environment, yet still attempt to claim compliance with the
PP.

So, the ORACLE DBMS PP is a different case.

> In any case, it is not true that assumptions in a PP or ST address only
> usage and connectivity. Part 1 indicates physical, personnel, and
> connectivity assumptions. Part 3 indicates "The statement of TOE security
> environment shall identify and explain any assumptions about the intended
> usage of the TOE and the environment of use of the TOE." While the
> informative part offers three topics, the normative part offers no such
> restriction or guidance.

There have been many disconnects between Part 1 and Part 3; this is why there
is a proposal to rework ASE. The comment deadline on that is rapidly
approaching. I *STRONGLY* suggest that you, and everyone else reading this,
hop on over to commoncriteria.org, download and review the proposed ASE
supplement, and submit comments on it to the CCIMB. If we have enough eye
looking at the new ASE proposal, perhaps we can make it so this whole notion
of the environment and composability is clear.

That said, the CEM makes it clear that the term "environment of use of the
TOE" refers to physical, personnel, and connectivity, as described in Part
1. Take a look at Paragraph 317 of the CEM. 

> My SUGGESTION is that FPT_SEP be interpreted such that it is more useful,
> such as the UK apparently did. 

First, the situation in the UK, as you described it, is very different than
the situation addressed by I-0463. The UK had a situation where there were
specific statements about what was expected in the environment. I-0463
addresses the situation where there are no such statements. Perhaps that can
be made clearer, and hopefully the NIB will rework I-0463 to do so. Hence, the
contexts are very different.

As for the UK interpreting something: It wasn't an interpretation. In fact, to
my knowledge, the UK has no formal interpretations or guidance process; no
equivalent to what the NIB and ODRB output. They certainly haven't made
anything public or out for public review. 

> If there is some driving need to force
> hardware to be included in TOEs, then some other requirements should be
> invented to dictate certain architecture restrictions.

It is not that there is a driving force to include hardware. I know I would
love it if I could do the application-only PPs. The problem is that most PP
authors are careless, and do not think carefully when they write their
PPs. They pop in SEP as a TOE requirement, and don't put in anything on the
environment. This gets approved because it meets the APE requirements (which
only judge what is written, not what is intended), then then people try to
apply it as intended. The issue comes up, and the schemes can only go by what
was written.

The point of I-0463 was: If FPT_SEP is allocated to the TOE, and there are not
objectives for the IT environment related to FPT_SEP or supporting the
implementation of FPT_SEP, then the hardware most likely must be included in
the TOE. 



>> From Part 3 of the CC:

> 433 "The components of this family ensure that at least one security domain
> is available for the TSF's own execution and that the TSF is protected from
> external interference and tampering (e.g. by modification of TSF code or
> data structures) by untrusted subjects. Satisfying the requirements of this
> family makes the TSF self protecting, meaning that an untrusted subject
> cannot modify or damage the TSF."
> 434 "a) The resources of the TSF's security domain ("protected domain") and
> those of subjects and unconstrained entities external to the domain are
> separated such that the entities external to the protected domain cannot
> observe or modify TSF data or TSF code internal to the protected domain."
> 435 "FPT_SEP.1 TSF domain separation, provides a distinct protected domain
> for the TSF and provides separation between subjects within the TSC."
> "FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution
> that protects it from interference and tampering by untrusted subjects."

> These statements should not be taken to mean that the TSF must actually
> implement the mechanism that provides execution domains.

Wait. The requirement says "The TSF shall maintain". I can't see how this can
be read as anything other than the obligation for the TSF to provide that
service. If it was as you said, then wouldn't it be written "The TSF shall
make use of any external mechanisms provided to maintain"

> Rather, the TOE
> must be architected (including features of its IT environment) to ensure
> that the execution domain of the TSF is distinct from the execution domains
> of untrusted subjects.

If that was the case, then this would be an assurance requirement, written
that the developer must architect the TSF so that... It wasn't written that
way. Sorry, but my training during TCSEC days, working with you in fact,
taught me that I can only go from what was written.

> Hence, an application-type TOE that spawns additional
> processes to embody its subjects might be able to qualify for this claim
> (provided that there are appropriate assumptions, or requirements on the IT
> environment, about process domain restrictions that must be provided by the
> IT environment).

REMEMBER, and I'll say it again: I-0463 was for the case where there are NOT
appropriate objectives for the IT environment. In the presence of such
objectives, the door has been opened to an argument that there is trustable
external support.

> Note that the IT environment is not an untrusted subject
> and is also not an "unconstrained" external entity provided that appropriate
> constraining assumptions have been crafted.

The key words there are: "provided that appropriate constraining assumptions
have been crafted." I'll say it again: I-0463 was discussing the case where
there are no such constraining assumptions.

> Note that this topic is disturbing because 1) it is being strongly suggested
> (by the CCEVS and its reps) that hardware is required when requirements such
> as FPT_SEP are claimed

What has been suggested is that, when FPT_SEP is present as a TOE requirement,
and there are no IT security requirements relating to FPT_SEP, then it is
highly likely that the hardware must be included as part of the TOE. 

What has also been suggested is that if one has a PP that puts FPT_SEP as a
requirement on the TOE, and an ST that attempts to claim compliance while
moving FPT_SEP to the IT environment, said ST is not compliance with the PP.

[In general, for an IT product, hardware is required: otherwise, how could
anything execute. I think you meant to say "is a part of the TOE"; be careful
in your writing. We've all seen where sloppy writing can get us.]

> and 2) the CCEVS is participating in the development
> of PPs for application-type (and other) TOEs and is insisting that FPT_SEP,
> for example, must be included as TOE requirements.

I cannot speak to the CCEVS and development of PPs. Please remember, when I
post as faigin@aero.org, I'm speaking only for myself, based on my
experience. I have not been involved with CCEVS development of PPs other than
OS PPs (many, many years ago). In fact, to my knowledge, CCEVS itself is *not*
developing PPs (they learned their lesson on CAPP and LSPP); it is being done
by other parts of the agency or the government.

> It seems as though CCEVS
> and its reps to not share the same ideas.

Perhaps, as I noted above, it is because they are being done by different
organizations. You've worked at NSA; you know how that goes, and how different
organizations do not necessarily talk well to each other.

> This guidance can only serve to
> render FPT_SEP and any associated PPs to be largely unusable.

I disagree, but I also think we are discussing two different contexts.

Daniel