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

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

On Tue, 16 Jul 2002 10:51:13 -0700, "Arnold, James L. Jr."
<JAMES.L.ARNOLD.JR@saic.com> said: 

>> for posting.  All comments should be posted no later than Monday,
>> August 5, 2002.
>> 

> Has the normal review period been shortened? I had thought the NIB was on a
> quarterly cycle which should allow more time for responses.

The normal review cycle is four to six weeks. The actual NIB meeting is August
14-15, so you do have a few days of grace. August 5 will assure it will get
into the primary package for discussion. 

>> Must hardware be included in a TOE that includes FPT_SEP 
>> as one of the
>> TOE's SFRs?

> As I think I've stated before, it is not clear why FPT_SEP is special in the
> regard. For example, if I have a requirement that only certain operations
> are available before I authenticate (FIA_UAU) - it seems that claim is not
> 100% true unless I ensure there is no possible way to bypass it (e.g., using
> hardware). The normal reason this is not an issue is that we make documented
> assumptions about the TOE and its environment to prevent it.

The particular rationale behind this guidance is that FPT_SEP has been a
common source of this question. Hence, there was felt to be the need for more
formalized guidance. Note that the question is not one of bypass (that's RVM);
it is what system components must work correctly in order for the mechanism to
be assuredly implemented.

As for documented assumptions, those are related to usage (people follow
guidance) or connectivity (there will be no connections made). Other aspects
of the IT environment (such as capabilities) would be specified as IT
environment objectives. 

>> STATEMENT
>> 
>> All TOE Objectives (which map to Security Functional Requirements)
>> must be met by the TSF. It is not acceptable to meet a TOE 
>> Objective
>> by a requirement allocated to the IT environment.
>> 
>> Hence, only if an argument can be made that FPT_SEP is satisfied
>> independent of the hardware would it be acceptable to 
>> exclude hardware
>> from the TOE for which FPT_SEP is a TOE SFR.

> There seems to be a significant assumption regarding what the applicable
> security objectives actually say. It is pretty safe to say that if FPT_SEP
> is a TOE SFR, then the TOE must satisfy it.

Correct. So you are agreeing with the 2nd paragraph you quote above.

> But reference to security
> objectives here and below are not clearly relevant since we don't know what
> those objectives say (e.g., perhaps they say that the TOE must protect
> itself within a limited context).

Note the parenthetical comment "(which map...)". The PP/ST author must present
the argument that the mapping from objective to requirement is complete and
correct. 

>> SPECIFIC INTERPRETATION
>> 
>> No criteria changes required. This guidance is supported by the CEM
>> Work Unit ASE_REQ.1-20 as interpreted by CCIMB-INTERP-0058.

> Again, reference to the interpretation (as characterized by the first
> paragraph of SUPPORT, below) doesn't seem too relevant to the topic at hand.
> The issue is whether FPT_SEP can be satisfied by a TOE without hardware, not
> whether FPT_SEP can satisfy some unknown security objective.

The issue is whether objectives that are allocated to the TOE can be met by
the IT environment. Hardware is an example of this, perhaps the most common
one CCEVS faces, but it also applies to operating systems. The interpretation
is cited because it supports the notion that one cannot take an objective on
the TOE and argue it is partially satisified by the IT environment, which is
something that is commonly done when people attempt to justify excluding the
hardware. 

>> SUPPORT:
>> 
>> CEM Work Unit ASE_REQ.1-20 requires that the security requirements
>> rationale provide a justification that every security objective for
>> the TOE is satisfied by the TOE security requirements. There is no
>> provision for security objectives for the TOE being satisfied by
>> requirements on the IT environment.

> This statement seems to imply a PP conformance issue since both PPs and STs
> can assign security objectives to the IT environment, the TOE, or both. Only
> PP conformance *might* dictate that a given objective cannot move from one
> category to another.

Correct. It really is a PP conformance issue (and you have acknowledged in
other discussion that we have some poor PPs out there, with respect to this
area). One could always write an ST *based on*, but not claiming conformance
to, a PP, and have that ST move some of the requirements to the IT
environment. 

>> Of particular interest is the FPT_SEP requirement. FPT_SEP.1.1 says
>> "The TSF shall maintain a security domain for its own 
>> execution that
>> protects it from interference and tampering by untrusted 
>> subjects". If
>> this requirement is allocated to the application TOE, this 
>> means the
>> application is 100% responsible for providing such protection,
>> completely independent of the behavior of applications on the
>> underlying abstract machine (operating system, hardware). For an
>> operating system TOE, this means the TOE provides the protection
>> independent of the behavior of anything else running on 
>> the hardware.

> This statement is not entirely correct. It is not clear that an application
> could not "maintain" its own security domain in the context of a process
> "implemented" by its underlying IT environment.

It could, but then isn't it dependent on the underlying IT environment
implementing processes correctly? That dependency should be made explicit in
the ST.

> It is also not clear that
> parts of the IT environment are necessarily considered to be "untrusted
> subjects". 

Again, what you are placing as objectives on the IT environment must be
explicit.

> And, this statement completely ignores assumptions about the
> environment that generally MUST be true or all bets are off in the first
> place (e.g., I could assume certain aspects of the IT environment away, such
> as other unknown processes).

Huh?

> The operating system TOE example is only true if other things are allowed to
> run (which of course is usually the case for an OS, but not likely for many
> other types of TOEs).

I think we're actually in agreement here. If your assumptions about the
IT environment are correct and explicit in the PP, then the issue doesn't
arise. If they are not present, and FPT_SEP is a TOE requirement only, then
the argument for excluding hardware becomes much harder. Not impossible, but
harder.

>> Similarly, FPT_SEP.1.2 talks about enforcing separation between the
>> security domains of subjects in the TSC (which is typically
>> interpreted to refer to process address spaces, for operating
>> systems). If this is allocated to the TOE but not the 
>> hardware, this
>> means the TOE must provide the capability independent of 
>> the hardware.

> It should be understood that "security domain" is distinctly different than
> "domain". Only the security portions of subject domains need be separated.

Correct.

> Furthermore, we are dealing with subjects as defined in the context of the
> TOE. Hence, it is possible to exclude entities operating in the IT
> environment. While certain aspects of processes supported by an OS are
> usually relevant in the context of an OS-type TOE, the subjects for a
> firewall application, for example, are entirely outside the context of the
> underlying OS (e.g., networks, connections).

True. Such applications usually have more trouble with FPT_SEP.1.1

> It seems likely that most application type TOEs (e.g., firewalls, VPNs,
> CIMCs, IDSs) should have no difficulty with this aspect of the requirement
> regardless of hardware.

I hesitate to give complete agreement, as it all depends on how subjects are
defined in those applications. I will agree that FPT_SEP.1.1 is the more
likely source of problems than 1.2.

> This doesn't mean that the underlying hardware could
> arbitrarily be replaced, rather assumptions about the support provided by
> the hardware (and perhaps OS) would be necessary to ensure an appropriate IT
> environment. Note that it would be silly to argue that in the case of a
> firewall locked in a room that hardware support is necessary to meet FPT_SEP
> when the security functions of the TOE could operate exactly the same
> whether the application was running on Solaris 8 or PC-DOS.

As was said before, all this guidance is saying is that the "going in"
assumption is that when FPT_SEP is present, the hardware should be in the
TOE. The sponsor always has the ability to attempt to make a sufficient
argument to convince the evaluation team.

> Rather, the
> application is satisfying FPT_SEP by managing itself and associated data
> with only underlying execution support from the IT environment (which should
> be readily assumable), by protecting itself from its subjects at its exposed
> interfaces, and by managing security attributes of its subjects so that
> their "security domains" are appropriately separated.

See my note above. Attempt to make the argument. Be explicit in your
assumptions in the ST, and in your IT environment requirements.

> It seems as though this whole issue may apply ALMOST exclusively to OSs,
> where their is much more reliance on the security features provided by
> hardware.

No. The whole issue, actually, applies to badly written PPs and STs that are
not clear and explicit about what they expect from the IT environment.

>> With respect to hardware being required to meet FPT_SEP: Although with
>> current technology hardware support is always used to achieve domain
>> separation and process separation, the ability to provide such separation
>> through software mechanisms alone is conceivable. However, if hardware is
>> excluded, there must be a clear argument that the hardware in no way
>> contributes to the software's satisfaction of FPT_SEP.

> In the context of an OS, hardware is usually essential to ensure that
> primitives used to implement domains are protected. However, the software
> usually does the majority of the work to ensure that those features are used
> effectively. Hence, in the case of an OS it may be true that either the
> hardware should be included or it should explicitly be made part of the IT
> environment. However, it is not useful to simply punt the FPT_SEP
> requirement to the IT environment since in the context of the IT
> environment, FPT_SEP would require only that the IT environment protect
> itself and separate the security domains of the primitives it makes
> available to the OS. The OS still must claim FPT_SEP to be applied within
> the domain controlled by the TOE in order to really achieve the necessary
> protection. Basically, the problem is that a given requirement might need to
> be satisfied by a combination of TOE and IT environment. Such as the case
> with the symbiotic relationship between and OS and its hardware. This might
> imply that an OS evaluation should require hardware, but I think that is
> wrong. The hardware security features used by OSs are very well defined and
> specifiable and as such I think it is appropriate to allow the TOE to claim
> FPT_SEP even though SOME of that protection is provided by the associated IT
> environment.

Huh? I'm not sure what you are saying, but in any case, the ST must make clear
the allocation of objectives between the IT environment and the TOE. If it is
a function allocated to the TOE, it must be met by the hardware and software
components within TOE. 

> The most important aspect is documenting the claims accurately
> so that the user understands there may be some rather significant
> assumptions being made. I believe it is better to do this than to fail to
> address this important security feature. It is also better to do this than
> to require a developer to try to incorporate components (such as hardware)
> they don't own/control into their TOE. After all, CCEVS is supposed to be
> promoting evaluations rather than creating evaluation deterrents.

Correct. Document the objectives accurately. 

> I disagree with the last statement, there never has to be a clear
> description of how something DOES NOT contribute. Rather, there has to be a
> clear description of how a given SFR is satisfied (in the context described
> in the ST, including assumptions in the ST). Hence, it would be fair to
> describe a feature caveated with the assumption that other applications are
> prevented from running or the hardware doesn't rise up to thwart the TOE
> implemented mechanisms. While it would not be fair to claim FPT_SEP and say
> we just rely on the hardware (or whatever) to perform that service.

This sounds reasonable. 

>> With respect to applications claiming FPT_SEP: In order to do so, one must
>> be able to show that the application provides mechanisms that implement
>> FPT_SEP independent of any operating system support. With current
>> technology, however, operating system support is usually required to
>> achieve FPT_SEP, and hence, FPT_SEP should be allocated to the IT
>> Environment (Operational Environment).

> We at least partially agree. If an application claims FPT_SEP, it also has
> to describe how it  is designed to satisfy it. However, it is not true that
> this must be accomplished without OS support. In the case where the
> application could operate on either DOS or Solaris, the support provided by
> the OS (i.e., basic execution tools, but no security services) should be
> readily acceptable.

And the required support should be explicitly stated as a requirement on the
IT environment.

> Let me reiterate - moving FPT_SEP to the IT environment is generally
> unproductive since the IT environment cannot effectively protect a TOE that
> does not protect itself. If the TOE provides interfaces, it most likely
> should be able to claim FPT_SEP in a meaningful and useful way.

Perhaps what needs to be done is to figure out a component that could be added
to FPT_SEP that would allow this division to be expressed better, as the
current component may indeed be better suited to the OS environment, and our
problems are arising from using an OS-designed component in a different
environment. Suggestions?

Daniel