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

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

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