RE: PD 0126: Administrator-entered Code Used To Meet SFRs

["Trey Henefield" <trey@cceval.com>]

I believe we are all making similar points. However, I would just like to
add the following concerning the proposed scenario: 

In such a case where the implementation representation is delivered in the
form of a printed manual, the delivery requirements (ADO_DEL or ALC_DEL &
AGD_PRE) should ensure that the printed manual can be proved to be received
in an unmodified state from that in which it was evaluated.

Upon receiving the printed manual, the secure installation, generation, and
start-up requirements (ADO_IGS or AGD_PRE) should ensure that the
implementation representation is generated, compiled, installed, configured,
and used in accordance with the evaluated configuration. At this point, the
implementation representation is either correctly or incorrectly generated.
Therefore, a secure generation of the implementation representation would
ensure that the implementation representation generated either is or is not
an exact replica of the implementation representation provided in the
printed manual.

After the administrator has confirmed that the implementation representation
generated is an exact replica of that which is provided in the printed
manual, the administrator is expected to compile, install, configure, and
use the TOE in accordance with the evaluated configuration. During this
phase, various compilation, installation, configuration, and usage options
may be chosen depending on the desired platform, environment, and uses
desired by that administrator. This is where a misuse analysis (AVA_MSU or
AGD_PRE & AGD_OPE) provides an added value by ensuring that all possible
options that may be available to an administrator have been analyzed to
ensure that any options that may violate the TSP have been appropriately
identified and documented as warnings to the administrator within the
guidance documentation.

Kind regards,


Trey Henefield
Principal
CC Eval Prep
http://www.cceval.com
(512) 350-2749

-----Original Message-----
From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Arnold, James L.
Jr.
Sent: Thursday, April 06, 2006 11:37 AM
To: Multiple recipients of list
Subject: RE: PD 0126: Administrator-entered Code Used To Meet SFRs



> I agree that no resolution should involve enumerating a specific 
> allowed solution. However, the specific solution I provided was 
> intended to give an example of how such a scenario might be 
> acceptable.

Such examples are useful for discussion, but given the other response I
wanted to head off a resolution that might insist on some specific mechanism
or a mechanism at all where the situation might not warrant one.

> With regards to misuse analysis, I do not see misuse analysis to be a 
> focal point for the generation of the implementation representation. 
> Rather, it is more a concern of satisfying ADO_IGS for ensuring that 
> the implementation representation is generated exactly as it was 
> intended by the developer. In such case, verifying the integrity of 
> the source code generated will satisfy such requirement by ensuring 
> that the implementation representation is an exact replica of what was 
> intended by the developer.

While agree that ADO_IGS is about providing adequate instructions to bring
the TOE into its proper configuration, I think this issue really is a misuse
analysis. However, the answer may actually lie somewhere in between. When
guidance provides all the instructions necessary to result in a proper
configuration, ADO_IGS is satisfied. Hence, instructing an administrator to
type 100000 binary characters exactly as presented in a file call TOE.exe
would result in a proper configuration if carried out without error, it is
highly unlikely (even with cut and paste) that no error would be made.
AVA_MSU offers that the guidance must be complete, clear and REASONABLE. It
also suggests that 'insecure states' can be detected. 

Reasonableness is somewhat subjective and could serve to mitigate overly
onerous guidance. The potential for insecure states could feed back into the
guidance to insist on additional procedures (e.g., tests, checksums,
etc.) if it is, again likely subjectively, concluded that there is a good
chance of a mistake resulting in an insecure state of some sort.

> I believe that the misuse analysis should focus on the compilation, 
> installation, and configuration activities that are involved after the 
> implementation representation has been generated and verified, as 
> verification of such activities can often be more subjective to 
> immeasurable compliance.

I believe that misuse applies to all user and administrator guidance and the
scope of that guidance depends on a number of variables.
Compilation, for example, is probably a rare topic in user/admin guidance.
Basically, misuse potential begins when the TOE is delivered.