Re: TSS Level of Detail/PD 0063: What Information Must Be Provided in the TSS

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

For the evaluation of some classes, I consider two categories "Vital" and
"Others" as follows.

1) Vital
SPD is vital, since it is the result of risk analysis.
REQ is vital, since SFRs/SARs express the security measures as well as the
requirements, and they are essential parts of the CC architecture.
HLD is vital, since it expresses the developers design intent.
IMP is vital, since it represents the real implementation of a product.

2) Others
OBJ, TSS and LLD are others, I think, since they are the
construction(by-product) to facilitate the evaluation,
although they provide with some additional methodical layered structure.

My opinion is:
Evaluation should lay more weight on Vital classes for examining the
correctness, completeness, sufficiency and consistensy.
It seems to me that, in some cases, a large effort is spent for the
evaluation of OBJ and
TSS on the appropriateness of the statements and phrasing for the pass
verdict.
Yet, it is grey (at lease to me) what amount of effort evaluators spend
for the analysis on the "real" source code.

Regards,
Hirofumi Yokota


----- Original Message ----- 
From: "YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>
To: <cc-cmt@nist.gov>
Sent: Thursday, August 03, 2006 10:21 AM
Subject: Re: TSS Level of Detail/PD 0063: What Information Must Be Provided
in the TSS


> Hi all,
>
> I recognize the vital importance to analyze the following mappings in the
CC
> evaluation.
>
> 1. Mapping between Threats/OSPs and SFRs/SARs.
> 2. Mapping between SFRs and HLD(design descriptions).
> 3. Mapping between HLD and IMP(source codes)
>
> If analysis were done really with rigour on those mappings, I think, it
> would not necessarily be required to write OBJ, TSS, and LLD for the
> evaluation.
> I mean and suggest, for the future, to remove all those OBJ, TSS and LLD
> from the evaluation, as I see there too much redundancy that is extremely
> hard to keep away.
>
> In respect to the future CC evaluation, I wish it allows more
> straightforward analysis on mappings.
>
> Regards,
> Hirofumi Yokota
>
> ----- Original Message ----- 
> From: "Daniel P. Faigin" <faigin@aero.org>
> To: "Multiple recipients of list" <cc-cmt@nist.gov>
> Sent: Friday, July 28, 2006 9:46 PM
> Subject: RE: TSS Level of Detail/PD 0063: What Information Must Be
Provided
> in the TSS
>
>
> >
> > On Fri, 28 Jul 2006 01:42:25 -0400 (EDT), Alex Ragen
> <aragen@netvision.net.il>
> > said:
> >
> > > Though the goal of this clarification seems straightforward and clear,
> it
> > > still leaves evaluators/validators with a judgment call: how much
detail
> is
> > > required in the publicly available ST?
> >
> > It's hard to give a hard and fast answer that applies to all situations.
> It's
> > easy to know what too little is: just regurgitating the SFR. It's easy
to
> know
> > what too much is: spilling the proprietary beans. Describing where the
> correct
> > middle is is difficult.
> >
> > > It's not just a question of balancing
> > > the customer's need to know how something is done with the vendor's
need
> to
> > > keep the details secret from competitors. These details must also be
> kept
> > > secret from the customers' users, who may be looking for ways around
the
> > > TOE's  annoying and inconvenient security mechanisms.
> >
> > I agree the proprietary details shouldn't be spilled, but there is a
> middle
> > ground. Let's look at an operating system. I think we would agree it is
> > insufficient to say that "The TOE has a feature to protect files.". I
> think we
> > would agree it is too much information to say in the ST the layouts of
> ACLs or
> > protection bits, and how these structures are loaded and checked on a
> call. I
> > think the middle ground is something along the lines of: Whenever a file
> is
> > opened, a check is made of the user's identity against an access control
> > list... together with a description of the logical policy of the check.
> >
> > > Why do the details have to be spelled out in the Security Target,
where
> > > everyone can see them? Can't at least some of them left for the
> non-public
> > > HLD and LLD docs? And if so, shouldn't there be clearer guidelines as
to
> > > what goes where?
> >
> > All the details don't have to be spelled out. What is needed is one or
two
> > lines of a very-high-level implementation summary. The proprietary
> specifics
> > are in the HLD and LLD.
> >
> > Daniel
> >
> >
>

smime.p7s