RE: Request for interpretation: treatment of hardware needed by software product

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

>> I was unable to find the interpretation that TOE functions cannot be
>> allocated to the environment. Can someone point me at it?

>It's in the CEM. 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.

>In other words, if it is a requirement on the environment it must be stated
as
>such. If it is a requirement on the TOE, it can only be met by the TOE.

This assumes that a security objective for the TOE cannot be satisfied by a
security objective for the IT environment. Where would one find that
requirement? 

>> I'm still not clear on why an ST shouldn't be able to allocate portions
>> of security functionality to the IT environment.

>Let's assume we're talking independent of a PP here. The ST certainly can
>allocate portions of security functionality to the IT environment. That
>functionality must then be met by the environment (which does include the
>TOE).

>However, if the ST allocates the functionality explicity to the TOE, then
it
>MUST be met by the TOE.

>Now, when PP compliance comes into play, you can't take an objective that
the
>PP states is to be met by the TOE, and in the ST move that to being met by
the
>environment, IF you want to claim compliance to the PP. The PP author
>explicitly wanted to the TOE to provide that function; the ST author can't
>reallocate it out of the TOE.

If one accepts this statement, there aren't many useful PPs on the NIAP
validated PP list since most of them have TOE requirements that would be
extremely difficult for the TOE to meet. A good example is the FPT_STM
requirement in the context of application type TOEs. I have even consulted
one of the authors of one of the more recent validated PPs who indicated
that they had no intention for the application TOE to provide its own time
stamps, but rather to get time from its hosting OS.  Hmmmm!

>> Even if SEP and RVM are
>> included, couldn't I write statements like the following in my ST:
>> 	- the TOE does not include the underlying hardware
>> 	- the underlying hardware constitutes the abstract machine
>> 	- the hardware must provide software with a means to establish
>> privileged and unprivileged domains
>> 	- the hardware must not allow software executing in unprivileged
>> domains to create, modify, or destroy data or execution flow in another
>> domain
>> 	- the hardware must not allow software executing in unprivileged
>> domains to change the address translation scheme or to expand the set of
>> addressable memory locations
>> 	- the hardware must not allow software executing in unprivileged
>> domains to gain hardware privilege
>> 	- the hardware must not allow software executing in unprivileged
>> domains to directly change the hardware state, except for the values in
>> general-purpose registers and memory locations that are available to the
>> unprivileged domains

>Well, not in that language. You could write statements such as the above as
>objectives for the IT environment, and in the current version of the ST
>structure, then express requirements on the IT environment. The problem is
>that these requirements are not verified by the validator, they must be
>verified by the integrator. Does that result in something less secure? I
guess
>it is up to the consumer.

I agree that the hardware could be excluded from the TOE. Your high level
design would have to clearly document your interface and dependencies. As
for the IT environment, I'm not exactly sure what sort of requirements would
be necessary. SEP and RVM might be good ideas since it would be good if the
hardware protects itself. However, much of your TOE dependency is more
functional (i.e., not specifically related to some SFRs). I think that
assumptions could also do the job.

The point that there is a problem because certain requirements are not
actually subjected to evaluation would be true in every case where there are
requirements on the IT environment.

>> The original NIB opinion said that hardware must be included in the
>> *TOE*. Did they mean TSF? I'm happy with TOE since that might allow less
>> documentation, CM, etc.

>Whether it is in the TSF, as opposed to the TOE, all depends on whether it
>provides security functions. If there is no dependence on the hardware to
>provide security functions, then it is not part of the TSF. 

Of course the definition of "security functions" is not static. Even though
the hardware may be required to behave a particular way in order for
security policies to be enforced doesn't necessarily make it part of the
TSF. If that were true, then all of the assumptions about physical
protection and behavior of users would result in users, administrators,
guards, locks, etc. to be part of the TSF.

I personally believe SEP and RVM are being misused. It is quite simply not
possible for any TOE to fully satisfy SEP or RVM (and many, if not all,
other requirements) because there is always an environment and that
environment might allow the molecules of the TOE to be reassembled such that
the security policy has been violated. This is where scope of control comes
in - the TOE is responsible to implement mechanisms that satisfy
requirements such as SEP and RVM only to the extent that it has control.
Where an environment could allow such a requirement to be violated, it must
be either assumed away or explicit IT environment requirements could be
included to address that issue.

In the case of an application TOE sitting on an OS, I would hope that SEP
and RVM would be applied to the TOE AND the OS (IT environment) and that the
non-IT environment would be addressed by assumption. However, I have seen
cases (in at least one validated PP) where such requirements are allocated
to the IT environment with the expectation that the IT environment will
protect the TOE and enforce its boundaries. However, this does not actually
require that the TOE protect itself and its own interfaces could (within the
requirements) allow the TOE to be compromised. On the other hand, insisting
that any TOE must include its IT environment is also wrong.