RE: I-0434: 3rd Party Hardware/Software And Assurance
> The problem is not with the notion of consumers specifying requirements
> and insisting they be met. The problem is a broader problem of
> specifying requirements that are in effect not practical to meet.
The underlying assumption is that the author of a PP has vetted the PP
to ensure that the requirements are practical. Of course, it is
important to note that the APE requirements do not require an evaluator
to check that the requirements are practical, or even make sense --
only that they are consistent and coherent :-)
More importantly, the US Government profiles (supposedly) represent the
needs of the DoD. Those of us that work with the DoD understand (but
the general public does not) that the DoD needs and requirements are
not necessarily *practical*, but are what are felt necessary to ensure
that safety and security of the mission of defending this nation. Thus,
although some particular product may be suitable for a consumer use, or
even in a non-critical government use (Commerce, HUD, etc.), something
stronger might be needed for defense purposes.
> Insisting that a product be evaluated against a PP is worse in the case
> where the only applicable PPs do not match the intended application, but
> must be met because a policy says you have to be evaluated against a PP
> should one happen to exist (regardless of its content).
I'm not trying to say that the US Government PPs are perfect. However,
to say something is *worse* for complying with a PP is just wrong. We
should be endeavoring to make the PPs correct for their intended use
(and suitably strong), not necessarily weakening them to meet the
products commercially available.
I've seen this working on the Web Browser PP. There are functions that
one might want even in a basic secure browser that are not in browsers
today (for example, appropriate sandboxing of all mobile code, not just
Java). Should we weaken the profile simply because the products today
cannot meet it, or should we set the bar based on the threat, and let
those that want to sell to the government meet the bar?
> > As for the how: The CC doesn't specify implementation. Developers are
> > free to choose whatever implementation they want that meets the stated
> > requirements.
> I am including the ability to allow a requirement to be met by the IT
> environment rather than the TOE as part of the HOW. Other examples,
> might include requiring a hardware rather than software solution.
I disagree. If a PP author, for reason of the perceived threat, wants a
particular mechanism to undergo evaluation at the level of effort of a
TOE component, as opposed to an IT environment component, they should
be able to specify it and know that said specification will be
followed. If they want to permit it to be met by the IT environment,
then they can specify IT environment (which can be met by the TOE, if a
developer wants). We shouldn't be second guessing the PP author.
As for requiring a hardware viz. software solution: If a specific
implementation approach is desired by a PP author, they can specify it
via refinement. If there is no refinement, the ST author can choose the
implementation approach (with the exception that if something is
specified as IT environment, it can't be met by a non-IT mechanism,
such as procedures).
> I agree that a PP author could put requirements in the IT environment to
> offer flexibility, but I'm claiming that it is not inaccurate for an ST
> author to claim that they partially fulfill a PP (if it is true).
I have no problem with truthfully claiming that a particular ST meets
some number of requirements of a particular PP, but not all, as long as
it is clear that full compliance is not being claimed, and it is clear
the areas in which the ST is non-compliant. Truth in advertising, and
all that rot.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com