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

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

On Fri, 21 Jun 2002 12:13:33 -0700, "Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.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.

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

First, if you are talking about an OBJECTIVE for the TOE being supposedly
satisfied by an OBJECTIVE on the environment, then you must be talking PP
compliance. [That's the only place you might map objectives to objectives. If
you were doing an ST only, the object would be in one place or the other]

So, lets look at the PP compliance case. If there is an objective on the TOE
in the PP, then, if the PP is valid, there will be TOE requirements that map
to that objective. When we get to validating ASE_PPC, ASE_PPC.1.2C requires us
to identify the IT security requirements statement that satisfy the permitted
operations of the PP. Moving a security requirement that the PP levies on the
TOE to the environment is not a permitted operation; it is neither refinement,
assignment, selection, or iteration.

Now, you may attempt to claim that CCIMB-INTERP-0058 allows this as a
refinement. However, in such a case you would be wrong. CCIMB-INTERP-0058
explicitly says, in the interpretation "With respect to requirements already
identified as applying to the IT environment". In other words, it is
permissible to change "The TOE shall" to "The IT environment shall" only in
those requirements already allocated to the IT environment. It is not
acceptable to take a requirement allocated to the TOE in the PP and MOVE IT to
the IT environment, and claim it is just a refinement.

Why? Look at CCIMB-INTERP-0098. The interpretation there states that "In order
for a change to be a refinement, in lieu of an extension, the change must
satisfy both the following conditions: * a TOE meeting the changed requirement
would also meet the unchanged requirement, as interpreted in the context of a
particular PP or ST;". If you move a requirement from the TOE to the
environment, then a TOE meeting the changed requirement (i.e., where the
requirement is satisfied by the environment) would not meet the unchanged
requirement (where the requirement is satisfied by the TOE).

Oh, you say, but I'm not talking about PP compliance. If that's the case, then
you are talking about something that is stated as an objective on the TOE, and
claiming it is satisfied by a requirement on the IT environment. This will
fail CEM work unit ASE_REQ.1-20, for you could then not provide a
justification that the objective for the TOE is satisfied by a *TOE*
requirement. 


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

Well, I can't speak to the usefulness of the PPs on the NIAP PP list. I do
believe that if one includes FPT_STM as a TOE requirement, then you do bring
the hardware into it, because you must depend on the hardware for the
reliability of the timestamp, in terms of the CPU clock. If you don't want
that dependency, then you must craft explicitly specified requirements that
appropriately divide the functionality between the TOE and the Operational
Environment. 

If a PP author did not intend to bring in the hardware, then they should have
written the PP differently. Evaluation or validation of the PP cannot judge
whether the unwritten intent of the author is satisfied (at list my DWIMmer
hasn't been installed yet).

For an example of doing it right, look at the Smart Card PP. There, they
explicitly did not include STM, because a smart card is dependent on an
external entity for its time signal.

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

The key point is that if you want to exclude hardware or the OS, then you must
be explicit about. You can't have your TOE security functions depending on
some hardware or OS behavior unless you explicity make that proper behaviour
an environmental objective. Having to specify this is a very different
paradigm than we are used to.

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

You'll have assumptions doing the job under the new ASE proposal (and you
SHOULD go out to commoncriteria.org and read it). There, the notion of
specifying the requirements for the Operational Environment goes away; the
lowest level is objectives. 

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

Yup. And thus it is up to the consumer to make the determination whether they
want to place their faith in Operational Environment objectives, or they want
those requirements evaluated. We seem to forget that the CC does not make it
easier for the end consumer. Before, they could rely on the digraph. Now, they
cannot just rely on an EAL2 or EAL3... they MUST MUST MUST read the security
target to see what the actual claims are.

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

Are you sure? Jim, you are an old time evaluator. If you recall, there was an
evaluation that achieved a two state machine through the use of compiler
enforced directives. However, that two state machine had a critical dependency
on the process implementing its virtual address space correctly. If that
wasn't done, they system architecture requirement wouldn't be met. Hence, the
hardware had to be part of the "TSF" (to use a modern term) that provided the
separation. 

So, let's look at your statement: "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 it is NOT part of the TSF, then we
have to be able to say that if it was malicious or misbehaving, then the TSF
would still work correctly. The ONLY way around that is to explicitly state
that the Operational Environment must behave in a certain way. We can then
take the correct behavior as axiomatic and not 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.

No, because the TOE is described as an IT system. No matter what we do, we
cannot levy requirements on users and have the TOE enforce them. 

> I personally believe SEP and RVM are being misused. 

They could very well be. More likely, I think they are misunderstood.

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

We had requirements back in the TCSEC days, under System Architecture, that
required domain separation and address space separation. Are you now claiming
it was never possible to satisfy those requirements, because there is an
environment where molecules can be rearranged?

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

That's not what the CC says. According to the CC, the TOE is responsible to
implement those mechanisms that are ALLOCATED to the TOE. Not just those it is
able to do (implied by "the extent to which 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.

That I agree with. If you are depending on the environment to do something,
you must explicitly state it. You can then attempt to make a convincing
rationale that the overall requirement on the TOE is satisfied given the
environmental requirement. I'd need to see what you wrote to know if I buy it.

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

Your hope would be satisfied ONLY if the ST was written that way. If the ST
only allocated SEP and RVM to the TOE, and said nothing about the environment,
then one would have to assume the environment did not provide any support one
way or the other.

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

Well, first of all, remember that validation does not ensure something is
sensical; it only ensures it meets the construction rules of the CC.

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

I'm sorry. I just don't understand this sentence.

> On the other hand, insisting that any TOE must include its IT
> environment is also wrong.

By definition, a TOE does not include its IT environment. I'm guessing you
meant to say "any TOE must include hardware and software". The answer is: It
doesn't have to. However, if you intend for it not to, then you must be very
careful in how you craft your ST. I think we've had a lot of sloppy ST
crafting going on out there.

Daniel