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

["Knoke, Jim" <Jim.Knoke@GetronicsGov.com>]

So can I safely restate the NIB opinion as: "If an ST or PP has
requirements against the TOE (as opposed to the environment) which can
not be fully satisfied without some security functionality in hardware
(such as SEP or RVM), then the hardware must (largely due to CEM Work
Unit ASE_REQ.1-20) be included in the TSF"?

And if the hardware as a whole is treated as a subsystem which is part
of the TSF, there will be no abstract machine and the TSF self and
functional tests would include tests of the hardware security features.

Now I just have to figure out to meet all the assurance requirements at
high EAL levels that will apply to the hardware....

The current set of rules for ST/PP construction aside, I was trying to
see why, from a customer perspective, its a problem if a TOE meets some
of the PP requirements against it by deflecting those requirements onto
the environment (especially if it is the abstract machine portion of the
environment).  As Dan says, the customer must read the ST for a product
carefully in any case.  And the customer will be very interested in the
hardware or abstract machine requirements of a product and the
non-security functionality of a product. I guess one reason is that it
would really make PP conformance very mushy since two products could
conform to the same PP, but one could deflect some important security
functionality onto the environment. And vendors would find that unfair
since the one that deflects requirements would be cheaper to build.

> -----Original Message-----
> From: Daniel P. Faigin [mailto:faigin@solarium.aero.org]
> Sent: Friday, June 21, 2002 4:36 PM
> To: Multiple recipients of list
> Subject: RE: Request for interpretation: treatment of 
> hardware needed by
> software product
> 
> 
> 
> 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
> 
>