RE: I-0434: Treatment Of TSF Components Provided By A Third-Party
- Subject: RE: I-0434: Treatment Of TSF Components Provided By A Third-Party
- From: Nir Naaman <firstname.lastname@example.org>
- Date: Tue, 26 Aug 2003 22:24:55 +0200
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=us-ascii
- Importance: Normal
- In-reply-to: <3F4B2004.12558.A1AB0C@localhost>
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.
> * 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
> 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
> 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.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com