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

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

I think the issues here are being presented in an over complicated manner.

With regard to TOE and IT environment objectives, you are correct in
assuming I meant corresponding PP TOE security objectives to ST security
objectives for the IT environment. You state that this is not possible
basically because moving a TOE security requirement in the PP to the IT
environment in the ST constitutes some sort of illegal refinement. However,
I think my argument has nothing to do with refinement at all. 

However, the ASE_PCC requirments state essentially that IT security
objectives in the PP must correspond to IT security objectives in the ST and
IT security requirements in the PP must correspond to IT security
requirements in the ST. However, both TOE and IT environment security
objectives are "IT security objectives". Similarly, both TOE and IT
environment security requirements are "IT security requirements". Hence, one
could interpret the requirements such that they do not disallow moving both
security objectives and security requirements back and forth between the TOE
and IT environment.

It is somewhat interesting to note that the CIMC PP explicitly states that
requirements can move from the IT environment to the TOE, but leads one to
believe the reverse is not true. There is certainly nothing in the CC/CEM
requirements themselves that might lead one to believe that this should be
true. Hence, I think if moving in one direction is allowed, it seems moving
in both directions should be allowed.

Note that I do not necessarily believe the position I am arguing is the
right answer, but I am more concerned about the current set of PPs which
effectively require CIMCs and Firewalls to include their underlying OSs and
perhaps H/W because of requirements such as FPT_STM and others. And, as I
previously noted, in at least one case the authors have indicated to me that
was not their intent (note that PP author intentions seem to be a very
important input to the CCEVS when resolving PP related issues). 

Basically, the position that is being pushed is that in most cases there can
be no underlying IT environment when FPT_SEP, FPT_RVM, FPT_STM and perhaps
other requirements are claimed. Since there are no parallel requirements
that might allow such claims with the exclusion of the IT environment, some
TOEs cannot claim that they protect themselves or ensures that their
functions are invoked - even through their own interfaces. Perhaps this was
just a big oversight...but I think that position is simply wrong.


-----Original Message-----
From: Daniel P. Faigin
To: Multiple recipients of list
Sent: 6/21/2002 6:35 PM
Subject: RE: Request for interpretation: treatment of hardware needed by
software product


On Fri, 21 Jun 2002 14:55:33 -0700, "Knoke, Jim"
<Jim.Knoke@getronicsgov.com>
said: 

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

Well, remember I'm speaking for myself here. NIB posts come from a
different
address. However, I think you have captured what I have said.

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

Sounds about right. And I seem to recall some precedents that allow you
to
treat it as a single subsystem (at least at lower EALs), even though
that's
sort of kludgy.

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

Consider it a challenge :-). But you're good at challenges.

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

It's only a problem if they attempt to claim PP compliance. If they make
such
a claim, I expect them to do stuff as written in the PP. If there is no
such
claim, or they use advisory words such as "based on the ... PP", then I
can
make no assumption as to how closely they have followed the PP.

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

Which is why you can't make the claim of PP compliance if you move stuff
to
the environment. That eliminates the unfairness. If it is PP compliant,
you
know they followed the PP as written.

Daniel
P.S.: Note: I head out for a two-week vacation in about 15 minutes, so I
probably won't be doing more long responses. Have fun.

DPF