RE: I-0434: Treatment Of TSF Components Provided By A Third-Party

[Nir Naaman <nir.naaman@metasec.com>]

ON Tuesday, August 26, 2003 NIAP Interpretations Board wrote:

> There are two issues raised by recent posters on this thread.
> 
> 	The NIB emphasizes that "rolling your own CEM" makes a TOE not
>       mutually recognized. Further, such explicit requirements would
>       still have to meet the requirements of APE_SRE/ASE_SRE, and must
>       be justified as appropriate in the face of identified 
>       threats and policies.
> 

I'm still a little confused about what is and is not mutually recognized.
(As an example of how VERY confused I am, I was amazed to see
 the CyberGuard Firewall for UnixWare 5.1 listed on the NIAP
 validated products list, with a note that AMA was done under the
 UK Scheme. Is AMA mutually recognized?)

It seems to me that you can always ADD assurance requirements,
e.g. for EAL 3 you could specify AVA_VLA.3 for a part of the TOE
and the TOE would still be mutually recognized to EAL 3.
Wouldn't it?

> *	Tom Benkart and Gary Stoneburner discussed the notion 
> of what Gary
>       called a "capability PP". The NIB notes that although such a
>       construct is potentially useful, it just doesn't fit within the
>       CC paradigm (in the same way that processes that are based on
>       Risk Acceptance don't fit well within the CC paradigm, although
>       they can be adjusted in advance through the correct selection of
>       threats). 
> 
> 	The thought that the CC does not capture is 
> "specification instead of
>       requirement".  In many cases, a requirement set is used as a
>       specification that can be negotiated during the design and
>       implementation  with "too hard or costly to do" perhaps becoming
>       an accepted risk. The CC has no  provision for threats moving
>       from one category (TOE, environment, accepted) to another over
>       time.
> 
> 	One way to address this problem is to write a 
> specification that is in
>       the style of the CC, but isn't a doctrinaire PP. The ST could be
>       compliant with this specification.
> 

Perhaps what Gary is looking for is what the ASE Draft v0.6 Supplement
calls a "security objective package". The idea is that you can define
security problem description pacakges and security objective packages
and publish them independently of any security requirements packages.

Objectives are a concise statement of the intended solution to the
security problem. They don't have to be one-liners, though. The advantage
of using objectives rather than requirements for specifications is that they
are given in informal language, rather than the very restrictive Part 2 and
Part 3 language. Furthermore, an ST author has the choice of drawing
from a given package threats and/or objectives into either the TOE or its
operational or development environments.

      Nir