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

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

On Fri, 21 Jun 2002 08:35:23 -0700, "Knoke, Jim" <Jim.Knoke@getronicsgov.com>
said: 

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

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

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

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

Daniel